"Let's make GD ROM emulation happen" Facebook group.

Finally got my board reviewed, everything looks good, so I sent it to OSH Park yesterday. Should receive three boards in 7-12 days and then I'll solder some together and make a "Hello World" program to make sure the microcontroller works correctly.
Then I just need to write all the firmware to make it actually work. Should be easy enough, right? We'll find out if this microcontroller is even fast enough, otherwise my project is a bust.

Final Rev 1 board design:

 

Wow, awesome, Mario! Way to make progress, that's very cool!

Best of luck when you get it back, and then the real work (and fun!) can begin for you, eh?

So glad you are also working on this too - - thanks for doing it!

 

How GDEMU operate with multi-disc games?

 

The same way than with original discs.

 

Wow just found this thread and god that's the kind of thing we need for non-cartridge systems so bad!
That's so awesome that you guys are making it happening! Thanks a lot guys for making such dreams come true!

I'm sorry to be a bit lazy to read the 50 first pages but can someone tell me what's the difference between the different projects here (OzOne/Cybdyn, Deunan and Mario)?

 

Two methods:

. Keep the image on different cards and swap them when prompted.
. Store the images in sequential folders and use the 'next folder' button when prompted for next image.

 

Thanks for explanation.

 

Deunan started on his late 2008, made sparse progress for a couple years and seemed to drop the project at the end of 2012. He recently finished it and is now beginning to sell the boards.

OzOnE started on his at the end of 2011 and made good progress before getting stuck on... SD card issues, if I remember correctly? He dropped it after a year or so (I don't quite remember, these threads are very long). Once this thread came along, he and cybdyn teamed up and have a functioning prototype as of right now.

I, Mario, showed up about two months ago and said I'm going to try to make a version that only uses a microcontroller (as opposed to a microcontroller and an FPGA). Really, the only difference is that it would be a bit cheaper, if it works. I currently have nothing to show off except a board layout.

 

Thanks a lot Mario and congratulations guys for such awesome projects!
So no difference in term of functionalities between the three ?

 

The irony of watching Mario developing a Sega product...

 

Great work Mario, all these projects give us hope that at least 1 of them will go mainstream! XD

The more folks making these the better! Competition is healthy and good for the consumers.

 

In essence, no. All three are meant to replace the disc drive and play games off an external media (like SD cards or a hard drive).

There are some interface differences, though. OzOnE, cybdyn, and SWAT are trying to integrate support with Dreamshell. Deunan switches between games with a couple buttons and some indicator LEDs. I think he might be looking into adding support for a small screen?
I haven't figured out yet how my device will switch games, but it can easily use buttons and a screen. My idea, though, is to make a boot image that you keep on the SD card and acts like a game selection screen. If there's no SD card, the microcontroller will have a small image on it that it can boot to. It'll probably just say to insert an SD card and reboot.

And thanks for all the support, you guys! Don't get too excited about my device; there's a decent chance it won't work. I'd still count on buying OzOnE/cybdyn's board; it's shaping up very nicely.

 

It wouldn't need to cost $200 if a large enough production run was done. Of course that requires someone front a lot of cash to cover a large production run which is obviously the hard part.

If I can't get at least 5 of these things I'm going to be very disappointed.

 

*WARNING*

This not about trolling, this is not about starting a war, this is not even about fueling the competition. This is just documentation purpose, I am not partial to anybody and I am still interested in alternatives and I still support everyone who wants to promote optical discs emulation on any system.

*WARNING*



This said, I got this:



I am pretty impressed with it. It's very small, it's very well thought, it seems solid and I hope Deunan will make updates, although I don't really see the need.

I haven't put it inside the DC yet (will try to do it later today), but already, I don't see the need for a small screen. What would it be needed for? I mean, I will put a game per SD Card, just like ol' times, and that will be it. Easier to manage for me, and the size of SD cards means I can put my original discs in safe storage, replace them by SD cards, and still gain space.

For the same reason, I don't need a menu. I put the SD card of the game I want to play in, knowing I play one game at a time, healthier than zapping through dozens of games on the same day. It's something I learned since I began piracy on my ol' Amstrad CPC6128; multigames discs are an hassle. You have to boot the menu, scroll to the game you want to play, etc. I don't want that. I am a NES guy. I put the game in, I power the console, I play. More than three steps and, IMNSHO(1), you aren't doing it right.

That's just my two cents, fully knowing that I am an old fuck stuck in the old times. But, I am open to all opinions. You want a menu, go for it. As long as it's optional, I think you can keep everyone happy, and if everyone is happy, it means the achievement is done, which is the most important thing.

Anyway, time to open my DC to see which VA it is. ^o^



(1) IMNSHO means In My Not So Humble Opinion; to be taken as a joke since it's really just a joke.

 

I do not share your fondness of one-game-per-sd-card. I want DCIO/DCEMU/MAR-IO (copyright) so I can have all my games at hand fast without switching all the time!

That said, whatever floats you boat

 

Just do what the old ToToTEK flashcarts did: If there's only one game present on the SD card, don't show a menu, just boot it directly, otherwise show the menu and let the user pick. Tiny little bit of logic to implement, and you get the best of both worlds.

Also, I'd add that for homebrew development and hardware research purposes, any GD-ROM emulator really must have the ability to run without any boot menu, so that you can really test how the system would behave when booting a game just as if it was run directly from a GD-ROM on a cold system boot.

 

Congrats, Mario on your board. It's looking good.

I think if you have a fairly fast ARM chip (84MHz or more), then it might just work OK.

It would be best to maybe trigger some interrupts on the ARM chip using the /RD and /WR signals from the DC?
If you make the interrupt routines fast enough, there's a good chance it will work OK.

You might even need to write some routines in assembly to make it fast enough.
DMA support may be tricky though - the data rate is fairly fast, so you'll need to buffer the full requested number of sectors in RAM if possible.

The DMA routine will need to output the next Word on every /RD strobe (after DMARQ from the DC goes high, you can prepare your buffer of data, then bring /DMACK low when the buffer contains enough data.)
It looks like DMA pausing will work OK as well, but you must output a burst of 16 Words (32 Bytes) of data at a time, then de-assert /DMACK until you have enough data in the buffer again.


We are also looking into ways to make the DCIO cheaper, but I'm having issues with my board atm. Maybe my soldering isn't quite as good as I thought.
(cybdyn sent me some test code earlier, so that will help a lot.)

I hope you won't think we're "copying" the ARM-only solution if we do release one? It does make sense for a future version.
cybdyn and I just wanted to get a proven design together quickly, so we could make them available for people sooner.


@lord_raymon - we will likely need to add a single button to the DCIO for changing to the next disk in a multi-disc game. How many multi-disc games are there on the DC though?
I think a nice solution to keeping the DC looking nice is to disable the lid eject function, then just put the "Disk change" push button under the eject button.

@madsheep - nice looking software there. Good to see some work being done for the DC still.


We are looking at using Dreamshell as a front-end for the DCIO atm, but it's very likely that we will write a much simpler menu which will load super-fast from power-up.
I think I could manage to write the menu using some of the KOS examples. Making it look pretty is a another thing. lol


I'm open to any and all other projects for GD Emulation of course. It's good to see a few different solutions appearing.

It was only with Deunan that I was a bit bemused by because of what he said many months ago about not wanting to condone "piracy".
Ahh, here's the quote....

(just under the "Features" heading)...
http://dknute.livejournal.com/41336.html

Still a slightly strange thing to say from the author of a popular emulator.
Surely around 90% of people using Makaron will be using game rips, and not necessarily own the original disks?


Anyway, great to see the DC scene alive and well.
It's definitely getting towards a true "retro" machine now.

OzOnE.

 

@MadSheep: *wants* *drools*

@Ozone: Imagine you're a knife seller and that you say you do not want to condone murder, is it still ridiculous? ;-) The thing is, the emulator is like a knife: either you use it for good things or for bad things. The tool itself is not responsible of what the fool does with it.

 

Thanks!

I've done a lot of thinking and calculations. I don't think 84MHz will be quite fast enough. The chip I'm using will be clocked at 169MHz and it'll still be a bit of a squeeze.

Here are some logic analyzer dumps I've made:
Reading with DMA: http://i.imgur.com/NwI31qW.png
Reading a register (alternate status, in this case): http://i.imgur.com/FHRLBUx.png

You can see the timings in the upper-right of those images. The DMA read strobes are ~80ns long, and the register read strobes ~94ns.
At 169MHz, each microcontroller cycle takes 5.917ns.

The Dreamcast pulls the read line low to indicate that data should be put on the bus, then reads it when it lets the line go high again. So that means we have 13 whole cycles for each DMA read strobe and 15 for register reads.

DMA is easy - once everything is set up, on each write strobe I need to increment a pointer, fetch the data from that address, and put it on the data bus. Probably 3-5 cycles max.
Register reads/writes are a bit more tricky, but should still be doable. On the falling edge I need to read the CS0/1 and DA2/1/0 lines, figure out what register I'm giving, and put that data on the bus. More complex, but I think it can be done quickly enough. I have those lines all in a row on a port, so I would need to read the port, mask the upper bits I don't want, use the value I got as an offset to fetch data from memory, and put it on the bus. Probably 5-8 cycles.

As you can see, there's really no time for anything else. Those high-speed bits are definitely going to be coded in assembly.
I think interrupts are even too slow. I haven't heard a definitive source, but I think they take 10-15 cycles on their own? So I need to run a tight loop that just watches for that falling edge. Any other processing needs to happen when I know I have free time (like after a packet command, for example).

While DMA transfer is going on, there's about 1.5-1.6ms (milliseconds!) between each word. I think that's plenty of time to read another 2048 bytes from the SD card, so I may not actually even need a buffer, or at least not a very big one. We'll find out!

EDIT: Woohoo, one thousand posts!

Edit2: Of course I don't think you're copying me! Do whatever you like, if you guys get it working better or sooner than me, then I'm all for it! It's still a good learning experience for me, anyway. I'd love to work together for that if you'd want, though. I feel I have a lot of experience with microcontrollers. Or don't, that's all good as well.