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)