USB MegaDrive DevKit
Moderators: BigEvilCorporation, prophet36
USB MegaDrive DevKit
What is it?
The USB MegaDrive DevKit is a project I started several years ago aiming to build a 100% open-source hardware/software development cartridge that aims to make it easy to write and debug homebrew code on a real MegaDrive, as cheaply as possible. And now it's pretty much "finished".
Video Part 1: Introduction
Video Part 2: Hacking a Commercial Game: Give Sonic Infinite Lives (watch fullscreen in at least 1080p)
Video Part 3: Source-Level Debugging an SGDK Application (watch fullscreen in at least 1080p)
Code & VHDL
FPGA PCB
Bridge PCB
It consists of an FPGA, 16MiB of SDRAM, 512KiB of flash, a fast (~42MiB/s) USB interface and an SD-card slot. With some patience and some soldering skills, you can make one at home for about $40.
When you plug in the cart and turn the machine on, the FPGA initialises itself from the bottom 75% of the flash chip, and then boots the MegaDrive by loading a machine-code monitor and a menu program from the top 25% 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. 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.
The machine-code monitor allows you to connect a PC via USB and using the GNU debugger GDB break into any code that is running, examine registers and memory, set breakpoints, single-step through code, etc.
You can also set up tracing, which will dump a trace-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, and details of whether the access was made by the 68000 or some kind of DMA, whether it's 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 an 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)!
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).
The USB MegaDrive DevKit is a project I started several years ago aiming to build a 100% open-source hardware/software development cartridge that aims to make it easy to write and debug homebrew code on a real MegaDrive, as cheaply as possible. And now it's pretty much "finished".
Video Part 1: Introduction
Video Part 2: Hacking a Commercial Game: Give Sonic Infinite Lives (watch fullscreen in at least 1080p)
Video Part 3: Source-Level Debugging an SGDK Application (watch fullscreen in at least 1080p)
Code & VHDL
FPGA PCB
Bridge PCB
It consists of an FPGA, 16MiB of SDRAM, 512KiB of flash, a fast (~42MiB/s) USB interface and an SD-card slot. With some patience and some soldering skills, you can make one at home for about $40.
When you plug in the cart and turn the machine on, the FPGA initialises itself from the bottom 75% of the flash chip, and then boots the MegaDrive by loading a machine-code monitor and a menu program from the top 25% 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. 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.
The machine-code monitor allows you to connect a PC via USB and using the GNU debugger GDB break into any code that is running, examine registers and memory, set breakpoints, single-step through code, etc.
You can also set up tracing, which will dump a trace-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, and details of whether the access was made by the 68000 or some kind of DMA, whether it's 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 an 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)!
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).
Yeeeeees !!! Dream becomes true !!
I want I want !!
If you know someone who can sell me this St Graal, let me know !
If you know someone who can produce this, I'll be more than happy to launch "mass" production
Thanks Prophet, it's been so many times I dream on an updated version of umdk1, this one is just awesome !
Can't wait to test it, so many projects running and it'll clearly allow me to write a lightgun4LCD patch...
I want I want !!
If you know someone who can sell me this St Graal, let me know !
If you know someone who can produce this, I'll be more than happy to launch "mass" production
Thanks Prophet, it's been so many times I dream on an updated version of umdk1, this one is just awesome !
Can't wait to test it, so many projects running and it'll clearly allow me to write a lightgun4LCD patch...
-
- Interested
- Posts: 27
- Joined: Wed Sep 21, 2011 9:00 pm
- Location: Sevilla, Spain
- Contact:
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
That's really neat, especially the trace log feature.
Seeed studio's Propagate program might be an option if someone wants to get a run of these done. Someone would need to put up the capital to get at least 100 made though. Might be more feasible for the lx9 board than the UMDKv2 bridge-board since it has other uses.[/url]
Seeed studio's Propagate program might be an option if someone wants to get a run of these done. Someone would need to put up the capital to get at least 100 made though. Might be more feasible for the lx9 board than the UMDKv2 bridge-board since it has other uses.[/url]
Thanks, MoD! Yeah I thought the trace-log would be of interest to emulator-writers such as yourself. Let me know if you need me to test stuff for you (for measuring timing, DMA scheduling, etc).
BTW, the project featured on Hackaday today.
BTW, the project featured on Hackaday today.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: USB MegaDrive DevKit
Incredibly cool! Thanks for sharing the entire project like this, it's sort of unprecedented. I can't wait to see what people do with it.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
I have witnessed Prophet work on UMDK for a few years now and tried my best to support him in his work.
I have UMDK here that Prophet sent to me for testing purposes and I can say that it will single-handedly change the way Developers work on the Megadrive.
There is support for tracing execution and for running GDB remotely - these features alone should make you all want to get one of your own!
I have been writing a Library for use with the MD that I want to bundle with UMDK to help Developers get up and running. If SGDK also supported UMDK then that'd help many people too.
Now, who fancies helping to add support for MIDI and a Tracker that supports UMDK too?
Also, I want to add XModem support to AXLib too.
There has been some talk about getting a batch of UMDK PCBs made but could we possibly come together as a community and make this happen? You all know well that this makes perfect sense
I have UMDK here that Prophet sent to me for testing purposes and I can say that it will single-handedly change the way Developers work on the Megadrive.
There is support for tracing execution and for running GDB remotely - these features alone should make you all want to get one of your own!
I have been writing a Library for use with the MD that I want to bundle with UMDK to help Developers get up and running. If SGDK also supported UMDK then that'd help many people too.
Now, who fancies helping to add support for MIDI and a Tracker that supports UMDK too?
Also, I want to add XModem support to AXLib too.
There has been some talk about getting a batch of UMDK PCBs made but could we possibly come together as a community and make this happen? You all know well that this makes perfect sense
Unfortunately getting PCBs made is the easy bit - soldering the chips on is less easy. I'm no electronic engineer so I don't know how to design PCBs for manufacture, so I just design them to be easily hand-solderable. But when I say "easily" it is of course all relative. It's easy for me, but time-consuming. And my time is worth quite a lot to me! I'm happy to continue maintaining the code and design, etc but I have no interest in marketing or manufacturing.
So either someone needs to sit there soldering (with practice you could probably get the time from blank board to a functional, tested UMDK cart down below an hour) or someone with design-for-manufacture experience needs to redesign the boards and pay a manufacturer to assemble them (maybe $10 per board). Or just use the current board layout and expect to pay the manufacturer more per board (perhaps $20 per board? I dunno).
There was a comment from a guy from the Assembler Games forum who may be interested in making and selling them[1] but I don't know how he intends to proceed, or what volume or pricing he hopes to achieve.
[1]https://www.youtube.com/all_comments?v=mEH7a-a8dvQ (search "Helder").
So either someone needs to sit there soldering (with practice you could probably get the time from blank board to a functional, tested UMDK cart down below an hour) or someone with design-for-manufacture experience needs to redesign the boards and pay a manufacturer to assemble them (maybe $10 per board). Or just use the current board layout and expect to pay the manufacturer more per board (perhaps $20 per board? I dunno).
There was a comment from a guy from the Assembler Games forum who may be interested in making and selling them[1] but I don't know how he intends to proceed, or what volume or pricing he hopes to achieve.
[1]https://www.youtube.com/all_comments?v=mEH7a-a8dvQ (search "Helder").
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Yes: manufactured and populated.
I dare say that there are Electronic Engineers who are active in designing PCBs in their Jobs who happen to also be interested in the MD - how about a Thread on Assembler-Games to ask who could help out?
I have a single contact who has a setup at home that would allow him to handle SMT components. The next question would be: should there be a Jig made ready to test the PCBs once populated? This might save some time as each populated Board could then be tested by whoever populates each PCB.
Is it worth us contacting some of the Sites that cater to the Hobbyist wanting some custom Hardware made in fairly lowish numbers?
I would like to know what sort of numbers would be required to then work out if it is worth it to have the PCB redesigned for machine manufactured and population of the components.
The other aspect as you have raised is that the LX9 alone can be used as an FPGA Devboard so it may be that a few would only want the LX9 board and not the Bridge so that could take the numbers up a bit.
Would hackvana or similar be interested in populating too? Also, I do know that Stoneage Gamer sells Flashcarts for the MD but is that site merely a Vendor or are they also involved with manufacture too? Does anyone know?
I dare say that there are Electronic Engineers who are active in designing PCBs in their Jobs who happen to also be interested in the MD - how about a Thread on Assembler-Games to ask who could help out?
I have a single contact who has a setup at home that would allow him to handle SMT components. The next question would be: should there be a Jig made ready to test the PCBs once populated? This might save some time as each populated Board could then be tested by whoever populates each PCB.
Is it worth us contacting some of the Sites that cater to the Hobbyist wanting some custom Hardware made in fairly lowish numbers?
I would like to know what sort of numbers would be required to then work out if it is worth it to have the PCB redesigned for machine manufactured and population of the components.
The other aspect as you have raised is that the LX9 alone can be used as an FPGA Devboard so it may be that a few would only want the LX9 board and not the Bridge so that could take the numbers up a bit.
Would hackvana or similar be interested in populating too? Also, I do know that Stoneage Gamer sells Flashcarts for the MD but is that site merely a Vendor or are they also involved with manufacture too? Does anyone know?
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Ah, I didn't know there were other console flash carts that were fully open source to the extent that yours was. That's good news.prophet36 wrote:Thanks Charles. But is it really all that unprecedented? The open-source hardware movement is gathering momentum, and I can't help but think/hope that the days of "look at this cool thing I made but you can't have it cos it's mine all mine my precious etc etc" are coming to an end.
The closest thing I've seen is a homebrew Sega Saturn GameShark type device so far:
http://koti.kapsi.fi/~antime/sega/usbcart/usbcart.html
I guess there are others, though?
I'm ordering the parts for this today, gonna build one ASAP.
I'm also interested in making some tweaks to get this unit compatible with a MegaCD attached. I noticed you made this comment on AssemblerGames:
I'm very interested in this hardware, and I'm more than happy to contribute some enhancements. One thing I really want is a fast and easy way to stream data back from the Mega Drive to the PC over the USB link, driven by the 68000 processor, IE, by writing to some target addresses. Is there currently any way to do this kind of thing? What I'd really love is a DMA mode where the kit itself can take ownership of the bus and do DMA from ram for example, and transfer to the PC. A lot more work, but it would give the best performance. Still, just the ability to stream data back over a USB link would be awesome.
I'm also interested in making some tweaks to get this unit compatible with a MegaCD attached. I noticed you made this comment on AssemblerGames:
The best candidate, if you need a wide range of addresses, would probably be the 0x800000-0x9FFFFF range. It's completely unused by the Mega Drive and MegaCD, with no DTACK generation. I think the 32x might use a region of this area when it's running, but not sure on the details of that. Still, it would be a better pick than the 0x400000-0x7FFFFF range for compatibility. If you only need a narrow address range, the best place would probably be squeezed into the "gaps" in the mapping of the VDP in the 0xC00000-0xDFFFFF range. For example, you could take the range at 0xC10000-0xC7FFFF. You will definitely not be conflicting with any other hardware in the system in this range, just process the access, and assert DTACK yourself.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.
I'm very interested in this hardware, and I'm more than happy to contribute some enhancements. One thing I really want is a fast and easy way to stream data back from the Mega Drive to the PC over the USB link, driven by the 68000 processor, IE, by writing to some target addresses. Is there currently any way to do this kind of thing? What I'd really love is a DMA mode where the kit itself can take ownership of the bus and do DMA from ram for example, and transfer to the PC. A lot more work, but it would give the best performance. Still, just the ability to stream data back over a USB link would be awesome.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
The 32X uses the whole range from 0x800000 to 0x9FFFFF. Part is the frame buffer and overwrite buffer, part is the fixed rom area for the 68000, and part is the banked rom area for the 68000.Nemesis wrote: The best candidate, if you need a wide range of addresses, would probably be the 0x800000-0x9FFFFF range. It's completely unused by the Mega Drive and MegaCD, with no DTACK generation. I think the 32x might use a region of this area when it's running, but not sure on the details of that.
What most flash carts do is use 0xA130xx, while keeping the address below 0xA130EC, which is the 32X recognition ID. 0xA130F1 to 0xA130FF are reserved for the cart mapper.Still, it would be a better pick than the 0x400000-0x7FFFFF range for compatibility. If you only need a narrow address range, the best place would probably be squeezed into the "gaps" in the mapping of the VDP in the 0xC00000-0xDFFFFF range. For example, you could take the range at 0xC10000-0xC7FFFF. You will definitely not be conflicting with any other hardware in the system in this range, just process the access, and assert DTACK yourself.
Looking at the videos he's posted, I can see he needs a space in memory large enough to store the monitor program for the 68K debugger, so that's not going to fit in the 0xA130XX region. I think picking a gap between a repeat of the VDP interface is the best bet. There are large gaps at 0xC10000, 0xC90000, 0xD10000, and 0xD90000. You've got 0x6FFFF continuous bytes per block, times 4 blocks. A bit less convenient than the 0x800000-0x9FFFFF range, but almost as big. It's large enough for bankswitching to be not too painful too.