I was wondering if there existed a tool that can decompress and then recompress the standard OoT ROM instead of the Debug version. Reasons being I'm running the extracted Zelda Collection N64 emulator on my Wii through Nintendont. For those of you who don't know what Nintendont is, I'll tell you. It's a GameCube interpreter for Wii/Wii U that allows GC games to be run in Wii mode so it can make use of the 729MHz CPU. The Zelda games don't slow down in certain parts like they do on GC. The loader does support Gecko codes but for some reason it can't hook codes for this particular application. I already know how to permanently inject codes into N64 ROMs (unless they are compressed like this one) also I know the checksum has to be fixed and also have a tool for that.
I wrote an extractor for some personal projects and could easily affix a compressor to it. Might take a few days to get around to doing it though (just fair warning). Take a bit longer if you want their fancy-pants names on them (since I'll have to find a reference for that to cross-reference as retail is in slightly different order than debug internally). Do you need all the files decompressed or are you just tampering with a few? If you only want to fiddle with one or two at a time single injection would be much faster than a full rebuild.
Basically I was just wanting a tool to decompress the entire ROM in one single file and then be able to re-compress it. And thanks a lot for doing this. Really, really appreciate it.
Alrighty, I'll try to get it out sometime soon. Incidentally, I think somebody already did something similar with Star Fox 64; the filesystems are related is why I mention it. (Actually, need to double-check padding for uncompressed files to be in-line with the filesystem. If you look at the debug ROM files many are padded to a certain boundry.)
Yep, that would be me. Although - while just creating an uncompressed ROM with no other modifications worked fine - when rebuilding the ROM from separate files, IIRC files beyond a certain threshold could not be expanded without causing the ROM to crash at some points... or something like that, its been several years since, and I don't really remember the details... Also, in case anyone's interested, the horribly messy source for the original "Star Fox 64 Toolkit" can be found here.
Alrighty, wrote something up: https://www.mediafire.com/?v17vsosjaij24ii I'm not sure what system you're using, so built it two ways. One is as a python script, the other as the same script compiled for win x64. Both rely on a win32 file for compression but that particular compressor should generate files 100% accurate to Nintendo's originals. It's a bit slow but gets the job done. Tested it only against a subset of the 27 versions of Zelda I have but so far no problems. As a bonus, also works with MM and Doubutsu no Mori.
Thanks a lot. Guess I should have mentioned I use 32-bit Windows 7. Is there any other way to use this on 32-bit? Or could it be converted to 32-bit?
...yes. (insert most optimistic-looking smiley not making direct eye contact here) Might need a day though. Somehow just knew you were going to say that ;*)
Compiled it for 32bit Windows and did something so the interface isn't as horrible. It's basically untested but presumed to work. (crosses fingers) Ran through OoT USA 1.2 fine and final output matched. Same place as before: http://www.mediafire.com/download/v17vsosjaij24ii/Aegh.7z Contains win32, win64, and pure python versions.
Thanks so much! Works great! I patched my "Hookshot/Longshot Grabs Anything It Can Reach" code I made in it and not one problem. Thanks for taking the time out to make this tool. I knew it was possible because there exists a 32MB hacked version with Mario in it. I guess whoever did the hack never released the tools to re-compress it.
They probably just editted one file and shoehorned it back in. That's usually what I do if the filesystem is permissive enough to allow it. You aren't the only person to download it though, so at least it will help out whoever it might help out.
The people on this site use the debug ROM for modifying models and stuff. Would be great if they would instead use the original. But I know the debug ROM can do a lot more like inventory modding, level select, and free movement so it makes it easier to edit. The only downside is that it needs the expansion pack to run. The emulator Nintendo built to run on the GC won't work with it because it expects to only use 4MB of RAM. Majora works fine. The debug Majora works but has bad graphics issues and freezes in certain parts.
There's been a handful of hacks that use non-Debug ROMs as their base - ex. Petrie's Challenge uses non-Debug Master Quest -, but MQ Debug is a common choice because it's already uncompressed and, IIRC, is more lenient when it comes to errors in the filesystem (malformed DMA table?), ex. when "injecting" custom maps. And while there has been at least one tool previously (ZDEC) that created uncompressed ROMs out of the retail builds, I think few people really used it... probably because, hey, MQ Debug is perfectly fine, who cares about the retail versions, right?!
I do. And I can use them on the N64 emulator Ninty built for GC. OOT Debug WILL NOT on work it, yeah I know most people probably don't care but I do. Also with this tool you can inject the re-compressed ROM into VC WAD's and use it. 64MB is too much for VC to load. The biggest it will load to my knowledge is Paper Mario which is 40MB. Wii64 is OK but the GC/VC emu is much better. No speed loss or graphic issues.
I should've ended my post with "/sarcasm", because that part about MQ Debug being fine was exactly that. I should've learned by now that sarcasm never comes across right on the internet, too...
Hey Zoinkity, I've seen some of your other N64 tools on Romhacking.net. Have you thought about posting this excellent one on there?
For the most part people post my stuff there without my knowledge. Most of those are old versions of things. I'd rather not post this anyway since it doesn't have on very important feature: ensuring codewords are correct and updating files when they aren't. (Codewords being the "address" used for lookup, compared to the filetable and used to look up the ROM address.) Incidentally, this tool can compress the debug ROMs if you were to make up a table for them. Only the first so-many files are expected uncompressed. Later uncompressed ones simply compress badly and are therefore excluded. The only thing is my tool will not rebuild an exact 1-1 copy of a debug ROM since it doesn't apply padding to files #500 and above. They're padded to a 0x1000 boundry seemingly for no good reason. Actually, I could add an option for that... Despite some of the files being out-of-order that should fall above when you start padding. The vast majority of files are nothing but resources and, incidentally, don't change much between regions and versions except for the codewords used. With a reference for old and new you should be able to port all but maybe 20 files that contain code between any region without much effort.
