What is it?
The USB MegaDrive DevKit is a 100% open-source (hardware & software) development cartridge and toolset whose aim is to make it easy to do homebrew development for the Sega MegaDrive/Genesis, using real hardware rather than an emulator.
With it, you can:
- Load ROMs at about 10MiB/s over USB when attached to a PC.
- Load ROMs at about 3MiB/s from SD-card when standalone.
- Attach a GDB debugger and single-step, set breakpoints, examine & update memory & registers etc.
- Source-level debug C & assembler on real hardware.
- Get RAM dumps and compare them to see the effect of running a piece of code.
- Nonintrusively trace execution: record details (with 20ns-resolution timestamp) of every bus-cycle, potentially for many hours' execution.
- Part 1: Introduction
- Part 2: Hacking a Commercial Game: Give Sonic Infinite Lives (watch fullscreen in at least 720p)
- Part 3: Source-Level Debugging an SGDK Application (again, watch fullscreen in at least 720p)
When you plug in the cart and turn the machine on, the FPGA initialises itself from the bottom 384KiB of the flash chip, and then boots the MegaDrive by loading a machine-code monitor and a menu program from the top 128KiB of the flash chip. The menu program was written using SGDK, and just displays a menu of all the ROM images on the (FAT32-formatted) SD-card, from which you can select a game to play using the controller. So when you're not using it for development you can get a 2GB SD-card and install several hundred ROM images on it and play them without having to switch carts again!
The machine-code monitor allows you to connect a PC via USB and use the GNU debugger (GDB) to break into any code that is running, examine registers and memory, set breakpoints, single-step through code, etc. You can also load .elf files containing debug information, giving you C or 68000 source-level debugging.
The tracing feature will nonintrusively dump a log to your PC containing details of every single bus-cycle executed by the MegaDrive as it runs. The trace-log includes a 20ns-resolution timestamp, details of whether the access was made by the 68000 or some kind of DMA, whether it was a read or a write, the address and the data that was read or written. The trace-log is written direct to disk, so if you have a typical 2TB hard disk, you can trace all day long without problems - useful for finding out what was happening just before that intermittent failure in your new blockbuster game cart!
How does it work?
At its heart is a Xilinx Spartan-6 LX9 FPGA. It implements a custom low-latency SDRAM-controller capable of arbitrating interleaved access to the 16MiB of SDRAM by both the MegaDrive and the host PC. The machine-code monitor and the host software collaborate in a kind of RPC arrangement, where a region of the shared SDRAM is reserved for sending arbitrary messages back and forth over USB, orchestrated by a simple semaphore.
This arrangement is used to implement a proxy for the GDB remote debug protocol, so whenever GDB asks for the value of a register or a bit of memory, that request is marshalled over the USB link to the MegaDrive, where the monitor fulfils the request and sends the results back to the proxy, and thence to GDB. It's over in quite a lot less than the blink of an eye.
The FPGA also implements an SPI master unit capable of reading from the flash chip and the SD-card.
Will you build me one if I pay you?
No sorry, I've got a full-time job building robot spacecraft, and it leaves me with no spare time! Besides, I did this to learn, not to make money. But you're welcome to build a UMDK cart yourself, or if you're not too hot with a soldering iron you could pay someone else to build one for you. You're also welcome to make several and sell them, if you think you can make money that way (if by some miracle you do get rich that way, don't send money to me, send it to Kaneda to pay for the SpritesMind hosting)!
If you can demonstrate to me that you have the required equipment and experience to solder the 0.5mm-pitch FPGA, I may be able to sell you a pair of PCBs (the LX9R3 board and the Bridge board) at cost, which is currently about $12 for the pair. I can also provide help sourcing components, building the tools and installing the UMDK firmware.
The software, firmware, VHDL, schematics and PCB layout are all published under copyleft-style licenses so you're free to use it all however you see fit, provided you abide by the various licenses (mostly GPLv3 or LGPLv3 for software & VHDL, and CERN OHLv1.2 for the PCB). In practice, that means abiding by the spirit of the copyleft licensing: you can make whatever proprietary modifications you like to your own personal UMDK carts, but if you give/sell a modded cart to someone else, you must provide them with all the source code modifications you've used so they can build upon your work, as you have built upon mine. Furthermore, you must grant them the freedom to use, replicate, modify and redistribute your work.
- Code & VHDL
- LX9R3 FPGA PCB (KiCad)
- LX9R3 FPGA PCB (Gerbers)
- LX9R3 FPGA PCB (BoM)
- Bridge PCB (KiCad)
- Bridge PCB (Gerbers)
- Bridge PCB (BoM)
The SD-card loader and the machine-code monitor use parts of the 0x400000-0x7FFFFF region of the 68000 address-map, which is used by the Mega-CD, so the UMDK is currently explicitly not compatible with the Mega-CD. Using them both together will probably damage your hardware, so don't even think about trying it.
The only bank-switching supported is the "official" SSF2 scheme. I have not implemented any custom mappers (e.g for Pier Solar support). The entire 16MiB of SDRAM is accessible through the SSF2 registers, but the very top 512KiB is reserved for UMDK internals, leaving you with 15½MiB to play with.
UMDK carts have been tested on unmodded European MD1 & MD2 models without problems. It has never been tested on American or Japanese models. There's a small chance the slightly faster memory clocking in those regions will cause problems with games that do a lot of DMA.