Coins and dipswitches

Some more integration into Neo Geo, bugfixes and tidy-ups tonight.

I got curious about the soft dipswitches on the Neo Geo; now the Donkey Kong dipswitches are all implemented on the Neo Geo. I've replaced the cabinet upright/cocktail switch with a horizontal/vertical switch that controls the screen rotation.

I got thrown for a while because the game name wouldn't appear correctly on the setup screen. After scratching my head for a while before relenting and tracing through BIOS calls, I discovered that it is read from the backup RAM, not the dipswitch settings table in ROM! And because I had run Neo Kong previously with garbage in the table, it had saved a rubbish game name in the backup RAM (everything is keyed from the NGH number in the ROM header). Deleting the saveram file and running it again fixed the issue.

I also fixed the coin-up issue, which was a bug in the 68K port; comes from reading Z80 instructions which are <dest>,<src> and translating to 68K which is <src>,<dest>. Not the first time I've made that mistake, and it won't be the last. So I can coin-up and start a 1P or 2P game (which I've now hooked up to the actual START buttons on the Neo Geo)...

...which brings me to another Z80 Donkey Kong bug. The routine to detect 1P and 2P start buttons stores a mask in the B register, depending on whether there is one or more credits. Then the routine periodically prints the 'PRESS 1P or 2P START' message, depending on a timer value, before reading the hardware and testing the input against the mask. The bug is that if the messages are displayed, then the B register is not preserved, and is always set to 0. It doesn't matter, because invariably the button is detected on the next loop, and the message not displayed and it all works.

This in turn resulted in a related but different bug on the 68K port; the mask register wasn't being set to 0, but 0xff - meaning that pressing 2P start with only 1 credit was being accepted. Anyway, all fixed on the 68K port now.

Next session I can well and truly get into the game-play code. First order of business will be getting Mario to move on the 1st level. But I have a feeling that I won't get the opportunity tomorrow, so it'll have to wait a few days...

Do you want to play a game?

Lunchtime progress: can insert (only 1) coin and select START1P.

Not sure if the issue with it accepting only a single coin is a Neo Geo issue or a Donkey Kong porting issue. Either way, it's likely a trivial problem (I always regret saying that!)

For now I've hooked the START1P to Neo Geo BUTTONC, only because after the experience I had with the coin-ups it was always going to be quicker and easier. I'll look at what's required to hook it up properly tonight if I get the opportunity.

But the big news is - it's now executing the main game-play loop!!!

Right now I've got the loop executing the attract mode initialisation - just to see something happening - but I've also verified it in the MAME debugger. And at this point, the attract mode and game-play modes merge again, so I can test either.

But first, I've got bills to pay...

Coins and housekeeping

Last night I did a few tidy-ups; reviewed (again) any missing functionality in the execution path thus far and found a small routine that 'fixes' the moving ladders on the 2nd (cement pie) level. Still a few sundry items and sprites which I'm yet to port, but they don't seem too important atm. And for some reason, the ladder-tops have appeared again on the title screen (although the transition from demo mode to title screen is a hack atm, so I'm not too fussed).

I also decided to code the coin-up logic, and found that the Neo Geo does things very differently to other arcade games. All the title, demo, credit and start functions are handled by the BIOS. I had to fill in a few missing vector functions in the cartridge header, and also had to set the USER_MODE variable in the system work area before I could get the coin-up function working, but now I can add a credit (not sure yet how this will translate to the non-MVS platforms). That's still WIP so you can't actually start a game yet.

I also took a quick look through the rest of the code, in particular the game-play loop. It all looks fairly straight-forward, and I should be able to get Mario moving about without having to worry about porting the rest of the game logic. There's quite a bit of crank-the-handle type porting to be done, which might be a little tedious but shouldn't throw up any surprises and will hopefully be straightforward to test as I go.

 But first, I'd like to be able to start a game.

Neo Kong is not Donkey Kong

Just playing around, since 'DONKEY' contains the letters 'N', 'E' & 'O':

Now I really have to get back to work...

4 on the floor.

Managed to find the bug in the rivet level. The dangers of local labels and unfinished code...

The game's data structures are starting to become a little clearer now. Aside from the expected jumble of timers, temporary and sundry variables there's a table of objects @$6400 to the end of memory. This table keeps track of objects like fireballs, springs, elevators, hammers, barrels, etc - basically anything that moves or can be interacted with. Everything's also nicely aligned; objects are either 16 or 32 bytes depending on how much data is required to store their state.

I've also found what appear to be two bugs in the level initialisation code!

In the 2nd (cement pie) level there's a call to the routine that initialises the spring sprites from the elevator level. The sprites themselves are located off-screen so there's no visible side-effects, but none-the-less there's no reason it should be called.

In the 3rd (elevator) level the code that initialises the elevators appears to have a bug. The code to initialise the 6 elevator objects instead uses two nested loops to overwrite a byte (with the same value) in the first 3 objects twice, instead of looping through all 6. It looks like the code used to use a different value for the 4th-6th objects and was quickly patched... either way there's still a bug as the start address is initialised inside the outer loop. I don't know (yet) what this byte represents, so I don't know the effects of the bug.

So now the real fun begins!

Elevators and crashes.

Tonight I got the 3rd (elevator) level finished:

But the problem now is that the 4th (rivet) level is crashing, and for some reason I can't work out exactly where it's going wrong, or the reason (eg. BUS ERROR) for the crash. A trace shows it crashing in the middle of drawing ladder segments, but removing that logic still causes a crash. Thus far crashes have been caused by misaligned word/long reads, or word operands with only the lower byte initialised, and they've been relatively easy to fix, as the bug is invariably in code I've just added. But this one is totally unexpected, in code that was running yesterday!

It's very, very annoying and it's going to have to wait until tomorrow now.

Two down, two to go!

The results from lunchtime today:

As well as completing the initialisation routines for the 1st two levels, I've also fixed the background and sprite placements for the rotated mode. In rotated mode, there's absolutely no scaling (or clipping, on MAME at least) required so for an MVS board in a vertical cabinet, Neo Kong will be a pixel-perfect clone of Donkey Kong!

Thus far, Donkey Kong is using 41 sprites. I don't think there's many more sprites to be added, so I'd be surprised if it tops 64 of the 96 total that gets DMA'd to the registers.

The remaining two levels should be straightforward, as they'll mostly use routines that have already been ported. So I'll finish those off (possibly tonight) before things will start to get really interesting!