Still trying to find 10 minutes here and there to work on the port. Managed to get name registration done, although I had to hack the score handling for the moment due to the fact that you can't actually score any points - so ignore that aspect for now...
You can also start a 2-player game and it runs right through to the end game for both now. Still a few minor issues to sort, like player 2 shows the wrong height on the "How high can you climb" screen, and those pesky ladder tops, but I'm getting closer to the point where there's only game-play code that remains to be ported.
I suspect the next few weeks won't be conducive to spending any significant amount of time on Neo Kong. I've got a week up the coast coming up but will probably leave the laptop at home in favour of the tablet and drinking with my cousin!
On a different but perhaps related note; I scored the Mega Pack for my Neo Geo X for Xmas, and I'm pretty happy that I can now play Blue's Journey on it! That'll be going up the coast with me for when my wife is playing Scrabble on her tablet! Maybe one day I'll jailbreak it and be able to play Neo Kong on it!
This blog originally detailed the progress of development of my Neo Geo MVS/AES System Board Replacement Project. However that project failed to see the light of day for various reasons, and is now considered obsolete given the options out there now.
After 7 years of inactivity in this area I've decided to dive back into retro FGPA emulation and as a result I've resurrected this blog to document my projects.
Friday, 27 December 2013
Thursday, 19 December 2013
Just Silly
Despite the fact that we're fast approaching the silly season, time to spend on 'silly' pursuits seems to be getting harder to find, not easier. And so in my spare 10 minutes here and there I'm still chipping away at the port...
And despite the fact that I had intentions of finishing off the non-gameplay sections of the code, I found myself looking for the code that ticks down the bonus timer. Interestingly, the timer on the barrel/girder level is handled differently and is inter-twined with the barrel deployment timers. Eventually I quickly gave up on that as I'm not ready to dive into that area of the code, but at least now I have the bonus timer ticking down... albeit it too quickly on the 1st level.
And putting off the less interesting bits yet again, I wanted to see if I could make Mario at least move without much effort. But alas, although now it detects left/right movement and updates the sprite, the code to adjust the coordinates was too convoluted with too many unknown variables to hack quickly.
At least I have a starting point for the game-play, but for now I'll return to the high score update and name registration screens. Then I'll do one final audit of the non-gameplay code and then I can start to make the game playable!
And despite the fact that I had intentions of finishing off the non-gameplay sections of the code, I found myself looking for the code that ticks down the bonus timer. Interestingly, the timer on the barrel/girder level is handled differently and is inter-twined with the barrel deployment timers. Eventually I quickly gave up on that as I'm not ready to dive into that area of the code, but at least now I have the bonus timer ticking down... albeit it too quickly on the 1st level.
![]() |
| Bonus timer displayed and ticking down |
And putting off the less interesting bits yet again, I wanted to see if I could make Mario at least move without much effort. But alas, although now it detects left/right movement and updates the sprite, the code to adjust the coordinates was too convoluted with too many unknown variables to hack quickly.
At least I have a starting point for the game-play, but for now I'll return to the high score update and name registration screens. Then I'll do one final audit of the non-gameplay code and then I can start to make the game playable!
Tuesday, 17 December 2013
Wading through the boring bits
Not a lot to show for it, but I've been plugging away at lunchtime again. Mario's death spin is fully animated now, and I'm slowly working my way through the sundry routines that get called during game initialisation and/or clean-up, or from the main loop. This includes the various timers and housekeeping routines that don't affect much on the display. I've still got some scoring and bonus routines to do, and the high score name registration screen. Probably a few more days before I can get into the actual game-play.
In the process of Mario's death spin I had to implement sprite flipx (I had only implemented flipy previously). That comprised about 5 extra instructions. I had previously re-ordered the sprites, thinking there'd be gaps in the sprite memory map for unused sprites, but there's a only a few. Trouble is, Mario's death routine wipes a lot of the sprite objects en masse, so I reverted all the sprites to their original indices; not too painful because I use macros to address them.
I also fixed a bug in the initialisation routines that were clobbering variables that shouldn't have been clobbered; and I haven't seen the START crash since. Fingers crossed that was the source of the issue...
Interestingly, the non-Neo Geo portion of the 68K code/data is $2B1C bytes now. Although I am optimising some of the code slightly, I suspect the end result will exceed the 16KB of the Z80 ROM. I'm loathe to estimate the percentage of code I have ported at this point, but I'm hoping by now I've hit the 50% mark. And FWIW the Neo Geo PRG ROM for Neo Kong is $3888 - a few bytes short of KOF2003!
In the process of Mario's death spin I had to implement sprite flipx (I had only implemented flipy previously). That comprised about 5 extra instructions. I had previously re-ordered the sprites, thinking there'd be gaps in the sprite memory map for unused sprites, but there's a only a few. Trouble is, Mario's death routine wipes a lot of the sprite objects en masse, so I reverted all the sprites to their original indices; not too painful because I use macros to address them.
I also fixed a bug in the initialisation routines that were clobbering variables that shouldn't have been clobbered; and I haven't seen the START crash since. Fingers crossed that was the source of the issue...
Interestingly, the non-Neo Geo portion of the 68K code/data is $2B1C bytes now. Although I am optimising some of the code slightly, I suspect the end result will exceed the 16KB of the Z80 ROM. I'm loathe to estimate the percentage of code I have ported at this point, but I'm hoping by now I've hit the 50% mark. And FWIW the Neo Geo PRG ROM for Neo Kong is $3888 - a few bytes short of KOF2003!
Monday, 16 December 2013
Introductions are in order
Despite the lack of updates on this blog, I've been plugging away at Neo Kong at every opportunity.
I jumped the gun a bit on the game-play; I thought I'd fast-track the game initialisation and get into the actual game, but it turns out that there's too much logic dependent on the initialisation. So I stepped back and ported all the initialisation routines properly. And then I realised that I had forgotten altogether about the introduction screens...
So now you can coin up, start a game, watch the intro, and when the game is over (I set Mario to die immediately) it returns to the attract mode loop. All that is missing outside the game-play now is the high score registration routine - which I'll probably finish off next just to get it out of the way. Once that's complete, it should mean that the only code remaining is in-game game-play code.
I do have one intermittent bug; occasionally the Neo Geo will reset when you start a game. I suspect it's an issue with a register having non-zero high-order bits due to BIOS routines where I have forgotten to zero them first - I've already made that mistake a few times. I'll track it down at some point when it starts to get too annoying.
Although I do 99% of my testing under MAME running un-throttled, I have noticed that the game runs too slow when it is throttled. I guess that's not too surprising, given that I'm rendering the entire tilemap, plus 64 sprites, plus calling the BIOS handler every VBLANK. At some point I'll do some further analysis but right now I suspect every 2nd VBLANK is being missed and it's running at half-speed. Not an issue atm since there's plenty of display optimisation to be done.
I've also been thinking ahead about what bells 'n' whistles might be nice. I'll add a (soft) dipswitch setting to select either US/Japanese level sequence. I guess I should also look at supporting loading and saving of high scores.
I jumped the gun a bit on the game-play; I thought I'd fast-track the game initialisation and get into the actual game, but it turns out that there's too much logic dependent on the initialisation. So I stepped back and ported all the initialisation routines properly. And then I realised that I had forgotten altogether about the introduction screens...
![]() |
| Coin-up and watch the intro screens |
So now you can coin up, start a game, watch the intro, and when the game is over (I set Mario to die immediately) it returns to the attract mode loop. All that is missing outside the game-play now is the high score registration routine - which I'll probably finish off next just to get it out of the way. Once that's complete, it should mean that the only code remaining is in-game game-play code.
I do have one intermittent bug; occasionally the Neo Geo will reset when you start a game. I suspect it's an issue with a register having non-zero high-order bits due to BIOS routines where I have forgotten to zero them first - I've already made that mistake a few times. I'll track it down at some point when it starts to get too annoying.
Although I do 99% of my testing under MAME running un-throttled, I have noticed that the game runs too slow when it is throttled. I guess that's not too surprising, given that I'm rendering the entire tilemap, plus 64 sprites, plus calling the BIOS handler every VBLANK. At some point I'll do some further analysis but right now I suspect every 2nd VBLANK is being missed and it's running at half-speed. Not an issue atm since there's plenty of display optimisation to be done.
I've also been thinking ahead about what bells 'n' whistles might be nice. I'll add a (soft) dipswitch setting to select either US/Japanese level sequence. I guess I should also look at supporting loading and saving of high scores.
Thursday, 12 December 2013
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...
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...
Wednesday, 11 December 2013
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...
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.
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.
Subscribe to:
Posts (Atom)



