The 6502 can be a BIT weird.

Quick update.

One thing I like about Asteroids is that it's completely deterministic. Each time you turn it on, it will behave in exactly the same way, until you start messing with the controls. Makes it easier to test my ports...

I was looking into why the movement of the first saucer in attract mode was seemingly mirrored on the Coco3 port. With the above-mentioned in mind, it came down to a BIT instruction, followed by a BVS (branch on overflow set) which was branching on the 6502 but not on the 6809. In my haste I (obviously) didn't pay careful enough attention to the descriptions in the 6502 and 6809 Zaks instruction references and decided they operated in the same way, at least as far as the V (overflow) flag was concerned.

Turns out the 6502 transfers bit 6 of the memory operand into the V flag, whilst the 6809 simply clears the V flag. I'm struggling to relate the 6502 behaviour to a real-world operation. Followed by a BVS, the 6502 code is effectively testing bit 6 of the memory operand (which incidentally is one byte of a 16-bit pseudo-random number) without having to load the value first into the accumulator. It of course simply required an extra instruction on the 6809.

Moving on, you can now start a game and (hacked) code to render the player ship is in place. However it turns out that the game simulates the player coming out of hyperspace when the wave starts (to enable the logic that waits for a clear break in the asteroids) and I've yet to code up the associated routines on the Coco3. That'll have to wait for another night.

Starting a game after coining-up

I have noticed, doing the IIGS, C and Coco3 ports, that the scores and copyright messages don't extend to the top and bottom of the screen respectively as the MAME emulation of the arcade game suggests they should. It has puzzled me somewhat, but now I believe I know the answer. The DVG operates on 10-bit coordinates, so I've been basing everything on a 1024x1024 display, and scaling accordingly. And to note, it's relatively easy to scale down to 256x192.

However, I was reading today about an FPGA emulation of Asteroids Deluxe, and it mentioned the vertical display resolution was in the vicinity of 800 (I need to look it up again) which would explain the discrepancy. The issue of course, is that scaling becomes more of a chore, i.e. inefficient. But I do seem to recall that Norbert's scaling was different to mine... so I need to go back and study his again, as well as the MAME emulation of the DVG.

UPDATE: Both the FPGAArcade page and the Asteroids MAME driver suggest the vertical resolution is 788. Note that 192*4 = 768. Damn... can we get away with it though? OTOH the Coco3 does have a 256x200 video mode...

I also did some work on the C port yesterday lunchtime, adding the saucer to bring it in line with the 6809 port. Interestingly it has the same bug - or more accurately the same side-effect - as the Coco3 version, but for a completely different reason!