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

sorry its in russian. but it talks about ripping gd-rom by pc cd-rw!))

http://www.dc-swat.ru/blog/hardware/24.html#comment127

i didnt test it myself.

 

wrong way... we need PC drives that read GD-roms wholly and correctly no matter the tracks
the swap trick is USELESS for replacing the actual drive

 

or, if we make g2 bus board - we can copy image from original gd-rom to hdd/sd

 

The lite-on LTD-165H can read gd-roms using a swap trick, it's the only Drive I know of that can be used out-of-the-box to dump games, although it have some issues sometimes. I nontheless verified tosec dumps with it so, when it's working, it's working well. It's mainly a big plastic case with small pcbs so it could be fit.

Here's a document I made years ago in french explaining the procedure, I guess it'd translate to english better than the russian one: http://dreamagain.free.fr/index.php...ft-ripper-un-gd-rom-avec-le-lecteur-de-son-pc

@angelwolf, with a custom firmware it could be possible to "transform" an optically compatible drive into a gd-rom one, but this would be over-complicated in my opinion.

 

not to mention time consuming and frustrating because hunting down a specific model of drive they is no longer made
and then upgrading the firmware its a very fruitless endevor

there was another tread talking about drives that had a compatible lazier or coil or whatever it was but it was hit or miss finding these

im far more hopeful on running arbitrary code from a custom hardware attached to G1 that interfaces with an attached SD reader
if you can run code from G1 theres no need to screw with G2

 

using g2 port is good offer for them who doesnt want unscrew console and want to leave it in virgin state))
and i heard from ppl - they want to leave GD-ROM support too.

but for debugging stuff it's better use g1, cuzz the bios uses same bus.

 

I'll repeat my offer and emphasize that there would be no expectation that something will ever come out of it. It seems that you have put a lot of effort into it and I would like to help out with your costs by making a small donation like $50.

Personally, I would like to get back into hardware development but family life/house projects get into the way at the moment.

 

i'm pretty sure something "good" will be done 99% in any case...

but main question in what i can't promise people is "when it comes out".
by the same reasons (family life/house/ official job )
i do my best but with little steps.
may be if someone realy rich))) would like to help "1000$ or more", i'll turn on all my work for this, then he can get money back or make more))

so little help (50-100$) is just good...but cant change much too far... that's why i never ask...

and i didn't get it , you talk about help for the Ozone, or i can rely on yours too?

 

I would love this project to get going and finally something to appear.

I personally offered OzOnE help/money as I have dealt with him before and found him to be honest and genuine. He provided all his research for the community and got further in a couple of weeks than many had seemed to do in months.

I think if people are considering donating to projects they would always require some hard evidence that people are willing and skilled enough to pull off what they are talking about, there are a lot of day dreamers around. I personally would have that required belief in OzOnE because of my previous corespondents and his earlier efforts but other people may not.

Donations or offers of donations are nothing personal

Cool

 

Thanks, Rob, and Thanks for the offers guys, seriously.

tbh though, I know from reading past threads that the offer of donations can often lead to "heated debates". lol

Now that I've just bought the new FPGA board, the money side of things isn't too much of a problem.
It's just a waiting game now for the board to arrive (doesn't mean I'll get the damned thing working though).

My motivation is that I KNOW that the CF card version actually started to load. I should have taken a video of it. :moody:

I don't really fancy hooking up the old board to the DC again - it uses 2mm pin headers instead of 2.54mm on the new board(s).
The 44-pin CF card adapter I had never worked either - I had to connect a 44-pin to 40-pin adapter via a 40-pin cable to a 40-pin CF card adapter to get it to work!

As I side note, I've actually just hooked up the Gamecube to the FPGA again (sorry, I know this is a SEGA thread! :sneakiness.
I know about the WiiKey etc., but I thought it would be interesting to mess around with the GC anyway.
I realized that I had bought the spare Gamecube months ago, and it's easy enough to connect to the FPGA board (solder one end of a standard 40-pin IDE type ribbon cable).

Also, do any of the WiiKey / WODE boards support streaming audio? If not, then it might be "fun" to get it working.
I'm running Destop's (yep, I remember his handle now!) original Crazynation VHDL code. I don't have enough pins on this board to connect a hard drive or CF, but it's capturing the commands from the GC at least.

I've been trying all of last night to convert Destop's VHDL code into Verilog (I can't read VHDL too well, it's very ugly).
The GC commands aren't working in Verilog though, it's not seeing the async signals properly?

@cybdyn or anyone - could you possibly help with a short section of code? I'm not too familiar with "always" blocks and how to reliably capture async edges without using a clock?

OK, back to the DC...

The biggest problem for me with the DC stuff is still the programming side of things. I haven't done much with using FIFO buffers etc. but I understand them better now.
I'm still convinced that the DC doesn't like the DMA transfer to be paused. It seems to respond to the pause OK, but I have a hunch that it will only work without pausing (hence the SRAM).

The SD Card code I'm using sucks as well. It seems to read the data OK-ish, but if you don't read it fast enough the FIFO gets full up and it stops the read process!
This is the code that came with this cheap FPGA board. I've looked it modifying it, but it would probably be a huge pain....

Does anyone have any SD Card driver code in Verilog which is simple to use? I just need to be able to supply it with the sector (or byte) offset, then trigger a multiple block read.

OzOnE.
P.S. Does anyone have a cheap GameCube controller? I'm stuck on the stupid language screen 'cos I disconnected the battery / controller board and I don't have a controller.

 

after my success work with my test board (as you can see on video http://psdev.psio.com.au/forum/viewtopic.php?f=17&t=4&start=105 )
i decide start developing independent PCB. and i include DC support to one board.
it's not last version, maybe better make it in separate project when it will came out psio / dcio, but my alpa will be for PS1 and DC.

my last update scm

http://s017.radikal.ru/i443/1206/6d/2e5c7f3ee207.png
http://s017.radikal.ru/i405/1206/45/5fe1775c56cf.png

 

dealextreme have pads for like $7-8 including shipping.

 

I have a gamecube controller. Its not super mint but it works properly. I will get my mum to dig it out as its at her house because I try not to keep all my crap in one place! If she can find it I will let you know

 

Oh, and here are some DC G1 pinouts if they're any help to anyone.
These should be 99.9% confirmed (referenced to the VA0 schematics, and I've tested them too).

In the first image, I've renamed most of the IDE signals closer to IDE/ATA conventions so they're easier to read.
Importantly, the VA0 show the address signals as this..

Pin B19 = G1RAL10
Pin B17 = G1RAL9
Pin A19 = G1RAL8

Because they are routed directly from part of the G1 address bus. I've renamed them to simply...

Pin B19 = A2
Pin B17 = A1
Pin A19 = A0

As this is more relevant to IDE/ATA conventions. The rest of the signals are self-explanatory, although the data bus signal names have been simplified too.
(they named them a certain way on the VA0 schematics because many of the signals connect to BIOS ROM / FLASH).




The second image of the DC mobo test pads was "borrowed" from the user @WERD I believe.
I just changed the pad labels to the actual SIGNAL names instead of A1-A25 / B1-B25.

btw, pins 8,13,18,21,24 on both sides (A and B) are also Grounds!
It looks like they have separate Ground routes ("P.GND") for the 12V supply; This is likely used so that the noise from the higher current 12V rail is reduced.




EDIT: Sorry, might as well add the info for the plug / socket too...

The 50-pin tall socket on the DC mobo is apparently Molex part 53408-0579.
And the 50-pin plug on the DC GD Drive is Molex part 52584-0579.

You can find both of these on Mouser and Digikey I believe.
Then again, you could always rip the plug off the GD Drive! (CD-ROMs are SO 1993!)

OzOnE.

 

Great, cheers Rob!
(I could buy one from Fleabay, but most people want stupid money for them. It would be "cheaper" to buy another GC + controllers, but I already have two GC's).

@cybdyn - Excellent work! Very exciting to see this sort of thing. :biggrin-new:
(I didn't know about that forum.)

I see you're using a 245M USB chip. They seem to be far better for this sort of thing. I put an FX2 on my old board, and kind of wish I hadn't!

@cybdyn - I know you use ORCAD, but I have some GC and DC drive connector symbols for Eagle if anyone wants them?
I can help with the DC stuff if you like? It would be nice see more than the boring SEGA Logo. lol

So many questions! Erm, is that an SRAM I see on your board? :friendly_wink:

Guys - it looks like DC and GC drive emulation won't be too far away...
If cybdyn makes his own PCBs, writes the streaming software, AND has PS games working, the DC and GC won't be much of a stretch tbh.

If he has SDRAM on board and enough spare IO pins, it could even do N64 / SNES / MEGADRIVE (and most other) cart emulation.


Great stuff!
OzOnE

P.S. If anyone's wondering - on cybdyn diagram, the data and address signal names on his DC connector start at "1".
It's basically the same thing, just different naming conventions.

 

No, none of them accept streaming audio.

 

Speaking of which -- there are pins for a separate PCM stream to the AICA, yes?

That also will need bridging (but probably much more forgiving than the complete G1-IDE handshake protocol).

 

Yep, the CD / CDDA pins supply the PCM audio from the GD Drive.

In fact, the DC won't boot at all without the CDDA_CLK signal. This is the master clock to the AICA's PCM stuff (33,868,800Hz, which is 44,100Hz CD Audio standard sampling rate * 768).

I don't think audio streaming would be too difficult on the DC. It's a slow sampling rate, so might only need a small buffer.
The more difficult part is handling the Q Subcode and MSF/FAD addressing stuff that the DC expects. The NullDC source is quite handy for this.

I actually started messing with the audio output on my FPGA board the other day - I've only tried random garbage noise so far but I'm looking to try streaming CD Audio from the SD Card.
The good thing is, I don't even need the DC to be hooked up to test basic audio playback. "This is Dreamcast disk, and is for use only on a Dreamcast unit. There are many others like it, but this one is mine."

Sorry, I'm very tired, so I think a bit of Full Metal Jacket might have crept in there somewhere. :topsy_turvy:

btw, for a bit of fun, you can listen most "track02.raw" files from GDI's using Cool Edit Pro - just go to Open file, and set the file type to "PCM Raw Data", you might have to enter *.raw in the file box to see the files; open "track02.raw" and choose 44100Hz / Stereo / 16-bit, then choose "16-bit Intel PCM (LSB,MSB)" and make sure "offset input data" is set to 0.

Make certain it's not a huge block of white noise before hitting Play, and turn your speakers down first too! :wink-new:

OzOnE.

 

@cybdyn or anyone - could you possibly help with a short section of code? I'm not too familiar with "always" blocks and how to reliably capture async edges without using a clock?

i use AHDL and graph, not vhdl or verilog, but for information from them i try start learn it


my dc-io con use ad1..ad3 as a0..a2 in dc original scheme

i use no SRAM/SDRAM, i try w/o them.

in new board i use 2232h , dual chanel usb bridge 1- for data, 2- for jtag/spi/.. (for configuration another words) , they say on specs 25..40 mb/s in syncronious FIFO mode.

for sound i use DAC it need for ps. dc has own sound channel on connector.

i can help with info or code for ALTERA after i start debbugin my board.

PS: of cause i plan add support of the GC / saturn / or any console to my board too))