Deunan
Genesis 
30th-Aug-2012 02:44 pm
Let there be light:
2012-08-30 GD-EMU proto V2 #1

And there was light:
2012-08-30 GD-EMU proto V2 #2

More pictures to follow soon :)

Status so far:
Voltage regulators - check
MCU starts - check
Bootloader operational using 3V3 UART - check
MCU JTAG - check
C runtime stub + simple exception handling - check
Status LEDs - check
UART 115200 8N1 console - check
Interrupts - check (need to investigate if registers are really properly saved though)
External RAM - check (problem found, should be fixed now)
High speed SD interface - in progress

Random fun fact: Many SD/SDHC cards exhibit various little quirks in SPI mode so the code needs to be aware of those to work properly in every case. One would think the native SD protocol is so tightly standardized that there should be no such surprises. Well, I just found a bunch of 2GB Kingston SDs that respond to ACMD41 with bad CRC7...

EDIT: Turns out the R3 answer is the only one not protected by CRC7, that space is marked as reserved and just filled with all-ones. I'm still not getting the busy bit within reasonable times on these Kingstons but I suppose reading the docs few more times might teach me something new again.

Anyway, here's the actual thing:
2012-08-30 GD-EMU proto V2 #3

Now it's a proper prototype, with all these wires and blinking LEDs. A few things are still missing on the PCB but right now I need to get SD protocol working so I can fetch FPGA configuration image and test it.

EDIT:

High speed SD interface - check
DMA on SD i/f - check
Basic FAT support - check
FPGA - in progress

I'm using my own FAT library, which has no write support but it was designed to be fast while consuming as little RAM as possible. In fact current SD cards are so fast it makes sector buffering impractical, since the lookups and LRU queues kill any gains with additional overhead. I suppose it'd be different if the CPU was clocked above some 400MHz and had some fast L1 cache.
Right now I get average of ~10MB/s in test that seeks to random part of 1.2GB file and reads 1-3500 consecutive 2352-byte long chunks. This is to simulate RAW image reads for GD-ROM. So pretty well I'd say, a nice boost compared to 2.5MB/s I got over SPI.

The native SD interface required a pretty much complete rewrite of some code, so I'm not 100% sure it's stable and all, but seems to work for hours without problems so far.
Comments 
30th-Aug-2012 10:16 pm (UTC) - You are a genius
Anonymous
When I read this I couldn't believe: this is a marvel of the reverse engineering!
Congratulations!
31st-Aug-2012 11:29 am (UTC)
Anonymous
Wow. that looks pretty :) well done mate.
31st-Aug-2012 12:02 pm (UTC)
Anonymous
Awesome work!

How have I not seen this before.
31st-Aug-2012 12:31 pm (UTC)
Anonymous
Awesome work!

I want to buy one lol
31st-Aug-2012 03:12 pm (UTC) - YES!
Anonymous
KEEP UP THE GREAT JOB! YOU CAN DO IT!
31st-Aug-2012 05:54 pm (UTC)
Anonymous
what fab shop is giving you a 2 week turn?
31st-Aug-2012 08:21 pm (UTC)
http://www.eurocircuits.com/
It's 7 working days for the cheapest 4-layer PCB service. Including shipping and a day or two spent on soldering this translates to about two weeks.



Edited at 2012-08-31 08:22 pm (UTC)
1st-Sep-2012 10:49 am (UTC) - Great work
Anonymous
Your work in all its forms is inspiring Deunan.
I very much look forward to the day that I can purchase this - even if it's only in kit form. PARTICULARLY if there was some way I could get it to work with CF cards....
Regardless, awesome work! Thankyou for posting about it and please keep us updated with how you go!
Kindest regards,
Alister.
1st-Sep-2012 11:17 am (UTC) - Re: Great work
I suppose you could always try to find CF to SD adapter :P
Seriously though, CF cards are bulky, not really that much faster than the best SDs (all I need is some 3-4MB/s, and I get 10 with old class 2's) and require tons of signals and delicate socket. I'd have add another FPGA just to have the I/O count to even connect a CF card.
In fact I wanted to use micro-SDs but I have many classic ones and there are easy to use adapters, so...
Re: Great work - Anonymous - Expand
1st-Sep-2012 11:45 am (UTC)
Anonymous
А какие форматы планируется поддерживать? GDI CDI ISO ?
Планиурется 1 игра = 1 карточка, или можно будет несколько образов закинуть на карту и вбирать уже потом?
1st-Sep-2012 05:37 pm (UTC)
ISO - yes, but keep in mind this will not boot. So, ISO is only good for homebrew and/or with boot disk. See below.

CDI - I want to support it but there are some legal issues (it's not a free format, it belongs to a company that made DiscJuggler)

GDI - it's free :) But the fact that it has one file for each track is a bit problematic, especially while trying to play CDDA without breaks between tracks.

So, initially I will support GDI but I want to make my own format that will work better with this device. There will be a converter for GDI and CDI, so that anyone can make SD card with games on it.

I plan to have several games on one SD card. But I want to make it a simple solution. So, it will be a structure like this (4GB card):

\ (root folder)
GD1 <- first game
GD2 <- second game, disk 1
GD3 <- second game, disk 2
etc.

The images can be switched with the two buttons, and the LEDs show which image is selected. So there is going to be a limit of about 16 images or so. I plan to support hot-swapping the cards as well.

With this solution you can also have boot disk image as "game 1", and then the rest can be non-bootable images.
2nd-Sep-2012 12:26 am (UTC)
Anonymous
Sorry if this has been answered already but, How much are these devices going to go for when they are finished? (that's if your planning on selling them)

I'd be interested in one if the price was right ;)

Also could you post a pic of the device connected to the DC?

Thanks :)
2nd-Sep-2012 11:09 am (UTC)
At this stage nothing has been decided yet.

As for the pic, you can see how the prototype connects to DC on some of my previous posts where I presented the proof of concept with FPGA dev board. In the end I'd like to have a connector there that would match the GD drive one but sourcing those is neither easy nor cheap for me.
2nd-Sep-2012 03:46 am (UTC) - \m/
Anonymous
Finally, you are a hero!!!
2nd-Sep-2012 04:01 pm (UTC)
Anonymous
regarding to your concerns about the CDI format, i must tell you that PADUS went out of business, wouldn't hurt to add native CDI support... there's also a lot of burning software on pc that supports it, even before padus went out of business and they didn't seem to have a single problem with them...
2nd-Sep-2012 04:33 pm (UTC)
Yes, but AFAIK someone bought the leftovers. See, Makaron also has CDI support but it's a free app. It might get hairy if I try to sell stuff that doesn't belong to me :) We'll see.
2nd-Sep-2012 06:44 pm (UTC)
Anonymous
So will this support 4 players because I thought in a previous post you said something about only 1-2 players?
2nd-Sep-2012 08:29 pm (UTC)
What? This is a GD-ROM drive emulator project. How is that even remotely connected to 4 player support? What game?
(no subject) - Anonymous - Expand
2nd-Sep-2012 10:06 pm (UTC)
Anonymous
Thank you for update. There are chinese copmanies that can mass produce it but they need big item number order, i can help with investment, most likely many peeps too. Good luck with the project.
3rd-Sep-2012 11:12 am (UTC)
Oh sure they can manufacture it. Also copy it while at it :)
Well, one idea would be to have them only make the hardware and send it to me first for firmware programming. Because obviously I'm not going to solder all of these by hand if I want to sell this product :)
3rd-Sep-2012 04:40 am (UTC)
Anonymous
This is pretty much exactly what I was about to start working on shortly. Do you have a complete build log on this? Sorry if this is an obvious question, I followed a link from a forum. I wish you luck, and I will offer services when I get time. Of course, you seem to pretty much have it covered, so my help likely isn't needed :P
3rd-Sep-2012 11:36 am (UTC)
No, there isn't a build log. Just my rant as I progress. I have so many projects that keeping a detailed log on each one would take all my free time :)
You can go through my older posts and look for V1 prototype (aka proof of concept) done on Altera DE1 dev board. V2 is meant to have a hardware CPU (rather than soft-core running on FPGA) and much smaller (thus cheaper and easier to use) FPGA.

Out of curiosity, what forum and what services do you offer?
(no subject) - Anonymous - Expand
3rd-Sep-2012 08:53 am (UTC) - How to control the board?
One word: awesome!

I just have basic groundings in electronic and this is why I tried to do a 100% software solution to boot game over the network. Things got awkward when I tried to play with DMA and I still don't have a solution for CDDA. I think your solution is just the best we can get. I've a question though: won't it be possible that your board embeds a serial if bound to the console serial if so a software running on the DC would enable US to select a game without playing with buttons on the board?
With my GDLan loader project, I've exploring the way the user can select a game with a nice interface. It results in the following impl:
- grab the soft-reset call (generated by the user when pressing A+B+X+Y+START on the game's title screen)
- make a custom syscall that the server interprets as a call to launch a menu
- mount locally (on the pc side) the Dreamone demo and keep in mind the LBA of the game list file
- boot the dreamone menu
- once the server gets the syscall for reading game list file, returns a custom list, built on the fly from the list of available GDI files in the library folder

You got my idea? I was capable of doing this but since the dc-pc connection relies on the broadband adapter, I have some issues with games that use the network stack... If you're interested in my idea, feel free to contact me.

Anyway, can't wait to play with your board!
3rd-Sep-2012 11:56 am (UTC) - Re: How to control the board?
DMA transfers need to be either completly by-passed on DC using software patches or must be handled by dedicated hardware to meet the timing requirements. And, as you noticed, there is no work-around for CDDA as it's a completly independent digital stream.

As for the idea, I guess I will need to make a post about it to make it clear to all. The point of this little project was to create a near-perfect GD-ROM replacement, but one not based on mechanical/optical media. It's meant to be such a close match that Dreamcast would never be able to tell the difference, hence the game compatibility would be 100%. That's my goal here.

Obviously it'd be rather wasteful to have just one game per card (as the cards are getting bigger and cheaper) so there is going to be some very rudimentary user interface based on a few buttons and LEDs. However, this is the extent of what I'm willing to add. There is nothing stopping anyone from writing a native DC app that would be booted as the first thing from the card to provide some sort of game list/menu. If anyone does that, and it's good enough, I'd be willing to add some talkback support so that this device could actually do what the user selected in the menu. But that's in future and not even confirmed.

What can I say, I like simple solutions. First: make it work as intended. Second: add features. Obviously some features must be taken into account when the design is being made but we are talking about a system with programmable MCU and FPGA, I'd say there is some room for improvement if the need arises.
3rd-Sep-2012 01:15 pm (UTC) - Questions!!!
Anonymous
I have some questions,

1. Price??? (not exact price an estimation)
2. What do you believe will we have something before Christmas?
3. Will futures like:
-Usb hdd support
-Usb game loading
-More advanced game selection
-Other planed features?
exists in your mind?
4. Feature firmware updates for bug fixes or improvements?
3rd-Sep-2012 02:10 pm (UTC) - Re: Questions!!!
Read the next blog entry I'll make soon.
3rd-Sep-2012 01:51 pm (UTC) - This will sell like hot cakes!
Anonymous
Just go Kickstarter with this project and you'll see how successful it will be! Then we make it go viral and bam, you're rich! Man, I am so excited with this, this is a dream come true! You rock dude, you're GOD!!!
3rd-Sep-2012 02:10 pm (UTC) - Re: This will sell like hot cakes!
Read the next blog entry I'll make soon.
18th-Oct-2012 06:50 am (UTC)
I'm looking forward to this going 'gold'. My Dreamcast has trouble reading GD-ROMs but works fine with CD-R.

How about cooking up a broadband adapter as your next project? ;D Technically it *should* be simpler since you wouldn't be dealing with proprietary data formats. The network chip Sega used is common as dirt and IIRC the expansion port is a modified subset of the PCI bus.
20th-Oct-2012 02:00 pm (UTC)
Someone in Japan did try that, with some success. Unfortunately that page no longer exists it seems.

AFAIR it was the Realtek chip plus Altera or Xilinx FPGA to emulate the PCI layer. Quite frankly it was not a very cost-effective solution :)

If it wasn't for compatibility with all current software I'd go for older ISA-based Realtek (10Mbps only is still enough) and just connect it pretty much directly to the modem port. Wouldn't be a problem to write a Linux driver for that, and perhaps modify the homebrew that used BBA (including GD rippers). The games and WWW browsers though... not so easy.
20th-Oct-2012 01:53 pm (UTC)
Anonymous
good work however i do have some questions
...is there a limit on sdhc size?
is the dreamcast bios need to be re-writen to handle the interface?

and

im kind of worried about yet another image format
20th-Oct-2012 10:37 pm (UTC)
I may be forced to impose a limit in order to keep the code simple. We'll see. So far I've tested it on 8GB SDHC without problems. I don't have any bigger cards at the moment :)
As for the BIOS, it stays as-is. The whole idea was to just swap the drive for a 100% compatible replacement and not have to worry about anything else. It's also why there won't be any fancy GUI - because the BIOS stays unmodified.

There's a way to convert GDI or CDI into new format and it takes just a minute or even less. You only need to do it when you put the image on the card (though I suppose Makaron will support that format as well), so it's not a big deal. I really with people would understand that it's not a PC, there are no gigabytes of RAM for file caching, and even keeping track of multiple open files is slowing things down.
24th-Oct-2012 05:00 am (UTC) - Congratulations :)
Congratulations man, you made something special here, I hope that you sell the boards in a close future in that case I will be like "shut up and take my money" ha ha, your project will revive many dreamcast I'm sure. I understand you with all those trolls making bad comments just ignore them and take all the time you want to complete the project, I had same incident with a similar project some time ago, about reading the maplebus (I made a prototype to connect dreamcast controller to a PC by USB HID) I post some info in a forum and then the trolls want that project NOW but the working prototype is all that I want to do (of course I share all my info and gave some advise those that want to do it) you know what I mean...
24th-Oct-2012 11:01 am (UTC) - Re: Congratulations :)
Connecting Maple to PC (via USB or otherwise) it also something I was looking into. I've seen some AVR-based projects that can work with DC gamepads but only because there is little data being exchanged there. Maple is being handled by tight software loop and it kinda works but just barely.

I wanted to make better interface that could be used along with my emulator and also support VMU and PPP. Problem is, I don't really see how it could be done without some additional logic on the Maple side to handle the state changes on data lines. FPGA would be an overkill, and discrete logic is probably too complicated. So, a small PLD chip would be best, it would include a simple shift-register for that purpose. But I never really made any attempts to test this theory in practice :)
5th-Nov-2012 01:32 pm (UTC)
Well in fact it's something like the xk3y for xbox 360 you're building here right ?

(but i think it's harder beacause the dreamcast don't use sata)

keep up the good work ! !
17th-Nov-2012 11:11 am (UTC) - Nice !
Anonymous
I have done myself the reverse engineering of the Sega DC Atapi bus some years ago (2009) :

Some pictures :
http://hxc2001.free.fr/vrac/dc_gdrom.gif
http://hxc2001.free.fr/vrac/dc_dump.gif
http://hxc2001.free.fr/vrac/analysedcgdrom.jpg
http://hxc2001.free.fr/vrac/dc_gdrom_board.jpg

The goal was the same : replace the GD-ROM and keeping the maximum compatibility level.

This is nice to see that someone else make more progress on with this board !

:)

Jeff / HxC2001
20th-Nov-2012 02:01 pm (UTC) - Re: Nice !
I see you've also used DE1 board.
12th-Apr-2013 01:09 am (UTC) - Complete?
Any chance this is complete as of yet?
16th-Apr-2013 06:19 pm (UTC) - Re: Complete?
Sorry but no, it isn't. Can't say more at this time.
10th-Jul-2013 01:59 pm (UTC) - still on it?
first awesome clean almost perfect job !!:D


are you still working on the project ?
17th-Jul-2013 11:25 pm (UTC) - Re: still on it?
In spare time. Which is quite rare commodity these days.
25th-Aug-2013 05:29 pm (UTC) - Region?
First of all, wow this looks so awesome! I'm gonna buy one as soon as it's available!

Second, will this make the Dreamcast region-free?
Page 1 of 2
<<[1] [2] >>
This page was loaded Sep 18th 2014, 9:44 pm GMT.