Back to top

Keep Dreaming Project

Creating an open-source ecosystem for Sega Dreamcast hardware research and development


The Dreamcast has a thriving community and even after 20 years, new games are still being made for it. I started the Keep Dreaming Project to provide the Dreamcast community with an open-source ecosystem for hardware research and development.

The project can be broken down into four major areas:

Development Hardware

Creating circuit boards that interface with the Dreamcast and its peripherals, I’ve made a few already.

Dreamcast Development Boards

The designs will all be open-source so anybody will be able to make their own.


Writing software, in collaboration with people in the Dreamcast community, that takes advantage of this hardware.


Gathering and preserving existing information about the Dreamcast. As well as creating documentation for all the other parts of the project and any discoveries made along the way.


The last bit is for all the extra things that are needed/help the project move forward.

Development Hardware

So far I’ve made breakout boards for the G1 Bus (disc drive)
Maple Bus (controllers)
as well as a prototype disc drive emulator.
openGDROM Prototype

When I designed the openGDROM it was with the intent of making an open-source GD-ROM emulator to sell. Now that I started the Keep Dreaming Project I’m looking to revise it as a development board for both the G1 and G2 bus. Even though I’m focusing on providing a development platform my design decisions will still be based on the idea of creating a marketable end product.

Bit of Research

The GD-ROM drive is essentially a modified CD-ROM drive. It’s similar to a regular ATA-3 device but uses the Sega Packet Interface (which is a modified version of the SFF-8020i ATA Packet Interface) for parallel communication on the G1 Bus. The GD-ROM drive can transfer data at up to 13.3MB/s from its 1Mb buffer.

I drew inspiration from several other GD-ROM drive emulators which helped in determining the design constraints.

The iceGDROM has a Lattice ice40 FPGA with an AVR softcore and reads games from an SD card using SPI.
The GDEMU has a 96MHz Atmel/Microchip ARM Cortex-M3 MCU, an Altera/Intel Cyclone II FPGA, and reads games from an SD card using a 4-bit interface.
The USB-GDROM has a 120MHz ST STM32 ARM Cortex-M3 microcontroller with an external USB-High Speed PHY to read games from a USB device. It has a Toshiba TC9466FA CD-ROM decoder with 1Mb of buffer RAM which handles communication with the Dreamcast, it’s similar to the one used in the Dreamcast GD-ROM drive.
Dreamcast Disc Drive Emulator

As an open-source project, the openGDROM was designed to be inexpensive, relatively easy to assemble, have parts that will be easy to source for a long time, and a PCB that any PCB manufacturer can make.

The iceGDROM is open source but doesn’t quite meet the design constraints. It uses a Lattice development board which isn’t produced in particularly high quantities so it could be difficult to source. For a custom board, the ice40 FPGA isn’t a good option as far as easy assembly is concerned since it only comes in a BGA package. The iceGDROM also has some performance issues.

Based on the USB-GDROM and GDEMU a 96MHz+ ARM Cortex-M3 microcontroller with 128KB+ of RAM would be a good choice, either with a 4-bit SD card interface or USB-High Speed.

From the iceGDROM and GDEMU, an FPGA with 4600+ logic elements and 12KB of RAM should be good. The FPGA needs over 30 I/O pins for the G1 bus and if a parallel bus is used between the MCU and FPGA the more pins the better.

Based on all that I picked a 300MHz Atmel/Microchip ARM Cortex-M7 MCU with an integrated USB-High Speed PHY and an Altera/Intel MAX10 FPGA for the openGDROM. Both come in 144-pin QFPs for easier assembly and generate their own core voltage so only need to be powered from a single 3.3V supply.

openGDROM Draft Sheet 1
openGDROM Draft Sheet 2

When I designed the openGDROM the Cortex-M7 MCUs from Microchip were some of the only ones with an integrated USB-HS PHY, not using an external USB PHY cut down on costs and is one less part to worry about. The family of Cortex-M7 MCUs from Microchip also has a wide range of similar parts which could make migrating to another cheaper chip in the future easier, they are also plentiful and easy to source.

The Intel MAX10 FPGAs are some of the more affordable FPGAs, they also have internal configuration memory so don’t need any external memory. There’s a decent range of pin-compatible parts so migrating to a different part in the future would be easy, they are also plentiful and easy to source.


There’s a long way to go as far as programming is concerned. I’m hosting Phabricator on my VPS for project management/planning and as a platform for collaboration.



Along with Phabricator, I’m hosting a BookStack instance on my VPS to use as a knowledge base. It will be a repository of information about the Dreamcast and host the project’s documentation. There’s a lot of information out there about the Dreamcast but it’s spread out and some of these sites are disappearing. To make this information easy to preserve BookStack can export everything as a PDF and I’ve made my BookStack Docker Stack available, so if I can no longer host it someone else can.



I created a package for SublimeText called QMSV (acronym for Quartus ModelSim SublimeText/SystemVerilog and VUnit) to make Altera/Intel FPGA development a bit easier, for me at least.

It uses the SublimeText SystemVerilog package to improve the actual HDL writing experience. Quartus is used for all the typical stuff (synthesis, place and route, etc), ModelSim for linting, and VUnit as a unit testing framework. QMSV contains build systems with syntax highlighting and inline errors for Quartus, ModelSim, and VUnit. As well as a snippet for a python script that is used for generating and updating Quartus project files, it also creates the basic folder structure, a VUnit python script, a Sublime Text project file, and gitignore file. Also included is an extended Monokai color scheme to support additional scopes in the SystemVerilog package.