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

Oh, bugger!

"Thank you for your mail.

The TV company (?:stupid spent so much money on their system, it is quite impossible you can get their products copied so easily.


The chip may look like to be a HD6433396 (H8/3396) equivalent chip, but it is for sure a ASIC, would strongly advis you to give it up, to cost and time and risks to work the chip is too much to bear.​

If we could be of further assistance, please feel free to contact me.

Have a nice day and looking forward to hearing from you."


Oh well, worth a shot. lol
​

 

I don't have any ambitions of emulating the MegaCD drive myself at this point, I was mainly just interested in getting the CD emulation for my Cross Products MegaCD devkit up and running. I've been working on a cycle-accurate Mega Drive emulator (http://www.exodusemulator.com), and the MegaCD is in my sights in the near future. I was looking for a way to test various hardware aspects without having to burn disks all the time, and I thought getting this unit back up and running would be easier than building a drive emulator from scratch. Given how much progress you guys have made on GD-ROM emulation though, it seems like emulating it from scratch using this code as a reference might be a better investment of time.

For the record, I'm happy to help with these efforts in any way I can. I've only skimmed a bit of what's been written, but I might have some equipment and skills that can help this effort. I have a Katana devkit, several Dreamcast systems, and I have a logic analyser. My time is limited, but if you need someone to sample data from the real system, I should be able to help you out. I'm very interested in seeing GD-ROM emulation happen, and I'll be one of the first in line to buy these units when you get them working. I'm interested in doing cycle-level Dreamcast emulation in the future, so this hardware will help me do testing on the hardware.

 

Cool. Can I send you an adapter then?

It may take me a few days to get some more built and tested. I've just discovered that I've run out of solder (new stuff ordered).

A decent logic analyser would be a great help, especially if it's easy enough to do direct comparisons of the logs between the GD Emu and real drive.

I was able to capture data from the FPGA Emu via JTAG / SignalTap, and it was labelled it quite nicely. The problem is the limited amount of capture time due to the small of on-chip memory...
http://www.assemblergames.com/forum...Facebook-group&p=596703&viewfull=1#post596703

I suppose I could have captured in chunks and stitched the resulting text files together, but it would have taken forever.

The non-booting issue is likely a timing / status / TOC / error in my code.
I actually tend to think the security response and the data transfer is working OK, so it must be something else stupid?

I recently just "built" a 32-channel LA based on the Sump code as well, and I intend to hook it up to the IDE cable soon (a friend is borrowing it atm).
Although, that one is also limited by the amount of SRAM on the board (512KB IIRC).

It would be great to have another person on board.
Even better that you have programming / emulator experience. I can't even imagine the challenges of a cycle-accurate emulator. :concern: :boxing:

(I'm slowly working on a micro based on the V9958. I've only just got the VRAM soldered with Kynar, haven't hooked it up to any data yet).

Please PM me your address and I'll get an adapter sent out to you as soon as I can.

Let me know if I can help with the MegaCD emu. The 6303 code is far more readable to me.
Are you missing just the CD emulator part of the devkit? If you have any photos of the internals, please post a couple when you get chance.


Regards,
Ash.

EDIT: Might not be replying for a few hours. It's 8:00am here and I haven't been to sleep yet. zzzzzzzzzzzzzz

 

Sorry, I've only got a few minutes online. Sure, I'd love to test an adapter. My current logic analyser has quite a limited buffer too I'm afraid, but I'm about to pick up a Hantek 4032L with a 256MB buffer. If my current logic analyser isn't up to the task, with a buffer that long, it should be easy enough to observe where things go wrong. I'll PM you my address. I'll write some more later.

 

As original creator of this thread, I've got only one thing to say at this point. Thank you for wanting this to happen. I had figured that this would die within a month when I started it nearly a year ago. I didn't realize that there were those out there who cared that much for this console and wanted it to continue on despite the fact the GD-ROM drives die sporadically.

I hope to god that those here can make this happen . I'm still surprised by the support this endeavor has received. Maybe we'll see it happen in our lifetimes and the last great console from Sega will live on.

 

I also really want this to happen, the Dreamcast is a console I will never be without and if we ever manage to emulate the GD rom imagine the mods we'd see people doing for the Dreamcast. Case mods, making the console smaller, more and more portable dreamcasts being made etc. it would also bring the Dreamcast to even more people's attention!

 

I have hopes of making a portable one (or having it made) if this project succeeds. I've already seen a Gamecube handheld that's just slightly larger than a Nintendo DS. It uses a Wii Key Fusion for loading ISO images from SD card thus ditching the ungodly large DVD drive. Main PCB is rather tiny surprisingly...

 

Hi, sonicdude,

Thanks for your comments.

Work is still in progress on this, and I think we could have better success now as there are a few different people who will have IDE adapters soon.
(all of whom have MUCH better programming knowledge than me).

I've also changed over to using the Altera DE1 board (same board as Duenan used on his prototype).
This doesn't necessarily mean that it will work any differently, just that debugging should be easier.

(Just to be clear, I'll be trying the FPGA method again, while other people are working on the software for the direct IDE method.)

Also, I have a plan for making a decent debug output while still allowing the serial port to be used for the Dreamshell SD card...

A while ago I thought about seeing if the modems have a serial signal inside that I can hook into, but it looks like it's just a pure parallel interface direct from the Sega G2 chip.
I first thought there would be way too much time and effort involved in connecting an FPGA direct to the G2 port, but this vid made me realize a different method...

http://www.youtube.com/watch?v=700hQyUWurc

So, you just remove the crappy modem chip then you can hook up to the parallel bus instead.
The Sega chip then does the work of handling the G2 port protocol, so it should be quite simple to hook up an Arduino to the resulting parallel signals.

Last night, I found the relevant pins on the Sega chip to hook up to (since it's pins are easier to solder to)...

RP336LD........SEGA 315-6137

D0 144..........45.
D1 1.............44.
D2 3.............43.
D3 4.............42.
D4 6.............41.
D5 8.............40.
D6 9.............36.
D7 10...........35.

RS0 11.........34.
RS1 12.........33.
RS2 64..........5.
RS3 65..........4.
RS4 66..........3.

/CS 67..........1.
/WR 68........47.
/RD 69.........48.


I've already removed the RP36 modem chip and will solder the Arduino on as soon the new solder arrives (I ran out. lol).
I thought I'd use the Arduino rather than tying up another FPGA board, which is overkill anyway.

The Arduino should be fast enough to transfer data between the DC and PC at around 2Mbps.
With a cheap USB board like an FT245 or FT2232, it would be capable of MUCH higher speeds (depending on how fast the Sega chip can go??).

This wouldn't be a direct replacement for the BBA ofc, but it could act as a type of modem "emulator".
The modem commands would be passed directly to the host PC, where it could act as the ISP server.

Initially, I just want to get some sort of debug info working.

I know this whole thing has been going on a very long time now, so I'd rather someone like Duenan might release their version soon tbh.

We'll keep trying though. As soon as we know it can boot something, we can then work on improving the code further.
(it's currently using a hard-coded TOC, and doesn't have any sort of filesystem).

I'm looking forward to seeing smaller portables too.

Like many of you, I'd just like to be able to switch on the DC and play any of the classic games from a reliable and fast storage medium.
Preferably this would all work from the full GDI images as well.

I was even contemplating making a hideous "Dream-Box" hybrid with the DC and N64 motherboards inside an old Xbox case.
Hell, there's enough room in one of those beasts to maybe squeeze in a Gamecube too.


OzOnE.

 

Apparently Arduino (atmega 8bit 16mhz) is limited to 1MBPS, with alot of disabling. I have never heard of it going up to 2mbps. If you have more info on how it can be done, I would like to know for future projects. Unless your going with the arm based Duo.
http://forum.arduino.cc/index.php?topic=49673.0

 

I'm just checking my Arduino Duemilanove based RGB laser DAC, and it's set at 2Mbps...

It sends 7 bytes for each point, and works up to around 35,000 pps.
This is 35,000 * 7 * 8 = 1,960,000 bits per second, so AFAIK it must be working at 2Mbps?

The DAC is based on the Open Laser Show DAC, but I modified it to use MCP4922 for the colour outputs (as well as the X / Y outputs)...
http://www.fab-favreau.com/index.php/Main/OLSDRev4

I've read that the Arduino can be made to work up to 3Mbps, but only if you use it in synchronous mode?
Oh, found it! The guy had to modify the FTDI EEPROM and use an external freq divider, but it does work apparently (although still looses bytes sometimes)..
http://forum.arduino.cc/index.php/topic,8412.0.html

Solder still not arrived today, but I got a nice boxed Toshiba HX-10 MSX machine to play with instead.

EDIT: btw, I also have an Olimex ATmega32u4 board (similar price to the Leonardo, but MUCH better designed) which I'll use to hook up to the Sega (G2 / modem) chip.
I haven't played with it much yet, but it should be capable of huge transfers rates of up to 12Mbps (on-chip USB).

I'm hoping to use it to replace the Duemilanove in the laser DAC.
One day I might even get around to hooking it up to the 64DD to rip the disks (which is kind of what I bought the Olimex for).


OzOnE.

 

Do you know if it's possible to execute code via this method?

 

Hmmm, not sure a standard Arduino would be fast enough unless the G2 speed can be kept low? (unless you use a faster ARM chip, like Evotistical said).

I guess if you had a custom proggie running on the DC already, it would be possible to load / run code from the G2 port.

What did you have in mind though?
Did you know you can already load and run homebrew apps from the IDE adapter via Dreamshell. :tongue:

EDIT: Oops, when I said "via Dreamshell", I mean I have to load my GD test app first from SD card, which then loads the homebrew app from CF.

(If I could figure out how to inject the basic IDE code into Dreamshell, then that would be the best solution.
We'll await Mr SWAT's results on this, but the IDE adapters haven't arrived at his door yet. :sneakiness

Again, there is no filesystem in place yet, but if I copy a .BIN to the CF card directly using WinHex, I can load and run it just fine.
I've only tried a few examples so far, but the ones from the KOS / libdream examples seem to work (Tunnel demo / Bubbles etc.).

If you mean to execute code "natively" via the G2 port, then it would still require a custom app / BIOS on the DC because I don't think it can boot from G2?

As it happens, most of the signals for the BIOS run through the G1 port, so this is another area to explore later on (ie. running a custom BIOS image via G1).
This would probably need a few extra wires to be soldered to the board, and a bypass of the original ROM though.

OzOnE.

 

Sounds like we might be getting a little closer now. Main issue at this point seems to be getting the darned thing debugged to get the code to all run properly. Then loading games via IDE protocol should work out assuming the debugging will also help with fixing the timing issues unless I missed somewhere that they were fixed already. Then the final hurdle will be getting full image games and ones with audio streaming to work properly. Hopefully further coding experiment will fix this? Otherwise it may take more hardware tweaks on the drive emulator side for the FPGA version. Not sure on the direct IDE from G1 bus (G2 bus? I forget...) using pure coding method. Hopefully the homebrewed "modem debugger" will reveal all.

Hope I have my tech talk straight. Imma tired from LOOOOOOONG day and may be confused and talking out my ass again...

 

Once its working ho much would these boards be??
I would want a few.

 

dont know, not less than price of parts. but for you as first tester i can sell w/o profit. and you will see yourself if you want give me more for future designs. now it's the Summer Time, so speed of work under emu is slow. last time i only chked that mcu is connected with pc by usb successfully.

 

i've solder a little - cyclone3, epcs, ... and tested - it detected successfully

http://s018.radikal.ru/i521/1307/f0/1b88d0ebc2ee.jpg



maybe i'll try it w/ dreamcast on August

 

Cool man. Gonna have to update the facebook group on this now.

 

damn , i,ve start worry about gdemu , i saw some ppl talk about "legit" things here. is it legit what we want do here by this project?

 

I don't get the meaning of your question, sorry. If you ask if it's legal or not to do an ODE, well it's legal. It's the end-users than could do illegal things with it, but that's not your problem. People still sells knifes right?

If you're talking about LeGIT, he's a nice guy...

 

ODE is not illegal. As -=FamilyGuy= said it depends on how you use it that makes or breaks the legality of it.

EDIT: I just realized this is post # 420 in this thread. Light one up anyone? Cookie if you get my reference.