Been very busy at work, but in the small amounts of spare time I have had over the last few weeks I've been concentrating on the hardware. It's changed again since the last post, but I've settled on a final architecture.
The two (2) adapters (MVS & AES) are simple passive 2-layer boards (plus two finger boards), so won't take long to design and will be cheap to prototype. I've already completed the schematics for the MVS adapter, and a quick auto-route suggests it won't take long to lay out by hand. Once I've done the complementary AES adapter, I'll get those manufactured as I can test them in 'pass-thru' mode with real cartridges and systems. I will, however, need to acquire either an MV-1C (unlikely) or a multi-slot PCB, because I'll need vertical slots for these prototypes.
I'm aiming to have some adapters ready for manufacture within the next few weeks, and certainly before the end of March. Connectors are readily available from Digikey, and the only other components are a couple of passives and a LED.
So whilst Donkey Kong has been on hold since I tested it on the NGCD, it certainly hasn't been forgotten, and I'll pick it up again whilst I'm waiting for hardware things to happen. Besides, I want that to be the first game I program onto my flash cartridge! ;)
Friday 21 February 2014
Saturday 8 February 2014
Back to hardware
This afternoon I had a spare hour or so and decided to study the cartridge connector signals in more detail in preparation for the 2nd round attempt at the cartridge adapter PCB's. It was time well spent in the end and I feel ready to tackle the hardware again.
This time around the MVS & AES cartridge adapters will each comprise both cartridge PCB connectors and a common breakout via the EURO connectors, allowing a single design for the analyser/programmer board attached to each PCB, as well as the respective system adapters. Although this means two distinct flash cartridge boards (CHA & PRG) it does reduce the total number of PCB's. It also means that the current design won't fit in a standard cartridge shell, although this is only a prototype.
The current plan is to design and manufacture the four (4) MVS/AES cartridge/system adapter boards and then plug them back-to-back and confirm both MVS & AES cartridges still work on their respective motherboards. Then I'll start on the analyser/programmer board with the aim of completing the development of the analyser functionality. That will allow me to capture traces of full bus activity on the CHA & PRG buses of both MVS & AES systems (and ultimately on the NGPACE board).
The final stage then of this phase of the project is to develop the flash cartridge PCB's and the programmer functionality of the analyser/programmer board. The idea is that the flash cartridge will generate both MVS and AES sprite bus signals and therefore allow insertion into either the MVS or AES system via the appropriate system adapter PCB.
Somewhere in there I also hope to complete the port of Donkey Kong so I can program the flash cartridge with my own homebrew software!
This time around the MVS & AES cartridge adapters will each comprise both cartridge PCB connectors and a common breakout via the EURO connectors, allowing a single design for the analyser/programmer board attached to each PCB, as well as the respective system adapters. Although this means two distinct flash cartridge boards (CHA & PRG) it does reduce the total number of PCB's. It also means that the current design won't fit in a standard cartridge shell, although this is only a prototype.
The current plan is to design and manufacture the four (4) MVS/AES cartridge/system adapter boards and then plug them back-to-back and confirm both MVS & AES cartridges still work on their respective motherboards. Then I'll start on the analyser/programmer board with the aim of completing the development of the analyser functionality. That will allow me to capture traces of full bus activity on the CHA & PRG buses of both MVS & AES systems (and ultimately on the NGPACE board).
The final stage then of this phase of the project is to develop the flash cartridge PCB's and the programmer functionality of the analyser/programmer board. The idea is that the flash cartridge will generate both MVS and AES sprite bus signals and therefore allow insertion into either the MVS or AES system via the appropriate system adapter PCB.
Somewhere in there I also hope to complete the port of Donkey Kong so I can program the flash cartridge with my own homebrew software!
Monday 3 February 2014
Neo Geo sprite limitations, RTFM and finally working!
It's been a mixed bag of frustrations, red herrings and re-reading documentation over the last few days but I'm very excited to announce that I have finally seen Donkey Kong running on my NGCD with all graphics intact!
Along the way I suspected issues with MAME/MESS, NeoCD/SDL and Raine emulators. In the end I can report that MAME/MESS appears 100% accurate with NeoCD/SDL actually rendering sprites that the hardware is simply not capable of (and sending me off on a wild goose-chase).
After a few experiments with furtek's sprite experimenter demo in MAME, and subsequently studying the SNK Neo Geo Hardware Manual in more detail, it became apparent that I was trying - in an attempt to fix the flickering issue - to produce a scaled display that the hardware wouldn't support. As time consuming as it is, the upshot of all this is that I learned a bit about the sprite hardware.
I won't bore anyone with intimate details, but in the end it was kyuuu on #neogeodev that suggested perhaps I was updating the VRAM too fast, and that was indeed the case. My background rendering had back-to-back writes to SCB1, whilst the documentation specifies a 12 CPU clock cycle delay is required.
So now I really have no excuse not to get back to finishing the port... except for work pressures and design of the flash cart...
Along the way I suspected issues with MAME/MESS, NeoCD/SDL and Raine emulators. In the end I can report that MAME/MESS appears 100% accurate with NeoCD/SDL actually rendering sprites that the hardware is simply not capable of (and sending me off on a wild goose-chase).
After a few experiments with furtek's sprite experimenter demo in MAME, and subsequently studying the SNK Neo Geo Hardware Manual in more detail, it became apparent that I was trying - in an attempt to fix the flickering issue - to produce a scaled display that the hardware wouldn't support. As time consuming as it is, the upshot of all this is that I learned a bit about the sprite hardware.
I won't bore anyone with intimate details, but in the end it was kyuuu on #neogeodev that suggested perhaps I was updating the VRAM too fast, and that was indeed the case. My background rendering had back-to-back writes to SCB1, whilst the documentation specifies a 12 CPU clock cycle delay is required.
So now I really have no excuse not to get back to finishing the port... except for work pressures and design of the flash cart...
Neo Kong on NGCD... hmm...
Not as smooth sailing as I'd have hoped but I finally got to see some less than stellar results on the NGCD. In fact it took several hours on a Saturday night, and thereafter plenty of minutes sneaking into the study to finally see something on this (Sunday) evening, and finally even managed to burn a CD to try on my newly acquired top loader unit.
Although I had built Bey's Phoenix emulator for the NGCD, and even built it for the MVS, I hadn't gotten around to trying Donkey Kong on the NGCD before. I expected to have to do a few tweaks, but after hours of tweaking I was still getting a blank screen! My main suspect was the PRG file header, and in the end I even filled in the vectors and several dummy routines for every interrupt - to no avail! I was getting nowhere.
I turned to Raine, whose 'console' implements a debugger of sorts. It crashed so often it was almost useless, but I did at least discover that the game was loading properly and then wiping itself soon after booting. Based on that evidence I had a very strong suspicion that there was an issue in my use of the BIOS interface routines.
Next I discovered - to my surprise - that the Neo Geo CDZ driver in MESS was reported to work properly, which filled me with a great hope that I could debug my code as I have been doing all along on the MVS under MAME. Alas I couldn't for the life of me get any CD image to work, let alone Donkey Kong, and finally asked for help on the official MESS forums. After some feedback and further mucking about, I could finally get MESS to load a CD image and debug it!
I discovered that it wasn't even executing the 1st VBLANK interrupt before rebooting, and then trapped a call into the USER routine with a parameter that doesn't happen on the MVS. Turns out I wasn't exiting properly and after fixing that it actually ran! Corrupt graphics, but it ran!
After pondering the graphics and hitting a brick wall for an hour or so, it occurred to me that perhaps my NGCD sprite file was out-of-date... and to my relief I discovered that was indeed the case! When I did my last re-ordering of the sprites (for rotated and non-rotated versions) I neglected to copy the updated NGCD sprite file into my Neo Kong development environment. I rectified that and - viola!
So it was with much excitement that I burned an ISO and popped it into my console. I watched it load and then... damn! The graphics looked 'right', they were recognisable, but they flickered severely - all over the screen! I could actually start a game and control Mario, but it was unplayable.
I should note that it displays perfectly under NeoCD/SDL, Raine and MESS!
Oh well, back to do more research. I do recall something about sprite placement and certain areas that should be left clear... I ignored it at the time as I wasn't seeing any issues but obviously now I need to go back and re-read it properly.
Still, technically it's the first program that I've ever written that I've seen running on real console hardware, and that's something!
Although I had built Bey's Phoenix emulator for the NGCD, and even built it for the MVS, I hadn't gotten around to trying Donkey Kong on the NGCD before. I expected to have to do a few tweaks, but after hours of tweaking I was still getting a blank screen! My main suspect was the PRG file header, and in the end I even filled in the vectors and several dummy routines for every interrupt - to no avail! I was getting nowhere.
I turned to Raine, whose 'console' implements a debugger of sorts. It crashed so often it was almost useless, but I did at least discover that the game was loading properly and then wiping itself soon after booting. Based on that evidence I had a very strong suspicion that there was an issue in my use of the BIOS interface routines.
Next I discovered - to my surprise - that the Neo Geo CDZ driver in MESS was reported to work properly, which filled me with a great hope that I could debug my code as I have been doing all along on the MVS under MAME. Alas I couldn't for the life of me get any CD image to work, let alone Donkey Kong, and finally asked for help on the official MESS forums. After some feedback and further mucking about, I could finally get MESS to load a CD image and debug it!
I discovered that it wasn't even executing the 1st VBLANK interrupt before rebooting, and then trapped a call into the USER routine with a parameter that doesn't happen on the MVS. Turns out I wasn't exiting properly and after fixing that it actually ran! Corrupt graphics, but it ran!
After pondering the graphics and hitting a brick wall for an hour or so, it occurred to me that perhaps my NGCD sprite file was out-of-date... and to my relief I discovered that was indeed the case! When I did my last re-ordering of the sprites (for rotated and non-rotated versions) I neglected to copy the updated NGCD sprite file into my Neo Kong development environment. I rectified that and - viola!
So it was with much excitement that I burned an ISO and popped it into my console. I watched it load and then... damn! The graphics looked 'right', they were recognisable, but they flickered severely - all over the screen! I could actually start a game and control Mario, but it was unplayable.
I should note that it displays perfectly under NeoCD/SDL, Raine and MESS!
Oh well, back to do more research. I do recall something about sprite placement and certain areas that should be left clear... I ignored it at the time as I wasn't seeing any issues but obviously now I need to go back and re-read it properly.
Still, technically it's the first program that I've ever written that I've seen running on real console hardware, and that's something!
Saturday 1 February 2014
Second thoughts and NGCD
Last night I started designing a couple of the adapter PCB's and realised I'd need a few more adapters than I originally thought. I also realised that the clearance between the cartridge PCB's wasn't adequate for EURO connectors. That sparked a discussion session with my colleague over lunch and I came away with a different take on the adapters.
I'm still mulling over the consequences but I think in the end it'll mean less adapters but a more straightforward design, at the expense of being able to house it in a standard cartridge shell. Interestingly today I stumbled across an old picture of part of a Neo Geo development system that I had downloaded from the net some time ago and it is of an adapter very similar to what I'm currently considering!
Anyway, still very early days yet...
I also received my NGCD unit from Japan today, and I'm happy to announce that it arrived in good working condition. I successfully burned one game (Metal Slug which, incidentally, I do own the MVS cartridge for) just to test the burn method in preparation for getting Donkey Kong running on it...
...but first I need to get it running under the NeoCD/SDL emulator. That has proved elusive so far. In the past I've managed to build C projects successfully for both systems, so I'm at a loss to explain why Donkey Kong is not running. I've even fired up Raine and attempted to use the console (debugger) to garner some clues, but Raine itself crashes too regularly to be of much use.
I'm still mulling over the consequences but I think in the end it'll mean less adapters but a more straightforward design, at the expense of being able to house it in a standard cartridge shell. Interestingly today I stumbled across an old picture of part of a Neo Geo development system that I had downloaded from the net some time ago and it is of an adapter very similar to what I'm currently considering!
Anyway, still very early days yet...
I also received my NGCD unit from Japan today, and I'm happy to announce that it arrived in good working condition. I successfully burned one game (Metal Slug which, incidentally, I do own the MVS cartridge for) just to test the burn method in preparation for getting Donkey Kong running on it...
...but first I need to get it running under the NeoCD/SDL emulator. That has proved elusive so far. In the past I've managed to build C projects successfully for both systems, so I'm at a loss to explain why Donkey Kong is not running. I've even fired up Raine and attempted to use the console (debugger) to garner some clues, but Raine itself crashes too regularly to be of much use.
Subscribe to:
Posts (Atom)