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

I think you're right!

 

Eagerly looking forward to this one.

 

Yep, I'm pretty sure that's what cybdyn meant.

The board will have both connectors, so you can plug the GD drive directly into a PC or other device to rip disks at high speed (or possibly run real GD's on an emulator?).

It's all doable with the ARM chips, it just depends on the firmware and which options you have hooked up.

OzOnE.

 

The way I though of it, it was a way to dump the gd-rom to HDD using the DC and DCIO, kind of a man in the middle attack! But anyways! It's looking like it's gonna be great!

Cheers!

FG

 

I thought the same thing too. Since the board will already be coded to read from a HDD or SD then it wouldn't be much more to allow for writing to the medium from the original GD drive. System Disk 2 or else a way to disable the disk check and we can then dump prototypes better.

 

DCIO should already be able to load GDI as if they were real gd-roms (I/O redirections and emulated disc checks), so it should be no problem to emulate ONLY the disc check, and not the I/O redirections.

 

I was thinking of this too but in a brainfart left it out...

Emulating the System Disk 2 GDI image to pass the security checks, then dump a real burned GD-R with a prototype, play, share, profit? Profit.

 

(OK, time for one of my famous slightly off-topic posts).

I wish we knew the EXACT mechanism for the security unlock.

But, as far as dumping the disks, I don't think the GD drive itself would be a huge barrier.
Should be possible to boot the System Disk 2 on the emu though, then swap to a real GD-R.

As far as I understand it, the "security" unlock command on the GD drive is some sort of crypt cipher?
The drive first checks to see if it's a GD disk, the DC reads the status then sends the 0x70 and 0x71 packet commands.

I'm guessing the reason the System 2 disk can unlock the drive for GD-R booting is purely because it has the required barcode on it?
Makes you wonder if it's doing a different type of check on the GD-R barcode though, or simply unlocks the drive temporarily for open access?

The 0x70 command has been called a "spinup" command in a few emulator sources, but it could be a request for the drive to read the barcode?

Do we even know if the drive does read the barcode in some way to generate the seed for the response?
After all these years, I haven't seen any info to say that this is definitely the case.

The data sent back from the GDD after the 0x71 is generally different each time, but for the GD emu, I was sending back the fixed data to the DC that is used in nullDC.
This is 1012 Bytes of data which is always the same. The DC didn't even attempt to boot to the license screen without the fixed response.

(I believe the fixed data is what cybdyn is using as well.)

My hunch is that it works in a similar way to the Saturn protection (as pointed out by FG or somebody a while back?)...
http://webcache.googleusercontent.c.../Saturn/cd_tech.htm+&cd=6&hl=en&ct=clnk&gl=uk

(btw, the crazynation page seems to be down now, so I'll have to save a cached copy of the whole site from web archive.)

If only we could extract the original firmware from the GD board.

Most of them use a Hitachi MPU which stores the firmware internally on Flash or Mask ROM. I can pretty much guarantee that the Flash will have it's security bits set.

TriMesh very kindly sent me a GD board with the OAK ATAPI controller on it a few months ago, but I'm not confident that I'll be able to dump the firmware.
I have traced a few extra pins on the test pads though. I'll hook it up to the serial port and see if I can find some more info.

(the "Yamaha" type GD boards output serial data too, but their RX pin isn't usually connected to the test pads?)

The second part of the GD protection involves the BIOS check where it transfers the BIOS data "through" a register in the Holly chip.
That is apparently only for stopping people modifying the retail BIOS and failing the checksum.
If it fails the check, it's supposed to "lock" access to the GD drive somehow? Possibly by disabling DMA transfers?

Obviously, this isn't a super secure checksum method, as the good work of Link83 and others on the Dev BIOS mod proved.

So, does anyone have any snippet of info at all on what the DC might actually be using for the GD disk protection?
I haven't seen any patents on it yet, so I was wondering if anyone else had?

Interestingly, and something I only saw in the last week or so, the demul emulator sends two different sets of data back to the (emulated) DC on each test?...

See the last part of the code...

http://code.google.com/p/demul/source/browse/trunk/Gdrom.c

Although, I can't see how it would ever get to the "else" part of the statement, as it's always setting the flag to 0 at the start?

OzOnE.

 

Oh, evidently I didn't search hard enough before. (where's the "embarrassed" emoticon?)

http://www.google.com/patents/US5627895

Answers lots of stuff. I didn't know half of this.

 

The SD2 can boot a retail because it has the ring. Thus why selfboots of the SD2 don't boot a gd-r. There's really no need to emulate a SD2 to boot gd-r using DCIO IMO, as long as cybdyn implements it it should be quite straightforward if it's already possible to load gdi. The DC checks for the "ring" a specially crafted zone which makes the text under the gd-rom and saturn cd. There might also be a small mirror zone at each edges of this region, according to some internal docs.

 

Thanks, FG,

I know you said about this stuff before, but I understand it better now that I've seen the patent.

You're right ofc - The DCIO will probably work for booting the SD2 image, but it shouldn't be a prerequisite for booting a GD-R.
Although, sending the fixed security response then switching to the real GD drive to read a proto disk may depend on how cybdyn has connected the ports etc.

Rather than running a proto GD-R directly, it will likely be easier just to rip the GD-R to the DCIO first.
If the data is good, then it should run like the original.


The more I think about the security ring check on the GD Emu / DCIO, the more I think the fixed data must be successfully bypassing it...

I've tried the fixed security data with the European, USA, and Link83 Dev BIOS images in the past, and they all at least booted to the license screen.
The theory is that the DC BIOS could in fact be requesting a specific part of the security pattern when it sends the 0x71 command.

cybdyn noticed that the DC sometimes requests a different number of bytes for the response, but this value might actually relate to pattern position.
Whoever found the fixed data must have reversed the algo for checking the response so it always passes the check no matter which pattern part is requested?

Or, could just be the drive itself which chooses a random position to read (as per the patent)?
I haven't yet found the BIOS routine which checks the security response. It's quite hard to track where the packet commands are coming from.

I'm intrigued by the security protection stuff. I think I'll leave it for now until the DCIO is ready. lol


Right, back to some Naomi experiments today.
I found a stupid bug last night where I was using the DMA offset instead of PIO.
I need to ensure that I'm grabbing the correct data from SD so that it matches the real cart, then I can sort out the G1 control signals.

 

For what it's worth, pinchy did a wonderful job partly (until it can be cracked with a modchip) reverse engineering saturn's ring (not the real saturn, that was done here: https://en.wikipedia.org/wiki/Roche_limit).

See this post: http://club.myce.com/f61/copy-protections-sega-saturn-59813/index16.html#post1752184
Seems like the mirror pre-ring minizone to me.

EDIT: See ring -> data transition here http://bit.ly/1hdCOcP
My guess is that the blank buffer zone is actually a mirror/reflective area and that the gd-rom firmware checks for that signature and then return the right bytes accordingly.

 

i think pcb is finished.

http://s005.radikal.ru/i210/1311/0b/b9599a55e7c2.png

 

Looking good. Looking good indeed.

 

*queing in line for it*

 

Let me join you in line there, Braintrash.

 

congratz @cybdn. i will probably buy both psio and dcio.

is there any video etc. while dcio is loading the game?

 

v1.0 of dcio is loading a games, there are videos on the youtube and somewhere else... but i remade new version... pcb is under manufacturing. you can see pics above how it will look

for psio 2.0 - it was done yet and on the way/fly to me

 

http://www.youtube.com/user/9madsheep/videos

 

thanks. it works great.