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

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

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.

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.

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.

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!

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!

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