Go big or go home!

 The two bomb-related bugs were related, and they've been fixed.

In the mean-time, I was getting sick of squinting at the small screen and thought I'd look into how difficult it would be to upscale the display on the PC. Turns out it was trivial (except for the bullets) using the Allegro5 bitmap scaling functions and the whole process, including research, took about 10 minutes.

Scale factor x2

It actually looks more accurate using 4:3 scaling but again, the point of this exercise is not about playing it on the PC.

So this last bug has me really scratching my head. The symptoms are (mostly) missing vertical strips from the landscape. Occasionally the strips will filled with erroneous landscape graphics, rather than being missing (black)...

Vertical bars missing from the lndscape

The odd thing is, although it happens quite frequently, it only seems to happen after you crash your ship into the landscape. It doesn't happen if your ship is destroyed by any in-flight enemies such as rockets.

I do know that it's not corrupting any ROM data structures (in this case static C arrays), because subsequent plays do not exhibit the corruption. That would suggest perhaps it's a corruption in RAM. But I have seen the case where it renders the flat landscape correctly, only to have it (the flat part) corrupted as soon as it starts scrolling. Once rendered, landscape should not be rewritten until it scrolls off the screen.

That left me wondering whether it was a bug in my Allegro-layer routines. But the fact it only happens when you hit the landscape doesn't quite fit with that theory either. But typing all this out has got me thinking...

UPDATE: I've just confirmed it's the character RAM (tilemap) that is being corrupted. I suspect the code to render two columns right of screen is writing to the wrong area, either because there's a bug in the routine itself, or some area of RAM is being corrupted or not initialised properly (more likely).

UPDATE #2: Not just landscape collisions that cause the issue.

UPDATE #3: Solved! That was a tough one. Turned out to be a race condition between the main routine and the NMI only because in my prototype implementation I don't have a pre-emptive NMI but rather just 2 threads running simultaneously. I was thinking that the landscape was drawn from the NMI, but I was wrong. I noticed a pointer was changing in the draw_landscape routine between the start and the end of the function and then it twigged.

Now just a little more play testing before I can announce the transcoding is officially done!