Pages

Wednesday, 20 April 2016

Not winning any coding awards...

I've been forging through all the code that is called as part of the demo and/or attract modes from the main line execution path. The only trouble is, I can't actually test any of it because it's all kicked off by events created in the ISR's which currently don't exist except for a simple countdown timer used for delay loops. But at least I know it assembles.

Along the way I coded the attract mode Easter Egg, which I'd completely forgotten about; if you haven't seen it, it's not very exciting at all. I did read that you can't actually trigger it in MAME due to the manner in which the input controls are sampled - so that's one thing the Coco3 port will have over MAME!

As others have noted before me, I would have to agree that Space Invaders doesn't exactly showcase the highest quality of 8080 coding. For example, some of the logic depends on variables being at particular addresses, so simply changing the .org statement in the .ASM file, or even adding or moving variables around, would actually break the code! The dilemma for me is, do I fix these issues, or faithfully reproduce them? Right now my memory map is purposefully identical right down to the byte level, so it makes no difference. But I still have half a mind to do it properly, even if I document the way it was done originally in the source.

It's pretty obvious the assembler they used was quite primitive - if indeed they used one at all! In fact, it wouldn't surprise me if they didn't use one. There's certainly evidence that at least some of the code was patched, rather than re-assembled, although that could have been done only to negate the need to re-image all of the discrete ROM chips.

Now to the interrupts...

UPDATE: You can add a coin. Just one coin for some reason atm...

3 comments:

  1. IMHO I think you should fix weird issues like having to sit at a particular address and if possible work the changes done by patching into the the source. That makes for a much cleaner source code and will be of more help to anyone looking at it later on. :-)

    ReplyDelete
  2. I will probably implement my 6809 port with these fixes, however some of them are quite subtle. For example, some variables have their MSB set in one piece of code, and their LSB set in another, so it's not always immediately obvious. It's a PITA to be honest.

    Not whether whether you're suggesting I patch the original Z80 source code or not, but it won't be possible at this point anyway because I don't have a Z80 .ASM file. Best to keep the original well, original, and just comment what's going on.

    ReplyDelete
  3. I see. Probably better this way then - and if well documented then it'll be an interesting read anyway. :-)

    ReplyDelete