Now I really have to get back to work...
Tuesday, 10 December 2013
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...
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!
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!
Monday, 9 December 2013
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.
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!
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!
Hammer time!
Again, weekends aren't the most conducive to working on Neo Kong, but I have managed to get the hammers coded up.
Perhaps a little more work than you'd expect just to display two hammers, but now we're getting into the meat of the code; objects (such as hammers) are represented by 14-byte data structures which are initialised in several stages from different data sources.
I've been doing my own reverse-engineering at this point because thus far I've encountered a few minor errors in the other disassemblies and have been thrown a little off course by them. I should note here that you can't really fault them - it's one thing to comment a disassembly and another thing altogether to actually re-write every single instruction for another CPU! It takes me a little more time but I guess it's worth the independent verification- though it's not something I'll need to do for every instruction as once the data structures are identified, the rest of the code should fall out quite easily.
And this is way too premature, but I've also been thinking of my next porting project... and I think I've got a candidate that is perhaps a better fit to the Neo Geo than Donkey Kong.
 |
| Ignore the sprite offsets, I'll fix them soon! |
Perhaps a little more work than you'd expect just to display two hammers, but now we're getting into the meat of the code; objects (such as hammers) are represented by 14-byte data structures which are initialised in several stages from different data sources.
I've been doing my own reverse-engineering at this point because thus far I've encountered a few minor errors in the other disassemblies and have been thrown a little off course by them. I should note here that you can't really fault them - it's one thing to comment a disassembly and another thing altogether to actually re-write every single instruction for another CPU! It takes me a little more time but I guess it's worth the independent verification- though it's not something I'll need to do for every instruction as once the data structures are identified, the rest of the code should fall out quite easily.
And this is way too premature, but I've also been thinking of my next porting project... and I think I've got a candidate that is perhaps a better fit to the Neo Geo than Donkey Kong.
Saturday, 7 December 2013
Even more spritely!
Not a lot of time on the weekends, but a little more progress..
Fixed a bug in the tilemap render routine that was cutting off the top row when rotated. Now you see the 1UP and HIGH SCORE text, which was absent from the last screenshot. Oh and the sprites aren't scaled yet, so the placement was never going to be right, but they're approximate atm.
I've been working on the level/game-play initialisation routine, which as you can imagine is not trivial. The background renders are done, as I mentioned, in a generic routine with a 2nd level-specific routine. Then all the game-play data is initialised, including sprite positions. Here each level has its own sprite initialisation routine as well, which is where Kong's barrels, the oil barrel and hammers (not ported yet) are done. You might also notice a couple of errant ladder tiles at the top of the screen are now missing - for some unknown reason black sprites are used to cover them!?!
I'll probably spend the time now and complete all the sprite routines for the other levels, since they are tightly coupled to other in-game data structures like the fireball locations. Then at least I can see all screens in their entirety and maybe even at least start to run them in attract mode. So Mario will have to wait a little longer before he can run!
Fixed a bug in the tilemap render routine that was cutting off the top row when rotated. Now you see the 1UP and HIGH SCORE text, which was absent from the last screenshot. Oh and the sprites aren't scaled yet, so the placement was never going to be right, but they're approximate atm.
I've been working on the level/game-play initialisation routine, which as you can imagine is not trivial. The background renders are done, as I mentioned, in a generic routine with a 2nd level-specific routine. Then all the game-play data is initialised, including sprite positions. Here each level has its own sprite initialisation routine as well, which is where Kong's barrels, the oil barrel and hammers (not ported yet) are done. You might also notice a couple of errant ladder tiles at the top of the screen are now missing - for some unknown reason black sprites are used to cover them!?!
I'll probably spend the time now and complete all the sprite routines for the other levels, since they are tightly coupled to other in-game data structures like the fireball locations. Then at least I can see all screens in their entirety and maybe even at least start to run them in attract mode. So Mario will have to wait a little longer before he can run!
There's life, Jim!
The wife went out for dinner so I got to play some more. Still haven't sorted the sprite placement properly, but in rotated mode, at least these look right with fudge factors.
I've skipped the code to draw level-specific sprites (oil barrel etc), so I'll probably go back now and do that. Maybe, just maybe, it won't be too long before Mario moves!?!
 |
| Attract mode, Kong, Pauline & Mario |
Subscribe to:
Posts (Atom)