Getting a 64DD unit for emulation research

If my programming skills were better I would gladly help, so all I can say is great work so far!

 

i could help more or less to Ozone, but he didnt ask ))

also, i still don't get what he does: OzOnE, you explained much but it's not information what easy to understand)) just "as is" on the table)) mn


as i get: you are trying copy data/image from 64dd cassette to pc(via usb). or another way is attach SD card, and safe image as file (in FAT32)


also I/F of 64dd? : it uses same i/f like n64 catrtrifge? like:
-multiplexed Addr/data bus?
- ALEh/ALEl for address latching high/low address area?
- nWR / nRD strobes for write/read?

so what we need if i'm right , set adrees in A/D[15..0] bus, then Read/Write data? for burst data we use 128-words or 256?

SAM3X has DMA's channels for sd and smc bus, so i think slowest hw is 64dd itself,
what speed it is? what about size of image we are talking about?

 

any news so far?

 

Incredible!
Can't wait for more on this!

 

Bump
Anything so far?

 

Sorry, but I got side-tracked with so many other projects again, I haven't had chance to look into the 64DD stuff since.

I was still getting dodgy sector reads when I last tried, so I've had to shelve it for a while and come back to it later.

It might have actually been easier just to write an app for the N64 to read from the drive instead, but I've never really done any N64 coding to speak of.

I may have another go at this soon, but I can't promise anything.

I feel I shouldn't really have posted too much before as it gets everyone's hopes up.
I can't always guarantee success with this stuff, and often real-life or other projects get in the way.

I know that some other people are looking into the 64DD though, and they are way better at coding than me.
Hopefully they can iron out the last few glitches and get a complete image dump made.

The data is definitely there to be had, it's just a case of tweaking the code to get a perfect image dump.

If I do get chance to take another look at this, I will of course keep the forum updated.

OzOnE.

 

From what I'm seeing on the software side, it looks like the system LBAs (first 24 usually obscured by software) should be unencrypted and read like the ToC previously dumped. After that though, it's absolutely vital to know if the drive passes C1 error data.
From the looks of the horrifying hash algos that use them, the "error data" is more like block-level encryption that's decrypted based on one of four algos selected by the number of C1 thingies passed it. So, if you're dumping an actual disk image some blocks are going to look like nonsense or have "bad data" embedded, and this can only be converted to the real data via decryption. So, basically, we won't know if your images are even correct until all the algos are reversed.

Aegh...

That said, if a block doesn't have C1 data no conversion is necessary. Looks like those data dumps from before could be useful after all. Note they're all incomplete though. The first 24 LBA are missing from them all, so what we have is 0x18-0x10DC. C2 isn't used unless C1 is present, and basically it points to a decryption table.

To give everyone an idea of the complexity of the algos, the first one is a simple XOR+shift kind of thing, and the fourth could be mistaken for SHA (it might be for all I know).

 

I didn't think there would be a complex decryption thingy tbh.

I thought the main thing was "emulating" how the N64 itself grabs the data, then just supply it with the same data from SD card etc.

Although, I have seen a few blocks which always have the C1 error bit set, and I realize this would need to be figured out.

For the most part, the data seems to in-the-clear though, and the C1 / C2 bits aren't usually set.

I've seen that C2 isn't usually set until it fails the C1 correction too.
Some of the comments in the SDK stuff suggests that there may be those "false C2 data" sectors though.

Would it be enough to just dump the C1 / C2 data as well, or is there more evil encryption going on between the drive and N64 so the drive produces the correct response?

From what I've seen on the real traffic from the N64, it doesn't appear to send any strange seed values or any unexpected commands?

OzOnE.

 

There's some stuff we haven't exactly worked out yet, but basically if you can dump the C1+C2 with the data it would probably be enough. Where that data is stored though is a bit of a mystery.

The decryption tables are the same for all titles (thankfully). There's four, although two of those are basically the previous table shifted one byte with one value that's different.

There's a lot left undocumented though. For instance, the +0x528 and +0x530 are both written to when doing a read or write. One appears to give the max and actual track length in the upper half of the word. The bitflags on the Sequence Status reg aren't all known either.

I think the big problem for everyone working on this issue is we're used to dealing with the data on the disk, not the disk image's formatting. It's hard to think of this thing in tracks and sectors, reading outward in or inward out. LBAs are basically an abstraction removed in the final two layers of the onion that is the Leo library. Congrats to Nintendo for making something that's actually difficult to hack ;*)