Long time lurker, but I was browsing some auction sites for gaming stuff; when I came across this one N64 with a strange item in the Jumper pack slot. I did a minor Google search on 3rd Party accessories for the Jumper pack, and came up with nothing. So anyone know exactly what this is?
That's a third party expansion pack, by Pelikan. I know as that's the one I have. Third party expansion paks are traditionally frowned upon by N64 users, as apparently they are unreliable, but I've had mine for twelve years or more and it's never failed, perhaps because it has the external heat sink that's so unusual. BTW, you probably know, but if you don't, the jumper pack apparently just connects up the connectors in the N64, it's the default state. When you buy an expansion pak, you remove the jumper pack, and replace it with the expansion pak, which contains 4MB RAM (remember when that was a lot?) and so doubles the N64's RAM to 8MB. The only two games that need an expansion pak to run are Donkey Kong 64, and Legend of Zelda: Majora's Mask, but Perfect Dark is extremely cut down without it, so you do really need an expansion pak to play PD. Quite a few other games use the expansion pak to give an optional high resolution mode (typically 640x480, again, remember when that was impressive? ;o) ), and a very small number of games do other things with the extra RAM. The NTSC version of Space Station: Silicon Valley crashes if the expansion pack is present - the PAL version has this bug fixed, thankfully, and I think later NTSC batches of the game were bug fixed too.
That's also the style of expansion pack sold by joytech had mine for at least 7 years and never had any trouble with it, i prefer it to the official truth be told, makes the n64 look more interesting. Certainly interesting enough for someone to make a thread about it It was also cheaper
There are a lot of different models. I remember reading in IGN64, they saying about their "engine-like" (like from a muscle car) expansion pak. Some people say about reliability, but Nintendo says only that you can't remove and insert it too much. I usually use only offical items, though...
If your using a 64DD you should only use official ram packs. I've seen some 3rd party packs make a DD inoperable, pop an official one in and it would work. Not sure as to why and to which brands but I've seen it happen.
I'm not technically minded, so I can't easily imagine why that happens, unless Nintendo deliberately made the DD refuse to work with a non-Nintendo expansion pak. Would that be possible? Do DD's work if there's a Gameshark attached (as I imagine a Gameshark would be easy to check for)?
The expansion pack that ign used was the madcats Hi-rez pack. It came with a cover that looked like a funny car blower.
To answer your question Conker: 64DD could potentially work with a GS with coercion. It's the same problem as certain 8MB games (Perfect Dark and Banjo Tooie, for instance). Minimum it should work with all combo games, but there's a possiblity with the IPL with a tiny hack to the BIOS. Let me explain. The GS boots after the cart, effectively piggybacking its bootstrap. From there, it uncompresses itself and runs like any other program, which is fairly safe until exit. On exit it uses the boot address from the cart header as the jump and sets the WatchLo/Hi (whichever it was). Without the code generator it uses an intercept with codelist at 80000200 (? double check), and with it on the trainer will take up everything from 80780800 to the end (with some gaps). Port access requires the trainer, but there's also a simplified trainer IceMario made a long while ago to circumvent that. It can also be redirected. Now, on the 64DD side of things there's only two ways the combo disks operate. The simple method is direct control, such as with the Dezaemon disk. That's pure data, and you can probably finnagle the trainer to work with that. The cart just reads data off the disk, makes up some tables, and reads it on-demand into rdram. The other method is Nintendo's disk reboot method. This involves the cart loading a replacement system/library segment off disk into the upper 4MB. It then replaces the cart's own system/library segment (usually 80000400+) and falsifies a soft restart, executing from the new boot address. To be fair though, the new and old code is surprisingly similiar. Ensuring the hook works is a matter of catching anything that plays with the Watch registers, then overwrite anything that does. No problem there. The trick relies on the built-in code to redirect the codelist to a different location--someplace safe during execution. That will permit codes, but without the trainer you won't have port access. The trainer is a different matter, and you may need to use the reduced trainer (aka PerfectTrainer) in order to avoid a conflict with the pre-reboot segment. Here's the clincher though: most 64DD combo games don't test for, much less swap, the new disk info until past the menus. That means that in the meantime you could just upload whatever you wanted and completely bogart the whole system ;*) The IPL would require a slightly hacked version of the GS BIOS, or you could do runtime editting via the port now that we know the codes to access during the menus. Mostly you need to set a new boot vector since the IPL resides at a different address range.
Thanks for the explanation. I have to admit, I'm surprised that a Gameshark could use the N64's RAM to store it's (the Gameshark's) own routines in, I'd have thought that some games would use near enough all of the N64's RAM, making the Gameshark's use impossible. Hopefully Chilly Willy's Gameshark emulation (simulation?) code will provide all of the Gameshark functionality, but with the stability that the Gameshark lacked, plus more reconfigurability than a real Gameshark (plus since it runs on the Everdrive 64 it means I can use NTSC and JAP games (and their codes), unlike my real N64 + real games). BTW, is it true that there were some 8MB expansion paks, so that the N64 had 12MB in total, and this made hacking game codes for games that used high res. mode (and whatever other uses of the first 4MB of the 8MB expansion pak, since the game only expected a 4MB expansion pak) easier and more reliable, since the Gameshark used the last 4MB RAM, leaving the first 8MB for the game? I'm sure I read this somewhere once, but I've never seen them mentioned elsewhere, let alone for sale. BTW, I had to look up the words "finnagle" and "bogart", so I've learned something else new!
I've had bad luck with 3rd party stuff in the past. When Zelda MM came out I needed one and tried Mad Catz. MM game was freeazing a lot. I reseated the RAM, still freezing a lot. I took it back for exchange, less freezing but still froze at random. Took it back and got Nintendo branded. No more problem. 3rd party RAM pack is crap shoot, sometimes you find one that works fine. Sometimes it's crap.
The way the GS is coded it doesn't take the detected rdram size and subtract from it. If a theoretical 8MB or 12MB pak existed (never seen one at least) it wouldn't take advantage of it. They hardcode pretty much everything, although there are some codes to move some of the trainer's elements around. A HUGE thing to note though is that some 1st party and some 3rd party games would, since their memory allocations are based on fractions of detected memory or relative to detected size. So, believe it or not, there would be some advantage to producing them. If you remove the tabs from the dust cover or plug a japanese game into a GS it would work on either a US or japanese console. The only difference is physical, not software-based. The GS can act as an adapter then, since the lack of tabs on a japanese cart doesn't prevent it from fitting on top of the GS.
