Hi, here is the disk format of 64DD disks. ========================================================= ----------------------------- N64 DD Disk information by kammedo, (c) 2011 kammedo@hotmail.com ----------------------------- a) Physical Structure ----------------- A magnetic disk is usually physically divided in tracks,sectors and cylinders. - Heads A 64DD disk is composed by one magnetic film, each side of it represents a "head" of the drive. This means the 64DD disk has two heads. - Tracks A 64DD has 0x86E tracks. - Sectors A 64DD disk track is composed by 0xB4 sectors, and some servo-data only tracks. Servo-data tracks are used by the reading heads of the disk controlloer to know where it is, where a track ends and / or begins and so on. Think of them as the "map" of the disk. They are irrelevant for us, but it is good to know they exist. A disk track holds up to 0xE8 bytes of data. - Cylinders A 64DD disk cylinder is composed by two tracks. b) Logical Structure ----------------- - Disk types There are 7 different Disk types, which basically range from the ROM-only type disk (type 7) to a ROM/RAM type (type 0). Most disks are type 3, but some of them are also type 7 (like Randnet's). - LBA A 64DD disk is logically divided in Blocks (LBAs), which means that from the application layer you can only acces reads and writes block-wise. An LBA size varies depending on the length of the disk tracks that compose the LBA; this in turn relates to how big its distance from the center of the disk is (radius). So tracks (and consequently LBAs) stored at the border of the disk store more information than the ones near the center. To make things easier to the user, DD disks are formatted with 8 zones in which LBA's sizes are constant (meaning all the LBA's of a given zone have the same size). There are predefined sizes for LBAs depending on which zone the LBA is in. A zone is basically a sequence of physical tracks (for an example all the tracks from 0 to 0x240). Obviously, LBAs in zones on the outer side of the disk (farther down the radius) will have larger capacities than theyr counterparts closer to the center, as the track is longer. The 64DD disk is formatted in a way that allow two LBAs to be paired on two tracks. That means that on the first track you will have LBA 0 and then LBA 1, then on track 2 you will have LBA 3 and then LBA 2. The pattern repeats itself on and on. A 64DD disk has up to 0x10DD (4317) LBA's. A LBA consist of a consective, contigue set of sectors. Not considering the sectors with servo-information (which is information used by the drive to know where it currently is, like track number, sector number etc), a LBA is made up of the following sectors: a) 0x55 sectors of data b) 0x4 sectors of C1 data LBA 0 and 3 start at sector 0x0, whilst LBA 1 and 2 start at sector 0x5A. An LBA can contain data, or be empty, trying to read an empty LBA results in an error from the Leo library. - Disk zones A disk zone combines LBA which have the same size. A disk has up to eight (8) such zones. - Physical zones A 64DD disk is divided in 12 physical zones. Physical zones are the "physical" version of the logical zones. So what is the meaning of them? This means they are fixed and the same for all types of disks. The locations of these zones can be organized in a different manner depending from the type of disk (we will see about this later). A physical zone doesnt end with the end of the last LBA, but continues for 24 more LBA's;that means that the size of a physical zone is by 24 LBAs bigger than the logical one. This kind of area probably stores servo information. - System data. The offical info states that a disk contains 4292 usable LBAs, plus 25 LBAs containing system information - 25 + 4292 = 4317, which is the real total of LBAs. - Disk format So disks store not only ROM and RAM, but also system data. System data contains servo-related informatio, as well as the infamous disk id. The outline of a DD disk is the following: <LBA 0..24> System data <LBA 25..disk_type_rom_end> ROM Depending on the disk type, the disk_type_rom_end varies from 1125 (Type 0) to 4317 (Type 6, ROM only) <LBA disk_type_rom_end + 1..4317> RAM -> No ram in disk type 6 Now, we have two types of disks : development (blue) and retail (gray) disks. This distinction is important, as the format of the system LBAs differ slightly. In the following list, blocks without data are labeled as NULL. A) retail (gray) disk system area format: <LBA 0..1> System / servo data <LBA 2..3> NULL <LBA 3..9> System / servo data <LBA 10..12> NULL <LBA 13> Empty <LBA 14..15> Disk ID, repeated in all tracks of the block <LBA 16..25> NULL B) development (blue) disk system area format: <LBA 0..1> System / servo data <LBA 2..3> NULL <LBA 3..9> System / servo data <LBA 10..12> NULL <LBA 13..14> Disk ID, repeated in all tracks of the block <LBA 15> NULL <LBA 16..25> NULL Notice the difference for LBAs 13, 14, 15. Dev drives expect LBA 13 and 14 to contain the disk id, whilst retail disks expect the same for LBA 14 and 15. Dev drives also EXPECT lba 15 to be NULL (needs to be confirmed). =========================================================
I saw in the introductary documentation that head 1 don't have zone 0, does that mean that the system data is located in that zone? Still have to read the DD doc guess it would be more clear after that. With the information you provided we could relocate the system data of Desaemon 3D dump in the right LBA and then write then to a retail disk?
No, the system data is stored in the first 24 LBAs only. I do not believe this to be the 0 zone. The DD doc does not say much about the hardware, but just about the LEO library. Oh btw, if you have the 5.0 SDK, you should have all the LEO tools (dddump, ddedit). They were removed in later versions. Writing a retail disk is most likely only possible from a dev drive. This needs to be confirmed tho. Also, making it would probably need a specific disk patching utility (which uses a patched Leo library in order to be able to access system area LBAs; the patch is quite easy to perform at runtime as the N64 loads all the code in RAM).
@ kammedo: Maybe you could join willis82 to make some reproductions of Dezaemon DD? This way both of you could get some return for your efforts! :nod:
And here's the LBA sizes: Zone 0: 19,720 Zone 1: 18,360 Zone 2: 17,680 Zone 3: 16,320 Zone 4: 14,960 Zone 5: 13,600 Zone 6: 12,240 Zone 7: 10,880 Zone 8: 9,520 As well as the capacity of each zone, head 0 first: Zone 0: 5,284,960 (19,720 * 134 * 2) Zone 1: 5,361,120 (18,360 * 146 * 2) Zone 2: 4,844,320 (17,680 * 137 * 2) Zone 3: 4,471,680 (16,320 * 137 * 2) Zone 4: 4,099,040 (14,960 * 137 * 2) Zone 5: 3,726,400 (13,600 * 137 * 2) Zone 6: 3,353,760 (12,240 * 137 * 2) Zone 7: 2,219,520 (10,880 * 102 * 2) And head 1: Zone 1: 5,361,120 (18,360 * 146 * 2) Zone 2: 5,162,560 (17,680 * 146 * 2) Zone 3: 4,471,680 (16,320 * 137 * 2) Zone 4: 4,099,040 (14,960 * 137 * 2) Zone 5: 3,726,400 (13,600 * 137 * 2) Zone 6: 3,353,760 (12,240 * 137 * 2) Zone 7: 2,981,120 (10,880 * 137 * 2) Zone 8: 1,942,080 (9,520 * 102 * 2) Both heads total to 64,458,560 (61.47 MB). But why is this less than 64? Because only 4,292 of the 4,317 LBA's are accounted for here?
Hi Twili, do you also own a 64DD dev kit? Hopefully someday someone will be able to write a commercial 64DD disk... ray: . . . . . ...and Dezaemon DD (thanks to willis82) will be playable for the community! :thumbsup:
