Replace GD-ROM with Flash Card?

[Hecato]

@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

I'm not a specialist in dreamcast hardware but I think this to be corect...

The access by the lens is phisical while the access by "emulator" is logical. These are two concepts incompatible. The lens don't need a supply information to "where to read" because this is made by driver positioning it. By the otherside the "lens emualtor" need this information "where to read and when to read" because the access is logical and software too request status and other info about unit.

[angelwolf71885]

i thought the lazier only reads blindly until it encounters a TOC then its all up to
the firmwares ability to read a multi session disk until it reaches the data in the 3rd zone
then its up to the game data to request a read from a certain LBA to the drive
plus isn't that where having the TOCs from the iso comes into play
the os would stream the iso as the lazier read it

actually thinking about it you'd need to know the head position
witch would mean tieing into the ribbon that attaches to the lazier head


its been a while since ive done the math for the speed of the dreamcasts drive so i was off by 500 kb/s :redface:

[Calpis]

The controller receives a MM:SS:FF, the controller translates it into an approximate stepper position, the controller seeks to the position, the laser tracks the spiral and the decodes the serial data until it gets the desired frame. Since the location is approximate it may take a (relative) while. The only way the controller knows where the laser is absolutely positioned is through subcode data. On data tracks there's also a redundant sector field (and this is solely how DVD and Bluray are addressed).

There is absolutely no generic way to do this for multiple consoles and it'd be hardly feasible to emulate at the laser assembly level since it's an radio frequency signal servo. Basically every console would need an entirely original assembly at the lowest level *digital* stage.

[angelwolf71885]

The controller receives a MM:SS:FF, the controller translates it into an approximate stepper position, the controller seeks to the position, the laser tracks the spiral and the controller decodes the serial data until it gets the desired frame. Since the location is approximate it may take a (relative) while. The only way the controller knows where the laser is absolutely positioned is through subcode data. On data tracks there's also a redundant sector field (and this is solely how DVD and Bluray are addressed).

dose the dreamcast lazier go back to position 0 after every read?
because the GD-rom never sounds as smooth as a normal cd reader

i guess it would be better to just dump the firmware then waste time on the lazier

[Calpis]

Dude, it's l.a.s.e.r. Laser is an acronym so there's no other spelling.

Like all CD players it doesn't return to the top, it reads a run of data, then the lens will step up or down according to the position of the next run of data, returning to the top would be crazy since there's no penalty for doing it the normal way.

Dump what firmware?

[Anthony817]

I love seeing smart folks replies. It helps me learn more. So thanks. ;)

[invzim]

Somebody made a nice writeup with pinout - same as yours mr.sporty?

http://notinmame.blogspot.com/

On second glance, ACE has made his own personal pinout scheme making it a bit tricky to dechipher.. :(

[-=FamilyGuy=-]

If someone is serious about trying to build such a device, and go the skills to do so given proper documentation, please pm me.

[MrSporty]

It will be the same pinout but isn't any of my work.

[Hecato]

If someone is serious about trying to build such a device, and go the skills to do so given proper documentation, please pm me.

Hi guy,

The first thing to do is get some doc regarding the Bus Specifications, without this the wotk to decypher the G1 bus protocol will be enormous adn will take a long time.

I've talked with dknute (http://dknute.livejournal.com/) about this project, as i know it's possible but will have a hard wort to get running.

[-=FamilyGuy=-]

I'm glad you're investigating!
This might help!
http://www.dc-swat.ru/blog/hardware/

Cheers!

FG

[billcosbymon]

I really hope this gets somewhere because it would be a hell of a lot faster than sd cards

[angelwolf71885]

I really hope this gets somewhere because it would be a hell of a lot faster than sd cards

its the slow speed of the serial bus that slows the SD cards not the SD cards that are causing the slowness

todays SD cards are just as fast as CF cards

ether way anything is better then using burned media and breaking your dreamcast drive in only a few short years

[billcosbymon]

yes i know that, i ment that the serial port was really slow

[Hecato]

I'm glad you're investigating!
This might help!
http://www.dc-swat.ru/blog/hardware/

Cheers!

FG

Hi guy,

Very good link but it's not enough. I found a doc named Dev.Box from 1999 that says some interestings things about the hardware. In this forum a guy nicked as MrSporty seems to have the doc containg the packet commands

http://www.sega-naomi.com/forum/viewtopic.php?t=1336

Regarding the Dev.Box doc, it says that device on teh G1 bus are all in parallel. This is good because we can put in the GD Emu Board a Flash ROM chip to boot by a custom ROM. We have only to disable the original ROM inside DC. This is better that soldering many wires on the DC board.

Regards.

[Anthony817]

Granted something like this actually took off, how much would all the components cost for all this?

[-=FamilyGuy=-]

I could swear I had a SPI protocol description pdf in a DC documents archive somewhere ...

[Hecato]

Granted something like this actually took off, how much would all the components cost for all this?

Really I don't know ... What will be a good price??? The FPGA and the PCB manufacturing will be the more expensive in this project.

MERGINATOR:

I could swear I had a SPI protocol description pdf in a DC documents archive somewhere ...

Please, find it!!!

Tks

[ackmed]

I could swear I had a SPI protocol description pdf in a DC documents archive somewhere ...

I would be interested in a copy if you could find it.

thanks
-ack

[link83]

blog post about the GD drive connector and possible GD drive emulator:-
http://jonr.neovanglist.net/?p=66