http://www.mediafire.com/download/i525yo852ep0gwf/DezaemonXD.7z
If you, like all but one of the estimated 3-5 trillion people in the world don't have a physical copy of the prototype Dezaemon DD disks you're in luck today! This patch intermeshes the cart and disk content from the publicly-released 2nd Dezaemon prototype disk into a single cartridge image.
The patch is confirmed to work on hardware, and if your flashcart can be set in a writable state will function nearly-identically to the disk version.
Features (and Limitations):
All disk content normally available when using the original disk in a dev drive is available with this patch.
Disk content is accessed using the normal drive libraries. Changes are made at a low level, substituting drive hardware calls with standard cart PI access. Data is accessed using LBAs, loaded and saved as LBAs, and the cart addresses match LBA byte offsets.
If you are using a 64Drive or if your flashcart allows cart space writing, you will be able to save modified data back to the cart just like a disk image. Please note the modified cartridge data is not written back to the SD/CF card but can be obtained by uploading the ROM to PC via USB. Use 64drive_usb.exe from http://64drive.retroactive.be.
If your flashcart doesn't support writing or you're using an emulator available features will be limitted. You will be unable to save modified data, create new files, or copy existing files.
Emulators vary in their support of an unhacked Dezaemon much less one that's been modified. Refer to the emulator's documentation for basic compatability. For any HLE emulator you'll also need to copy the emulation settings used for the unmodified game and create a new entry for the patched version. This varies wildly from one emulator to another, so ask on their help forums and refer to their documentation for a better idea of what settings are necessary.
Note that regardless your setup you will be unable to use the disk-to-disk copy feature. The reason is both a logical falacy and a software issue but should be self-evident.
Danger Will Robinson!
The patch embeds data from a publicly-released 64DD disk expansion, the second of three known disks. There is only one known extant copy of this prototype, which may cause legal complications depending on your local and national laws.
Use common sense, and be aware of what limitations you may be under based on your locale.
Application:
You'll need an unbyteswapped (big-endian) Dezaemon 3D ROM. For the sake of legality I'll assume you dumped it yourself and didn't Google some ROM site someplace.
The patch comes in two flavours:
DezaemonXD.bps, which can be applied with Beat (http://byuu.org/programming/) or the python bps module.
DezaemonXD.xdelta, applied with, well, xdelta. It's a command-line tool but there are frontends for it on many platforms.
You only need to apply one of the patches. You couldn't even apply more than one if you wanted to as they're checksum-enforced.
Hoopla!
Dezaemon doesn't "reboot" like other expansion carts do. The cart accesses data from the disk but does not replace its system code. That allows a bit of magic that wouldn't be possible with other titles such as the F-Zero X expansion.
Obvious drive maintenance commands such as rezero, reset, etc. are disabled. Seeking sets a position which will then be used during read/write operation. Read/write function by converting disk request data (LBAs, sectors, sizes) to a byte offset in the ROM file. Reads and writes occur at their normal sizes in their normal buffers but use cartridge access.
Hardware register tests and confirmation are kept at fixed "good" values. This does cause a complication; if errors occur they can't be cleared in most cases. Most notably, disk-to-disk copy requires ejecting the disk which throws an expected error state. However, fixed values never allow that state and there isn't exactly a way to signal an ejection anyway--or a disk to replace it with.
To a degree the patch cheats. Originally it was going to keep track of "good" values for registers and handle the hardware register requests/writes. This proved a bit tedious and somewhat problematic so now most simply return static values.
The RTC is only read, and the value copied is not used (or for that matter incremented like a proper clock). For this reason it was set to static values. Originally the AF clock method was going to be utilized if the time was important or, minimally, stored.
Elsewise:
If you'd like to show your thanks to the collector who salvaged, dumped, and distributed the disk image please contribute toward willis82's fundraiser. Granted it's been some time since it's been run, but it only met a small fraction of the cost for acquiring these disks and preserving their higly-volatile, gradually-aging magnetic storage. It would also be a great way to coax them to release the other two images ;*)
If you have any questions and concerns that don't involve the F-Zero X expansion, please feel free to email me. I don't ever seem to have direct internet access, but presuming your mail doesn't hit the spam folder I'll try to respond to you somewhat timely.
If you're curious what the easter egg is this time, I'll give you a hint. It has more to do with this distribution than the code itself.
-Zoinkity
Bonus!
http://www.mediafire.com/download/0mg1nui1fhc4eb0/DezaPelican.7z
The three cart games embedded on the disk instead.
Last edited: