Open Source FPGA based GDROM Emulator

I'm guessing the SD card is being used in SPI mode. Could that be the issue? I hope not, since the specs for accessing SD cards in faster modes aren't publicly available. It's too bad that the GDEMU is closed source.

 

There is adequate documentation on how to use SD cards in 4-bit mode - the problem is that according to the SD card association you need a license to use it. I suspect that GDEMU is using the 4 bit mode - that SAM3 CPU he is using has support for it.

 

Maybe part of the cost of GDEMU is that license. Perhaps there's a more efficient SD card core on opencores that could be swapped in without a ton of effort. I'll probably order the parts and make one too, since I just missed out on the recent GREMU order.

I briefly took a look at the Verilog code, and it looks like that there's a direct memory interface between the SD card's SPI library and the IDE interface, but I'm not sure how many bytes are being transferred at once (it looks like a single byte at a time?). I think there's at least one SD card core on opencores that might implement transfer of sectors instead of single bytes.

Actually, I'll probably hold off for a bit, since it looks like Marcus is actively working on iceGDROM- there were some commits as late as 10 days ago, and it looks like he's working to improve the throughput.

 

I didn't read every post in here, but is anyone planning on producing enough of these to put them up for sale? And will the price be less than GDEMU and if so what's a rough estimation of the price?

 

I'm willing to bet someone will, once the development on this gets a more refined. As a very rough estimate, using the exact parts listed in the first post from the listed sellers runs up to about $84. But around half of that is the breaker board, so if someone gets this working with a cheaper module (as it seems people are trying to do), and is able to scout out cheaper prices for the rest of the necessary components, it's possible someone could put one together for significantly cheaper.

 

I bought all the parts (minus a resistor) off Mouser for about $75 shipped in the US. This doesn't include the cost of the PCB, which I ordered from dirtypcbs.com at $25 for 10-ish of them. After assembly and shipping, I'm not sure it'd be much cheaper than GDEMU. The FPGA dev/breakout board is about $40, but has the largest FPGA in its class from Lattice (iCE40HX-8k CT256, 7680 LE's). The bare FPGA is around $13 on Mouser, so if someone were to design a single PCB, costs would go down (plus there'd be fewer headers/connectors on the board).

It looks like one of the goals of the iceGDROM is that you can build it yourself relatively easy- I think the Dreamcast G1 connector is the only surface mount part on the board. The issue with a custom PCB is that the FPGA is a BGA package, making it more difficult to build the board yourself.

I'm hoping Marcus (and/or folks here) can get the speed of this board up. I'll certainly try my best to help, but as I'm pretty new to FPGA development, I'm not sure I can contribute too much. I had always hoped Denuan would open-source his design and/or software, but a few years ago he stated that he wouldn't.

 

why would he, when hes making good money off gdemu

 

Perhaps; I'm not sure how much he makes off each unit. Also, at some point he'll probably stop producing them. Hopefully he'll open-source it all when that time comes. More importantly, hopefully iceGDROM will be nice and speedy by then, making it kinda moot. =)

 

some days ago i think he did mention he might stop making them

 

If he stops making them, he could still license the design to stoneage gamer or something and still make some money out of it with minimal effort.

 

I was looking again at the schematics and parts for iceGDROM, and I noticed that the SD card module that Marcus is using appears to have resistors connected to each line. I assume said resistors are for level shifting. If this is true, then it could result in slower signal rise times, causing the card's speed to slow considerably. From the pictures, it looks like @TriMesh has the same modules.

I'll have my boards from the fab house in a couple days, and will try an SD card module without the resistors.

Edit: Here's a link to the schematic for that board: http://www.waveshare.com/w/upload/8/83/Micro-SD-Storage-Board-Schematic.pdf

Edit 2: Nevermind, those are pull up resistors! =)

 

Hello im looking to build this project and im wondering if it would be possible to use HX4K? it would allow to use 144 TQFP package and be possible to make cusatom board by hand. I dont know about the software side and how it would be possible.

 

The FPGA needs at least 6000 LEs for the bitstream to fit. I'm not sure how many you can get on the HX4K.

 

so its a no go

my idea is to build a pcb but dont want it to use BGA chip. I want to try di desing a pcb a solution to run this code that is cheaper. For this i have to use tqfp package to make it easy to solder. Maybe a smaller fpga and external avr chip.

 

I totally understand, and agree. The Verilog code is probably easily portable to other FPGA platforms, some of which offer *QFP packages. Also, it's possible that the 16MHz AVR soft core is contributing to the current bottleneck, so moving to an external chip might help things out. Both the GDEMU and USB-GDROM use external microcontrollers. =)

 

there is a guy making the hdmi adapter that porter the avr code to external cpu i will try to get more info prom him!

 

It's OzOnE, and he mentioned that he ported the FPGA portion on his Altera chip, and the C (microcontroller) portion to the ESP8266. It seems that OzOnE is pretty busy with the HDMI board, so I didn't want to bother him about his iceGDROM progress. I'd like to get the speed issues resolved, but haven't had any time to work on it. Step 1 for me would be to change the SD card access mode from SPI to 4-bit and see how it affects the speed of the system. Lattice has a reference design for this.

 

This sort of thread is what we really like to see, guys - members working on projects and bouncing ideas off each other, providing support. Superb work, keep it up!

That said, I've had to do a lot of moderation on the thread. Please remember that we have an edit button - if nobody has replied to the thread since your last post (and it's within a week of that post), just edit it rather than double/triple/5x posting! I've removed all (bar one) of the double posts and the thread is now a page lighter! It's really appreciated in these threads - of course there's a lot of back-and-forth conversation, but 5 posts from the same user in a row really clutters these posts quickly.

Likewise, try to write in proper paragraphs. You don't need a new paragraph for every sentence! Basic paragraph rules - use a new paragraph for a new topic. So if you're talking about code in one paragraph then go on to talk about your test board, that's a new paragraph. If the next sentence begins with "that means" or therefore or so or any such conjunction, you don't need a new paragraph.

Good luck with the project!

 

I hope that more people will work on open source solution for this! It's a shame that such knowledges could be lost. And i think one could still make money from this if it's necessary (deunan stated that he use the money to work on other devices)

Keep up the good work!

 

I actually have a board built, but haven't had a chance to test it yet.