This has had me going for a couple days, and maybe somebody more knowledgable could explain why this is the case. Now, the dump has an MFS RAM table starting at offset 0xEF5A60, which would be LBA 0x34E assuming this really is a type 3 disk. Obviously, if this were a type 3 disk that's entirely the wrong place to put it. It shouldn't be found until zone 6, certainly not within zone 3. All the data up to this point followed the predicatable LBA offsets and expected sizes, and files spanning multiple LBAs spanned multiple LBAs without filler. Then there's the MFS table. There's filler between each LBA starting here and onward, but the filler is remarkable. Just like you'd expect for zone 3, the span between each clump of data is 0x3FC0. However, the actual contents of each LBA is 0x2FD0, just as you'd expect for zone 6. So, to read the data from the MFS you have to read in 0x2FD0, then skip the 0xFF0 filler to align to the expected LBA size, then read the next 0x2FD0, etc. Is this correct, and if so, how are you expected to know the expected read length of each of these LBA? Plus, why is the RAM MFS table found within the ROM area? If not, was the disk dumped badly? I assume it was LaC that did the original dump. How was it done, anyway? Did an extract of the contents though. It's a bunch of bonus images for the pilots you'd load into the Mario Artist Paint Studio. Format for those is listed too, although I've noticed in user images it will usually be followed with a few lines of something (maybe palette or just overdump) despite the image dimentions being correct. http://www.mediafire.com/download.php?8qdhfg6dyjqccqm
Yeah, they were, along with a few other things. Actually, at one point I made an uploader so you could send those tracks (or presumably any others) via GameShark. E33140 LBA320 bin CK1-user_circuit_course_1.bin E37650 LBA321 bin CK1-user_circuit_course_2.bin E3BB60 LBA322 bin CK1-user_circuit_course_3.bin E40070 LBA323 bin CK1-user_circuit_course_4.bin E44580 LBA324 bin CK1-user_circuit_course_5.bin E48A90 LBA325 bin CK1-user_circuit_course_6.bin E4CFA0 LBA326 bin DD1-Silence_3.bin E514B0 LBA327 bin DD2-Sand_Ocean_3.bin E559C0 LBA328 bin DD3-Devil's_Forest_4.bin E59ED0 LBA329 bin DD4-Port_Town_3.bin E5E3E0 LBA32A bin DD5-Devil's_Forest_5.bin E628F0 LBA32B bin DD6-Big_Blue_3.bin E66E00 LBA32C bin EE1-Mute_City_4.bin E6B310 LBA32D bin EE2-Space_Plant_2.bin E6F820 LBA32E bin EE3-Port_Town_4.bin E73D30 LBA32F bin EE4-Fire_Field_2.bin E78240 LBA330 bin EE5-White_Land_3.bin E7C750 LBA331 bin EE6-Big_Foot.bin
Actually, that's part of why I was asking about this. This disk dump doesn't seem like it's quite kosher, or if it is there's definately something lacking in what little documentation exists. It could also explain one of the huge problems right now with reading data properly, even after compensating for the missing system area. I was rather hoping somebody knowlegable here could either explain how this behaviour works or verify the disk image is bonkers so a new one can be made. At the very least it would make reading stored data a whole lot less annoying.
F-Zero X Expansion Pack dump (and same for Dezaemon DD dump) aren't complete. In the case of FZX Expansion Pak: It's overdumped AND System Data is missing. The latter is also the case for Dezaemon DD. That's why that it's weird.
