That? There's an internal filelist with all the offsets. All I did was piped them though the N64toTGA.exe I've bundled up in the TWINE and AF tools. Didn't feel like tracing everything so just took at peek at them to guess the dimentions/format. Really easy, actually. There aren't any stage-specific images from the second stage present. Also, when it attempts to load it it will peek at data beyond the actual end of ROM (0x800000) and treat teh display lists there as though they were pointers. That, needless to say, is very bad.
My bad. It works exactly as seen on real hardware xD Only one level of SP and MP also working, very slow
Matters on the game, and there's a few different ways to do it. The way I do it is backtrace from ROM access or search for known addresses. First, there's a few standards for sound, and since those addresses are needed for a certain other side-project searching for their identifiers helps. Some will use "B1", "S1", "N64 PtrTablesV2", "N64 WaveTables ", or actual midi/mp3 headers. The more useful method is to set a write breakpoint on A460000C (PI Write Size), advance one op, and see what ROM address it's loading. Also, looking at the return will usually key you in on what the rdram address is for the ROM loading routine(s). You can search for JALs to it. In Wild Waters, one of them is 8000A6F4, in ASM 0C0029BD, loading A2 bytes from ROM A1 to rdram A0. The advantage is that you can then look for any immediate hardcoded addresses and also pick up on any tables, usually the number of entries, and especially any base address they'll increment from. For instance, take a peek at 80030D70 and you'll see it loads two banks of stuff ('sfx' and 'graphics') within 0x40 headers. Knowing filesizes and peeking at offsets it's pretty easy to guess the header's format. Others would be: 800360F8 V0=p->image entry A0 within MWo2 file @ 0x8E0C0 80036330 load image entry A0 within MWo2 file @ 0x8E0C0 to A1 This game's data uses a rather silly table at 0x89370 in ROM to index the 'sd' block. Each entry is 0x20 in size and I don't think all of it is used. It'll look something like this: 00013880 00000040 00000000 800350A8 800350F8 00000000 00000000 00000000 The breakdown is something like: 0x0 2 type, or they could just read the GUID stupidly 0x2 2 GUID(?) 0x4 4 offset 0x8 4 offset to multiimage table or NULL 0xC 4 p->preprocessor handler(?) 0x10 4 p->postprocessor handler(?) 0x14 4 RESERVED 0x18 4 size 0x1C 4 RESERVED Note I didn't export the objects in the 'graphics' block. The microcode interpretter I have has a stupid bug in it. Doesn't cause problems with GE usually but does with this game. Depends on the game though how well that will work. There isn't a lot to these prototypes and they didn't compress anything so really, its quite simple to do. Some games have dozens of microtables, and some hardcode everything. Take, for instance, Mini Racers. So far, no compression. There's a couple tables, and some are offsets from a standard address while others are immediate offsets, and there's quite a few hardcoded addresses. 0x801E0 - 0x802C0 is a table of 17 entries, each one an actual ROM address. Most are hardcoded. Things like the sound table, ASM, and some of the DL/image files are loaded directly; a few are more complex, like how 80000874 is a linked table of hardcoded offsets corresponding to entry number A0; and then you get into the truly questionable like 80000CB8 and 80000E40, loading one of 8 images from one of five banks or a default image, and the sizes can differ. Anyway, found each and every one by looking for ROM load requests sent to the PI and backtracing the loader.
Sorry to bump this one, but just because Team Carrot is "gone" you can't release anything?... I don't get it. If you don't want to release stuff for free, I can understand that, there are always fundraisers... (not necessearily here) In case you're looking for N64 prototype carts again (in return for releasing roms) I won't be the one to chip in this time around, I've done my part ;-)
Back after a long time. I got a 1 of a kind prototype of frogger,straight from a developer.No not that fake 1 but a 3D version. And a prototype version of macethats different(more gore etc,) And some other stuff i need to compaire.
Already replied but wanted to add that i did offer the sugestion of a fundraiser,but that was locked by a mod and now im almost never on the net and the proto closet is in lock down mode. So the release of my other protos is close to zero. There was already a deal made for the public.The 3D version of frogger that had many if not all of the sound effects of glover 2 btw was going to get released for the public in exchange for the miniracers cart after the dump. The rabbit backed out and that was that. Your lucky i even read this Like i said im almost never online anymore(here or nesworld or gaming sites in general)
Wanted to mention this, since it was sort of touched on before. The Wildwaters dump is actually an overdump, and everything past 0x800000 is from another game. This is rather common, since it's impractical to completely reformat (blank) an entire eeprom cart every build. The overdump data itself comes (presumably) from the US build of Destruction Derby 64. Image resouces match, image DLs match within reason, although there isn't a 1-1 correspondance with the order of image resources. Might be of interest to compare (the sound files appear different), but I sincerely doubt we'll see much of anything interesting. Aegh... I was honestly hoping it was another of their in-development titles ;*) It's a close enough fit though to call it though.
what about Mini Racers? .. is there any extra data? can't remember if it was resized for the release, if it was I'd be happy to supply a "raw" dump (overdump made with a gameshark).
I don't remember there being anything interesting at the end of it. (I had a chance to poke through the raw in fact ;*) Wish it duplicated part of the ROM at the end, but sadly didn't. There's some data lost to bitrot: part of a sound sample, part of a track, part of a car's images. Car image was easy enough to fix, and the part of the track can mostly be patched together (on the TODO list) but that sound snippet may be lost. Pretty sure Tamiya Racing was a case of duplication. Nothing interesting at the end of it either.