Replace GD-ROM with Flash Card?

[Evotistical]

I really want a DODE (Dreamcast Optical Drive Emulator)
I'm not a dev, but a fan of most projects that come out of assembler games. I personally would pay 100-150 for a "REAL" solution to run my dreamcast games from either cf,sd,harddrive,usb. I'm sure there are many others on this board who feel the same.:cur_sonic:




*by real I mean at least 99% fully compatible.

[mathieulh]

guy, you have no clue about what you are talking about

First, there is a checksum on dreamcast bios that avois any modification there (the mix betwen retail and debug bios works thanks to a collision)

Seccond, this is not as easy as patch something into the bios, you have to create a lot of code from scratch, a compat flash its not an ata cdrom drive.

Now call all your friends and bring us a hacked bios

How good it would be that speak would not be free

Can it be done ? Yes, it can, everything is possible, but this pinout is not the rosseta stone, its the same thing than bios pinout, nothing special

I've helped making that bios and I can tell you there is no such checksum.

The Dreamcast isn't a naomi.

[Serantes]

I've helped making that bios and I can tell you there is no such checksum.

The Dreamcast isn't a naomi.

You have no clue, ask the author of the Makaron emulator and will tell you that there is a checksum on the bios, you guys got a colission, nothing else

He spent hours trying to fin the checksum, and what he found it was same that you guys found, collisions, as on naomi, there are only some blocks affected by this checksum, thats why its so hard to guess it

[mathieulh]

You have no clue, ask the author of the Makaron emulator and will tell you that there is a checksum on the bios, you guys got a colission, nothing else

He spent hours trying to fin the checksum, and what he found it was same that you guys found, collisions, as on naomi, there are only some blocks affected by this checksum, thats why its so hard to guess it

Yes, so we happened to get a collision out of nowhere without even looking for one, at first try !

I should seriously start playing at the lottery....

By the way, care to enlight us on how you do know a checksum is being used, yet do not know how it's calculated (meaning you don't have the code that checks the bios hash) ?
Unless you start decaping the SH4 and find some checksum code (to be honest I seriously doubt they even have a rom in there), I don't see how you can claim with absolute certainty that a hash is being checked. Do you even know what checksum algorithm is being used ? (I seriously hope you're not suggesting they are using sha1....)

[-=FamilyGuy=-]

It's actually possible to open a retail Dreamcast bios in any hex editor and start changing the strings that represents the words used in the bios menu, just try it for yourself and see.

If the bios was hash checked before booting, changing a single byte would prevent it to boot, afaik. Of course a collision in the checksum (same checksum code for two different files) is possible, but it's rather unprobable in any decent checksum algorithm, even those from the 90's. There's also a small lot of custom DC bioses which works well, that much collision is almost statistically impossible.

In my humble opinion, if this bios is hash checked, it must be a minimal part of it. Maybe you're confused with Naomi?

Please try not to turn this discussion in a flame war guys.

FG

[mathieulh]

It's actually possible to open a retail Dreamcast bios in any hex editor and start changing the strings that represents the words used in the bios menu, just try it for yourself and see.

If the bios was hash checked before booting, changing a single byte would prevent it to boot, afaik. Of course a collision in the checksum (same checksum code for two different files) is possible, but it's rather unprobable in any decent checksum algorithm, even those from the 90's. There's also a small lot of custom DC bioses which works well, that much collision is almost statistically impossible.

In my humble opinion, if this bios is hash checked, it must be a minimal part of it. Maybe you're confused with Naomi?

Please try not to turn this discussion in a flame war guys.

FG

Not to mention in die rom space was VERY expensive back in the days, do you really think sega would have spent that much money back then just to perform a rather useless checksum (useless considering that so many custom bios' hashes conveniently happen to "match" the expected one through a "collision") and I don't see any other rom chip lying around on the Dreamcast motherboard other than the bios and flash chips, do you ?

Even on lousy hashing algorithms such as TEA, the probability of a collision happening out of nowhere (without actually even trying to bruteforce one) is (dangerously) close to null.

Who knows though ? Maybe Serantes is right and I "have no clue" ...

P.S. I am not trying to turn this into a flame war either.

By the way, the Dreamcast bios happens to be mapped from 0x0 to 0x1fffff
How much do you want to bet that 0x0 is the SH4 reset vector? ....

[l_oliveira]

Just think... If there were checksum, the modchips that make the Dreamcast region free would not work at all.

The two byte mod I posted on the other thread would not work as well... :shrug:

[LCardoso17]

I'm new in the forum and I found it because of this post. I'm was trying to connect a mini HDD instead of the GD-Rom Drive. My first idea was connecting trough the bus connector of the GD-Rom Drive board or directly to the main dreamcast board, but later I tough of the ZIP Drive. The Extension port as the speed to run games smoothly and since the Zip (it would be used for games add-ons, etc. I think) would go in there it would be easy to make it work with the Dreamcast. That's a natural functionality that DC has. :-)

[splith]

But no-one has the said zip drive, there's no board scans or pinouts of it and there's no software that utilizes it nor anything in the SDK that's usable for it so how're you gonna manage that?

[dark]

There are some people who have been able to get a harddrive working through the expansion slot via Net BSD
http://www.youtube.com/watch?v=ctxijoP2gqo

But that's not going to let you boot commercial games...

[APE]

I always enjoy the enthusiasm people bring to the table, wish it could be converted into a useful product.

A shell is known to exist but I don't think anyone could get the seller to cough up if it had internals and if it did, if they functioned.

[LCardoso17]

Yeah, I would like to see the internals of the Zip Drive... But if those guys from Net BSD managed to get it to read that's already most of the work done.

The Dreamcast, "inside her", has the ability to read and write data from the Extension port. If the software from the experimental Dreamcast Zip disk could be seen and used it would be easy, but even without that we know that, for example, with Dreamshell, the dreamcast can access data from the serial port as an SD Card Reader. Now I'm focused on the hardware issues and not the software.

I wrote a message to the guys from Net BSD to know some details of the Net BSD project and issues that they had during the process.


Note: talking about software I found this http://mc.pp.se/dc/ipslave.html which is a functional reader/writer for the Expansion port.

[OzOnE]

I don't know a huge amount of background on the various Naomi stuff, but if you're looking to replace the GD-Rom on a retail Dreamcast with a CF card (or HDD) and run native GDI images, I think the way Deunan is doing it would be the best path...

http://dknute.livejournal.com/24111.html

While I'm waiting for my 64DD to arrive, I thought I'd also take a look at the Dreamcast...

Thanks to this forum, I downloaded the Dreamcast VA0 schematics and have traced the GD-Rom pinouts to the test pads on the underside of the board so I can solder to it easier (without needing to buy the correct connector and making a PCB for it).

I'm not promising anything at this point, but I can at least start to spy on the data...

I basically need to emulate Sega's custom "packet" interface commands, then read a GDI image from the CF card. The first hurdle was finding the interface info, but I realized that a big help was already sat on my hard drive (in the MESS source!).

I wanted to find the PROPER document though, and after some hardcore Googling (and thanks to Web Archive), I finally found it... :-)

http://www.mediafire.com/?01x4dmma6waf3dm

It sounds like Deunan has got much further already, but I'll give it a damned good try.

OzOnE.

[OzOnE]

OK, I've managed to get the FPGA hooked up to the Dreamcast and can now spy on the GD-Rom accesses...

http://imageshack.us/f/811/gdromfpgagrabozone.jpg/

I need some help though - it's been many years since I messed with burning DC disk images and I've forgotten exactly how the boot process works...

What I'm trying to do next is to dump the tracks from a GDI image onto the CF card, hopefully with tracks starting at the same LBA offsets as defined in the .gdi file (to make things easier for testing).

The first thing I need to know is where the TOC is stored in your average GDI image (eg. Crazy Taxi)? The .gdi file has this...

3
1 0 4 2352 track01.bin 0
2 600 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0

I understood it that on a real GD disk, the TOC is actually stored in the first 150 sectors BEFORE track01.bin? I'm assuming track01.bin is the normal "IP.BIN" file contents?

I need to store the TOC for this GDI image in raw sectors on the CF card - is the TOC already in there somewhere, or do I need to generate it?

The TOC is normally 408 bytes (204 words) apparently. I think the DC reads the normal CD (low density) TOC first, but does it then read a high-density TOC in a similar way?

Also, did anyone ever find a definitive conclusion about the 0x70/0x71 commands that the GD drive does? Is this the barcode check, and can this same "reply_71" response be used for a European DC?...

http://code.google.com/p/nulldc/sour...sponse.cpp?r=2

I'm working from the nullDC source, as this seems the closest to what we need (and easier to understand).

btw, I haven't tried emulating any responses or sending any sectors yet, I need to figure the TOC stuff out first.

Thanks,
OzOnE.

[OzOnE]

Nevermind, I think I'm starting to understand now. The TOC can't normally be read directly and is in the pregap of the CD. The Sega TOC is also NOT compatible with a standard CD TOC.

Please bear with me, the FAD stuff is probably well known but I thought I might leave some info here.

(Comment from MAME Sega Saturn CD handling source)...

"Address is mostly in terms of FAD (Frame ADdress).
FAD is absolute number of frames from the start of the disc.
In other words, FAD = LBA + 150; FAD is the same units as
LBA except it counts starting at absolute zero instead of
the first sector (00:02:00 in MSF format)."


Below are partial FPGA captures from my real Dreamcast, the disk used was "DreamOn Vol. 2" GD-Rom...
The DC reads the Single-density TOC first (actual bytes on the left)...

41 (Data track, control bit 4) (Sub Q indicates pos, adr bit 0).
000096 Start FAD of Track 1 is 0x96 (FAD 150, so LBA 0 decimal)

01 (Audio track, no control bits) (Sub Q indicates pos, adr bit 0).
000343 Start FAD of Track 2 is 0x343 (FAD 835, so LBA 685 decimal)

ff
ffffff (no track!)

ff
ffffff (no track!)

...etc. etc. Until the start / end / leadout info at the end of the TOC.


Then the DC reads the Double-density TOC...

ff
ffffff (no track!) ? I think it leaves the gaps here because the single-density tracks are already defined?

ff
ffffff (no track!) ?

41 (Data track, control bit 4) (Sub Q indicates pos, adr bit 0).
00b05e Start FAD of track 3? is 0xb05e (FAD 45150, so LBA 45000 decimal)

01 (Audio track, no control bits) (Sub Q indicates pos, adr bit 0).
048577 Start FAD of track 4? is 0x48577 (FAD 296311, so LBA 296161 decimal)

41 (Data track, control bit 4) (Sub Q indicates pos, adr bit 0).
04c621 Start FAD of track 5? is 0x4c621 (FAD 312865, so LBA 312715 decimal)

ff
ffffff (no track!)

ff
ffffff (no track!)

...etc. etc. Until the start / end / leadout info at the end of the TOC.


It's actually a simple TOC, and could be emulated by parsing a .gdi file on the CF card.

For games with only a few tracks, it's not necessary to generate all 408 bytes of the TOC, just the first few bytes for the track info, and the last few bytes for the start track / end track / lead-out info.

Lots of coding to do before this happens though.

OzOnE.

[angelwolf71885]

wow your making some fantastic progress
i appreciate your work

i hope familyguy and olivia see the work your doing they are the resident experts on the Dreamcast

[splith]

Very nice, I like the N64 backup parts in the quartus screenshot too ;p.

[OzOnE]

Thanks!

@splith - Yeah, I was waiting to see if someone would spot that. It's just a remnant. ;-)

It's was easier to just modify the last project file because it keeps the pinouts the same for the CF flash card and reserves the pins for the SDRAM (so nothing clashes).

I'm still coding, but a bit stuck. I'm trying to work out the best way of implementing everything in Verilog. I still have a lot to learn.

I'm not sure whether to just keep adding state machines, or try separate "tasks" (like in C)? I remember having problems with tasks before if multiple processes try to set the same registers.

I'm also trying to figure out how to make the CF card transfers as transparent as possible. I want to avoid using buffers and RAM blocks if at all possible and just transfer the data directly from the CF card (after adjusting the LBA offsets and accounting for the larger sector sizes etc.)

Another hurdle is - does anyone know if it's absolutely necessary to have 2352 byte sectors in the .gdi image files?

I'm guessing it needs the Sub Q channel data for audio tracks, but could the data tracks be converted to 2048 sectors (chop off the headers and error correction stuff)? This would make things a LOT easier.

Are there any C or Verilog coders out there who could help? I haven't got very far yet, but here's the Verilog for the "spying" version (no output yet)...

http://pastebin.com/b5Ynj4g2

There are many things to be tidied up (like having a counter for grabbing the 6 packet words using a single state).

It's probably a good idea to keep it similar to the nullDC source...

http://code.google.com/p/nulldc/sour...dromv3.cpp?r=2

...but as simplified as possible. Of course, the main difference is we're grabbing the data from the CF card and generating the output signals directly.

(I haven't added anything for handling the CF card yet btw.)

OzOnE.

[OzOnE]

Oh, almost forgot the "money shot"...

http://imageshack.us/f/85/fpgatodreamcastgdozone1.jpg/

(now you can play "spot the V64 and cart case" :redface:)

EDIT: ...and my "P.L.I.E.R.S (tm) lid switch device for Dreamcast."

[_SD_]

:clap:

Awesome work OzOnE, interesting to read your progress on this. :Rock: