Cosmetics

Again, I've been forging through the code to get the attract screens animated. The first one - where the invader replaces the upside-down 'Y' in 'PLAY' - is complete. The second - where the invader shoots the extra 'C' in 'COIN' - is (finally) coded but not debugged.

To give you an idea of how much code is involved just to get these animations done, the Coco3 ROM image is now more than half the size of the arcade ROM! The source file is now just shy of 3,000 lines, though it includes the comments from the Computer Archeology disassembly (for the code that has been ported) plus data. Taking a quick look at the listing though, I'd say I've definitely completed more than half of the code, if not somewhere approaching two-thirds!

Of course that's not to say that half of the code is concerned with attract screen animations. Aside from the expected low-level print/render routines etc, much of the framework needs to be in-place to allow the task scheduler to run - which controls the animations - and also control the alien shot (bomb) which is treated much like an in-game shot. So in theory, once I debug the 2nd attract animation, a lot of the hard work will have been done, and the rest of the port should go relatively smoothly.

An aside: it's funny how you don't notice things until you're developing/debugging... when the alien replaces the 'Y' it's actually 1 pixel too close to 'PLA' and once you are aware of it, it sticks out like a sore thumb!

UPDATE: First of all, I've (finally) fixed the timezone on the blog.

Tonight has been all about debugging the 2nd animation, and I've managed to more-or-less get it working. However it doesn't exit the task when the 'C' has been bombed, so it sits in a loop executing the same task, but doing nothing. At this point I can't find the code that exits the task or, more specifically, I can't find where it would be called from that task. For another day.

One issue that permeates the code is endianity. There's a bunch of tables that store 16-bit values, a lot of which are accessed via both 8-bit and 16-bit operations. And to further complicate matters, a lot of them are initialised from blocks of data in ROM - sometimes multiple blocks depending on game logic. I need to swap the byte order (labels) in the tables (for 16-bit accesses), adjust the ROM values accordingly, and then inspect each code reference to decide whether or not the code also needs to be modified. Note also that some of these data sections in the disassembly are not commented.

And as I've mentioned previously, the dependence on variable addresses is ghastly.

Once I debug this last animation, I'll need to implement a software emulation of the hardware shift register to see accurate graphics, even in the attract screens. Just like Knight Lore, I'll build shift tables in memory, though the layout will be optimised specifically for Space Invaders.