Replace GD-ROM with Flash Card?

Yeah, but the OP was asking if something like this could be adapted for a Dreamcast, and the only things I can suggest are the SD adapters and an IDE Harddrive interface mod that works on LinuxDC.

Still, one can dream...

 

So what is it about the Wii that makes its DVD drive seemingly easy to emulate? There's more drive emulators available for the console than just the WODE.

What's so technically different about doing essentially the same thing with a GD-ROM drive?

 

Technically .. nothing. Financially .. everything

Creating a sellable product for a potential userbase of ~85 million Wii consoles is a great incentive as opposed to a potential market of miniscule amount of retro enthusiasts.

 

That's really cool - had a look at a picture of the CF adapter, do you need to pull some lines high with a resistor array?
http://kirurg.org/drop/naomi_cf_box.jpg

 

Nope, it would definately be good practice to but i couldn't be bothered

 

if all else fails you could be creative
and just use the lazier leads to stream data from a SD or CF card and drive interface circut that was able to have an interface launch just like a dreamcast game

you'll be limited to the 1.2 or so kb/s the drive is capable of

it would be alot cheaper and simpler then creating a chip that attaches to the ribbon cable to stream the games from because youed have to spend time analyzing the chips on the GD-drive in order to emulate it
although you could probably just dump the GD-drives firmware and make it easier

 

I believe that is possible to emualte with a FPGA or a microcontroler the GD-ROm unit. All that is needed is the GD-ROM specs,the electrical signals and how to access an ISO file(an ISO emulator) in the SD card. It wiil be a bridge between GD-ROM and ISO virtual drive. This method is better than update BIOS, like angelwolf71885 said, the only thing that iwe has to do is remove gd unit from ribbon and repace with the board emulator.

 

I have 2 DC's with dead lasers which would be ripe should someone get this off the ground. FYI given as I have several Dreamcasts, I've noticed the dead lasers are sort of light/pale blue tint but the working lasers are a darker blue.

 

A good electronic engineer could do that somewhat "easily" (as in easy enough to be a hobby). However, there's no such person that showed an interest in making it so far...

I'd buy two of those if it somehow gets done!

 

This is no too dificult when we have the specifications and documentation about the GD unit. I have a long experience with electronic and embedded programing. All I need is some documentations about the GD unit.

 

sadly no GD-rom docs have ever surfaced
you'd need to disassemble a dead dreamcast's drive and examine each chip and dump the drives firmware

 

I started on this exact project some time ago, but needed some hardware to continue. If anyone is interested in working on their own, the G1 pinout exists to help get you started. Search for the schematics (I think they were the Chipworks ones) and it will be the "rom flash and io" image (labeled in the diagram as CN503(A/B)).

 

Yesterday i found this

http://hitmen.c02.at/files/docs/dc/cdrom.html

It was the link that I got regarding GD unit hardware. I fiound too that the Gd unit uses a type of SCSI interface...

How was your project? Can you say some details about it?

 

i think it would be far better and much easier to attach a chip/device to the 3 lead points the lazier is soderd to or attach a chip/device to the lazier ribion
the one that connects directly to the lazier head

that way we have direct access to the input of the drive
it also has the benefit of not having to examine or tear apart the chips on the GD-drive

because even on dreamcast with dead or damaged laziers the drive its self is still good and would save development time and cost

 

The custom scsi part on the main board we could just some how dump that frimware
and bam or mod the bios to support something like a modded xbox.

 

Do you think the device read only a type of raw data abstracting/bypassing the SPI(Sega's Packet Interface)? If the device only "emulate" the lenz, how it will know the position of file to read? Because the only thing that move the lenz and say where to read is the unit spindle motor position(this position was already decoded by chip firmware).

Modify the BIOS is another option to think about. I've seen some post about reflash, is a good solution point the input data to the serial and read a SD card too, but I never seen some tool to edit BIOS file. I believe a type of SH4 disassembler and a HEX Editor... I'm a good 8051 and ARM7 assembly coder, I believe that this is not too dificult, but slow and arduous.

 

the chip/device would have it own OS on the low level witch would stream
the iso to the lens no emulation nessery of the lens because then it would be just electrical pulses a simple cpu a simple os and a pulse generator
that operates a 1.2 kb/s thats the data rate the GD-drive could operate at and you should have little to no issue steaming an iso from a storage media to the input wires that the lens used to use

 

I believe that is not too simple like this...The problem is "How the chip OS wiil know where position to read on a ramdom access to ISO/GDI? The lenz is blind because the firmware already give your position, the problem is emulate the postion lenz without analize the G1 Bus requests."

 

i never said it was simple to do just much easier and less costly to do then trying to emulate the entire drive

and actually knowing what the lazier is looking for is rather easy
because we already have all 3 TOC's for the iso

so when the signal for the next sector comes up
then the os on the drive then streams the next sector of the iso

writing the os is gonna be the most tricky part

knowing what the lazier is looking for is the easy part

 

@angelwolf, to make it a bit more clear,

The lens "blindly" reads the data it "sees" without being aware of were on the disc it is. So let's say the gd-rom controller board ask to read a sector, let's completely randomly take 45000, the controller board ask the drive motor to move to LBA 45000 and then ask the lens to read what's there. The lens doesn't "know" where it is, it just reads. With your idea, to know where the lens is would be pretty much impossible.

While your idea of hijacking the data stream at the lens itself isn't stupid at all, it'd still require a way to know what sector is actually being read.

Also where have you got the 1.2kiB/s rate? Seems extremely slow ...
AFAIK the gd-rom board is 12x, which makes it 1800kiB/s (75 sector/second * 12 * 2kiB/sector = 1800kiB/second) ...

@Hecato, I beleive there's some documentation hidden somewhere in the devkits. I'll look around I could swear I've read some kind of complex documents somewhere about gd-rom protocol ...

Cheers,

FG