Last night I managed to clean up the linker script and it now builds with multiple ASM files linked together, as opposed to a monolithic source file with .includes scattered throughout.
And today at lunchtime I put together a minimal header include file and linker script for the NGCD.
Have to say, the NeoCD emulator does a better job of rendering the scaled sprites than MAME does. Whether it looks that much better on real hardware - I have no idea. Unfortunately, developing for the NGCD is a more tedious process, as each build requires un-mounting the virtual CD image, burning another with ImageBurn (which I've managed to reduce to a 2-click process) and then re-mounting and launching the emulator. There's also the lack of a built-in debugger, which I've already used in MAME extensively whilst trying to solve my numerous NOOB mistakes, and I haven't even scratched the surface of the port yet!
EDIT: After proof-reading this I realised I could probably leave the image mounted and copy the PRG file directly to the virtual CD drive - DOH!
As a result I will primarily be working on the cart version, which can be up-and-running in MAME well within 2 seconds from the last edit change. Every now-and-then I'll check that I haven't broken the NGCD build.
So now it's down to the business of porting the Z80 code. My first milestone is to have the attract mode screens (minus the game-play demo) ported and cycling through. That's at least a few week's work given my time constraints, so probably not a lot to blog about (except for hardware news) until then.
Tuesday, 26 November 2013
Monday, 25 November 2013
Same Same But Faster
After lunchtimes and nights stumbling my way around GNU assembler and linker, Neo Geo hardware and 68K ASM, I've finally managed to replicate my Donkey Kong rendering demo in 100% assembler.
This time 'round, I've got it rendering in both horizontal and vertical orientations, the plan being to develop both variations if practical - even if it means assembling both variations in their entirety and having them side-by-side in the same PROM image (after all, it's only 16KB of Z80 code!).
It's not perfect yet - there are obviously a few nuances of Neo Geo sprite hardware I need to tame - but it's enough to get me started on porting the code. The demo comprises a single render function for the entire screen (which handles either orientation, selected with the controller A & B buttons) and is being called from the demo VBLANK handler (after executing the BIOS handler).
I'm still yet to decide the best approach for rendering in-game graphics, so for now I'll take the 'easy' way out, and maintain a copy of Donkey Kong's 1KB VRAM in Neo Geo RAM, and render from that every VBLANK (as the demo is doing now) until the best solution becomes clearer. I figure if I use macros to address the VRAM it'll be easier to adapt them to direct Neo Geo (and other platform) hardware accesses at a later date, as well as facilitating rotation of the display.
Before I get much further though, I need to step back and configure the linker properly, and I should also set-up the CD version as well rather than wait until the end. Regardless, there's a decent amount of code to port until I get anything at all to show for it, so probably not much to blog about in the next few weeks... although I am attempting to get the NGPACE hardware moving along...
This time 'round, I've got it rendering in both horizontal and vertical orientations, the plan being to develop both variations if practical - even if it means assembling both variations in their entirety and having them side-by-side in the same PROM image (after all, it's only 16KB of Z80 code!).
 |
| 100% ASM rendering - horizontal and vertical orientations |
I'm still yet to decide the best approach for rendering in-game graphics, so for now I'll take the 'easy' way out, and maintain a copy of Donkey Kong's 1KB VRAM in Neo Geo RAM, and render from that every VBLANK (as the demo is doing now) until the best solution becomes clearer. I figure if I use macros to address the VRAM it'll be easier to adapt them to direct Neo Geo (and other platform) hardware accesses at a later date, as well as facilitating rotation of the display.
Before I get much further though, I need to step back and configure the linker properly, and I should also set-up the CD version as well rather than wait until the end. Regardless, there's a decent amount of code to port until I get anything at all to show for it, so probably not much to blog about in the next few weeks... although I am attempting to get the NGPACE hardware moving along...
Friday, 22 November 2013
(Not Sega) Genesis
Today I spent my lunchtime setting up a new 68K ASM project that will become NeoKong (aka Neo Geo port of the arcade Donkey Kong). I've decided to stick with the GNU assembler for compatibility with C projects and the devkit, and I also figured (rightly or wrongly) that it was the de-facto standard assembler for Neo Geo development.
As it stands, my code instructs the BIOS to run the eye-catcher animation, sets the stack pointer, acknowledges interrupts and then loops kicking the watchdog. Not too exciting I admit, but it took a bit of time to convert the header files from the (ASW-based) sprite sample source from the Neo Geo Development Wiki page for GNU AS.
Now the fun begins.
As it stands, my code instructs the BIOS to run the eye-catcher animation, sets the stack pointer, acknowledges interrupts and then loops kicking the watchdog. Not too exciting I admit, but it took a bit of time to convert the header files from the (ASW-based) sprite sample source from the Neo Geo Development Wiki page for GNU AS.
Now the fun begins.
No brute force for Kong?
I've been pressing ahead with the disassembly during my lunchtimes and evenings, where possible. Right now I've completed the bulk of the non-game-play portions of the code, which includes the initialisation, title and coin-screens, and the high-level program flow. I'd estimate about 25% code coverage so far, which perhaps sounds less advanced than it is, considering a lot of the data areas have been identified. These data areas appear all throughout the non-commented portions of the ROM code, giving valuable time-saving clues to their function. There's also a fair amount of drawing and animating code that has yet to be commented, which should prove more tedious and time-consuming than technically challenging.
I have to say that the code is rather well structured, and obviously well thought-out. After initialisation, the main foreground loop is responsible for mundane tasks like checking bonuses and updating scores, whilst the rest of the main logic is scheduled from the 60Hz (VBLANK) NMI. Here the inputs are read, sprites and sounds updated, and the rest of the logic dispatched via a hierarchy of function vector tables, not unlike Pacman.
The hardware is also funky; two (2) banks of up to 128 sprites (a total of 16 per scan-line) whose registers are DMA'd from CPU memory space every NMI. Not unexpectedly, Donkey Kong only uses a handful of those sprites.
As I become more familiar with the code, I'm now considering re-thinking my approach to a 68K port. A brute-force, line-by-line translation would not only be mind-numbingly tedious and error-prone, but I'm starting to think also unnecessary! Previously I was worried about implementing portions of code that weren't understood, and whose side-effects were unknown, but now I'm thinking that those incidences will be kept to an absolute minimum.
It also tends to negate the need to maintain a side-by-side Z80-68K ASM listing. I would retain the overall architecture whilst organising the code and data in the same sequence as the original Z80 code, but in a separate file. Perhaps a little more cumbersome during development, but ultimately more flexible in the long-run. For instance, it would be easier to start implementation before 100% completion of the disassembly - for example right now I could code the attract screens without the game-play portion (and I may do just that) - and easier to patch functions and/or modify program flow for debugging/development.
The end result would be cleaner, more native 68K code, and easier to maintain. I would also strive to separate the Neo Geo hardware aspects of the code, facilitating easier porting to other 68K-based platforms, such as the Amiga.
All still pie-in-the-sky atm, but I firmly believe completely achievable!
I have to say that the code is rather well structured, and obviously well thought-out. After initialisation, the main foreground loop is responsible for mundane tasks like checking bonuses and updating scores, whilst the rest of the main logic is scheduled from the 60Hz (VBLANK) NMI. Here the inputs are read, sprites and sounds updated, and the rest of the logic dispatched via a hierarchy of function vector tables, not unlike Pacman.
The hardware is also funky; two (2) banks of up to 128 sprites (a total of 16 per scan-line) whose registers are DMA'd from CPU memory space every NMI. Not unexpectedly, Donkey Kong only uses a handful of those sprites.
As I become more familiar with the code, I'm now considering re-thinking my approach to a 68K port. A brute-force, line-by-line translation would not only be mind-numbingly tedious and error-prone, but I'm starting to think also unnecessary! Previously I was worried about implementing portions of code that weren't understood, and whose side-effects were unknown, but now I'm thinking that those incidences will be kept to an absolute minimum.
It also tends to negate the need to maintain a side-by-side Z80-68K ASM listing. I would retain the overall architecture whilst organising the code and data in the same sequence as the original Z80 code, but in a separate file. Perhaps a little more cumbersome during development, but ultimately more flexible in the long-run. For instance, it would be easier to start implementation before 100% completion of the disassembly - for example right now I could code the attract screens without the game-play portion (and I may do just that) - and easier to patch functions and/or modify program flow for debugging/development.
The end result would be cleaner, more native 68K code, and easier to maintain. I would also strive to separate the Neo Geo hardware aspects of the code, facilitating easier porting to other 68K-based platforms, such as the Amiga.
All still pie-in-the-sky atm, but I firmly believe completely achievable!
Tuesday, 19 November 2013
Back to Donkey Kong...
After playing around with the Phoenix emulator, and unsuccessfully trying to get it running on the MVS system, I've decided to leave that to the original author and get back on track with my Neo Geo BIOS and Donkey Kong projects.
To that end, I've now finished transcribing Sockmaster's comments into IDAPro which would mean that, technically, there should be enough information to start work on the 68K port. However, I'm loathe to leave the source half-commented (actually, considerably less than half) and have decided to press on with the reverse-engineering and comment as much of the code - aiming for 100% - as possible.
As it stands I've got a reasonable idea of the structure of the code; the program flow and the data structures involved. The code should also be almost completely re-locatable (at assembly time) now; later on in the piece I'll try moving code and data around and see if it still runs on Donkey Kong hardware! It might also be possible to port it to other, suitable, Z80-based hardware as well - any 8x8 tilemap system with 16x16 sprites should suffice. There is, for example, a port on Galaxian hardware.
Anyway, once I start the port my aim to is get the first level running, and release that as a playable demo. I'm also intending on coding both horizontal and vertical versions (selectable via soft dipswitch) - I guess it'll be the Neo Geo's 2nd ever vertical game!?!
Thinking more about the 68K port - it will perhaps be a little more work than the 6809 because of the 68K's 16-bit data bus. There will also be the temptation to simply re-write routines in 68K ASM with little regard to Z80 registers; an approach frought with danger when other routines expect certain values to be retained in certain registers. Must... resist... temptation...
So it's not going to end up as nice 68K code by any standard, unfortunately. But once it's running on the Neo Geo, other possibilities are interesting. An Amiga port almost goes without saying, but then there's also the Sega Genesis/Megadrive! Hmmm...
To that end, I've now finished transcribing Sockmaster's comments into IDAPro which would mean that, technically, there should be enough information to start work on the 68K port. However, I'm loathe to leave the source half-commented (actually, considerably less than half) and have decided to press on with the reverse-engineering and comment as much of the code - aiming for 100% - as possible.
As it stands I've got a reasonable idea of the structure of the code; the program flow and the data structures involved. The code should also be almost completely re-locatable (at assembly time) now; later on in the piece I'll try moving code and data around and see if it still runs on Donkey Kong hardware! It might also be possible to port it to other, suitable, Z80-based hardware as well - any 8x8 tilemap system with 16x16 sprites should suffice. There is, for example, a port on Galaxian hardware.
Anyway, once I start the port my aim to is get the first level running, and release that as a playable demo. I'm also intending on coding both horizontal and vertical versions (selectable via soft dipswitch) - I guess it'll be the Neo Geo's 2nd ever vertical game!?!
Thinking more about the 68K port - it will perhaps be a little more work than the 6809 because of the 68K's 16-bit data bus. There will also be the temptation to simply re-write routines in 68K ASM with little regard to Z80 registers; an approach frought with danger when other routines expect certain values to be retained in certain registers. Must... resist... temptation...
So it's not going to end up as nice 68K code by any standard, unfortunately. But once it's running on the Neo Geo, other possibilities are interesting. An Amiga port almost goes without saying, but then there's also the Sega Genesis/Megadrive! Hmmm...
Tuesday, 12 November 2013
Phoenix Emulator (not mine)
I've been in touch with the NGCD Phoenix emulator author, and unfortunately (for me) the Z80 core he's using - Marcel de Kogel's portable Z80 emulator - is written in C. Right now the emulator itself is in its infancy, and running very slowly, although obviously there hasn't been any optimisation done to it yet.
I also volunteered to help out with the rendering; first ripping the tiles and palette from MAME and enhancing my Donkey Kong demo to work with Phoenix as well.
Then I started work on building the emulator, which was designed for the NGCD, for the MVS (cartridge) system. Ultimately I discovered that there isn't enough RAM on the MVS to run the emulator as-is, so I then turned to building it for the NGCD in an environment I was familiar with.
After coming to grips with the nuances of the NGCD vs MVS, such as the sprite format, it was quite straightforward to add my demo rendering to the emulator. I've still got some tweaks and clean-up before I send it back to the original author, but at least it will give him a head-start on the display - something I've had a lot of experience with whilst working with FPGA emulations!
It might also be worth my while getting Donkey Kong running with the C Z80 core, just for fun...
I also volunteered to help out with the rendering; first ripping the tiles and palette from MAME and enhancing my Donkey Kong demo to work with Phoenix as well.
 |
| Neo Geo Phoenix demo |
After coming to grips with the nuances of the NGCD vs MVS, such as the sprite format, it was quite straightforward to add my demo rendering to the emulator. I've still got some tweaks and clean-up before I send it back to the original author, but at least it will give him a head-start on the display - something I've had a lot of experience with whilst working with FPGA emulations!
It might also be worth my while getting Donkey Kong running with the C Z80 core, just for fun...
Monday, 11 November 2013
Eye catcher, and possible emulation?
I noticed during development that the so-called eye-catcher graphics (the spinning NEO-GEO graphics and SNK logo) had completely random tiles on my Donkey Kong demo. This piqued my curiosity so I decided to look into how it is actually rendered.
Turns out that the animated graphics can be either rendered by the BIOS, or the game itself (or not at all), depending on a flag set in the cartridge header. Either way, the actual tile data must be supplied by the cartridge - there is no graphic data in the BIOS itself!
The official documentation mentions as much, but doesn't give a lot of detail on exactly what is required. So I did some more digging in the BIOS disassembly, together with some experimentation with my demo. I discovered that the spinning logo is - not surprisingly - rendered as a series of sprites, and it uses a bank of (somewhat less than 256) tiles whose MSB is read from the cartridge header. As for the remaining text and copyright symbol; these are rendered from the FIX layer ROM on the cartridge and comprises various tiles interspersed with the more commonly-used ASCII characters.
So in order to clean-up my demo, I injected 256 sprite tiles from Baseball Starts Professional (surprisingly, NGH-001 - aka, NAM-1975 - renders its own eye-catcher) and set my cartridge header appropriately. Then I simply replaced the entire FIX ROM with that from the same and viola - a nice clean eye-catcher animation! Nothing exciting, but at least it's one more mystery solved for me.
In the mean-time I've been slowly plodding through the Donkey Kong disassembly, since the version I received - whilst extremely helpful - isn't quite as complete as I'd like. And since I'm using IDAPro to produce a Z80 source file as a starting point (I'd like to re-assemble it at a different address and see if it still runs in MAME), I'd like to ensure that it's as complete as possible since once I start adding 68K code to it, there's no going back.
It is a daunting task but I can see how, in some cases, a brute force approach - for some areas of the code - is sufficient. And that's no doubt what has happened with the 6809 conversion. But perfectly valid, obviously, as it runs beautifully on the Coco!
However, I'm starting to wonder whether an emulation might actually be possible on the Neo Geo. No doubt it would have to be hand-crafted in 68K assembler, as compiled C-code is just not going to cut the mustard on a 12MHz 68K. But maybe, just maybe, an assembler core with hand-patched graphics routines will do the job!?! I'm not sure, but I'm hoping to find out, as I'm now aware of possibly two (2) Z80 cores written in 68K assembler; one in a TRS-80 emulator on the Amiga, and another (yet to be confirmed) on a WIP Phoenix emulator on the Neo Geo.
A Z80 core would make life a little easier for sure, and open up the possibility for more arcade ports on the Neo Geo. Or maybe a TRS-80 emulator for it??? ;)
 |
| The standard eye-catcher graphic |
Turns out that the animated graphics can be either rendered by the BIOS, or the game itself (or not at all), depending on a flag set in the cartridge header. Either way, the actual tile data must be supplied by the cartridge - there is no graphic data in the BIOS itself!
The official documentation mentions as much, but doesn't give a lot of detail on exactly what is required. So I did some more digging in the BIOS disassembly, together with some experimentation with my demo. I discovered that the spinning logo is - not surprisingly - rendered as a series of sprites, and it uses a bank of (somewhat less than 256) tiles whose MSB is read from the cartridge header. As for the remaining text and copyright symbol; these are rendered from the FIX layer ROM on the cartridge and comprises various tiles interspersed with the more commonly-used ASCII characters.
So in order to clean-up my demo, I injected 256 sprite tiles from Baseball Starts Professional (surprisingly, NGH-001 - aka, NAM-1975 - renders its own eye-catcher) and set my cartridge header appropriately. Then I simply replaced the entire FIX ROM with that from the same and viola - a nice clean eye-catcher animation! Nothing exciting, but at least it's one more mystery solved for me.
In the mean-time I've been slowly plodding through the Donkey Kong disassembly, since the version I received - whilst extremely helpful - isn't quite as complete as I'd like. And since I'm using IDAPro to produce a Z80 source file as a starting point (I'd like to re-assemble it at a different address and see if it still runs in MAME), I'd like to ensure that it's as complete as possible since once I start adding 68K code to it, there's no going back.
It is a daunting task but I can see how, in some cases, a brute force approach - for some areas of the code - is sufficient. And that's no doubt what has happened with the 6809 conversion. But perfectly valid, obviously, as it runs beautifully on the Coco!
However, I'm starting to wonder whether an emulation might actually be possible on the Neo Geo. No doubt it would have to be hand-crafted in 68K assembler, as compiled C-code is just not going to cut the mustard on a 12MHz 68K. But maybe, just maybe, an assembler core with hand-patched graphics routines will do the job!?! I'm not sure, but I'm hoping to find out, as I'm now aware of possibly two (2) Z80 cores written in 68K assembler; one in a TRS-80 emulator on the Amiga, and another (yet to be confirmed) on a WIP Phoenix emulator on the Neo Geo.
A Z80 core would make life a little easier for sure, and open up the possibility for more arcade ports on the Neo Geo. Or maybe a TRS-80 emulator for it??? ;)
Subscribe to:
Posts (Atom)