USB MegaDrive DevKit

Some of you may find this of interest, it's a project I've been working on intermittently for several years, to build a 100% open-source (hardware & software) development cartridge for the MegaDrive/Genesis, and it's now pretty much finished. The code and VHDL is all LGPLv3, and the PCB is CERN OHLv1.2. With a bit of patience and a decent soldering iron you can make one for about $40.

Here are some videos I made about it:

https://www.youtube.com/watch?v=mEH7a-a8dvQ
https://www.youtube.com/watch?v=JxBzxhMhANI
https://www.youtube.com/watch?v=dLoudQc8L08

...and the Hackaday write-up:

http://hackaday.com/2014/06/18/the-sega-mega-drive-dev-kit/#comment-1579271
http://hackaday.io/project/1507-USB-MegaDrive-DevKit

The cartridge has an FPGA, an SDRAM chip, an SD-card slot and a fast USB interface. It's able to setup a proxy for the GDB remote serial protocol, so you can build code using GCC, and source-level debug it using GDB just as you would with code running locally: set breakpoints, single-step through the code, examine memory and registers, etc.

The GDB link makes use of the fact that the SDRAM is fast enough to interleave accesses by the MegaDrive with access by the PC: a small machine-code monitor runs on the MegaDrive and uses a reserved area of the SDRAM to implement an arbitrary RPC mechanism using a semaphore to orchestrate message-passing.

The USB link is fast enough to implement a 100% nonintrusive bus-cycle tracer, so details of every memory read or write that the machine executes along with a 20ns-resolution timestamp is sent back over USB and written direct to disk. The length of the trace-log is limited only by your hard disk; a typical 2TB drive will allow you to trace execution for more than 24 hours! Perfect for finding out what was happening just before that intermittent bug in your latest blockbuster MegaDrive game!

The cart can also be used standalone (i.e no USB connection to a PC), whereupon it boots into a menu program that displays a list of all the games on the SD-card and allows you to select one using the control-pad.

Unfortunately I don't have any of them to sell, but the designs are all open-source so you can make one yourself if you wish. If you're not too good with a soldering-iron you could pay someone else to do it for you. I'd also be very happy if someone decided to make a few of them and sell them (no royalties required!).

 

Very cool. I'll look into getting the parts together for this Very awesome that you've open sourced it all, too.

I haven't watched all the videos yet, but do you see any particular disadvantages with this tool? I know it's completely unfair (since the intended purposes are so different), but I can't help trying to compare it to an Everdrive - which can do extra little nifty things like load mega CD bioses, and be used as a backup RAM cart for the mega CD. In fact - that's an interesting question. Does it allow debugging etc of mega CD games? Or can it not interface with the extra processors in the mega CD? Same question goes for 32x I suppose!

Great work!

 

Saw this on my rss feed earlier, top stuff.

 

Hi fluxcore,

I don't own (or have any particular interest in) the Mega-CD or the 32X. This cart will almost certainly not work with the Mega-CD because it uses the hole in the 68000 address-space from 0x400000-0x7FFFFF (in fact it just extends the SSF2 paging scheme to include the seven pages from 0x480000-0x7FFFFF, with 0x400000-0x480000 hard-coded to page 31 of the SDRAM, just as 0x000000-0x080000 is hard-coded to page 0). Someone sufficiently motivated could find a suitable hole in the Mega-CD address-map and use that for the monitor, etc instead, but that would probably mean getting DTACK-generation working (DTACK is connected to the FPGA via a transistor which is currently unpopulated).

I'm not sure about the 32X. The memory timing is tight - the MD itself does some quite short bus-cycles when doing DMA reads: I measure them down to 7 cycles @48MHz, and the SDRAM controller takes 4 cycles to do a read, plus one cycle to synchronise the MD signals to the 48MHz clock-domain, plus the traversal time of the level-shifters.

The one thing I would like to see working is the game saves - currently writes to 0x000000-0x3FFFFF are ignored altogether.

The Mega Everdrive is a great product, and I'd hate for people to percieve me as being somehow in competition with Krikzz. But the aim of UMDK is rather different - basically to provide a modern remote-debug environment, and to be completely open-source; the SD-card menu thing (which is the main competitor-feature to Krikzz's carts) is really only a "nice extra".

 

Nice stuff!

 

wow, very nice! thank you for sharing your work.

i think this is going to be my next project when some time is left.

 

Thank you; hope to build one soon

 

Awesome stuff, any way you could post a zip of the gerber files for each board? I don't see any gerber files in the gerber directory in the github page. Could you also post a link to where you got the parts to build the boards? Thanks.

 

fluxcore,
I'd rather not be seen as competing with the Everdrive - Krikzz is a great guy and the Everdrive is a great product, and it is a product, that you can actually buy, whereas UMDK is really a DIY thing.

Unfortunately in its present form UMDK will not play nicely with the Mega-CD because it uses part of the 0x400000-0x7FFFFF address space that is (apparently) used by the Mega-CD. That's not to say it would be impossible to get working, but someone would probably have to enable DTACK generation from the FPGA (it's connected, via a currently-unpopulated and therefore obviously unused pulldown transistor on the bridge-board) and find a suitable hole in the 68000 address space that won't interfere with the Mega-CD. As for game saves, currently the 0x000000-0x3FFFFF range is write-protected from the MegaDrive side, and anyway I have not implemented any FAT32 writes to the SD-card, so no game saves are possible (I'd love to see that feature working, actually!)

Helder,
That's not a bad idea. I could make a zip file with the gerbers and the binary to load into the SPI flash, and the loader FPGA design that allows you to load the flash chip over USB. I should think about ways of getting the various components to self-test. There are a few tests you can do:

Can you read the FPGA's JTAG IDCODE over USB?
Can you program the FPGA with a "blinky" example?
Can you read and write data streams from the FPGA over USB?
Can you write data to the SDRAM and then read it back over USB successfully?
Can you write data to the SPI flash and read it back successfully?
Can you toggle each FPGA I/O over USB without affecting neighbouring pins?

With that checklist done there's a good chance that when you plug it into your MD it won't go up in smoke. But as ever, there are no guarantees.

Incidentally, if any of you are seriously interested in actually building one of these, if you can prove to me that you're capable of soldering the 0.5mm-pitch FPGA (e.g by showing me a picture of some similar bit of soldering you've already done) then I may be willing to sell you some PCBs at cost. Don't be put off - it's not a difficult job, but you do need a steady hand and a decent soldering iron, and if possible I want to avoid selling boards to people whose only previous experience is soldering through-hole components using a soldering iron that they inherited from their grandfather or bought from Radio Shack for $15. That way lies disappointment and frustration, which I don't want directed back at me.

Chris

 

I can solder tiny pitches fine , all I need is the gerber files along with the necessary binaries to program the FPGA. Using the gerbers I can order my own board so you don't have to be bothered selling me the board. Thanks for putting this out there.

 

I had noticed that you had some updates on your github for this. Exciting news. I will have to dig through all the info you posted.

Thanks

 

just download kicad and make them yourself?

It will take you all of 5 minutes.

 

OK, I updated the main page on Hackaday with the gerbers for both boards (these are the actual .zip files I sent to Hackvana), and the FPGA and MD firmware binaries:

http://hackaday.io/project/1507-USB-MegaDrive-DevKit

I recommend building the host-side code from source; let me know when you're ready and I'll help you with that.

Chris

 

Thanks!

The Host side meaning the debugger on the PC or compiling the FPGA binaries?

 

The pc

 

I would like to try one of these, wonder if it has full compatibility with all MD games, What if we throw a Genesis rom on there?

 

The only games I've found which don't work are the ones that were never intended to work on my European MegaDrive in the first place (they do a region check and print "this came cannot be played on European machines" or somesuch). I don't have an NTSC mod so I don't know what would happen on a US MegaDrive (Genesis, I guess). The faster NTSC clock may cause issues, because the memory timing is pretty tight.

 

So this will likely not work on a Sega Genesis? or cause issues due to timing? I'm from USA so I have the Genesis, I guess I will be the guinea pig to see if it's all good here. The timing issue you mention could it be fixed by changing the 24MHz crystal to something else or is that specifically for the FPGA?

 

Currently the whole FPGA has only one clock domain, the 48MHz which is used by the USB interface and cannot be changed. If you wanted to reduce the memory latency you'd have to separate the MD & SDRAM clock domain from the USB clock-domain, and drive it using a PLL. That's quite possible to do, but it's likely that pushing up the frequency of the memory controller will require extra wait-states to be put into the memory controller, so it's a delicate balance. The truth is I just don't know how well it'll work on a US machine, but if it doesn't work, I will certainly be willing to help get it working, by fiddling with the clock-domains, etc.

 

How much for one of these, I'm interested it trying it out.