Open Source FPGA based GDROM Emulator

Open Source FPGA based GDROM Emulator

ALL the info is Copy/Paste from ---> http://mc.pp.se/dc/gdromemu.html

This page describes an FPGA based piece of hardware that serves as a drop-in replacement for the GDROM drive in a Dreamcast. It uses data from a micro SD card to provide sector data and CD-DA streaming that would otherwise come from a CD or GD disc, thus simplifying development of disc-based software.

The supported features are:

• Sector read in all formats
• Audio track playback including subchannel Q emulation
• Multiple disc images on the same SD card (switched by removing and reinserting the card)

The design files for the hardware, and the source code for the FPGA bitstream and software, can be found on GitHub.

Hardware

The basis for the hardware is the Lattice iCE40HX-8K FPGA, which is a simple FPGA for which a completely open-source toolchain is available. I'm using the official breakout board, but due to the SMT connector needed interface with the motherboard, there is also a custom PCB that acts as a riser. The design files and Gerbers are available on GitHub, see above.

The complete bill of materials is as follows:
Quantity --- Description ------------------------- Mouser SKU
1 x ---------- iCE40-HX8K breakout board --- 842-ICE40HX8K-B-EVN
2 x ---------- 20x2 socket header --------------- 517-929975-01-20
2 x ---------- 20x2 pin header -------------------- 517-929836-01-20
1 x ---------- USB A female ----------------------- 571-292303-3
4 x ---------- 11mm spacer ----------------------- 761-M0540-3-N
4 x ---------- M3 nylon hex nut ------------------- 534-4688
4 x ---------- M3 nylon screw 16mm ----------- 534-29346
1 x ---------- 11.2896MHz oscillator ------------ 732-SG210STF11.289S3
1 x ---------- 0.1µF capacitor --------------------- 581-CB018B0103J
1 x ---------- Molex 52602-0579 connector ---- 538-52602-0579
1 x ---------- 9 pin header ------------------------- 517-9611096804AR
4 x ---------- 3 pin header ------------------------- 517-9611036804AR
4 x ---------- Jumper ------------------------------- 571-28815452
5 x ---------- 100Ω resistor ----------------------- 603-MFR-25FRF52100R
2 x ---------- 10kΩ resistor ----------------------- 603-MFR-25FRF5210K
1 x ---------- 22x2 pin header (optional) ------- 517-951244-8622-AR
1 x ---------- LED 3mm 1.9V 2mA (optional) - 604-WP710A10LGD
1 x ---------- 1kΩ resistor (optional) ------------ 603-MFR-25FRF521K

Most of these components are generic and there is no need to pick exactly the same manufacturer or model. Be careful about the dimensions of the pin headers and sockets though, as they are matched to the spacers.

The 20x2 pin headers are for populating J3 and J4 on the breakout board. Please note that the pins should be facing downwards. The last three components are not needed for the main functionality, they implement a passthrough for connecting a slave hard drive.

In addition to these components, you will need:

• A short USB-mini cable to power the breakout board (fits into the USB-A connector on the riser board). A cable with the connectors at a right angle, such as this one is recommended due to the limited space inside the Dreamcast.
• An SD-card module, and wiring to connect it to the 9-pin header. I used this module.
• Some rubber feet to support the board inside the Dreamcast. Since the distance to the plate below differs between the corners, using stackable feet is a good idea.

This is what the populated board will look like:


FPGA Configuration

The FPGA configuration consists of several blocks, as illustrated by the following schematic:


The AVR softcore implements the instruction set of an ATmega AVR CPU, and provides somewhere for the control logic software to run. It was developed by Ruslan Lepetenok and published on OpenCores. The Data and Program Memories are implemented using Block RAM. The Program Memory is preloaded by the bitstream, but can also be updated from the serial port using the on-board AVR109 compatible loader (which is implemented in logic, and does not run on the AVR softcore; the SPM instruction is not implemented).

The IDE block implements the standard IDE register file which is shared between the Dreamcast and the AVR softcore. It will interrupt the AVR when the Dreamcast writes to the command register, or when a transfer has completed. There is a 512 byte data buffer for PIO and DMA, which can be accessed by the AVR but also filled directly by the SDCARD block.

The CDDA block generates the digital audio signals going to the AICA system, and is used when playing audio tracks. There are two 512 byte sample buffers which are used in a ping-pong fashion to provided uninterrupted playback, and these can be accessed by the AVR as well as filled directly by the SDCARD block.

The SDCARD module currently implements SPI mode only. It has a built-in CRC16 calculator which can be used to check the CRC of a data block after a transfer.

Software

The software runs on the AVR softcore, and processes IDE commands from the Dreamcast as well as keeping the CDDA buffers filled during audio playback. Disc sector contents, for both data reads and audio playback, are read from an image file in a FAT filesystem on the micro SD card. The image file also contains canned replies for the GET_TOC and REQ_SES commands, as well as the disc type (GD-ROM, CD-ROM XA, CD-ROM, CD-DA) to report to the Dreamcast. When no micro SD card is inserted, the software will report that there is no disc in the drive.

The current image state can be observed on the LEDs of the breakout board. If they are scanning, it means that no micro SD card is inserted. If they are all lit, it means that no disc image could be mounted from the micro SD card. Otherwise, LED0-6 will indicate the disc image number (0-127), and LED7 will show when the image is being accessed.

Image files should be named DISC0000.GI0, DISC0001.GI0 etc on the micro SD card. On power-up DISC0000.GI0 will be mounted, to switch image eject and reinsert the micro SD card. The image files are created by the tool makegdimg which is built in the tools directory. It accepts .gdi files (for GD-ROMs) and .nrg files (for MIL-CD and audio CDs) as input.

Straps

There are a few strap jumpers on the board. JP1 controls the source of the 3.3V for the micro SD card. Normally this should be set to "DC" to use the 3.3V directly from the Dreamcast's power supply. However, during development it can be useful to set it to "FPGA" instead, using USB power converted to 3.3V on the breakout board, so that the micro SD card can be used even when the Dreamcast is powered off.

JP2 and JP3 controls the voltage on the VLOGIC and VMOTOR pins of the 44-pin IDE passthrough connector. Do not set them to different voltages unless you are absolutely sure what you are doing, as the pins may be connected to each other inside the drive. JP4 controls the CSEL pin of the 44-pin IDE passthrough connection. In the "M" position it is grounded, in the "S" position it is floating.


http://mc.pp.se/dc/gdromemu.html

 

I hope this project takes off and continues to grow.

 

That's very nice! Always cool to see such achievements being shared with the community!

Marcus's back!

 

I will be offering the boards unpopulated soon as my order arrives. Cheaper than OSHpark price (and you dont have to buy 3).

So anyone wanting to build their own, keep your eye on my sales thread.

 

Cool. Just saw this on the Faceplant group.

I've manage to modify the project and compile it for the Altera / Terasic DE1, so it should be possible to port it to pretty much any generic FPGA board. The code only takes around 4,000 Logic Elements atm, and only 13K of RAM blocks (which will fit in even the cheapest FPGA board). Not I'm just trying to compile the AVR core software, which is actually the most frustrating part because I have to use Ubunutu. lol

Usually when I've tried something as "simple" as compiling a tiny bit of code under Linux, something always goes wrong.

Anyway. This is great stuff. It's also been done by somebody we can have faith in. Marcus definitely knows his stuff, and his site has been invaluable for many years. I got a nice credit on the github readme at least. (but I must confess that if he's talking about the pinout with the RED text on, I did kind of pinch the original image from elsewhere, then added the extra text. Sorry. ) Very excited to finally get a GD Emu project working. I'd like to port the code over to an ESP8266 module though, as it will be plenty fast enough for the job, but will also make it FAR easier for anyone to compile the code using the Arduino IDE.

OzOnE.

 

Any idea what the hardware compatibility is like? In particular, GDEmu doesn't like VA0 DCs. I of course have a VA0 japanese DC without a drive...

 

I expect it isn't compatible with the VA0 - they use 5V signalling on the GDROM interface and that FPGA is only rated for 3.3V VCCio and there is no mention of it being 5V tolerant. Although, since it's an open-source project, there is nothing stopping someone from making a version with translating buffers on it.

 

Wonder if any one knows how to get the GD-ROM module connector.
I would like to make some experiment i need that connector to make one PCB to plug to VA1 board.

 

Shouldn't be a problem to do the voltage level conversion.

Are you sure the VA0 uses 5V on the G1 bus though? I don't think the Holly chip itself has a seperate VCC pin for +5V? I think it's just the GD drive itself, and Flash chip that run at 5V Either way, it's simple enough to add the buffers for it, or just add series resistors and clamp diodes, like my Altera dev boards do.

It won't be usable on the VA2 / 2.1 boards of course (without a custom flex and removal of one or more of the GD chips), as they don't have a G1 connector on.

Yesterday, I finally managed to get Marcus' code to compile under Quartus. It was a pain to get the stuff to compile properly under Ubuntu (as I've said recently. lol), but it's OK now.

But, I can't seem to get the AVR core itself to run properly. It's supposed to flash the LEDs while running, but I have nothing? Although, due to the fact that the "od" command in Linux not supporting the "endian" switch (and I have no idea how to update it, because... Linux), I'm not sure if I have the pmem_high and pmem_low hex files swapped.

I did confirm though that all the makefile is supposed to be doing with the od command is splitting thr originally compiled "avr_main.bin" file into the upper and lower bytes. So, I can run the core now, and see it reading instructions from the Program Memory (implemented in chip RAM on the FPGA), but still no flashing LEDs, and only two brief flashes of the UART_TX LED after power-up? I posted many more details on the "Let's make a new GD" Faceplant group. It would be great to get this running as-is, just to show that I've "ported" it correctly to Altera.

I did try to get the exact same AVR core running last year so I could run the SD2IEC core on the FPGA for the C64 core, but had lots of similar problems then.

Once Marcus' code is up-and-running though, I want to get it working using an ESP module on the SPI bus (will be more than fast enough, and have easier access to the SD card etc., and can be programmed very easily via the Arduino IDE, and could be hooked up to the HDMI board / OSD for game selection. ) I'll hopefully figure out this stuff today.

@FamilyGuy - would you possibly br able to take a look at the source code, and see if you can get the "od" command stuff to work with the --endian switch?

It doesn't matter about the yosys stuff, as I just need to confirm that I don't have the pmem_low / pmem_high files swapped (due the the possible endian mismatch). Also, if you would be able to get avr-gcc to be able to generate a proper .LST file with the Assembly code, that would be awesome. I did try adding the -S switch to the CCFLAGS constant in the Makefile, but no joy? Actually, I'm guessing the od command is part of the normal binutils stuff, so not avr-specific? I don't know which versions I'm using, I simply installed everything using sudo apt-get.

OzOnE.

Oh yeah - @mx450...

You can get the connector itself that plugs into the G1 port from Molex directly. You can request some free samples from their main site if you search for the part number first (given on the BOM on Marcus' page). Probably best to only request five or six connectors though, and you have to put in a "company name".

 

@OzOnE
Thanks
Found it.

 

It doesn't go all the way up to 5V, but it does swing significantly over 3.3V - the levels look to be basicallly unclamped 5V TTL levels. To be honest, you can probably get away with it (some of the early Everdrives were connecting signals like that directly to non 3.3V tolerant I/O pins, and they seemed to stay working), but it's not exactly best practice.

 

I just compiled it under Ubuntu 16.04 64bits. Although I think my avr-gcc version was lower than what Marcus suggests, it did compile the avr stuff with no problem, I have no way to test the resulting files though. They're in attach.

I had to install some stuff before it compiled:

Code:

sudo apt-get install gcc-avr binutils-avr avr-libc

I don't know what's a LST file, how do I create it from the sources?

I did not compile the yosys stuff.

If you can describe in details what the od commands are supposed to do I could cook you up a short single-purpose program to do it.

 

@TriMesh - Ahh, I remember now - I believe it's only the GD drive itself (and possibly the BIOS chip?) on those versions where they are 5V powered. But, I also recall that the G1 bus on the Holly chip is 5V tolerant. That means that if we can confirm if the BIOS is 3V3 instead of 5V, then it would be safe enough to put a GD Emu on those boards. That's because the outputs FROM the Holly chip will most definitely only be 3V3. It should even be possible to mod those machines with a 3V3 Flash chip if need be, then the GD Emu can definitely be used.

@FamilyGuy - Thanks, that's great.

All the Makefile really does with the "od" command is to split the avr_main.bin file into separate files with the upper and lower bytes of each Word. It also dumps the data out as ASCII HEX. So, where the avr_main.bin file has this at the start...

54 C0 00 00 6F C0 00 00 0C 94 AF 0A 6B C0 00

The pmem_high.hex file contains this (as ASCII text)...

c0 00 c0 00 94 0a c0 00

And the pmem_low.hex file contains this (as ASCII text...

54 00 6f 00 0c af 6b 00

So, it seems I was wrong about the order of the files - I should have known that the pmem_low file would contain the "first" byte, since the option switch in "od" said little-endian. Oh well, at least I know now, and I'll give this files a test later. I doubt it will cause the AVR core to magically run yet, as I seem to have something else wrong, but it's definitely a good start to have those files correct.

It sounds like I do also need to update my Ubuntu on the VM, as it's a rather old ver 14 now.
I thought it was a lot newer than that, but that was on Oracle VirtualBox, but there were TONS of problems with the latest version of that with x64 Ubuntu for some reason (lots of crashing and corruption etc.) I'm now using VMware Workstation, and the mouse and copy 'n' paste integration is far better. I just need to add an newer Ubuntu. That would probably explain why the "--endian" option was missing from "od" on Ubuntu 14?

Anywho. I'll definitely be playing with the GD Emu stuff again very soon.

I've spent most of the day messing with this evil 8" floppy drive, as I'm trying to prepare to recover the data from the old BBC Quantel Paintbox disks using the DE1 dev board ('cos the disks are in a weird format, and the Paintbox itself refuses to live).

(did I mention this crap before? lol)

Thanks again,
OzOnE.

 

It's been a while since I looked at this stuff, but I think it's the GDROM, the boot ROM and the flash that are 5V powered. The flash seemed to pull pretty high - about 4.5V, IIRC - which is about 1V above the absolute maximum I/O pin voltage rating on that FPGA. There are some series termination resistors on the G1 bus (33R?), and the FPGA presumably has ESD diodes in it, so there is likely to be some clamping effect (yeah, still not good practice..).

 

I think you're right. I should just take a look at the schematics, but my brain is fried. lol. So yeah, in that case, the BIOS chip would need to be changed to allow (Deunan's) GD Emu to work on those DCs.

I'm slowly getting somewhere with Marcus' code. I believe the AVR core probably is running, but it just got stuck because it was trying to process the IDE stuff without anything connected (inputs floating). On first glance, I thought the LEDs would flash a few times at power-up, but it seems not...

Code:

int main()
{
  DDRA = 0xff;
  DDRB = 0x00;
  PORTB = 0x00;
  DDRB |= _BV(EMPH_BIT);
  DEBUG_INIT();
  timer_init();
  sei();

  uint8_t leds = 1;

  for (;;) {
    PORTA = leds;
    delayms(250);
    delayms(250);
    if (!(leds <<= 1))
    leds++;

    service_ide();

    if (SDCARD_INSERTED)
      handle_sdcard();
  }

  return 0;
}

(ignoring the stupid smiley face, of course. lol)

I don't think the output buffers in the code were quite right either, so I re-wrote them in my own style...

Code:

assign porta[7] = (porta_ddrx[7]) ? porta_portx[7] : 1'bz;
assign porta[6] = (porta_ddrx[6]) ? porta_portx[6] : 1'bz;
assign porta[5] = (porta_ddrx[5]) ? porta_portx[5] : 1'bz;
assign porta[4] = (porta_ddrx[4]) ? porta_portx[4] : 1'bz;
assign porta[3] = (porta_ddrx[3]) ? porta_portx[3] : 1'bz;
assign porta[2] = (porta_ddrx[2]) ? porta_portx[2] : 1'bz;
assign porta[1] = (porta_ddrx[1]) ? porta_portx[1] : 1'bz;
assign porta[0] = (porta_ddrx[0]) ? porta_portx[0] : 1'bz;

assign porta_pinx = porta;

And for PORTB, it can have the SPI module take over (for accessing the SD card), so it's a tad more complex, but easier to understand than the original AVR code...

Code:

assign portb[7] = (porta_ddrx[7]) ? porta_portx[7] : 1'bz;
assign portb[6] = (porta_ddrx[6]) ? porta_portx[6] : 1'bz;
assign portb[5] = (porta_ddrx[5]) ? porta_portx[5] : 1'bz;
assign portb[4] = (porta_ddrx[4]) ? porta_portx[4] : 1'bz;

wire [3:0] bddrx;
assign bddrx[3] = (spe & spimaster) ? 1'b0 : portb_ddrx[3];
assign bddrx[2:0] = (spe & (~spimaster)) ? 3'b000 : portb_ddrx[2:0];

assign portb[3] = (bddrx[3]) ? (spe & (~spimaster)) ? misoo : portb_portx[3] : 1'bz;
assign portb[2] = (bddrx[2]) ? (spe & (~spimaster)) ? 1'b0 : portb_ddrx[2] : 1'bz;
assign portb[1] = (bddrx[1]) ? (spe & (~spimaster)) ? 1'b0 : portb_ddrx[1] : 1'bz;
assign portb[0] = (bddrx[0]) ? (spe & (~spimaster)) ? 1'b0 : portb_ddrx[0] : 1'bz;

assign portb_pinx = portb;

Oh yeah - @FamilyGuy. The LST (List) file is just a disassembly of the compiled code. It's really helpful in trying to debug stuff when looking at which address / instruction is being accessed next etc. You can disassemble the file after compiling by doing something like this...

avr-objdump -D avr_main.elf > avr_main.lst

But, it doesn't look quite right to me, as I don't think the starting vector is correct?

avr-gcc is supposed to generate a List file when you add the -S switch to the Makefile, but I can't seem to get it to work?

I just upgraded to Ubuntu 16 as well, but I STILL can't figure out how the hell to update the "od" command, as it still doesn't support the --endian=little switch?

How do you tell in Linux which package a program is part of, and how do you then upgrade it to the latest version? Really annoying. lol

OzOnE.

 

Oh...

od --help

...says it is part of "GNU coreutils".

So...

apt-get install coreutils

Seems to do the trick.

OK, so I can now finally generate the main files easily, so I can change the LED stuff just to see if the AVR core is actually alive.

OzOnE.

[EDIT]
Spoke too soon - it still doesn't support the --endian switch. But whatever - if you omit the endian switch, it DOES still produce the files in the correct order (on my PC at least). Can't get the LEDs to flash though? It's doing even less than it did earlier, and all I did was change to this... lol

Code:

uint8_t leds = 1;

for (;;) {
    PORTA = leds;
    delayms(250);
    delayms(250);
    leds++;

    PORTA = leds;
    delayms(250);
    delayms(250);
    leds++;

    PORTA = leds;
    delayms(250);
    delayms(250);
    leds++;

    service_ide();

    if (SDCARD_INSERTED)
      handle_sdcard();
  }

It's a bit weird why the leds uint8 gets assigned to PORTA rather than the PORTA bits written to directly, but fair enough. Now the code just seems to get stuck in a loop after a few hundred instructions? sigh.

OzOnE

[EDIT 2]
Wow - finally got some life out of it. lol. The LEDs now cycle a few times, but I had to disable the debug stuff to get it working (in config.h). So, the AVR core is alive, and the RAM must be working. That's all I was trying to determine at this point. hehe

Thanks for your help, guys. Next step is to hook it up to a G1-ATA adapter and a Dreamcast.
I know I'll need to use the "makegdimg" file to generate what the code expects from a GDI though.

I'm also not sure where the files for the 0x71 and other responses are? They are apparently supposed to be written to the SD card as well, so I'll have to look at what the code expects.

I'm not making any promises to even have the DC hooked up today, but I'll see what I can do.

Once the AVR core version is working, I still want to rip that out and use my own OSD core with the ESP8266 module to see if I can port the code over to it. That would mean that a very small FPGA or even a CPLD could be used to interface to the Dreamcast G1 port, and that would reduce the cost even more.

OzOnE.

 

The response for 0x71 seems to be in the AVR code:

(in ide.c)
static const uint8_t cmd71_reply[] PROGMEM = {
0xba, 0x06, 0x0d, 0xca, 0x6a, 0x1f
};

 

od is just octal dump and is part of coreutils as you found out, if you need a version that supports the --endian switch and don't want to build from scratch let me know and I can send it to you. All it does is dump a file to stdout in a given base (16/hex, two byte units, "-tx2" in this case), and based on the makefile it looks like he is using sed along with od to do an in-place byte swap. Though admittedly my sed regex is pretty bad.

Did you get the assembly listing sorted? Let me know if not and I build the target for you.

 

@TriMesh - That's so weird - I literally just found that as well just now, and Googled it to see if any other emulators had used it (because all the ones I've seen previously used that large-ish 400-odd byte reply). lol

I'm currently looking at how best to "port" the code over to the ESP8266. The IDE buffer and other stuff will all be accessed via SPI though, so that may prove "interesting" for the memcpy stuff.

@Trident6 - that's OK thanks.

I still didn't manage to find a version of "od" / coreutils that had the switch, but it still generates the pmem files in the correct order on my system.

I couldn't figure out how to generate a "proper" LST / LSS file either.
What I'd really like is for the Makefiles to generate a full List file based on the whole avr_main.bin. The disassembly from avr-objcopy doesn't seem to have the right address offsets though? ie. those "vectors" at the start might even be in the right places, but I'm not sure that it was supposed to try to disassemble those directly? (assuming they are the reset / interrupt vectors?) What would be even better is if it could generate the List file with the C code interspersed (which GCC is supposed to be able to do?) Don't worry too much though - if I can work out the best way to map the low-level hardware stuff in this C code, I'll hopefully get it ported to the ESP anyway soon.

Regards,
OzOnE.

 

Sure, I can take a look. I am a bit busy at the moment so it might be a day or two however. Can you tell me why you think the offsets are wrong?

In the meantime, try running this from the same place you are running make from and see if it does what you want:

Code:

avr-gcc -MMD -c -Os -fomit-frame-pointer -Wa,-adhln -g -mmcu=atmega64 -I. -I./source -x assembler-with-cpp -Wl,--defsym,__stack=0xfff -mrelax ./source/main.c ./source/sdcard.c ./source/fatfs.c ./source/imgfile.c ./source/cdda.c ./source/ide.c ./source/timer.c ./source/debug.c ./source/delay.S -o tmp.out > test.list

This is kind of a shot it the dark since I can't test it right now, don't worry if it doesn't work. It is worth noting that he is using objcopy to create the .bin from the .elf and some other files. I haven't used objcopy much but according to the manpage it will generate S-records. These will likely have different offsets than the .elf will.

I'll admit that I'm not totally sure of the information you are looking for, but avr-objdump -d [file] will disassemble only the executable sections of a bin, or avr-objdump -h [file] will give you a section listing.