What a difference a flag makes.

When porting between CPUs, some differences are more subtle than others, and can be the cause of some hard-to-find bugs. A case in point is the routine that determines whether the invaders have reached the side of the screen, and need to drop down and change direction.

[An aside here: the game checks this by examining a scan line of pixels at the left or right edge of the screen; any non-zero pixels means the invaders have hit the edge. Tandy Invaders, written originally for the 4KB TRS-80 Model I, and which I reverse-engineered not too long ago to port to the Microbee, does exactly the same. I recall thinking at the time that it was a funny - if not slightly dodgy - way of doing things. Turns out the Real Deal uses exactly the same method. Oops!]

Back to subtle bugs - the routine that checks the above-mentioned line of pixels explicitly sets the carry flag if a non-zero pixel has been detected. Otherwise it simply returns once the scan line has been checked. It should be noted that each time through the loop, it executes the AND A instruction to test for pixels, which incidentally clears the carry flag.

In my porting, I negate the need to load and subsequently test the video memory byte by simply using TST ,X - a nice little 6809 optimisation - except for the fact that it doesn't affect the carry flag. In fact, none of the instructions in the entire routine affected the carry flag. So I was getting the invaders oscillating one step the the left, then right, as they quickly marched down the screen. Of course the fix was to simply clear the carry at the start of the routine.

Knight Lore had a few routines that used the carry flag to signal various conditions, and I was careful to ensure that the 6809 code did the same. However for some reason I found this particular instance to be more subtle, and hence harder to debug.

So with the invaders marching in the demo now it's time to add the player. But first, there's the minor matter of the game crashing when you coin up and start an actual game...

UPDATE: You can now coin up and start a game; it draws the invaders and they start marching across the screen as they should. The main game (background) loop is running, albeit with a few subroutine calls commented-out as they have yet to be ported. Nothing particularly exciting in there.

Next step is to add the handlers for the missing game objects; first on the list is the player. The player laser base should then appear and be able to move and shoot! That'll be the next blog update.