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:

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)

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.

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!

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

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

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!

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

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!