Work is continuing, albeit slowly, on the flash cartridge.
The schematics are all-but-complete, according to my colleague. The SRAM for a pseudo 'bitmap' mode has been included as well. I still need to discard a few debug pins on the design as the FPGA pin count has been exceeded on the CHR board, but otherwise it's all good.
I've created the FPGA design, the NIOS, and the software project for programming the flash. The FatFS module for reading from SD card has been compiled-in and it seems the EP3C16 will be adequate for the task (on-chip RAM being the critical resource). The prototypes will be loaded with the EP3C40 in any case.
Layout schedule will depend on the availability and the motivation of my colleague. Assuming he gets bored over the break, we might have something ready for review in January!
In the mean-time, I've acquired a 'sacrificial' (faulty palette but otherwise fully operational) AES console which turned out to be a bit of a Frankenstein. The case is for a 5V model but the motherboard is clearly a 10V design. But I have confirmed it powers up and runs a game.
I also acquired Metal Slug 3 for the MVS, which means I now have episodes 1-3, and I'm eyeing off 4 for a decent price on eBay right now. Of course this is for The Project, and not for playing (or for the sake of collecting). Right!
Friday, 19 December 2014
Thursday, 27 November 2014
Quick update
As mentioned, the re-think has reduced the PCB design count from 3 to 1.
This does make the cartridge configuration of the adapters obsolete, unfortunately. Whilst the PCB's themselves won't be wasted (same PCB for cartridge and system adapters) there's a few connectors that may be.
After taking a closer look at the protection and bank switching on the existing commercial cartridges, it soon became clear that an all-encompassing design would require an FPGA capable of snooping and/or routing almost every pin on the cartridge bus. So I've decided to scrap the analyzer/programmer PCB and have the flash cartridge capable of analyzing the bus and also programming itself.
The prototype design will be over-engineered somewhat; I want to address the Neo Geo technical issues without a half-baked design getting in the way. There may be scope for a limited run of this design, but it will be expensive. In any case I'd look at possibly two (2) products from this - a cheaper, cut-down Homebrew Edition that is suited to testing and playing homebrew titles only, and the full-blown Pro Gamer Edition that could, well, play any Neo Geo title.
I've also included some SRAM on the design, for the purpose of experimenting with dynamic sprite tile data. This would in effect allow for a bitmap display mode, opening up all sorts of possibilities for ports from other platforms (Defender, anyone?)
As for progress, all the devices have been specified and chosen, and schematic capture is under way. On the firmware side, the FPGA projects have been mapped out at the top level and a NIOS core has been added to the PRG project - mainly to gauge adequacy of the chosen FPGA.
I'm hoping things will progress quickly from here, as the design really is simple, and it's possible we could have the PCB's ready for manufacture this calendar year! It's not going to be a cheap process as they will need to be assembled externally, so timing may also depend on available funds.
This does make the cartridge configuration of the adapters obsolete, unfortunately. Whilst the PCB's themselves won't be wasted (same PCB for cartridge and system adapters) there's a few connectors that may be.
After taking a closer look at the protection and bank switching on the existing commercial cartridges, it soon became clear that an all-encompassing design would require an FPGA capable of snooping and/or routing almost every pin on the cartridge bus. So I've decided to scrap the analyzer/programmer PCB and have the flash cartridge capable of analyzing the bus and also programming itself.
The prototype design will be over-engineered somewhat; I want to address the Neo Geo technical issues without a half-baked design getting in the way. There may be scope for a limited run of this design, but it will be expensive. In any case I'd look at possibly two (2) products from this - a cheaper, cut-down Homebrew Edition that is suited to testing and playing homebrew titles only, and the full-blown Pro Gamer Edition that could, well, play any Neo Geo title.
I've also included some SRAM on the design, for the purpose of experimenting with dynamic sprite tile data. This would in effect allow for a bitmap display mode, opening up all sorts of possibilities for ports from other platforms (Defender, anyone?)
As for progress, all the devices have been specified and chosen, and schematic capture is under way. On the firmware side, the FPGA projects have been mapped out at the top level and a NIOS core has been added to the PRG project - mainly to gauge adequacy of the chosen FPGA.
I'm hoping things will progress quickly from here, as the design really is simple, and it's possible we could have the PCB's ready for manufacture this calendar year! It's not going to be a cheap process as they will need to be assembled externally, so timing may also depend on available funds.
Wednesday, 19 November 2014
Let there be only one
Major rethink of the project over the last few days. All good news though!
I won't go into too much detail as it's very late, but in a nutshell the programmer/analyzer board has been scrapped, and the 2-PCB flash cartridge (PRG & CHA) in the pipeline has been brought forward and replaced with a single PCB that is also a programmer/analyzer. IOW, a single PCB design will do everything that previously three (3) were intended to do!
This has all been prompted by more detailed analysis of the various cartridge protection (banking and encryption) schemes which, although not overly complex, require a lot of routing through an FPGA if it is to cater for every cartridge.
And adding to the mix is the possibility of adding a 'bitmap' mode to the Neo Geo via the cartridge!
More details in a subsequent post.
I won't go into too much detail as it's very late, but in a nutshell the programmer/analyzer board has been scrapped, and the 2-PCB flash cartridge (PRG & CHA) in the pipeline has been brought forward and replaced with a single PCB that is also a programmer/analyzer. IOW, a single PCB design will do everything that previously three (3) were intended to do!
This has all been prompted by more detailed analysis of the various cartridge protection (banking and encryption) schemes which, although not overly complex, require a lot of routing through an FPGA if it is to cater for every cartridge.
And adding to the mix is the possibility of adding a 'bitmap' mode to the Neo Geo via the cartridge!
More details in a subsequent post.
Thursday, 13 November 2014
Back in a flash!
Copping a lot of heat to get the Neo Geo flash cartridge finished off. To be honest, I'm feeling burnt out at work and the knock-on effect is that I don't feel motivated to do any computer-related activities in my own time either - even fun stuff like Neo Geo. So I find myself riding my bike and surfing the net...
However I'm making a concerted effort to get the grey matter ticking over and move things along now, particularly in light of the fact that come Jan 27th 2015 - or thereabouts - I'll have a lot less time for leisurely pursuits with the arrival of a little boy.
To this end, I decided to look at cartridge capacities and try to work out what size flash devices I'd need on a programmable flash cartridge. Keeping in mind that the prototype need only be large enough for a single game, I'd like the option for that to be ideally any game currently available for the Neo Geo! For the purposes of this exercise, I chose to use The King Of Fighters 2003 as a benchmark.
The numbers I ended up with (KOF2003 bracketed) are:
I want to get a preliminary design of the flash cartridge drafted before I commit the programmer/analyzer PCB to manufacture. However I need to do some more research on the bank switching and protection on the various carts before this task is complete. Either that or throw a large CPLD into the mix, and pass most of the address lines through it...
However I'm making a concerted effort to get the grey matter ticking over and move things along now, particularly in light of the fact that come Jan 27th 2015 - or thereabouts - I'll have a lot less time for leisurely pursuits with the arrival of a little boy.
To this end, I decided to look at cartridge capacities and try to work out what size flash devices I'd need on a programmable flash cartridge. Keeping in mind that the prototype need only be large enough for a single game, I'd like the option for that to be ideally any game currently available for the Neo Geo! For the purposes of this exercise, I chose to use The King Of Fighters 2003 as a benchmark.
The numbers I ended up with (KOF2003 bracketed) are:
- P-ROM (9MB) = 16MB/128Mb (x16)
- C-ROM (64MB) = 64MB/512Mb (x32)
- V-ROM (16MB) = 16MB/128Mb (TBA)
- S-ROM (none) = 512KB/4Mb (x8)
- M-ROM (512KB) = 512KB/4Mb (x8)
I want to get a preliminary design of the flash cartridge drafted before I commit the programmer/analyzer PCB to manufacture. However I need to do some more research on the bank switching and protection on the various carts before this task is complete. Either that or throw a large CPLD into the mix, and pass most of the address lines through it...
Wednesday, 15 October 2014
0 days has September...
September has been and gone and not a lot of progress unfortunately, least of all my hope that I would have at least sent the analyser PCB out for manufacture.
I don't really have any good excuse except that I am trying to fit a lot into my days and at the end of it all there's little energy left to devote to NGPACE. As I've maintained before, it's not the type of project that lends itself to working on in short bursts; it is for this very reason that I was diverted onto software projects in the past. Lately though I haven't even being doing that; I've spent my spare time being lazy on eBay and forums (retro and otherwise).
The only Neo Geo related activity has been the acquisition of a few more AES cartridges and a bulk lot of NGCD titles to boost my collection a little. I'm still undecided as to whether I'm collecting AES or NGCD, so for now my strategy is to pick up the dirt-cheap titles whenever they present themselves, before prices inevitably get even sillier than they are now. I briefly toyed with the idea of picking up a copy of Razion for the AES, but it's a big investment and I ultimately decided against it.
Back on topic, I've been lamenting the lack of progress to my colleagues and they've been urging me to allocate time and push ahead to get it finished. They're right of course - I need to get this done before someone else beats me to it, which would make all this effort and expense for nought. That would be extremely disappointing.
So on that note, I am going to endeavour to schedule time into my week solely for working on NGPACE. What that means in the short term is completing the programmer FPGA image and reviewing the PCB before sending it out for manufacture, ideally drafting a preliminary flash cartridge schematic in parallel.
Having a working analyser/programmer PCB in my hands before Xmas would be something I could realistically aim for. Shortly thereafter, my son is due so I'd imagine not a lot will be done early in the new year. At least can say with certainty that I'll have produced something before the end of January!
I don't really have any good excuse except that I am trying to fit a lot into my days and at the end of it all there's little energy left to devote to NGPACE. As I've maintained before, it's not the type of project that lends itself to working on in short bursts; it is for this very reason that I was diverted onto software projects in the past. Lately though I haven't even being doing that; I've spent my spare time being lazy on eBay and forums (retro and otherwise).
The only Neo Geo related activity has been the acquisition of a few more AES cartridges and a bulk lot of NGCD titles to boost my collection a little. I'm still undecided as to whether I'm collecting AES or NGCD, so for now my strategy is to pick up the dirt-cheap titles whenever they present themselves, before prices inevitably get even sillier than they are now. I briefly toyed with the idea of picking up a copy of Razion for the AES, but it's a big investment and I ultimately decided against it.
Back on topic, I've been lamenting the lack of progress to my colleagues and they've been urging me to allocate time and push ahead to get it finished. They're right of course - I need to get this done before someone else beats me to it, which would make all this effort and expense for nought. That would be extremely disappointing.
So on that note, I am going to endeavour to schedule time into my week solely for working on NGPACE. What that means in the short term is completing the programmer FPGA image and reviewing the PCB before sending it out for manufacture, ideally drafting a preliminary flash cartridge schematic in parallel.
Having a working analyser/programmer PCB in my hands before Xmas would be something I could realistically aim for. Shortly thereafter, my son is due so I'd imagine not a lot will be done early in the new year. At least can say with certainty that I'll have produced something before the end of January!
Sunday, 31 August 2014
August Update
I've finished the Quartus project pin assignments for both the CHA and PRG projects. I've also built the analyser configuration for each of those projects and they appear to build without issue. Nothing exciting here as each pin is configured as I/O and tri-stated so that the SignalTap analyser can be enabled. I've also confirmed there's enough memory on the device (EP3C16) for a decent trace.
The programmer function build for the CHA project includes a NIOS with sufficient PIO to drive the three (3) buses and - in theory - the FLASH control pins. I've hooked up the former, but not the latter. That's my next task on the list, before I attempt to write the programmer function software.
Once that's done I'll repeat the exercise for the PRG project, and we should be (almost) good to go for manufacture of the programmer/analyser PCB - it would be prudent to do further research on the known bank-switching and protection mechanisms in newer cartridges before committing the design to manufacture.
The programmer/analyser should (incidentally) also have the capability to operate as an MVS->AES converter board. No doubt there's some tweaking to be done in the sprite data serialisation, given the technical issues with most of the commercial converter boards. It's something I'll have to tackle on the flash cartridge eventually, as it will of course operate in both MVS & AES systems. I do not, however, have any intention of producing commercial converter boards; I'll leave that to those who have already done so. I have no desire to encroach on existing markets.
Realistically, I'm hoping to send out the PCB before the end of September.
The programmer function build for the CHA project includes a NIOS with sufficient PIO to drive the three (3) buses and - in theory - the FLASH control pins. I've hooked up the former, but not the latter. That's my next task on the list, before I attempt to write the programmer function software.
Once that's done I'll repeat the exercise for the PRG project, and we should be (almost) good to go for manufacture of the programmer/analyser PCB - it would be prudent to do further research on the known bank-switching and protection mechanisms in newer cartridges before committing the design to manufacture.
The programmer/analyser should (incidentally) also have the capability to operate as an MVS->AES converter board. No doubt there's some tweaking to be done in the sprite data serialisation, given the technical issues with most of the commercial converter boards. It's something I'll have to tackle on the flash cartridge eventually, as it will of course operate in both MVS & AES systems. I do not, however, have any intention of producing commercial converter boards; I'll leave that to those who have already done so. I have no desire to encroach on existing markets.
Realistically, I'm hoping to send out the PCB before the end of September.
Thursday, 28 August 2014
Will it blend?
I'm thinking, in order to increase the desirability of a Neo Geo Motherboard replacement, of including a built-in esky with ice crusher, waterproof speakers, and USB charger.
Think it'll fly?
Think it'll fly?
Wednesday, 20 August 2014
Analyse this!
Well, this is almost as much a shock to me as it will no doubt be to my thousands of two followers, but the analyser/programmer PCB is ready for manufacture! Yes, you read that right. From vague promises of a schematic in progress to a finished board in a single blog entry. Wow!
You see, my colleague has been toiling away on the design in between paid work which has been, unfortunately, quite sporadic for him lately. I knew he'd made some headway with the layout, but it came as a complete surprise when he presented me with the gerbers this afternoon!
Needless to say, I have a lot of catching up to do. I had started the HDL months ago, but that had languished on the back-burner whilst Lode Runner took all my spare time. Now I need to crank up Quartus again and finish it off, to ensure that the connectivity (eg. pin mapping) is correct and that the hardware design is adequate for the intended functionality.
And before I send out the board for manufacture, I also want to do a preliminary draft of the schematic for the flash cartridge, for the same reasons outlined above. And of course I need to do a thorough design review of the current PCB, so there's a fast growing pile of work on my plate.
Once manufactured, I'll be in a position to run the analyser functionality through its paces. The point was to obtain detailed bus timing diagrams for both CHA and PRG cartridge buses, via the Quartus SignalTap tool - information that will be invaluable for the FPGA implementation of the motherboard. The programmer functionality will only be useful when the next PCB - the flash cart - has been finished.
My final comment on the subject for this entry is that my dreams of hand-assembling the few (4?) boards that I will get loaded have been dashed by my colleague's rather... comprehensive... design practices. Suffice it to say, industrial strength power supplies and I/O protection are included as standard. I guess that means the production version won't require much in the way of a re-spin.
And a note on the possible Neo Geo port of Lode Runner I mentioned in the last entry; instead of producing a 68K translation I wrote a C version which should be (more) readily portable to any 16-bit or newer system. Progress here.
The next few updates on the analyser/programmer PCB should be a lot more frequent now!
You see, my colleague has been toiling away on the design in between paid work which has been, unfortunately, quite sporadic for him lately. I knew he'd made some headway with the layout, but it came as a complete surprise when he presented me with the gerbers this afternoon!
Needless to say, I have a lot of catching up to do. I had started the HDL months ago, but that had languished on the back-burner whilst Lode Runner took all my spare time. Now I need to crank up Quartus again and finish it off, to ensure that the connectivity (eg. pin mapping) is correct and that the hardware design is adequate for the intended functionality.
And before I send out the board for manufacture, I also want to do a preliminary draft of the schematic for the flash cartridge, for the same reasons outlined above. And of course I need to do a thorough design review of the current PCB, so there's a fast growing pile of work on my plate.
Once manufactured, I'll be in a position to run the analyser functionality through its paces. The point was to obtain detailed bus timing diagrams for both CHA and PRG cartridge buses, via the Quartus SignalTap tool - information that will be invaluable for the FPGA implementation of the motherboard. The programmer functionality will only be useful when the next PCB - the flash cart - has been finished.
My final comment on the subject for this entry is that my dreams of hand-assembling the few (4?) boards that I will get loaded have been dashed by my colleague's rather... comprehensive... design practices. Suffice it to say, industrial strength power supplies and I/O protection are included as standard. I guess that means the production version won't require much in the way of a re-spin.
And a note on the possible Neo Geo port of Lode Runner I mentioned in the last entry; instead of producing a 68K translation I wrote a C version which should be (more) readily portable to any 16-bit or newer system. Progress here.
The next few updates on the analyser/programmer PCB should be a lot more frequent now!
Tuesday, 17 June 2014
June 2014 Update
Again, a month since my last update and again, work has prevented me from spending any significant time on this project.
My colleague has continued to work on this when he's available though, so it is forging ahead. Just yesterday we did some measurements on the +5V rail to ensure the power supplies that have been designed for the programmer/analyzer board are sufficient - they are.
Very soon I'll need to pick up the FPGA projects again as the schematics near completion. However we'll probably start work on the flash cartridge before manufacturing our prototype, just to minimise the risk that we've forgotten something crucial on the programmer/analyzer board. So nothing tangible for another few months I'm afraid.
In the meantime I'm considering a Neo Geo port of my all-but-complete Coco 3 port of Apple II Lode Runner. It'll be an experiment in automated static translation from 6502/6809 to 68K. And of course I need to finish off my half-complete Donkey Kong port as well...
My colleague has continued to work on this when he's available though, so it is forging ahead. Just yesterday we did some measurements on the +5V rail to ensure the power supplies that have been designed for the programmer/analyzer board are sufficient - they are.
Very soon I'll need to pick up the FPGA projects again as the schematics near completion. However we'll probably start work on the flash cartridge before manufacturing our prototype, just to minimise the risk that we've forgotten something crucial on the programmer/analyzer board. So nothing tangible for another few months I'm afraid.
In the meantime I'm considering a Neo Geo port of my all-but-complete Coco 3 port of Apple II Lode Runner. It'll be an experiment in automated static translation from 6502/6809 to 68K. And of course I need to finish off my half-complete Donkey Kong port as well...
Tuesday, 27 May 2014
May 2014 Update
Thought I'd give a quick update on the state of this project, since it's been about a month since I tested the adapters on real Neo Geo hardware.
Whilst it has been very busy for me at work, and I haven't had free blocks of time that have been significant enough to do much on this particular aspect of the project, my colleague has voluntarily taken up the torch and is working on schematic capture of the programmer/analyzer board.
He has designed the voltage level shifting for the board, added the Cyclone III and today, the RS-232 port. There isn't a lot more to add to the schematic design; the SD card, FPGA configuration device and the power supplies probably comprise the rest of the board. The real work here is in the layout, and ensuring that the design is adequate for flash cart programming. To this end, it would be prudent to design the flash cartridge circuit before committing this PCB to manufacture.
I also believe the proposed FPGA will be adequate to enable MVS->AES converter functionality!
I have actually started to code up the FPGA HDL projects for each configuration of the board; whilst I'll require completely different projects for the CHA & PRG personalities, I'm hoping to get away with a single project (configured at run-time) for the programmer & analyzer functions. The FPGA will have a simple NIOS (soft-core CPU) and will likely be running FatFs to read files from the SD card - hopefully I won't require any external SRAM to run the programmer software. Again, it would be prudent to finish this design before manufacturing any boards!
Whilst it has been very busy for me at work, and I haven't had free blocks of time that have been significant enough to do much on this particular aspect of the project, my colleague has voluntarily taken up the torch and is working on schematic capture of the programmer/analyzer board.
He has designed the voltage level shifting for the board, added the Cyclone III and today, the RS-232 port. There isn't a lot more to add to the schematic design; the SD card, FPGA configuration device and the power supplies probably comprise the rest of the board. The real work here is in the layout, and ensuring that the design is adequate for flash cart programming. To this end, it would be prudent to design the flash cartridge circuit before committing this PCB to manufacture.
I also believe the proposed FPGA will be adequate to enable MVS->AES converter functionality!
I have actually started to code up the FPGA HDL projects for each configuration of the board; whilst I'll require completely different projects for the CHA & PRG personalities, I'm hoping to get away with a single project (configured at run-time) for the programmer & analyzer functions. The FPGA will have a simple NIOS (soft-core CPU) and will likely be running FatFs to read files from the SD card - hopefully I won't require any external SRAM to run the programmer software. Again, it would be prudent to finish this design before manufacturing any boards!
Wednesday, 30 April 2014
MVS Adapters and a world first???
My colleague kindly finished soldering the MVS adapters, though I suspect it irked him that my soldering (arguably) wasn't up to scratch. I certainly didn't see anything wrong with it, and I haven't really had any problems with it in the past... but I can't complain considering he saved me the task!
So, I'm happy to report that the MVS adapter also works fine - that's 2 from 2!!! It's a bit tight on the horizontal 1-slot - in fact it does interfere with a cap on my MV-1FZ - and we're likely to run into more problems once the programmer/analyser board is connected, so I suspect I'll be repairing the multi-slot PCB's that I bought for this very eventuality.
What I was really keen to test, however, was swapping the two cartridge adapters for each system, to see if they would at least boot on the other hardware.
The obvious first choice was an MVS cartridge in the AES - there are several converter boards out there - and I thought it would be the more likely of the two configurations to work. Well, unfortunately that wasn't the case; my UNIBIOS-enabled AES system simply displays the same blank white screen that you get when you have no cartridge inserted. Quite disappointing. Also unfortunate was the fact that I had left my one-and-only Neo Geo controller at home, and I had no way to tweak UNIBIOS settings to see if I could coax it into working. So that will have to wait until another day.
EDIT: I just tried it again - and it worked!!! I guess I wasn't holding my tongue right!?!
So it was without much optimism that I plugged the AES cartridge into the MVS board and switched it on. Much to my surprise - no to mention delight - I was greeted with a mess of non-graphics that was none-the-less unmistakenly the rotating NEO-GEO logo, and then the FIX layer text appeared!!!
Not long after that, the demo of Fatal Fury 2 started running with the FIX layer intact and random data for the sprites (although in theory I would have expected fully transparent pixels, since I'd grounded the AES sprite data pins on the adapter). But I'll take what I got!
EDIT: The MVS sprite data lines are actually not connected (floating) so that would explain the random sprite data. OTOH the MVS cartridge in the AES system has the grounded serial sprite bus and I do indeed see black/transparent pixels on that system. So all good!
Regardless, this is a very promising result, and has me wondering if this is indeed the first time anyone has ever run an AES cartridge on an MVS motherboard? Not that it is particularly useful - it's merely a by-product of my design - as it simply isn't possible (according to my limited analysis) to have the serial sprite data from the AES cartridge re-combined as parallel data, only to be re-serialised internally by the MVS hardware with the correct timing.
I'll therefore return to the issue of the MVS->AES adapter as soon as the opportunity permits with a renewed expectation that it should actually just work.
Finally, to return to the indecision I expressed in my last post; I've decided to keep my prototype flash cartridge as simple as possible, and stick to the original plan of using flash devices that must be programmed via the programmer PCB. I figure that it's adequate for my requirements in the short term, and more important that I maintain the momentum on the project.
So, I'm happy to report that the MVS adapter also works fine - that's 2 from 2!!! It's a bit tight on the horizontal 1-slot - in fact it does interfere with a cap on my MV-1FZ - and we're likely to run into more problems once the programmer/analyser board is connected, so I suspect I'll be repairing the multi-slot PCB's that I bought for this very eventuality.
What I was really keen to test, however, was swapping the two cartridge adapters for each system, to see if they would at least boot on the other hardware.
The obvious first choice was an MVS cartridge in the AES - there are several converter boards out there - and I thought it would be the more likely of the two configurations to work. Well, unfortunately that wasn't the case; my UNIBIOS-enabled AES system simply displays the same blank white screen that you get when you have no cartridge inserted. Quite disappointing. Also unfortunate was the fact that I had left my one-and-only Neo Geo controller at home, and I had no way to tweak UNIBIOS settings to see if I could coax it into working. So that will have to wait until another day.
EDIT: I just tried it again - and it worked!!! I guess I wasn't holding my tongue right!?!
So it was without much optimism that I plugged the AES cartridge into the MVS board and switched it on. Much to my surprise - no to mention delight - I was greeted with a mess of non-graphics that was none-the-less unmistakenly the rotating NEO-GEO logo, and then the FIX layer text appeared!!!
 |
| An AES cartridge running on an MVS motherboard |
Not long after that, the demo of Fatal Fury 2 started running with the FIX layer intact and random data for the sprites (although in theory I would have expected fully transparent pixels, since I'd grounded the AES sprite data pins on the adapter). But I'll take what I got!
EDIT: The MVS sprite data lines are actually not connected (floating) so that would explain the random sprite data. OTOH the MVS cartridge in the AES system has the grounded serial sprite bus and I do indeed see black/transparent pixels on that system. So all good!
 |
| AES Fatal Fury 2 - all working but for random sprite data |
Regardless, this is a very promising result, and has me wondering if this is indeed the first time anyone has ever run an AES cartridge on an MVS motherboard? Not that it is particularly useful - it's merely a by-product of my design - as it simply isn't possible (according to my limited analysis) to have the serial sprite data from the AES cartridge re-combined as parallel data, only to be re-serialised internally by the MVS hardware with the correct timing.
 |
| An AES cartridge plugged into an MV-1FZ motherboard |
Finally, to return to the indecision I expressed in my last post; I've decided to keep my prototype flash cartridge as simple as possible, and stick to the original plan of using flash devices that must be programmed via the programmer PCB. I figure that it's adequate for my requirements in the short term, and more important that I maintain the momentum on the project.
Tuesday, 29 April 2014
Decisions, decisions...
First; I simply haven't had the time to finish soldering up the MVS adapter, though I have almost finished the MVS Cartridge adapter. It's not difficult, but tedious, given that the pair of MVS adapters have 1,080 pins between them. Plus I've also been competing for time in the lab and, unfortunately, real work gets priority for some reason!
I've had a few questions both here and elsewhere on the make-up of my planned flash cartridge. Given that I've decided it would be prudent to design it in parallel with the analyser/programmer PCB, I really need to sort that out ASAP if I'm going to move ahead with the project in the short term, which I certainly plan to do.
Initially I was planning on designing a pure flash cartridge, which required programming via the analyser/programmer PCB but would then subsequently be a non-volatile, instant-on Neo Geo cartridge. It would have capacity for (at most) a single commercial title, and certainly not designed to be a general multi-cart.
The primary reason for this is that I wanted a simple, quick-to-prototype design that wouldn't get bogged down in the design decision stage. The cartridge would initially allow me to run my own home-brew software on real MVS & AES boards, run any commercial title on the NGPACE motherboard (for testing), and finally allow me to write software to assist in the development and testing of the NGPACE motherboard project.
The 'product' spin would incorporate the programmer on-board and/or utilise some form of volatile memory that could be programmed on-the-fly from, say, SD card. It does increase the risk somewhat of the 2nd spin, but I do believe that most of the challenge in this phase is getting the actual cartridge bus right and the non-ROM functions of the cartridge working for all commercial titles.
There is some temptation to go straight to this version of the board - it would allow faster turn-around times on writing and running software of course - but that is perhaps not important with the ability to do much of the work under software emulation. It's also worthy to note that if the flash cartridge does not require the programmer PCB, then there's very little point in designing the analyser board (at significant expense).
What would be interesting however, is the possibility of using RAM-based sprite memory and (also) providing access via the 68K bus. The up-shot of all this would be to provide a sort of bit-map memory, not unlike the MSX has, for example. The trick is accommodating sufficient CPU access bandwidth to make it truly useful, which I believe could be done with faster modern RAM.
That would open up all sorts of possibilities on the system, in particular porting some classic arcade and computer games. One might argue that it's then no longer a Neo Geo, but I would argue that several consoles in the past have used cartridges with additional hardware to enhance the system's capabilities.
Either way, my initial focus is finishing the assembly of and testing the MVS adapters, then moving on to the design of the other PCB's ASAP. So there's a good chance I'll simply stick with my original plan of a simple flash-only cartridge, and get the next phase done-and-dusted before the next millennium.
I've had a few questions both here and elsewhere on the make-up of my planned flash cartridge. Given that I've decided it would be prudent to design it in parallel with the analyser/programmer PCB, I really need to sort that out ASAP if I'm going to move ahead with the project in the short term, which I certainly plan to do.
Initially I was planning on designing a pure flash cartridge, which required programming via the analyser/programmer PCB but would then subsequently be a non-volatile, instant-on Neo Geo cartridge. It would have capacity for (at most) a single commercial title, and certainly not designed to be a general multi-cart.
The primary reason for this is that I wanted a simple, quick-to-prototype design that wouldn't get bogged down in the design decision stage. The cartridge would initially allow me to run my own home-brew software on real MVS & AES boards, run any commercial title on the NGPACE motherboard (for testing), and finally allow me to write software to assist in the development and testing of the NGPACE motherboard project.
The 'product' spin would incorporate the programmer on-board and/or utilise some form of volatile memory that could be programmed on-the-fly from, say, SD card. It does increase the risk somewhat of the 2nd spin, but I do believe that most of the challenge in this phase is getting the actual cartridge bus right and the non-ROM functions of the cartridge working for all commercial titles.
There is some temptation to go straight to this version of the board - it would allow faster turn-around times on writing and running software of course - but that is perhaps not important with the ability to do much of the work under software emulation. It's also worthy to note that if the flash cartridge does not require the programmer PCB, then there's very little point in designing the analyser board (at significant expense).
What would be interesting however, is the possibility of using RAM-based sprite memory and (also) providing access via the 68K bus. The up-shot of all this would be to provide a sort of bit-map memory, not unlike the MSX has, for example. The trick is accommodating sufficient CPU access bandwidth to make it truly useful, which I believe could be done with faster modern RAM.
That would open up all sorts of possibilities on the system, in particular porting some classic arcade and computer games. One might argue that it's then no longer a Neo Geo, but I would argue that several consoles in the past have used cartridges with additional hardware to enhance the system's capabilities.
Either way, my initial focus is finishing the assembly of and testing the MVS adapters, then moving on to the design of the other PCB's ASAP. So there's a good chance I'll simply stick with my original plan of a simple flash-only cartridge, and get the next phase done-and-dusted before the next millennium.
Thursday, 24 April 2014
AES Adapters
As always, new toys turn up at the worst possible time - when work is at its busiest - and the adapters are no exception. Fortunately, a colleague (who did the layout for me) with a little more time on his hands came into the office today and volunteered to do some soldering.
He managed to complete one each of the the AES Cartridge and System adapters. The Cartridge and System adapters are the same PCB, but with the card-edge and euro connectors mounted on opposite sides of the PCB, with mating euro connectors.
The System adapter also requires the fingerboard PCB, which mates the female card-edge connectors on the main board (AES) PCB and the System adapter PCB.
The Cartridge and System adapters may be plugged directly into one-another to form a passive pass-though device, which itself serves no useful purpose, except to perhaps verify the design of the adapters themselves.
This evening I did exactly that, and can report that Fatal Fury 2 still works on the AES with the back-to-back adapters in-circuit! One minor inconvenience is that the AES case top must be removed as the fingerboards aren't long enough to mate with the main board connectors through the cartridge slot - but this isn't too much of an issue as these devices are purely for development prototyping.
Next step is to populate a pair of MVS adapters and test that out on the MVS system. To the best of my knowledge at this point, the board will (just) fit on a horiztonal-cartridge 1-slot system - if it doesn't I do have a couple of 2-slot systems in various states of repair...
That probably won't happen until later next week, as I'm not back into the office until Tuesday afternoon at the earliest.
In the mean-time, I should continue with the programmer/analyser PCB design. I've decided it's also prudent to work on the schematic (at least) for the flash cartridge in parallel, to best ensure that the programmer will do what it is meant to do - program the flash cartridge!
There are a couple of other things I can try with the adapters in the short term, but I'll leave that until another post!
He managed to complete one each of the the AES Cartridge and System adapters. The Cartridge and System adapters are the same PCB, but with the card-edge and euro connectors mounted on opposite sides of the PCB, with mating euro connectors.
 |
| AES Cartridge adapter - top |
 |
| AES System adapter - top |
The System adapter also requires the fingerboard PCB, which mates the female card-edge connectors on the main board (AES) PCB and the System adapter PCB.
 |
| AES System adapter - bottom |
The Cartridge and System adapters may be plugged directly into one-another to form a passive pass-though device, which itself serves no useful purpose, except to perhaps verify the design of the adapters themselves.
 |
| AES Cartridge and System adapters plugged together to form a passive pass-through device |
This evening I did exactly that, and can report that Fatal Fury 2 still works on the AES with the back-to-back adapters in-circuit! One minor inconvenience is that the AES case top must be removed as the fingerboards aren't long enough to mate with the main board connectors through the cartridge slot - but this isn't too much of an issue as these devices are purely for development prototyping.
Next step is to populate a pair of MVS adapters and test that out on the MVS system. To the best of my knowledge at this point, the board will (just) fit on a horiztonal-cartridge 1-slot system - if it doesn't I do have a couple of 2-slot systems in various states of repair...
That probably won't happen until later next week, as I'm not back into the office until Tuesday afternoon at the earliest.
In the mean-time, I should continue with the programmer/analyser PCB design. I've decided it's also prudent to work on the schematic (at least) for the flash cartridge in parallel, to best ensure that the programmer will do what it is meant to do - program the flash cartridge!
There are a couple of other things I can try with the adapters in the short term, but I'll leave that until another post!
Saturday, 12 April 2014
Adapters ordered
I've finally ordered the adapters and the connectors! I made sure I ordered enough card-edge connectors for the NGPACE Neo Geo motherboard project as well.
I expect them all to arrive sometime before Easter. I probably won't get time to build anything until after Easter though, unless they come in very early in the week.
I've started on the Lode Runner disassembly as a side project. I've decided to do two (2) ports in parallel - the TRS-80 Model 4 (Z80) and Coco 3 (6809). I know I should be doing Donkey Kong as well...
It's been slow going as I'm not very familiar with either the Apple II or the 6502, but thus far I've decoded the title screen and converted the graphics to a format more suited to non-Apple machines. I've got the TRS-80 Model 4 displaying the title (pixel-doubled) in 640x240 mode, using George Phillip's trs80gp emulator. The Coco 3 version is currently WIP while I find an easy way to launch binary files directly in an emulator without having to muck about with DSK images. I'll develop a monochrome version on the Coco 3 initially, in order to use the same graphic data as the TRS-80 Model 4. Later on I can add a 4-colour version.
Next task on NGPACE proper is to design the programmer/analyser board. I've started on the FPGA HDL code in order to confirm my choice of devices. In parallel I'll start on schematic capture as I can hopefully convince my colleague (who laid out the adapters) to lend a hand there too!
I expect them all to arrive sometime before Easter. I probably won't get time to build anything until after Easter though, unless they come in very early in the week.
I've started on the Lode Runner disassembly as a side project. I've decided to do two (2) ports in parallel - the TRS-80 Model 4 (Z80) and Coco 3 (6809). I know I should be doing Donkey Kong as well...
It's been slow going as I'm not very familiar with either the Apple II or the 6502, but thus far I've decoded the title screen and converted the graphics to a format more suited to non-Apple machines. I've got the TRS-80 Model 4 displaying the title (pixel-doubled) in 640x240 mode, using George Phillip's trs80gp emulator. The Coco 3 version is currently WIP while I find an easy way to launch binary files directly in an emulator without having to muck about with DSK images. I'll develop a monochrome version on the Coco 3 initially, in order to use the same graphic data as the TRS-80 Model 4. Later on I can add a 4-colour version.
Next task on NGPACE proper is to design the programmer/analyser board. I've started on the FPGA HDL code in order to confirm my choice of devices. In parallel I'll start on schematic capture as I can hopefully convince my colleague (who laid out the adapters) to lend a hand there too!
Wednesday, 9 April 2014
Adapters and distractions
First with directly associated news; I've sent the adapters out for a quote and whilst they're more expensive than I'd hoped, I've finally decided to bite the bullet and tomorrow I'll kick off the order for four (4) complete sets. That'll be followed by an order to Digikey for the connectors and then it's a matter of waiting about 2 weeks for it all to arrive and solder them together.
I've also been thinking again about picking up Donkey Kong and that'll happen soon.
In the mean-time I've been distracted by some smaller software projects. Somehow (I won't bother to explain how) a YouTube video of the Dick Smith System-80 resulted in me reverse-engineering the TRS-80 Model I game Tandy Invaders and then porting it to the Microbee. That in turn ended up with me acquiring and then sprucing up the source code for the TRS-80 Model I version of Donut Dilemma, and again porting that to the Microbee.
And because I don't already have enough irons in the fire, tonight I started to reverse-engineer the Apple II version (which happens to be the original version) of Lode Runner. It's my favourite Apple II game and one of my favourite games on any 8-bit platform, and it's something I've wanted to do for a very long time. I've dabbled with Lode Runner in the past, but never attempted to disassemble the Apple original. Fortunately someone has already reverse-engineered the 3-stage anti-piracy bootloader and I'm starting with a clean dump of the actual game code. Ultimately I'd like to finish what I started about 30 years ago and port this to the TRS-80 Model 4 (with uLabs Grafyx Solution hires board) and also the Coco 3 - and perhaps other platforms.
The next update should have photos of the assembled adapter PCB's...
I've also been thinking again about picking up Donkey Kong and that'll happen soon.
In the mean-time I've been distracted by some smaller software projects. Somehow (I won't bother to explain how) a YouTube video of the Dick Smith System-80 resulted in me reverse-engineering the TRS-80 Model I game Tandy Invaders and then porting it to the Microbee. That in turn ended up with me acquiring and then sprucing up the source code for the TRS-80 Model I version of Donut Dilemma, and again porting that to the Microbee.
And because I don't already have enough irons in the fire, tonight I started to reverse-engineer the Apple II version (which happens to be the original version) of Lode Runner. It's my favourite Apple II game and one of my favourite games on any 8-bit platform, and it's something I've wanted to do for a very long time. I've dabbled with Lode Runner in the past, but never attempted to disassemble the Apple original. Fortunately someone has already reverse-engineered the 3-stage anti-piracy bootloader and I'm starting with a clean dump of the actual game code. Ultimately I'd like to finish what I started about 30 years ago and port this to the TRS-80 Model 4 (with uLabs Grafyx Solution hires board) and also the Coco 3 - and perhaps other platforms.
The next update should have photos of the assembled adapter PCB's...
Monday, 24 March 2014
Adapters ready to go
Thanks mostly to my colleague who has been working hard on layout in his spare time, the adapter boards are ready to go out!
As promised, some eye candy, and I'll attempt to explain what they are and how they're going to be used for the project:
Both the AES and MVS adapter boards connect to the respective AES and MVS system boards and cartridges. Shown above is a 'system' adapter, with the card-edge connectors on the bottom side of the PCB. In this case a fingerboard (shown below) connects the adapter board to the system board. The adapter has been designed to (just) fit into a horizontal 1-slot MVS motherboard, although the size was ultimately constrained by routing requirements. We'll have to wait and see if it does actually fit when fully assembled.
At the cartridge end, the same adapter PCB is loaded with the card-edge and (opposite gender) EURO connectors mounted on opposite sides of the PCB. The AES/MVS cartridge plugs directly into the card-edge connector on this adapter.
Ultimately then, a pair (CHA & PRG) of analyser/programmer PCB's plug between the EURO connectors on the system and cartridge adapter boards. In the analyser configuration, the PCB snoops the cartridge bus accesses for display via the Altera Signal Tap analyser in the FPGA.
The analyser/programmer PCB also has a programmer configuration for the flash cartridge which I won't go into now.
The plan is to send the adapter and fingerboard PCB's out to be manufactured this week, and also order the rather expensive connectors from Digikey. When they're assembled they can be tested by plugging the cartridge and system adapters back-to-back via the EURO connectors, which should act as a completely passive pass-through on the MVS and AES systems.
While we wait for the manufacture of the adapter boards, I'll press ahead with the design of the analyser/programmer board. I've chosen a candidate FPGA and have started on the HDL design of both analyser (trivial) and programmer functions. Once I've convinced myself that the FPGA is sufficient for the task, I'll start on schematic capture.
As promised, some eye candy, and I'll attempt to explain what they are and how they're going to be used for the project:
 |
| MVS Adapter Board (System Adapter configuration) |
Both the AES and MVS adapter boards connect to the respective AES and MVS system boards and cartridges. Shown above is a 'system' adapter, with the card-edge connectors on the bottom side of the PCB. In this case a fingerboard (shown below) connects the adapter board to the system board. The adapter has been designed to (just) fit into a horizontal 1-slot MVS motherboard, although the size was ultimately constrained by routing requirements. We'll have to wait and see if it does actually fit when fully assembled.
 |
| MVS Fingerboard - system adapter to MVS board |
At the cartridge end, the same adapter PCB is loaded with the card-edge and (opposite gender) EURO connectors mounted on opposite sides of the PCB. The AES/MVS cartridge plugs directly into the card-edge connector on this adapter.
Ultimately then, a pair (CHA & PRG) of analyser/programmer PCB's plug between the EURO connectors on the system and cartridge adapter boards. In the analyser configuration, the PCB snoops the cartridge bus accesses for display via the Altera Signal Tap analyser in the FPGA.
The analyser/programmer PCB also has a programmer configuration for the flash cartridge which I won't go into now.
The plan is to send the adapter and fingerboard PCB's out to be manufactured this week, and also order the rather expensive connectors from Digikey. When they're assembled they can be tested by plugging the cartridge and system adapters back-to-back via the EURO connectors, which should act as a completely passive pass-through on the MVS and AES systems.
 |
| AES Adapter Board (System Adapter configuration) |
Saturday, 15 March 2014
Friday late night update
Happily I can report that progress is being made. My colleague, who has some down time, has volunteered to take on some of the development. This has also spurred me to get the project into a state where he can work on it.
I've finished the schematics for both MVS and AES adapters. And as of this afternoon the AES adapter is almost fully laid out; only a few traces remaining and then the fun bits like the silk-screen overlay. The MVS adapter will be next, and will also leverage off the work done on the AES adapter, which was tackled first in order to gauge the size of the PCB - the MVS is much simpler to route, since the connector pin-outs are closer to 1:1.
At this rate we might have something to go out to manufacture by next Friday!
I've also been re-thinking the analyzer/programmer board and the flash cart board - considering making them both single PCB's to handle both CHA and PRG functionality. I think the flash cart is a definite candidate, the analyzer/programmer not so certain. A lot will depend on the real estate required by the level-shifting logic.
Donkey Kong is always in the back of my mind too.
And I've had a renewed interest in the Coco... need to prototype it on NGPACE first!
I've finished the schematics for both MVS and AES adapters. And as of this afternoon the AES adapter is almost fully laid out; only a few traces remaining and then the fun bits like the silk-screen overlay. The MVS adapter will be next, and will also leverage off the work done on the AES adapter, which was tackled first in order to gauge the size of the PCB - the MVS is much simpler to route, since the connector pin-outs are closer to 1:1.
At this rate we might have something to go out to manufacture by next Friday!
I've also been re-thinking the analyzer/programmer board and the flash cart board - considering making them both single PCB's to handle both CHA and PRG functionality. I think the flash cart is a definite candidate, the analyzer/programmer not so certain. A lot will depend on the real estate required by the level-shifting logic.
Donkey Kong is always in the back of my mind too.
And I've had a renewed interest in the Coco... need to prototype it on NGPACE first!
Friday, 7 March 2014
Still here...
Not much to post about - work and Real Life have been taking most of my time. I have been picking up a few Neo Geo-related items here and there in the last few weeks, like a couple of (faulty) 2-slot boards, hoping I can fix at least one of them.
Tonight I cleaned up the MVS adapter project, fixing the cartridge connector footprints and getting the Altium Designer libraries sorted - with the assistance of my knowledgeable colleague. Whoever designed that library system needs a good, swift, kick up the bum.
Since the AES adapter is going to be the messier of the two, I really need to lay it out before the MVS so I can match the PCB sizes and, more importantly, the EURO connector spacing. To that end I started on the AES adapter schematic, and would be working on it right now if only the ^%!@$# project files had gotten saved and/or checked-in to SVN before I left the office. Don't know WTF happened there.
Neither of the boards are particularly complex, so I'm hoping I can knock them over in the next few weeks as I'm expecting work to quieten down for a little while at least.
Lastly - Donkey Kong. I still have every intention of picking it up - and almost did a few nights ago - ever mindful of the fact that the longer I leave it, the harder it will be to continue where I left off. I just haven't really had a large enough slice of free time to devote to ramping up again.
My next update should be news about the adapter PCB's going out to manufacture. Not exciting in itself, but a step towards moving the entire project ahead. I did briefly flirt with the idea of putting the analyser/flash cart on hold and just going straight for the NGPACE main board... and I still might...
Tonight I cleaned up the MVS adapter project, fixing the cartridge connector footprints and getting the Altium Designer libraries sorted - with the assistance of my knowledgeable colleague. Whoever designed that library system needs a good, swift, kick up the bum.
Since the AES adapter is going to be the messier of the two, I really need to lay it out before the MVS so I can match the PCB sizes and, more importantly, the EURO connector spacing. To that end I started on the AES adapter schematic, and would be working on it right now if only the ^%!@$# project files had gotten saved and/or checked-in to SVN before I left the office. Don't know WTF happened there.
Neither of the boards are particularly complex, so I'm hoping I can knock them over in the next few weeks as I'm expecting work to quieten down for a little while at least.
Lastly - Donkey Kong. I still have every intention of picking it up - and almost did a few nights ago - ever mindful of the fact that the longer I leave it, the harder it will be to continue where I left off. I just haven't really had a large enough slice of free time to devote to ramping up again.
My next update should be news about the adapter PCB's going out to manufacture. Not exciting in itself, but a step towards moving the entire project ahead. I did briefly flirt with the idea of putting the analyser/flash cart on hold and just going straight for the NGPACE main board... and I still might...
Friday, 21 February 2014
Slow going
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! ;)
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! ;)
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.
Thursday, 30 January 2014
First thoughts on a flash cart
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!
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!
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)