Xevious for the NGCD

No progress on the corrupt title screen after high score entry. I suspected it was related to the scrolling routines, as there are 3 distinct cases handled differently; in this case it would be an arbitrary scroll value which requires the entire background layer to be re-constructed. I did find what I think was a bug in that routine, but I also believe the case affected never actually happens!

However I've gone cold on that theory now; it only happens after high score entry, and there's no difference to the sequence of scroll register values written. I'm at a loss TBH...

Onto some good news. My inbox has been flooded with emails begging me to include a CD build of Xevious when I release the beta (by 'flooded' I mean I got one message and by 'begging' I mean asking me if Xevious could possibly be made to run on the NGCD).

And so I attempted to build - for the first time - the CD version of Xevious. Not having built a CD in probably 10 years, the build failed miserably. But after some refreshing of memory and re-visiting my old Donkey Kong project I updated the Xevious build tools to produce the .SPR file and managed to create a bootable CD.

Easy enough to run in NeoCD/SDL; running it in MAME is another story altogether. That was a learning curve but I finally worked it out, and added the necessary ISO to CHD conversion to my makefile.

The game loaded and ran fine. The graphics, however, weren't. It looked like the palette wasn't initialised. I could see the Xevious sprites, but just about everything else was invisible and/or black. I could see the forground tiles for example, as the Xevious sprites flew under them.

It's running in sttract mode!

So I went back and checked all the locations in the code that differed for a CD build - only one (OK). I checked the header file for the CD (OK), I checked the Donkey Kong code for differences in a CD build (none), I checked that I wasn't running out of RAM (OK). I perused the NeoGeoDevWiki for any clues... but I was starting to run out of ideas...

In fact I was typing up a post for one of the dev boards when I thought to re-check the format of the sprite data in the .SPR file. Referencing the NeoGeoDevWiki again, I noticed that the bitplane ordering was reversed wrt what I had just copied from the old Donkey Kong project...

A quick code hack and re-build and it confirmed the issue; Xevious looks just great on the NGCD!

I will burn a CD and try it on real hardware this weekend though.

That begs the question about how Donkey Kong was working. One possibility is that DK is using less bitplanes. Another is that I hacked the palette becase I couldn't work out what was wrong? It was 10 years ago... In any case, it's all fixed now and I even went back and fixed the original DK tool in the process.

Now back to that corruption bug...

UPDATE: A good day - not only did I get the NGCD build going, but I also fixed the title screen corruption bug!

Single-stepping through the code that updates the background layer after the high sore entry screen, it got interrupted by code that jumped into the BIOS. It then hit me that the hardware scroll update code wasn't actually being called within the VBLANK interrupt context - and thus potentially having the VRAM address register being changed mid-stream.

Right now I can't explain why the routine is being interrupted - it should be executing well before the next VBLANK interrupt - but that's for another day. What matters is that disabling interrupts around the scroll routine fixes the problem!

That now leaves just two (2) "bugs"; both of which I need to confirm are actual bugs. Just recreating them may be a challenge in itself. If I'm not successful in doing so within a couple of sessions, I might just release a beta and see if anyone else encounters them. Getting close now...