Super Mario 64: Super Mario 64DD to Cart

The disk build of Super Mario 64 was a hastily-made promotional piece that was little more than a sliced up cartridge ROM (see readme). This patch reassembles the original ROM and switches disk read requests with cart requests. Disk saves are replaced with EEPROM saves, thereby eliminating the two things that made this version at all interesting.

As a bonus, the Wiggler health bug was also corrected so it should be possible to collect all 120 stars.

To distinguish the patched file from other cartridge versions, the internal name reads "SUPER MARIO 64DD", the version is -1, and a timestamp was applied.


Apply the xdelta patch using the similarly named xdelta; use version 3.0.8 or up.
The patch will only apply to a disk image in LBA order, not track order (ndd, not d64) and in its original release state (saving to the disk changes the file). If you've saved data back you may be able to force patching by ignoring data checksums; there's only one of these games in the world after all.

Note the patched file will be much smaller than the disk image: 949D60H / 9739600 bytes.

Super Mario 64DD to Cart

.: Introduction :.
The disk build of Super Mario 64 was a hastily-made promotional piece that was little more than a sliced up cartridge ROM (see ".: Notes :." below). This patch reassembles the original ROM and switches disk read requests with cart requests. Disk saves are replaced with EEPROM saves, thereby eliminating the two things that made this version at all interesting.
As a bonus, the Wiggler health bug was also corrected so it should be possible to collect all 120 stars.

To distinguish the patched file from other cartridge versions, the internal name reads "SUPER MARIO 64DD", the version is -1, and a timestamp was applied.


.: Patching :.
Apply the xdelta patch using the similarly named xdelta; use version 3.0.8 or up. The patch will only apply to a disk image in LBA order, not track order (ndd, not d64) and in its original release state (saving to the disk changes the file). If you've saved data back you may be able to force patching by ignoring data checksums; there's only one of these in the world after all.
The resultant file will be much smaller than the disk image.

Common names include:
NUD-DSMJ-JPN.ndd
SM64Disk.ndd

Original File Checksums:
SHA-1
E8F5C3F0E151CBC3B02184A2437E39FA9D1E2686
SHA-512
A752DB1F7D4FA166E7F65A323B2C1558E61FA74E3110B5FB88857683813E7385F5B91C9D9A0614C7521846F543FA6BF0ED4C78CB31AC9510B55EC14781C49B4B

Patched File Checksums: (0x949D60 / 9739600 bytes)
SHA-1
D8001861F06C9009EF6A9276095E3780AEA36800
SHA-512
170A03FE7FEBB6736A2FFFA19D9F9E6C547008C05388BC4BD7AFE7D0AB2D1457F9922532455A0916C3969ADAA77A964976A41FA47FBBEA00DA38B73F5566D2C5


.: Notes :.
tl;dr: It's likely this build was created in a matter of hours, not days. It's also prone to getting crossthreaded.

*)Disk support is a complete hack.
Internally, files are still loaded using ROM start-end addresses. The ROM is split (for the most part) in two~ish parts: The main runtime code, loaded in a massive block at boot (0x36 LBAs); and everything else, packed and aligned to virtual zone 2. There's some neat overdump inbetween, and save file at the start of RAM. There's quite a bit of overlap in the "code" and "other" sections.
Effectively, only two functions create data read requests: 8040BAEC & 8040BBE0. Both manually convert ROM addresses into offsets from the start of virtual zone 2 (LBA 0x230/0x248). In fact, it can't load anything from other locations. The address is divided by the size of its LBAs, and these vary in size depending on where on the disk you read from. It reads from the nearest LBA, then offsets to the start of data within it, ultimately copying it to the final destination.
These two functions differ only in the length they accept (due to target buffer) and a hardcoded file substitution.
*Converting back to a cart only required realigning data to this ROM map, changing the type of read request, and skipping Leo thread creation.

*)There's a hardcoded sound sample substitution in one of the two file reader 8040BAEC.
0x4FC1F0 is replaced when its filesize (0xDE230) is detected. No address convertion is used in this case; it reads 0x42 LBAs directly from LBA 0x10C/0x124.
It reads it from the "other" audio bank, in this case 0x127D70 bytes at 0x57DD20. That replaces a range of instruments without affecting the sequences themselves--or it would, if the data were in any way different. However, the file length is updated, so it may be a hack-ish bugfix.

*)The game was adapted to save the game to disk. It's a blind read/write to the first RAM LBA on disk type 0. On any other disk type this would fail.
*Extremely stripped-down EEPROM support was hacked back in, replacing the reader (80406C88) and writer (80406CE4). If an EEPROM is not found it should gracefully continue without error...and not save your game.

*)It is the only released version subject to the Wiggler health bug.
Disk games have to buffer data--you can't read real-time. Basically all game code and current audio is in memory at all times. On the plus side this is why the game runs unusually fast and smooth (until music changes). However, there's zero delay when wiggler's event starts so there isn't a dead frame where the health is updated.
*That bug has been patched out in this release. You can collect all 120 stars.

It *is* quite interesting from a historic perspective. The earliest disk library is used here, prior to including the clock. It handles certain commands in very different ways, such as address translation. It has no security checks--no mention of the IPL at all.

-Zoinkity


*Common Names:
NUD-DSMJ-JPN.ndd
SM64Disk.ndd
*Original File Checksums:
*SHA-1
E8F5C3F0E151CBC3B02184A2437E39FA9D1E2686
*SHA-512
A752DB1F7D4FA166E7F65A323B2C1558E61FA74E3110B5FB88857683813E7385F5B91C9D9A0614C7521846F543FA6BF0ED4C78CB31AC9510B55EC14781C49B4B