The sound of silence

Quick update; added sound hooks and osd stub functions for them - but nothing else!

Have been doing a little more RE of the SOUND CPU and it has helped a little, although I won't be needing (or wanting) to complete it. It's a bit more complicated than I first imagined, with lookup tables for which sounds to silence when certain other sounds are playing, for example. I don't think we'll go that far into replicating the behaviour - it has probably more to do with hardware limitations than anything else anyway.

Still yet to look for that last gameplay bug...

...but I was playing it tonight and when the Bacura appeared I was waiting for the bug to manifest itself. It wasn't happening when it should have... and then I realised I had actually fired up the arcade original to check out some of the sounds! I guess it's a good thing when you can't tell the difference between your port and the arcade game (ignoring the obvious aural hints!)

Another gameplay bug squashed - potentially only one to go!

Getting really close now - fixed another game play bug! Only one confirmed, and one unconfirmed to go now... (that I know of!)

I fixed the bug where you would suddenly start to earn an extra Solvalou for every hit. I had suspected it was something to do with the dipswitch settings and bonus life calculation; what I didn't suspect was that it actually comprised about 4 different bugs! 😮

The dipswitches on the Neo Geo were a bit of a mess TBH. And for some reason, I was negating the bits when reading them which only confused matters - including debugging - further. The trick to avoiding CPU-consuming bit operations is to order the Neo Geo settings to match the bit patterns of the arcade dips, rather than preserving a nice 'natural order' for each option. It's better that the options listed for lives is "5, 2, 1, 3" (you'll likely only ever look at them once) than requiring an extra 12 instructions every VBLANK just to read the dipswitches - or a few lookup tables!

Suffice it to say, as well as incongruencies in the Neo Geo dipswitch settings, there were a few bugs in the bonus calculation routine as well (comprising 16-bit BCD addition), which meant around 64,000 you started getting Solvalou every hit. And because it worked fine at 20K and 60K, it went unnoticed for a long time, until I started patching the starting score to test the high score table and load/save.

So now I'm left the randomly exploding Solvalou, seemingly (only) when Bacura are present. At least I believe I can reliably recreate the issue every time, so I'm hoping that won't be too difficult to fix either. I'm a bit surprised that it might be related to the olde Bacura hit-box issue again (which was a bit of a bugger to find), but no solid theories just yet.

The only other issue I'm aware of is something I noticed early on when working on the scrolling - when ignoring attribute settings for tiles (can't remember fg or bg) there was a curious black square scrolling down the left-hand side of the screen. It could have been related to the Xevious sprites - which have since undergone a complete overhaul - so I'm half-expecting the issue to longer exist. But I will see if I can recreate that one as well, just for good measure.

That should cover everything, except for the purely cosmetic issue of 'sparklies' on the screen, mosty down the left-hand side. Absolute worst case, they don't affect the game at all and are easily ignored, but again it wold be nice to know what it is, and whether it can be eliminated.

I suspect it is Neo Geo sprite code running outside the context of VBLANK. It may even be the foreground layer tiles being updated - they are always outside VBLANK. If that's the case, I can look at using dirty squares and deferring update until VBLANK, or just leave them as-is. Not a show-stopper by any means, and akin to 'sprite flicker' you see on a lot of platforms being pushed to their limit.

Now, those pesky Bacura...

Running on real NGCD hardware!

One step forward, two steps backwards perhaps?

Firstly, I burned a CDR and tested Xevious on my NGCD. Works as expected! I can also confirm that high score load/save (to/from virtual memory card) works fine on the NGCD hardware as well - yay!

Xevious running on real NGCD hardware!

During play testing however, I noticed another bug today. I also confirmed one of the two existing gameplay bugs - extra Solvalou suddenly starting to appear every hit - is definitely still an issue.

The new bug, which I haven't really noticed before, is the Solvalou suddenly exploding for no reason! In hindsight I may have seen a hint only a few days ago, after fixing the "hanging bullets" issue, but at the time I thought it was due to a teleporting Zakato. Not so it seems...

So I have 3 outstanding issues, one yet to be re-confirmed.

Another observation; I do get "sparklies" on the screen. I noticed this on my AES, but couldn't discount the fact that it was crappy output/cabling. Now that I get the same issue on the NGCD, I'm forced to concede that it may well be my programming (although I'm using the same cables). Not a show-stopper by any means, but would be nice to find the cause and eliminate it...

And as a reminder to myself; I also need to generate the proper FIX layer for the NGCD.

UPDATE: Fix layer for NGCD done (just needed to copy the cart FIX ROM and rename).

A bit more play testing. High score load/save working on NGCD. The random explosion of the Solvalou seems to be related to the Bacura; at the very least it happens more often with Bacura on the screen. Hopefully a good clue. Sparklies my issue; my splash screen is rock-solid.

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...

Transcode audit finished & bullet bug fixed!

Significant day today - finished the audit of the SUB ROM, and also fixed a long-standing bug!

I'm reasonably happy with the state of the transcode, though I may still need to tweak some of the execution flow to better accomodate the single-CPU architecture with respect to the VBLANK. I don't think it's an issue on the Neo Geo, but the graphics-intensive Amiga port may be another matter.

I've fixed the bug where some bullets just "hang" in the air. As happens way too often, you "fix" it and it still doesn't work - because it actually turns out to be a combination of multiple (in this case 2) bugs. In both cases, it was about register usage; one case of a register not being preserved around a subroutine, the other a case of a subroutine called from two places but parameters in different registers.

And only now that the bug is fixed, have I noticed that the Brag Zakato firing patterns look right!

Brag Zakato spraying 5 bullets

I also confirmed that one 'bug' was an artifact of skipping areas when debugging - it happens on the original version as well. In fact I don't really understand why it's happening, and suspect it's a bug. Regardless, it doesn't happen during normal gameplay.

That leaves me with three (3) outstanding bugs now; corrupt title screen after high score entry, extra Solvalou every hit, and a glitch that I noticed when debugging the graphics routine. The first is almost certainly a bug in the Neo Geo (OSD) layer, the 2nd may be related to dipswitch settings, and the 3rd I'm not even sure is a bug!

There is also the question of transparency in the Xevious sprites; jotd has pointed out that a whole bunch of sprite CLUTs have multiple transparent colour entries. I do know the crosshairs use such CLUTs, but was not aware of the others. I certainly haven't noticed anything "wrong" whilst testing... but I haven't been looking either. To be investigated...

Hopefully I can knock these off in the next few days and I can move onto sound!

I may also release a beta before adding sound for people to test the gameplay...

Audit of the MAIN CPU ROM complete!

A couple of big sessions today and I've finally finished the audit of the Xevious MAIN CPU ROM!!!

No more bugfixes - in fact I flagged a possible 5th outstanding bug - but a substantial task out of the way.

Next up is the audit of the SUB CPU ROM, but it is a lot smaller than the MAIN; only 1/6th the number of lines and almost half of that is data. The code tends to be a little simpler as well, so I'm not expecting it to take more than a couple of sessions to complete.

That'll then leave bug fixes, and adding sound!

jotd is progessing well with the Amiga port, it's all-but-playable as-is. He has released a video in the last few days on YouTube. I'm trying to knock over the audit ASAP so I can assist with some of the details.

A bug fixed, high score load/save finalised, and not much else.

As usual not a lot of progress over the weekend due to Real Life.

jotd did find another bug that I'd never actually noticed before; on the attract mode gameplay screen the ground objects were misaligned with respect to the map - how I missed that I have no idea! 😮

Upon closer inspection I noticed that it was the map that was offset (not the objects) and only after the title screen - not after the high score table screen. This made it easy to compare the values of the inputs to the map-rendering routine in each case, since the attract mode always plays Area 1 from the start. And it was only a handful of minutes before the difference was revealed and less than a minute later that the culprit was found.

Nothing even remotely interesting - just an unintialised register used as the index into the table that specifies the offset in the map data for each area. The Z80 code was clearing A to initialise a few other variables, and then using that as the index. In the transcode I was using the CLR instruction instead, then using an uninitialised D0 as the index.

Since this code is not time-critical at all, I reverted to clearing and then using D0 as per the Z80 code, keeper it closer to the original source.

The only other update was finalising the high score load/save on the Neo Geo. The only system to use BRAM (as BRAM) is the MVS; the other two systems (AES/NGCD) support memory card I/O, even though the AES implements a "virtual" memory card in BRAM. I decided to first read from BRAM on MVS systems, and then attempt to read from memory card (on all systems), overwriting any BRAM data if found. On saving high scores, MVS systems write to BRAM, and then all systems attempt to write to memory card.

Probably not how it's supposed to be done, but that's my preference.

Since the "known" list of bugs had grown by 2 (from 8 to 10), and I have fixed one of those, the outstanding list now stands at 4 (with 1 still yet to be confirmed as an actual bug). But for the week heading forward, I'll be spending my lunchtimes at work trying to finish the audit of the MAIN ROM.