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:

• 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)

These are reasonable numbers for single/dual device solutions per bus, and flash is surprisingly cheap, so no big deal here. I could probably even double it if I felt the need. As it stands though, the proposed flash cartridge will therefore have a capacity of 776 MBits.

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...

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!

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.

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?

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!

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...

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!