Open Source FPGA based GDROM Emulator

Is anyone else playing with this? I just put together some boards based on Marcus's reference design, and I was wondering if anyone else had already got it running (I'm still waiting for the actual FPGA boards to arrive, so I can't do any actual testing yet).

I guess once it's running the first step is going to be to write a user-friendly menu system.

 

@Trident6 - thanks, but not to worry - I managed to "port" the Verilog to the Altera FPGA (and my OSD module) and port the C code to the ESP8266.

I mainly had to change the hardware routines to work via SPI instead of being directly memory-mapped like Marcus was using on the AVR core. I still have a fair few things to test and fix, but I'll be hooking it up to a DC soon.

I also just bought a Pico PSU, and only just soldered it to a cable yesterday so I can power the DC from it.

I'm going to plonk the whole thing onto a bit of MDF board (ironically from a Sega Mega Tech cabinet), which will make it safer and easier for me to test everything using the DC mobo, Pico PSU, Dev board / HDMI board, and a 7" TFT panel with controller board.


@TriMesh - that's awesome progress already, my friend. How on Earth did you get the PCBs manufactured so quickly? lol

As you've no doubt seen in Marcus' code - it looks like he did keep the high-level stuff fairly simple so that it can be easily enhanced later on. It shouldn't be too hard at all to allow the filename to be chosen via a menu etc.

Also, with the help of you guys on here, we'll hopefully be able to add direct support for GDI / NRG / ISO images, so they don't have to be pre-converted to run on the board.

Personally, I'd rather ditch the older ISO rips altogether, and just stick with full GDI rips from now on. That is unless there are some homebrew / rare / obscure / unreleased titles on ISO, of course.

I may be releasing my code at some point, but only after I've confirmed that it's all working.
That will let anyone use a cheap Cyclone II dev board or whatever. If it's used with an ESP8266 module like I'm doing, then it should still work out cheaper than the board Marcus recommended, as it only requires a tiny amount of logic on the FPGA side. The whole design should then fit in a small off-the-shelf 5,000 LE FPGA just fine. The other advantage of the ESP module is just that it makes it a lot easier for people to compile and re-program it via USB on most PC or Mac platforms. Plus, I'm hoping people will add some cool features that work via WiFi etc. (although I don't think the WiFi libraries are currently very fast, so transferring files to the SD card via WiFi is bound to be fairly slow atm.)

OzOnE.

 

Very cool stuff guys.

I'm not working on it personally at the moment (too busy, short on time, blah blah all the usual excuses) but if you need any help on the MCU side of things I can take a look.

ESP seems like a bit of a strange choice admittedly. IMO if you are going full-custom with the PCBs it would make more sense to just drop a small ARM SoC on there instead of worrying about the soft core. Then you could JTAG to your heart's content and keep the FPGA logic even smaller. Nordic also has some BLE MCUs that would be fun to play with. The nRF52 supports BLE and proprietary 2.4 GHz wireless with the SoC radio, and uses an ARM M4 for the micro. Food for thought anyway.

In fact you may be able to dispense with the FPGA completely. Atmel's SAMG55 line can clock up to 120 MHz, we used one for a project at work recently and were pretty impressed by it. I'm not sure what the throughput and latency requirements are for this but you may be able to keep up using an MCU alone.

 

The ESP module was mainly chosen because they are dirt cheap, very easy to program (for us, and for the end-user), and are fast enough to just use SPI to hook up to the HDMI board.

Even if / when I can get Marcus' GD Emu code working, the SPI bus should still be plenty fast enough for transferring the data etc.

The idea with the HDMI board was to keep it as small as possible, and it was a pretty tough job for Mr [RDC] to design and route the board as nicely as it is now. If we added any more parts to it, the board likely wouldn't so easily fit into many of the handhelds and other machines we're planning on targeting (eg. Atari Lynx, Game Gear, Game Cube, etc.).

Also, the idea of being able to use the WiFi on the ESP module is huge for future plans / upgrades.
(Not to mention the fact that since it has WiFi, the ESP module will need to be placed somewhere outside the footprint of the GD drive anyway, so it can pick up a decent signal through the DC's case.)

The ESP module was originally intended as a nice way for people to code mini-games on the new OSD module, but it looks feasible to be able to run the GD Emu stuff from it as well.


Literally just a few hours ago, I just hooked up a Pico PSU to a Dreamcast mobo for the first time.
That will make it safer / easier for me to do some testing with the GD Emu stuff (and the HDMI board in general).

I don't like the idea of trying to do the low-level stuff using only an MCU though, personally.
I wouldn't have been able to do the OSD stuff quite like I've done, plus I'd still need the FPGA or CPLD to be able to handle all the different video protocols of each console / computer anyway.

(add the fact that my C coding isn't a good as some of you guys on here, so it would take me about another two years if I tried to do the whole lot using a different MCU. lol)


Even with the video stuff for the DC, and the OSD, there's still plenty of logic left on the FPGA to be able to implement the low-level parts of Marcus' code. The rest of it will simply run on the ESP module, so it was a natural choice tbh.

So, we're still working on trying to get the kits released as soon as we can.
It will likely not include the GD Emu stuff at this rate, but will instead be an option later on with a firmware update and another custom flex cable to hook up to the G1 port. I'll be doing my best over the next few weeks to get that running though.

There are JUST enough spare IO pins left on the board to be able to do that, but I'm doubtful that I'll have everything working and thoroughly tested before the boards are released. We just need to get the kits in people's hands for now tbh, then worry about the extra features later.

(the obvious other benefit of getting the GD Emu code working on the same HDMI kit is being able to allow users to choose different games directly via the On-screen menu. That will literally be a game-changer. )

OzOnE.

 

@OzOnE - I got them from one of the PCB suppliers on Shenzhen on 4 day turnaround, and then shipped by courier to one of my friends that lives there, so they arrived the next day. Picked them up this weekend and then soldered them. The annoying thing is that I ordered the FPGA boards from Mouser, and expected them to turn up before the rest of the boards did, but they seem to have been delayed. I still need to get the spacers (don't have any the right length) and the feet.

 

I have 100 boards on their way to me, I just happen to be on holiday - so they are sitting in a DHL warehouse. They were supposed to have been delivered on the 19th.

Back on 27th, so anyone who wants a board to build can buy one too. Expect this to get busy in the coming weeks

 

Wow, I can already imagine all the possibilities. While it is already possible to boot back to GDMenu by pressing A+B+X+Y+Start with the new custom bios from JapaneseCake, this would be great for those whom don't have modded systems.

How much memory will that board have reserved for the OSD? With the WIFI functionality you are touting I can already see some interesting possibilities with this. You mention the ability to have mini games on it, but that leads me to think it has some ok gfx, so maybe some internet RSS reader type stuff could be displayed on it. Obviously that is something super simple, just speaking about ideas, but I could see maybe the ability to interface with some simple stuff on the net, like showing who of your friends are online ect.

 

OK, the FPGA board came in, and it 's all together now:



And here is it in the process of booting up (@OzOnE - that little response to 0x71 clearly IS enough...)



For anyone else planning to build one of these. don't use the versions of yosys and arachne-pnr that are in the Ubuntu package feed - they are too old. Arachne-pnr stops with an assertion failure and yosys apparently works but seems to produce a broken bitstream that won't allow the board to boot.

I ended up getting the latest versions of those and the latest version of icequake from git and that all worked. The dependencies are about what you would expect - lots of compiler type stuff for yosys (flex, bison, etc.) and you need to install mercurial because some of the source packages are being patched.

If you find the board won't initialize (all the LEDs are on dim) then make sure you are running at least yosys 0.6 and try a clean make.

 

Where can I buy one?

 

Right now, you can't - basically you have to build it yourself. This is also (right now) a much more clunky solution than something like USB-GDROM or GDEMU - but being open source we should be able to get some development going to make it more user friendly.

 

Yeah, I remember when Denuan was working with one of these types of FPGA boards when he was developing GDEmu. What it was in the very beginning and what it ultimately ended up being were vastly different devices.

It might take a while but this is just the first steps towards designing ones own board. Good luck with your project. Will be keeping an eye on this.

 

@TriMesh - Ahh - I forgot you lived out there, mate. Makes sense how you got the PCBs so fast. hehe. Awesome work, my friend - I haven't even got around to plugging the dev board into the DC yet. Would you be able to upload a short vid of it booting something?

@Bad_Ad84 - 100 boards.

Blimey - is there much point me struggling to find the last few IO pins to add the GD Emu stuff to the HDMI board? lol (which is delaying it's release atm, as well as having to do another small PCB layout for the ESP module and USB UART.)

btw - there are some peeps on Faceplant who have apparently been trying to contact you regarding some Flash chips? Can't recall exactly who now, but they said they'd PM'd you, or possibly e-mailed you?

@Anthony817 - There is about 1MB of Flash available on the ESP8266 when using it with the Arduino software.
At the moment, it's using about 25% of that while storing the background data for the first screen you see on Sonic 2 (Mega Drive), so that's not too bad. There would be enough Flash and RAM to write small games for the HDMI board itself, using MD / Genesis style graphics.
There's only enough spare Block RAM on the FPGA to hold about 16KB of pattern (tile) data though, which is a quarter of what the MD normally has.

We always have the option of offering a board with a bigger FPGA on, but really it's just a fun thing to mess with that adds support for the OSD menu, but also some cool scrolling graphics etc.

There's also still plenty of code space left on the ESP module to handle some WiFi stuff, and still about 50% of logic left on the FPGA for possibly adding the MJPEG compression / decompression for the Netplay idea (maybe).

The GD Emu stuff has kind of taken priority over the Netplay and "dial-up via WiFi" stuff now, but we just want to get the damned thing released ASAP. lol

I've just sent an e-mail reply to Mr [RDC] about getting these last things done, so we can release the board pretty much as-is, then offer the GD Emu stuff later on.

Deunan was using a Terasic DE1 board to develop the low-level stuff for his GD Emu.
That's the same board that I still use for most stuff these days. It's a superb all-round board for tons of stuff.

The DE1 has 20,000 LEs, but only a small fraction of that would be needed for the GD Emu stuff (when using an external MCU for the high-level stuff, like what Deunan and cybdyn did, and what I'm aiming to do now with the ESP module.)

It won't take very long at all for somebody to design a new PCB for the GD Emu though, and I know for sure that it could be made a fair bit cheaper. That's why I'm wondering if I should bother at all trying to add support for it with an all-in-one board, or just release a separate board for that (which could still definitely hook up to the HDMI board anyway, so the OSD could be used to select the games.

I'm kind of stunned that TriMesh got this working so quickly though. Great work.

I still wonder why Marcus didn't upload a vid of his working though? I think it's just his style?
It will be good to be able to read GDI images directly, but that can be figured out later.

It's certainly very easy to modify the source to select filenames etc.
I'm sure an OSD could easily fit on that FPGA board too.

OzOnE.

 

If you are buying 10, 100 isn't much more etc.


Any pm's or emails about chips I will respond to. I am little slow this week as in Ireland, but I am getting through them when I get the chance. I am back Saturday and all back to normal then.

I'm planning to design a custom board for this whole thing too

 

I'm a bit of a newbie to this, just how compatible with this solution is the Dreamcast library of commercial games? I heard the GDEMU is like 99% compatibility, will this come any close? Has anyone tested games on it yet?

 

£9 per bare PCB - including worldwide untracked shipping

 

Wow that looks awesome.

 

OK, I"ve been holding off posting this for a bit, since I wasn't sure if it was just a problem with my board, but the current firmware is pretty slow - like 1/3 to 1/2 of the speed of a real GD-ROM. It doesn't crash, but it slows things down and makes anything that relies on real time streaming from the GDROM (I.E. Crazy Taxi) basically unplayable.

This weekend, I put together another board and got identical results from it - so I can be pretty sure that it's not a problem with my board, but is just the current state of this design.



So right now, if you want to run commercial games, then you have to accept that this will be slow - and sometimes annoyingly slow. It does seem to be perfectly stable, though.

I'm going to have a look at improving the buffering, since that seems to be the bottleneck right now. There is not much BRAM left, though, and since the design is using a soft core that means that RAM for buffering and increased code space are both competing for the same resource.

 

@TriMesh

Thanks for the through reply. Then the issue is mostly software-bound and there's room for improvement so that streaming-intensive games will be improved? Do games that have FMVs need even more constant loading than Crazy Taxi?

 

I'm sure it can be improved - the code seems to have been written more with clarity and correctness in mind than high performance. Biggest potential issue seems to be the memory shortage, but that shouldn't be insurmountable, just fiddly.

At the moment, FMV generally stutters - this seems just to be insufficient sustained transfer rate.

 

just saw this. great to see another dreamcast mod. will keep an eye on this