Initial Progress and openGDROM Design Choices

Initial Progress

Development Hardware

  • Planning Stage
    • Serial adapter/coders cable
    • Wireless controller development boards
    • G2 Bus Breakout
  • Revision Stage
    • G1 Bus Breakout
    • Maple Bus Breakout
    • openGDROM board into a G1 and G2 bus development board

Programming and Prototypes

  • Planning Stage
    • Wireless Network Adapter
  • Proof of Concept
    • Wireless Controller
    • GD-ROM Drive Emulator

Information

  • Gathered a bunch of information and documentation that needs to be cleaned up

Tertiary

  • Proof of Concept
    • 32+ Channel Logic Analyzer

About The openGDROM Design

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. Even if I’m not the one who ends up selling it.

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

Design

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 MCU with 128KB+ of RAM would be a good choice, either with a 4-bit SD card interface or USB-High Speed. Since you technically need to be a member of the SD association to sell a product that is an SD host that makes SD cards a questionable choice,  I don’t think you need to be a USB-IF member to sell something with USB unless you need a vendor ID.

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.

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.

Coming Soon

In the next post, I think I'll talk about plans and design considerations for some of the other boards.