Island2Live

I am doing this right now (for a little game I am programming which I am going to release later). My toolchain is: Windows PC (Windows 7) Altirra 2.40: Emulator (yes, I know, it's an old version) Notepad++ with the »NppExec«-Plugin: this is my IDE ATasm: Atari-Assembler Works perfect for me. Kind regards, Henrik Fisch

This is MOST interesting. :-) By looking over the defined instruction set I don't see anything important missing. What's missing would be a deeper documentation but that's definitely nitpicking at this point. Oh, one thing: You should set up a little website ... with a donation-button! I would be willing to pay for that!

I am using ca65 from cc65 compiler myself on a project. As far as I can tell what sanny suggested is completely right: You need to put round brackets around the whole expression. So your provided code example <ScreenAdr+(BytesPerLine**0, <ScreenAdr+(BytesPerLine**1, ... will of course result in 16 Bit values. This is intentional and is described in the provided documentation (»ca65 Users Guide«) in chapter 4. »Expressions«. Especially sub-chapters 4.2 »Size of expression result« and 4.5 »Available operators« are of importance. Your code example will evaluate to something like this: 8 Bit + (16 Bit * * 0, 8 Bit + (16 Bit * 8 ) * 1, ... which results in 16 Bit, 16 Bit, ... So you must do what sanny already told: <(ScreenAdr + BytesPerLine * 8 * 0), <(ScreenAdr + BytesPerLine * 8 * 1), ...

Hey Dropcheck, thank you SO MUCH for creating a shell AND (!) putting it online for others to have a look or to just use that (for example for 3D printing). I've just downloaded your design from your website and must say it's a very clever design. Just because you've made a shell where you can one and the same design element as the upper and the lower part of the shell. Not sure how good a PCB will fit ... but it's definitely worth a try! Thank you again (feel yourself hugged please). Professional Molding Regarding professional molding: I think it's overall too expensive. The problem is the form which need to be manufactured by professional plastic molders (because they know from experience how plastic in the form will react when pressed into). It's made from aluminium for lower production charges and $5.000 is the absolute lower charge for this. I think for low production runs the best way would be a 3D printing machine. That's probably the way I will go. Kind regards (and Merry Christmas to all), Henrik Fisch

»Rescue on Fractalus«. Maybe together with »Ballblazer«, »Koronis Rift« and »The Eidolon«. I personally also still like »Necromancer« a lot for it's clever use of various techniques. And of course »Alternate Reality« for it's ability to play a music during disc load operations and it's fine scroling 3D dungeon. And there's also »Capture the Flag«. But the most »mouth opens wide«-effect had RoF on me. Kind regards, Henrik (Island2Live)

Hello baktra, thank you very much to put some light on the control-problem. I probably found a solution WITHOUT changing the way you intended the game to be played. I have vague feeling you are comparing for destinct values when you write this code: ... if (js_left) { long_jump_left(); break; } ... Which probably means: ... if (joystick == left) { long_jump_left(); break; } ... Practically this would mean if the player pushes the joystick diagonal - which is very often the case during hectic gameplay - the program logic does not see a side movement. This would reflect my gaming experience. You can change this behavior by ANDing the input from the joystick with a vuel that masks the specifci direction bit. Like this: ... if (!(joystick & leftbit)) long_jump_left(); break; } ... The NEGATE must be done because on the Atari all bits are set while no direction is pressed. Hope this explains a little.

I appreciate every little new game which comes out for the beloved Atari computer. So thank you very much to the developer of this game. But, well ... in all honest respect to the creator ... I had problems with the movement too. In my case it was not the movement. It was more how the character is supposed to jump. I am not totally sure about the design decision why to push up AND press fire to jump. It was also very frustrating to see just to make just ONE little error and the whole level regenerates. Well, of course, it's a design decision and it's the same story in the good old »Miner 2049er« (which I like a lot). Overall I had problems again and again and again just to get the diamonds in the first row. So after some minutes I gave up on this game.

Out of curiosity I took a look into the documentation of cc65 (v. 2.12.0). While the assembler ca65 does have support for the 65816 the compiler cc65 does not. There is an option named --cpu where you can set the target CPU ... but there is no hint to a 65816.

I've also ordered and payed ... Now an other one is camping in front of his mailbox! Kind regards, Henrik (Island2Live)

I was instantly heading to the website of RPC-Games http://www.rpcgames.com.au/ Sadly there is nothing more than three little text lines in the top menu of the site stating - Atari 8 Bit - MineME [ In development ] But what I've found is a suspended sale of the game »Centron 3D« together with a page containing some (very harsh) rants from and to possible (I don't know) AtariAge forum members. Without wanting to open up old wounds ... but may I ask what's going on there? Sounds like very underage childish behavior. Kind regards, Henrik (Island2Live)

Regarding the »checksum«, it's now getting also interesting for me, because I am also developing a game for cartridge. Can you put some light on this checksum-thing please? Or maybe provide a link where I can further investigate by myself? Kind regards, Henrik (Island2Live)

Because no-one did it so far, I'll do it: Thank you very much for the link and for starting this thread. Very valuable information!

That is a most interesting fact here: You discovered Rescue on Fractalus is not that optimized. We all know the sad story behind the first two LucasArts-games on Atari. They leaked before they had a chance to get released and instantly spread around the world. Now think twice: How much enthusiasm was there on the side of LucasArts games and on the side of the programmers to put EVEN MORE time and money into the development of the game to release them? Hm?

Believe me: It's not. Back in those days I had the »C/65« compiler from OSS ... but since our loved Atari simply lacks the curly brackets { } - which is most important for C-code - it was far from being fun hacking code. C also gains it's readability from indents - tabs or spaces - into the code. The compiler does not need it but the code can get unreadable very fast if your not using that. And with a maximum of 40 characters in a line ... welll ... Beside that modern C-compilers follow the ANSI-standardization. Which means you do not only have the compiler itself but you also have a standard library with many many useful functions at hand ... for example the most important printf(). I am not sure but as far as I recall the C/65 was not compliant to any ANSI standard. And last: The C/65 translates into assembler and not into a direct executable. The compile process was very time consuming and very disc swapping intensive as far as I recall. If you are a programmer and know C ... go on ... it might be fun. But if you are willing to learn C, be yourself your best friend and start with cc65 on PC. Kind regards, Henrik (Island2Live)

Well ... I don't think it is that simple. Moreover I don't want to reinvent the wheel again and again. The original idea was to create a 16 Kbyte cartridge which a) runs on all real hardware (Atari 400/800/600XL/800XL/XE/XEGS) b) runs in emulation on Altirra c) runs on Altirra even with no OS present (HLE/LLE; copyright problems) d) provide an undivided address space across the 16 Kbyte There is still the idea to create a »diagnostic« cartridge but that would mean to care for all the setup of the computer by myself. Again: I want to program a game and not to reinvent the wheel. So up until now - after some more tests - the best solution would be to do the following: a) threat the cartridge as left and right with both init vectors valid ($9FFA-$9FFFF for right and $BFFA-$BFFF for left) b) set right cartridge »PRESENT« ($9FFC) to something other than zero to not let that cart start on an 400/800 or on HLE/LLE c) set left cartridge »INIT« ($BFFE) to a simple »RTS«-instruction; this can be put into $9FFC to not waste a byte e) set left cartridge »PRESENT« ($BFFC) to $00 to let the OS know »here is a cartridge« e) set left cartridge »FLAGS« ($BFFD) to $04 to start the cartridge but not boot DOS f) set left cartridge »START« ($BFFA) to start of the game; this way I can use WARMST the way it is intended to work That would mean to split the address space of the cartridge ... it's not that bad after all, because it's a good training if I am to create a page banked cartridge with more than 16 Kbyte one day. Kind regards, Henrik (Island2Live)

I found an other problem, this time regarding the WARMST flag in zero page ($0008) to distinguish between a cold start (WARMST = 0) or a warm start/reset key press (WARMST != 0). I would love to use this to reset the highscore of the game at power up. When I am ONLY using the init vectors of the cart to start the game, WARMST is not valid, it's always set to zero. But when I am directing the init vector of the cart to an RTS and use the start vectors instead, WARMST is valid. This is the case when using the original OS-B or OS-XL of the machines. Using LLE on Altirra shows a different thing: In this case the WARMST flag is always valid regardless how I initialize the cart. I was close to the point where I about to drop support for the old 400/800, only support XL/XE/XEGS machines and don't care for the whole vector and flag area of the right cartridge ($9FFC - $9FFF). But when using LLE on Altirra with 600XL/800XL it DOES care for the flags in the right cart. Right now I do not see an elegant way how to make a cart run on all real hardware and on Altirra with LLE. It looks like I have to split memory in two 8-KByte parts and take care for the initialization of both carts.

I am still puzzled about the way Cybernoid is creating more colors than usual on the playfield. As far as I understand there are players involved which mix up with the playfield. So far so good. 1st problem: How to mix? How is the player data mixed with the playfield data to form new colors? I know it's possible with ANTIC mode 2, 3 and $F (40 characters and hires graphics), where the color of the player is taken and mixed with the luminance values of the playfield data. But in other ANTIC modes? 2nd problem: Black areas. When mixing player and playfield data the way I described above a problem with »black areas« arise. When using the player in 4x-wide-mode it covers 8 characters (in for example ANTIC mode 4). So one bit of the player can only cover one complete character ... not partly. The color of the player would always shine through in the background. But in Cybernoid you can't see this. I suspect here a very clever method of using the priority register PRIOR. This forces ANTIC to produce black area when the four priority bits 0 - 3 are used non-exclusive.

Hey snicklin, I am reading this thread now since you started it and it gives me lot's and lot's of ideas how to do things. Thank you for that! I've also had a look at RPG from peteym5 which is astoundingly flicker free despite the fact he does not use close luminance values when overlaying the screens in flicker mode. The answer to this is simple: Today we are in the world of relative slow LCDs which helps to blend the two frames. Don't know about plasma TVs and other technologies. But LCDs are slower in reaction time of their pixel than good old CRTs. Have a look at those old »S.A.G.A.« text adventures (the ones with graphics not the text only versions). They also use a flicker method to produce more colors. I recall a visible not very nice flickering on my old Sony TV. It is gone on my Toshiba flatscreen TV and on my PC screen when using Altirra. Just my two cents. Kind regards, Henrik (Island2Live)

@Brian: Thank you very much for this detailed description of the Atari boot process. If I get this right my method 1 (setting $9FFC to a non-zero-value) or the »diagnostic mode« looks most promising. The »diagnostic mode« has an other benefit: Since I have to take care for all those NMI/IRQ-vectors by myself a game could better be translated to an Atari 5200 (which I am not planning to do). @phaeron: In my case »HLE« is nevertheless most welcome. For booting up a cartridge image and handle some OS jumps it's perfect. I've also tried »LLE« (both as OS-B and OS-XL/XE) and they showed the same behavior as »HLE« (boot right cartridge before left cartridge in a 16-KByte ROM-Image). So the way to go would be to create a cart which runs on both systems (old Atari and XL/XE). Good point regarding the flash-cartridges. @Rybags: I am currently doing exactly this: Do not boot, do not »diagnostic mode« and don't return from init. Kind regards, Henrik (Island2Live)

Not exactly ... but the debugger of Altirra took me onto the right track: It reported a »bad instruction at $00FF«. What the ... how could my program jump into the zero page?!? There was only one explanation: The start vector for the »right cartridge« which was set to zeros because my current program does by far not occupy the whole cartridge space by now. So I prepared a 16-Kbyte ROM-image in the way to use two sets of vectors: One for the »right cartridge« at $9FFE which made the screen red and one for the »left cartridge« at $BFFE (the usual one) which made the screen blue. Now, here are my results: Atari 600/800XL, OS-XL: blue Atari 600/800XL, HLE: red Atari 400/800, OS-B: red There is only one conclusion: The OS of the Atari 600/800XL did not initialize the »left cartridge« at all probably because there is no »right cartridge slot« anymore. Same goes with XE/XEGS. But on the Atari 400/800 which has a »right cartridge slot« this one is initialized BEFORE the »left cartridge slot« when a cartridge is present. This is the case with a 16-Kbyte-cartridge. And the HLE of Altirra 2.40 emulates this behavior. So, if you want to make a 16 Kbyte cartridge run on every system, you have to make sure either the »right cartridge present« flag at $9FFC MUST NOT be zero. This forces the OS to not initialize the cartridge at all. Or you have to set the »right cartridge init-vector« at $9FFE to the same value as the »left cartridge init-vector« at $BFFE. This will make all OSs jump to the same start-routine. I may have overlooked something. But the first solution is the more interesting one because with data scattered all over the ROM area of that cartridge you can arrange useful data to this byte without taking special care to set this NOT to zero. It's nevertheless a pain in the a**. Does anyone have any idea how to better solve this? Kind regards, Henrik (Island2Live)

Folks, I am currently having a strange problem when using the Altirra 2.40/HLE kernel. Simply put: The game crashes. Here are my tested configurations (everything Altirra 2.40): Emulation Atari 600XL/800XL, 16 Kbyte, XL-OS: runs Emulation Atari 600XL/800XL, 64 Kbyte, XL-OS: runs Emulation Atari 600XL/800XL, 16 Kbyte, HLE: crash Emulation Atari 600XL/800XL, 64 Kbyte, HLE: crash Moreover I found out that the game also does not run on the emulation of the old hardware: Emulation Atari 400/800, 16 Kbyte, OS-B: crash Emulation Atari 400/800, 48 Kbyte, OS-B: crash My game does not use any fancy RAM-techniques, nor does it use many OS-vectors: CARTINIT: $BFFE CARTRUN: $BFFA SETVBV: $E45C XITVBV: $E462 Looking at SETVBV and XITVBV in HLE reveals code there (many MANY kudos again to Avery Lee for this absolute wonderful piece of software). Of course, my next step would be to install the (as of writing this) newest version »Altirra 2.50«. But I seriously doubt this could be the cause of the problem. An idea would be the start-vector of the cartridge. I am »using« a 16 Kbyte cartridge. Could it be I've overlooked the start vectors for the right cartridge ($9FFA - $9FFF)? Those vectors are currently all initialized to zeros though. Kind regards, Henrik (Island2Live)

My current game is intended to run on Atari 400 & 600XL and it should end on a cart. And I've chosen $3800 as PMBASE. I don't see a benefit to let PMBASE start at $0. The opposite is the case: I am loosing compatibility with DOS if, who knows why, later in the development process I am forced to put the game not on a cartridge but as a file on a floppy instead. But the idea is good.

The 6502 is surely an entry system for interested programmers. But other processors - not the ones you mentioned - have drastically different concepts. For example chips like Motorola »DSP56000« or AMD »AM29000« have separate address spaces for program and data (no self modifying code). The »AM29000« and the older »MIPS« processors have a concept, where a flag is set in an universal register based on a comparison and conditional jumps are made based on those flags. The older »MIPS« ones - not sure about the newest generation - has an »out of order« execution where an instruction directly following a jump is also executed (due to pipeline construction of the processor). Chips like the »DEC 21064« has different jump instructions where you as a programmer has to choose if the jump is most probably taken or not ... this can dramatically increase speed because of not needed pipeline refills. And a processor like the Intel »i860« has a pipeline oriented architecture (much like the »Cray-1« supercomputer), where you as a programmer will only get speed if you have thousands or millions of exactly the same operations on different data. This is to let you get a peek into it's not just »how it's arranged«. But I agree: A processor like the 6502 is a perfect tool to get an insight into how a program works.

Whow! Thank you very much ... this is a perfect solution! Kind regards, Henrik Fisch

Folks, I have a little problem. I am currently developing a game on cartridge. Not sure if it will come out on cartridge but the memory layout is currently planned that way. This game will maintain a highscore ... of course not after power down. But I like to keep the highscore even after tapping the [Reset] button on our Atari. Any ideas? Kind regards, Henrik Fisch