Getting a 64DD unit for emulation research

Thanks, Fudge,

It's still a bit premature though, I'm not 100% on the MSEQ data, but I can always plug the N64 back in and do some more captures for that.

tbh, I'm not even a major gamer, I just loved the N64 hardware from the minute it was released. It's more about the technical challenge for me I suppose.

Oh btw, can anyone help work out how the hell the "heads" relates to the sector sizes etc? If you look at Twili's table here, you'll see what I mean...
http://www.assemblergames.com/forum...DD-disk-format&p=521007&viewfull=1#post521007

We need to find the relationship between any given LBA / Track number, and the sector size (Bytes per sector)...

The "official" numbers are as follows, but I don't understand how the "Heads" part comes into it?...

#define C1_LENGTH 7 /* Number of bytes of C1 code per sector */
#define SEC_SIZE_ZONE0 232 /* Number of bytes in a Zone 0 sector */
#define SEC_SIZE_ZONE1 216 /* Number of bytes in a Zone 1 sector */
#define SEC_SIZE_ZONE2 208 /* Number of bytes in a Zone 2 sector */
#define SEC_SIZE_ZONE3 192 /* Number of bytes in a Zone 3 sector */
#define SEC_SIZE_ZONE4 176 /* Number of bytes in a Zone 4 sector */
#define SEC_SIZE_ZONE5 160 /* Number of bytes in a Zone 5 sector */
#define SEC_SIZE_ZONE6 144 /* Number of bytes in a Zone 6 sector */
#define SEC_SIZE_ZONE7 128 /* Number of bytes in a Zone 7 sector */
#define SEC_SIZE_ZONE8 112 /* Number of bytes in a Zone 8 sector */


#define GAP_BYTES_ZONE0 4


#define TK_PER_ZONE0_HD0 150 /* Number of tracks for head 0, zone 0(including alternates and system area) */
#define TK_PER_ZONE1_HD0 150 /* Number of tracks for head 0, zone 1(including alternates) */
#define TK_PER_ZONE2_HD0 141 /* Number of tracks for head 0, zone 2(including alternates) */
#define TK_PER_ZONE3_HD0 141 /* Number of tracks for head 0, zone 3(including alternates) */
#define TK_PER_ZONE4_HD0 141 /* Number of tracks for head 0, zone 4(including alternates) */
#define TK_PER_ZONE5_HD0 141 /* Number of tracks for head 0, zone 5(including alternates) */
#define TK_PER_ZONE6_HD0 141 /* Number of tracks for head 0, zone 6(including alternates) */
#define TK_PER_ZONE7_HD0 106 /* Number of tracks for head 0, zone 7(including alternates) */


#define TK_PER_ZONE1_HD1 150 /* Number of tracks for head 1, zone 1(including alternates) */
#define TK_PER_ZONE2_HD1 150 /* Number of tracks for head 1, zone 2(including alternates) */
#define TK_PER_ZONE3_HD1 141 /* Number of tracks for head 1, zone 3(including alternates) */
#define TK_PER_ZONE4_HD1 141 /* Number of tracks for head 1, zone 4(including alternates) */
#define TK_PER_ZONE5_HD1 141 /* Number of tracks for head 1, zone 5(including alternates) */
#define TK_PER_ZONE6_HD1 141 /* Number of tracks for head 1, zone 6(including alternates) */
#define TK_PER_ZONE7_HD1 141 /* Number of tracks for head 1, zone 7(including alternates) */
#define TK_PER_ZONE8_HD1 106 /* Number of tracks for head 1, zone 8(including alternates) */

I can understand that for a Track number greater than 300, it would then be in Zone 2 (141 Tracks, but for Head 0)...
But, for Head 1, Zone 2 has 150 Tracks? I can't see a specific parameter which would select either Head, so how can the same Zone have two different numbers of Tracks??

I'm assuming the heads are staggered, but surely they can't be an entire Zone apart?...

............Zone
............0......1......2......3......4......5......6......7......8
Head 0..^
Head 1..........^

Note: The "Zones" are mainly needed to work out the "Bytes per Sector", because it varies depending on the current Zone.
The number of Sectors per Block is constant, but there are actually some extra sectors for C2 (error correction) and 1 Gap sector between Blocks...

// There are 12 TRACKS (0 to 11) / 24 BLOCKS (0 to 23) reserved for the "System" area.
// Pretty certain that the System Area starts at BLOCK 0 / TRACK 0 / ZONE 0 (the comment after "TK_PER_ZONE0_HD0" above says the System Area is in Zone 0).
//
//
// Each SECTOR contains...
// [ 232 Bytes of USER DATA + 7 BYTES of C1 ] <- Note: The number of BYTES per SECTOR depends on the ZONE!!
//
// Each BLOCK contains...
// [ 85 SECTORS + 4 C2 SECTORS + 1 GAP SECTOR ] <- Total number of SECTORS per BLOCK == "ALL_SECS_PER_BLK" == 90 (0x5A).
//
// Each TRACK (one disk rotation, or could be Head 0 / Head 1 so a Block on each side?)...
// [ FIRST BLOCK + SECOND BLOCK ]

I'm fairly sure each block has the 7 C1 Bytes added to the given "Bytes per sector" values, so for Zone 0, there are actually 239 Bytes per sector?
And due to the extra C2 and Gap sectors, there are actually 90 Sectors per Block?

Of course, after the error correction and Gap sectors are discarded, you just end up with the "User Data" only.

For emulation, there may be a way around all of this. You just read all the Blocks into a file, but use the maximum "Bytes per sector" when storing each Block.
This will obviously make the image file bigger, but it will then be simpler to find correct data. Then again, we'd still need to figure out all of this crap to read the disk in the first place. :witless:

btw, I don't think it's a problem posting some of this info here seeing that the majority of this stuff is available from things like the Acclaim data dump (and that is HUGE!).
If anything looks a tad dodgy, please let me know ASAP.

OzOnE.

 

Oh, maybe that does make sense. It's just the way the "Zones" are numbered on each side of the disk?...

Head 0..\/
Top.......0......1......2......3......4......5......6......7
Bott..............1......2......3......4......5......6......7......8
Head 1..........^

This makes sure the number of "Tracks" per "Zone" matches on each side of the disk. It's just a silly way to number the zones?
So, if Head 0 is in Zone 2, Head 1 will be in Zone 3, and each head will see 141 Tracks in there respective Zones.

I really hope it works like this, it will make things a lot easier. All you do then is add the number of tracks for each Head together, then the rest should be straightforward. :cocksure:

EDIT: Ahh, this makes even more sense. The heads are only staggered by a small amount?...

Head 0..\/
Top.......0......1......2......3......4......5......6......7
Bott........1......2......3......4......5......6......7......8
Head 1....^

 

OK, I think I've got the Zone stuff figured out now...

I should have paid more attention to the 64DD part in the Intro Manual (bottom of the page)...
http://n64.icequake.net/doc/n64intro/kantan/step4/index2.html

So, the 64DD starts reading the top side of the disk from the outside in (Head 0), then switches to Head 1 and starts reading the underside from inside outwards.
My assumption about the Zone layout was correct, but I couldn't visualize how this tied to the LBA.

It turned out to be simpler than I thought (as tends to happen with these things)...
I first thought that it was doing some sort of interleaving between the two heads, but you basically just keep incrementing the LBA and the drive takes care of the head switching...

// Head 0. Starts at outside edge of disk..
if (LBA >= START_LBA_ZONE0_HD0) {SecSize = SEC_SIZE_ZONE0; Zone = 0; Head = 0;} // Starts at LBA 0. Sec size of 232 Bytes.
if (LBA >= START_LBA_ZONE1_HD0) {SecSize = SEC_SIZE_ZONE1; Zone = 1; Head = 0;} // Starts at LBA 268. Sec size of 216 Bytes.
if (LBA >= START_LBA_ZONE2_HD0) {SecSize = SEC_SIZE_ZONE2; Zone = 2; Head = 0;} // Starts at LBA 560. Sec size of 208 Bytes.
if (LBA >= START_LBA_ZONE3_HD0) {SecSize = SEC_SIZE_ZONE3; Zone = 3; Head = 0;} // Starts at LBA 834. Sec size of 192 Bytes.
if (LBA >= START_LBA_ZONE4_HD0) {SecSize = SEC_SIZE_ZONE4; Zone = 4; Head = 0;} // Starts at LBA 1108. Sec size of 176 Bytes.
if (LBA >= START_LBA_ZONE5_HD0) {SecSize = SEC_SIZE_ZONE5; Zone = 5; Head = 0;} // Starts at LBA 1382. Sec size of 160 Bytes.
if (LBA >= START_LBA_ZONE6_HD0) {SecSize = SEC_SIZE_ZONE6; Zone = 6; Head = 0;} // Starts at LBA 1656. Sec size of 144 Bytes.
if (LBA >= START_LBA_ZONE7_HD0) {SecSize = SEC_SIZE_ZONE7; Zone = 7; Head = 0;} // Starts at LBA 1930. Sec size of 128 Bytes.


// Head 1. Starts at inside edge of disk (Zone numbering reverses!)...
if (LBA >= START_LBA_ZONE8_HD1) {SecSize = SEC_SIZE_ZONE8; Zone = 8; Head = 1;} // Starts at LBA 2134. Sec size of 112 Bytes.
if (LBA >= START_LBA_ZONE7_HD1) {SecSize = SEC_SIZE_ZONE7; Zone = 7; Head = 1;} // Starts at LBA 2338. Sec size of 128 Bytes.
if (LBA >= START_LBA_ZONE6_HD1) {SecSize = SEC_SIZE_ZONE6; Zone = 6; Head = 1;} // Starts at LBA 2612. Sec size of 144 Bytes.
if (LBA >= START_LBA_ZONE5_HD1) {SecSize = SEC_SIZE_ZONE5; Zone = 5; Head = 1;} // Starts at LBA 2886. Sec size of 160 Bytes.
if (LBA >= START_LBA_ZONE4_HD1) {SecSize = SEC_SIZE_ZONE4; Zone = 4; Head = 1;} // Starts at LBA 3160. Sec size of 176 Bytes.
if (LBA >= START_LBA_ZONE3_HD1) {SecSize = SEC_SIZE_ZONE3; Zone = 3; Head = 1;} // Starts at LBA 3434. Sec size of 192 Bytes.
if (LBA >= START_LBA_ZONE2_HD1) {SecSize = SEC_SIZE_ZONE2; Zone = 2; Head = 1;} // Starts at LBA 3708. Sec size of 208 Bytes.
if (LBA >= START_LBA_ZONE1_HD1) {SecSize = SEC_SIZE_ZONE1; Zone = 1; Head = 1;} // Starts at LBA 4000. Sec size of 216 Bytes.


BlockSize = SecSize * USR_SECS_PER_BLK; (85)


You can see that when it reaches the end of Zone 7 (Head 0 / Top side), it switches to Head 1 (underside), then the Zone ordering counts down again towards the outer edge of the disk.
ie. The "Zones" mainly relate to the Bytes per Sector in each part of the disk. It appears to read in a fairly linear fashion using only one Head at a time.

So now, the Windoze proggy is improved :tongue: ...



It automates the Read of the chosen sector now, but the FPGA code is still a tad unreliable.
I need to work out how to transfer whole blocks, then we should be getting closer to making it useful.

I doubled-checked my proggy against the DDDump program from the N64 SDK, and all the Zone / SecSize / BlockSize / Head calcs appear to match fine. :victorious:

 

This is really great work! You might want to post something in the Nintendo Dev section because I feel a few people interested in this might not see it here. You said that it should be possible for people to make a much less expensive interface over at the 64DD forums. I assume you have plans of selling/releasing the schematics for making one?

 

Hey Ozone, when you said: not just on computers but on real n64, you were referring to boot up 64DD roms on flash cartridges?

 

@Master - It should be possible to make a much cheaper interface with a simple AVR chip.
Many AVR / PIC chips have direct USB support nowadays, so they just need power / crystal / USB and a fairly simple bit of software to interface the 64DD to a PC.

It should even be possible to use a standard FT2232 USB module like this one...
http://www.ebay.co.uk/itm/FT2232-US...166?pt=LH_DefaultDomain_0&hash=item519ca9902e

With the right software, that USB module could pretty much be connected directly to the "cartridge" slot on the 64DD (with an extra 12V PSU).

But first I need to get the current version (FPGA) to reliably transfer full blocks instead of just single sectors...

@Fandangos - The original project was to emulate the 64DD directly on the FPGA so the disk images could be stored on SD Card and streamed to the N64.
This proved to be far trickier than I first thought because of the lack of info on the registers, and it was difficult to debug.

(In theory, some of the newer "Flash" carts could be made to emulate the 64DD too. Even if the full image doesn't fit in SDRAM, they could stream the disk image from SD Card).

The other problem was that none of the publicly released disk images appear to have the necessary "System Area" blocks?

So, I thought I might try interfacing the 64DD directly to the PC so the high-level debug stuff could be done on the PC instead.
This is what @cybdyn was recommending for the Dreamcast GD Emu, but I didn't think I knew enough Windoze coding to get it to work.

Well, I have to say that it's MUCH easier to debug on Windoze now that I have the basic interface working.

The hardest part was actually finding a code example for the USB chip (FT245) on my FPGA board, and getting the damned thing to compile properly.
Then, I had to figure out how to program using MFC which the example code uses. I know a bit of C coding, so I'm getting used to the MFC stuff now.

Another possibility (if we can dump FULL images) is to run real 64DD disks on a PC emulator. If there was enough interest, this could even be ported to the 360 / PS3 / Wii.

Still early days I guess...

I'm a tad worried that the "BM Error" bit is always set when I try to read the disk. The actual data seems to be consistent though?
This could be because I'm not using the correct MSEQ data or something? I need to do more captures from the real N64. :concern:

Did I mention I type a lot? lol

OzOnE.

 

Mind if I move this topic to the Nin dev section? It really does not belong in the WTB area anymore.

Also poor 64DD. I think there is more then enough info 2x over to fully emulate it but nobody cares to do it. =/

 

Yep, please move it to the N64 dev section. Maybe from post #15 onwards if poss?
You might have noticed I posted in the dev section too, just to annoy you. :biggrin-new:

I know what you mean, it seems like there are only about four people left who are interested in the 64DD.
Again, it's more about the challenge for me. I get a kick out of finally seeing stuff working (especially if it ever actually works.) lol

Cheers.

 

I know you're just joking but the point to move the topic is it does it a disservice to you and others not being in the Nin dev section where other 64DD topics are. =(

 

Yep, I understand. :encouragement:

Actually, I wish I'd posted the update in this section first (Nin dev) instead of posting the separate update.
It sounds strange, but I often think that incremental updates aren't always worthy of a new thread.

btw, what the current policy on releasing 64DD images? (If it goes without saying, then please ignore this question).
Personally, I would think that the 64DD is way past obsolete now, and there are already thousands of ROM images floating around for other systems?

I mean, since Dezaemon was released, would other disk images really cause a major stir with "you know who" these days?

OzOnE.

 

Thanks for the reply, OzOnE.
Hope you can make it

 

please release more

 

According to the release policy it isn't current gen or even previous gen so it should be fair game. The limitted releases really have more to do with the technical knowledge not being widely available.

I'd think that since these are also magnetic media there's a certain urgency to backing them up as soon as possible, moreso than eeproms. In addition there's other non-game disk data that should be preserved if possible, such as content that may only have been available via download, etc.

 

Thought I'd just say: Amazing work Ozone, very interesting read! Seems like you've got the hang of the start

 

Thanks!

It only took a couple of days to get the basic code working in the end, but that's probably due to months of "insight" from DC project.

I think it would have been much harder for me trying to code an app for the N64 itself, and then you'd still have the issue of easily transferring the data to the PC.
I just about know where to start with N64 coding, but setting up compilers and getting them to work properly is not really my idea of fun. :mad-new:

It sounds like the code for the app / FPGA is in good hands now, so hopefully a few people can figure out how to read full blocks.
Once that's done, I'm sure we'll see more disk images "finding" their way onto the Web. :sneakiness:

Like Zonkity said, the 64DD is so damned old now, I don't think too many people care any more.

Then again, I don't want to be responsible for seriously devaluing the 64DD unit, as I think they're a nice item to own.
What I might do (if this all works out) is to release the USB interface, which means people will still need a real 64DD to run disks, and the disks can be "backed up".

OzOnE.

 

I don't know, I almost feel like if everyone was able to emulate it there would be renewed interest in the add on. I would love to have one myself but damn they are expensive, I think a lot of people would enjoy being able to emulate it. Then again, I see your point not wanting to deter people from buying the system, and completely respect your decision on this.

 

It's rare enough I don't see it impacting the cost of the hardware. To be fair, nobody is collecting the rarest titles due to quality (I'm looking at you, Doshin 2).

Much like VB, these are more collector's items than gameplay machines. More 64DD owners will likely turn to emulating their games just to avoid disk corruption issues. You hear stories about FZX Exp. owners complaining that certain tracks no longer work, either due to track or music corruption.

 

Wow you are so far above my head. lol I just gotta say how awesome it is what your doing. i remeber being so excited about the 64dd back in the day. It's really a shame it never took off and made it's way to America. I still have some Nintendo powers talking about it.

 

I really cant wait to see what will come from all of this! Hopefully this can lead to the development of an N64DD emulator. ive actually run into a Copy of a IPL (J), which is a rom dump of the bios (achieved with a Gameshark), this can be used with an emulator for the N64 to load the rom as a game, which will emulate the N64DD Bios. I have also run across a copy of the N64DD Bios for both the commercial NTSC-j version, and the N64DD Developers Kit (which is supprisingly NTSC-U, and all the menu's are in English) unfortunately, I do not know how to make a rom dump of the developers kit Bios, BUT I can give you all the information that I have found and other users are discussing at the Gamers collective network (including both bios, and the rom dump, and utilities and information regarding Debugging the N64 as well as N64DD emulation attempts and info that you might really beable to use. Hopefully you can use the information we have posted here at the-GCN to help you with your emulation research. http://www.the-gcn.com/topic/2288-n64dd-hacking-thread-2-bios-versions-included-64dd-iplj-rom/

 

*Bump*

Any more news about this project? I am very interested on getting these games working on a N64 flash cart!