Tonight I sat down and thought about the flash cart. Bearing in mind that I also require some hardware to analyse the buses and program the cart itself - on both MVS and AES systems - I ended up no less than with six (6) distinct PCB's! I'm also tempted to add MVS->AES and AES->MVS converter functionality as well, but it's by no means definite. I would also stress that this is not a consumer product - at least not in this form - so ease-of-use and price are definitely not factors in my design at this point.
Four (4) of the PCB's are little more than EURO to card-edge and socket adapters for MVS and AES systems, allowing me to plug either cartridge into either system, via the analyser/programmer PCB. Hopefully these will be cheap, 2-layer boards.
The aforementioned analyser/programmer PCB comprises the FPGA and (most likely) an SD card socket for ROM images. It can be configured for use as either a CHA or PRG board. It can also be powered externally for stand-alone operation.
In analyser mode, the PCB plugs into both the MVS/AES motherboard, and a standard MVS/AES cartridge. The FPGA is configured to capture cartridge bus activity and all/any lines as required, using Altera's excellent SignalTap function. It's worth noting that the FPGA PLL's will allow super-sampling to capture asynchronous events. Trace depth is limited by the size of the FPGA.
If it were possible to add converter functionality, it would effectively be done in analyser mode.
In programmer mode, the PCB must be powered externally and is connected only to a flash cart PCB (CHA/PRG). The FPGA is configured with a soft-core processor that reads ROM images from the SD card and programs the memory on the flash cart.
Finally, the flash cart is configured as either a CHA or PRG board, and operates simultaneously? as both an MVS and AES cartridge. The flash cart itself may be plugged into either the analyser/programmer board or into an MVS/AES system via the adapter boards.
I'm thinking I'll need an EP4CE22 or EP3C25 at the very least on the analyser/programmer board, and likely a decent CPLD on the flash cart. EURO connectors would need to be 150-way or equivalent.
Disclaimer: these are all random thoughts put together in a single evening, and may represent impossibly ambitious or technically infeasible goals. But I have to start somewhere!
Thursday 30 January 2014
Saturday 25 January 2014
NGPACE in 2014
Back from holidays, getting back into the daily grind at work, and yet to get time to sit down and immerse myself in Neo Kong again. It'll probably be another week or so, but I'll definitely ramp up on the porting again very soon.
In related Neo Geo news, I've just won an auction for a Neo Geo CD (top loader) which is winging its way from Japan as I type this blog. This will complete my Neo Geo hardware trio (MVS, AES & NGCD) but more importantly will allow me to see Neo Kong running on real hardware, which I'm pretty keen to do!
As for NGPACE hardware, I've finally decided to re-direct my initial efforts towards a development cart for MVS/AES. This will actually serve two purposes; not only will it allow me to play Neo Kong on MVS & AES hardware, but I'll be kitting it out with a pair of reasonably-sized FPGA's to facilitate reverse-engineering of the MVS/AES hardware (cartridge buses) for NGPACE.
At this stage I've made no decisions about the design, the capacity, the memory technology, the programming mechanism or pretty much anything else. If I had to guess, I'd say some parallel flash with a micro and USB and/or SD card. It's unlikely the initial design will allow me to program up KOF2003, but that's not the focus anyway. Hopefully I'll be able to then scale-down the FPGA's (and even use CPLD's) and scale-up the memory for a more generic programmable cartridge.
As an aside; something I've been thinking about and was also raised on the #neogeodev channel recently is a custom cartridge with sprite RAM, enabling on-the-fly sprite programming which in turn can be used to generate a bitmap display! I know that the NGCD sprite RAM is programmable by the CPU, but there are timing and bandwidth limitations and AFAIK it hasn't been done outside a demo - i.e. never proven viable for arcade game-play. It would be interesting indeed to provide such a mechanism on the programmable cartridge, for demonstration if nothing else! Neo Defender anyone?
I'm hoping to kick off the design in parallel with Neo Kong; maybe the hardware will be finished by the time the porting is done!?!
In related Neo Geo news, I've just won an auction for a Neo Geo CD (top loader) which is winging its way from Japan as I type this blog. This will complete my Neo Geo hardware trio (MVS, AES & NGCD) but more importantly will allow me to see Neo Kong running on real hardware, which I'm pretty keen to do!
As for NGPACE hardware, I've finally decided to re-direct my initial efforts towards a development cart for MVS/AES. This will actually serve two purposes; not only will it allow me to play Neo Kong on MVS & AES hardware, but I'll be kitting it out with a pair of reasonably-sized FPGA's to facilitate reverse-engineering of the MVS/AES hardware (cartridge buses) for NGPACE.
At this stage I've made no decisions about the design, the capacity, the memory technology, the programming mechanism or pretty much anything else. If I had to guess, I'd say some parallel flash with a micro and USB and/or SD card. It's unlikely the initial design will allow me to program up KOF2003, but that's not the focus anyway. Hopefully I'll be able to then scale-down the FPGA's (and even use CPLD's) and scale-up the memory for a more generic programmable cartridge.
As an aside; something I've been thinking about and was also raised on the #neogeodev channel recently is a custom cartridge with sprite RAM, enabling on-the-fly sprite programming which in turn can be used to generate a bitmap display! I know that the NGCD sprite RAM is programmable by the CPU, but there are timing and bandwidth limitations and AFAIK it hasn't been done outside a demo - i.e. never proven viable for arcade game-play. It would be interesting indeed to provide such a mechanism on the programmable cartridge, for demonstration if nothing else! Neo Defender anyone?
I'm hoping to kick off the design in parallel with Neo Kong; maybe the hardware will be finished by the time the porting is done!?!
Thursday 2 January 2014
Jump, jump, jump if you feel you want to...
Sorry, that's the line from my daughter's favourite song atm...
I've fixed a few bugs in the jump routine, merely by checking key register values on Z80 vs 68K. Mario can jump now, but it's still a little too high. Aside from that, his subsequent position is tracked correctly so the jump logic is 'working' - just allowing him to jump too high (and far). An amusing side-effect is the ability to jump from one girder to the next where they converge (much like a power-up in an enhanced version of the game!)
Also started on the falling logic, thinking that perhaps Mario 'falls' from a jump and that's why he wasn't stopping. That's not the case, however, (and ironically it's the falling case that is treated like jumping) and it's quite broken so I've commented it out for now until I get jumping working properly.
The thought of commenting the jumping code is still quite daunting...
I've fixed a few bugs in the jump routine, merely by checking key register values on Z80 vs 68K. Mario can jump now, but it's still a little too high. Aside from that, his subsequent position is tracked correctly so the jump logic is 'working' - just allowing him to jump too high (and far). An amusing side-effect is the ability to jump from one girder to the next where they converge (much like a power-up in an enhanced version of the game!)
Also started on the falling logic, thinking that perhaps Mario 'falls' from a jump and that's why he wasn't stopping. That's not the case, however, (and ironically it's the falling case that is treated like jumping) and it's quite broken so I've commented it out for now until I get jumping working properly.
The thought of commenting the jumping code is still quite daunting...
Wednesday 1 January 2014
Lighter than a feather
Managed to find some time last night (yes, NYE - I have a toddler who is not sleeping well atm so no parties for me) and at lunchtime today (yes, working on 1st Jan - the fun of owning your own business) to work on Neo Kong.
Last night I finished the climbing, including commenting most of the logic. During level initialisation, the code builds a table of ladder top-and-bottom coordinates, and each frame checks to see if Mario is at either end of a ladder. Not too complicated at all, but it did take some time reverse-engineering and commenting the code. So now Mario can climb to the top of the girder (and other) levels.
As an aside, the code has an anti-tamper routine that checks if the copyright message is in-tact. If not, it corrupts the above-mentioned ladder data so the game won't play properly.
The next thing I tackled was the end-of-level-check routine. That was straight-forward, cranking-the-handle type work and now when you reach the top of the girder level, Kong grabs Pauline and climbs off the top of the screen, and the game progresses to the next level. Different level types have different (albeit similar) 'reunion' sequence logic so the girder level is the only one working for now.
So today I tacked the jumping. This is the first area of the code that I've really struggled to understand how it works. In fact, not too far into it I decided to just forge ahead porting the code. There's a lot of it, and amongst it there's plenty of unknown variables and mathematics that escape my understanding for the moment (no surprise that other listings haven't commented this code either). I've ported most of the code; a few routines left that I believe have to do with grabbing the hammer mid-jump. However, it's not quite working yet...
Mario will jump, in what looks like a decent arc but roughly twice as high as he should, and instead of landing on the girder he continues to fall through the bottom of the screen, and into the top, where the game deems that the level has been completed as Mario is at the 'top'.
Given that there's so much code ported 'blind', as well as a few missing subroutines, I'm not surprised by this at all. It does however mean that I'll need to go back and try to understand what's happening. I suspect it'll take a handful (or more) of hours in the MAME debugger on both the Z80 original and Neo Kong.
Anyway, once jumping is complete I'll upload a new video showing Mario's movements and completion of the 1st level. From there-on in, I'll start on the scoring aspects of gameplay, and inevitably start to implement the barrel and fireball AI.
On a different note, an alternate DK ROM set was sent to the MAMEDEV team in the last few days. This so-called 'hard' set differs from the US set by only a handful of bytes. Given that I'm mid-analysis of DK, I couldn't resist having a look.
It's a patch to a single routine; the 'difficulty timer' routine that calculates enemy object speed from 1-5 during the game. It's based on how long you've been on a screen, plus the current level that you're playing. The patch, which overwrites unused text at the end of the ROM, always sets the speed to 5, except when the speed would normally be '1' on the girder level. So you get a short reprieve on that level, until the speed ticks over to 2, where it's immediately cranked up to 5. It's not known if it's an official patch, but it looks a little 'hacky' to me.
On a last note, after finishing the climbing code I went through the listing tallying up the percentage of code that has been analysed (which is approximately what has been ported) and was a little surprised (and a little disappointed) to learn that it's only around 50% at this point. What that means is that there's still a lot of tedious, low-level game mechanics (AI etc) to work through.
Last night I finished the climbing, including commenting most of the logic. During level initialisation, the code builds a table of ladder top-and-bottom coordinates, and each frame checks to see if Mario is at either end of a ladder. Not too complicated at all, but it did take some time reverse-engineering and commenting the code. So now Mario can climb to the top of the girder (and other) levels.
As an aside, the code has an anti-tamper routine that checks if the copyright message is in-tact. If not, it corrupts the above-mentioned ladder data so the game won't play properly.
The next thing I tackled was the end-of-level-check routine. That was straight-forward, cranking-the-handle type work and now when you reach the top of the girder level, Kong grabs Pauline and climbs off the top of the screen, and the game progresses to the next level. Different level types have different (albeit similar) 'reunion' sequence logic so the girder level is the only one working for now.
So today I tacked the jumping. This is the first area of the code that I've really struggled to understand how it works. In fact, not too far into it I decided to just forge ahead porting the code. There's a lot of it, and amongst it there's plenty of unknown variables and mathematics that escape my understanding for the moment (no surprise that other listings haven't commented this code either). I've ported most of the code; a few routines left that I believe have to do with grabbing the hammer mid-jump. However, it's not quite working yet...
Mario will jump, in what looks like a decent arc but roughly twice as high as he should, and instead of landing on the girder he continues to fall through the bottom of the screen, and into the top, where the game deems that the level has been completed as Mario is at the 'top'.
Given that there's so much code ported 'blind', as well as a few missing subroutines, I'm not surprised by this at all. It does however mean that I'll need to go back and try to understand what's happening. I suspect it'll take a handful (or more) of hours in the MAME debugger on both the Z80 original and Neo Kong.
Anyway, once jumping is complete I'll upload a new video showing Mario's movements and completion of the 1st level. From there-on in, I'll start on the scoring aspects of gameplay, and inevitably start to implement the barrel and fireball AI.
On a different note, an alternate DK ROM set was sent to the MAMEDEV team in the last few days. This so-called 'hard' set differs from the US set by only a handful of bytes. Given that I'm mid-analysis of DK, I couldn't resist having a look.
It's a patch to a single routine; the 'difficulty timer' routine that calculates enemy object speed from 1-5 during the game. It's based on how long you've been on a screen, plus the current level that you're playing. The patch, which overwrites unused text at the end of the ROM, always sets the speed to 5, except when the speed would normally be '1' on the girder level. So you get a short reprieve on that level, until the speed ticks over to 2, where it's immediately cranked up to 5. It's not known if it's an official patch, but it looks a little 'hacky' to me.
On a last note, after finishing the climbing code I went through the listing tallying up the percentage of code that has been analysed (which is approximately what has been ported) and was a little surprised (and a little disappointed) to learn that it's only around 50% at this point. What that means is that there's still a lot of tedious, low-level game mechanics (AI etc) to work through.
Subscribe to:
Posts (Atom)