(Action RPG) Version 0.006
Oct. 21st, 2006 07:15 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
owsf2000Not that there's much different between this and version 0.005, it's about all I'm going to pretty it up at this point. All I did was remove a few things here and there that weren't needed and were just messing up the code unnecessarily. I figured it was pointless to go through the display code right now as I'm changing/modifying it with the next goal anyway, which I'm hoping to have done by sunday night. :)
That next goal is going to be the status bar. >_>
This will obviously cause changes to the display kernel, which is why I'm leaving it as is for now. I plan on having several different display kernels written as this thing goes on, but one constant feature of them all will be the player's status bar which I'm going to place at the top of the screen. This way I can just clear collision latches as the status bar finishes up so that any collisions detected at the end of the frame will only be caused by the in-game portion of the creen. At first I was considering putting it at the bottom but then I realized I'd have to save collision latches before the statusbar began, which isn't very efficient. ^^
I've posted a zip containing the source code for version 0.006 as it stands now as well as a binary of it on my Atari Age Blog. Anyone who's seen version 0.005 in action won't notice any difference. Yeah, I know the code isn't super optimized, I also know some of the things I can do to cut down a few bytes of rom space here and there etc. I'll likely change things around as I work on the next version. Was planning on doing that sort of stuff this week but ended up sleeping half of it away. ^_^
That next goal is going to be the status bar. >_>
This will obviously cause changes to the display kernel, which is why I'm leaving it as is for now. I plan on having several different display kernels written as this thing goes on, but one constant feature of them all will be the player's status bar which I'm going to place at the top of the screen. This way I can just clear collision latches as the status bar finishes up so that any collisions detected at the end of the frame will only be caused by the in-game portion of the creen. At first I was considering putting it at the bottom but then I realized I'd have to save collision latches before the statusbar began, which isn't very efficient. ^^
I've posted a zip containing the source code for version 0.006 as it stands now as well as a binary of it on my Atari Age Blog. Anyone who's seen version 0.005 in action won't notice any difference. Yeah, I know the code isn't super optimized, I also know some of the things I can do to cut down a few bytes of rom space here and there etc. I'll likely change things around as I work on the next version. Was planning on doing that sort of stuff this week but ended up sleeping half of it away. ^_^
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-10-21 01:55 pm (UTC)Also, how many registers does the processor have?
no subject
Date: 2006-10-22 03:13 pm (UTC)Without bankswitching technqiues (even for an emulator it matters since the emulator has to replicate the system as perfectly as possible) an Atari 2600 rom can be up to 4k in size. This is a limitation caused by having only 13 address lines on the CPU. The CPU is a 6507 chip, which is for all intents and purposes a 6502 with interrupts disabled and the top 3 address lines cut off. The 6502 (or a later variant of it with a few extra opcodes) is the thing that the NES runs off of, and the Atari 7800 also uses a modified 6502. (6502C iirc, or something like that)
As such, the CPU has an accumulator, the stack pointer, and two index registers (X and Y).
The 2600 also has only 128 bytes of ram total, and the stack shares that ram with program variables. Normally a program starts defining it's variables at the low end, and the Stack utilizes the top and works it's way down. So long as the two never meet, all is good.
With bankswitching, you can increases the size of the rom quite a bit. Common bankswitching techniques that were used back in the day enabled rom sizes of 8k, 16k and 32k. Most early games rarely used more than 4. The later games generally used 16, only a few had bothered with 32k. Additionally Atari had a "super chip" that it could add to the cartridge that would give the programer an extra 128 bytes of ram. (woo!) and it was usable with the bankswitch formats above.
The Krocodile Cartridge I bought from Atari Age a couple years ago supports all those bankswitching formats, plus several others. It also has a unique format that enables a rom size to be as high up as 512k rom + 256k ram. I don't really see anyone bothering to make full use of that format, although it does enable some tricks you otherwise couldn't do.
But I rant when I should be sleeping.