SPONSORED LINKS
Backup units
The reaction to the Nintendo 64 chosen media to store games was not very well accepted by many people who believed that there were more advantages in the CD-ROM format. Cart games could not be copied and backupped so easily like Sony Playstation CD Roms, so Taiwanese and Hong Kong manufactureers started to develop backup units to solve the problem
The four Nintendo 64 backup units in wide use are the: Doctor V64 and V64jr by Bung, the CD64 by UFO Company, and the Z64 by Interesting Devices. All of these units are very handy for a Nintendo 64 user. Even though they were primarily designed to play pirated games, they have many other legitimate uses. Homebrew development is one. Not every aspiring game developer can afford the official Nintendo dev kits. With a backup unit, anyone can create their own programs and run them on the Nintedno 64. Also, cheat codes and save management are two other widely used features on backup units. Another legitimate use (but still one Nintendo would not like you to do) is to play import game cartridges, which are normally hardware locked-out by Nintendo.
Backup unit users are really not all the scumbag pirates that Nintendo would have you believe. People that have spent money on a backup unit also must own a real Nintend 64, and thus are much more likely to buy original Nintendo software than people who download entire GoodN64 collections. Typically, backup unit users are a more tech-savvy crowd than the typical consumer, and thus they are the people that can benefit the most from having access to the neat features that backup units offer. In addition, Nintendo benefits from having a homebrew development scene and having more people familiar with coding for its console. Nintendo would not agree with this, but I firmly believe that a backup unit is just one more reason to own a Nintendo 64, and thus helps Nintendo more than it hurts in the long run, as a console's install base is much more important than individual game sales ever will be. This is completely shown by Sony with Playstation and the ease of copying games on that platform. Would have been difficult fo Sony to develop some proprietary (uncopiable) media like Nintendo's GameCube?
Also, the Nintendo 64 backup-scene (main hub at www.dextrose.com) employs many talented coders and intelligent individuals who are dedicated to advancing the Nintendo 64 and helping each other.
Problems encountered with backup units
Unfortunately for the user, Nintendo learned their lesson with the ease of use and wide proliferation of the Super NES backup units. This time, they knew what was coming, and intentionally made it difficult to operate a backup unit to play pirated games. Here is a summary of the problems a user might face, and the workarounds.
Boot chips. The N64's lockout scheme employs quite a few different boot chips (called CICs) that reside in the game cartridge, and unless the CIC provides the correct response to the Nintendo 64, it will refuse to boot the game that is inserted. So, without a proper CIC at all, the Nintendo 64 will refuse to boot. This is also a problem, say, if you are attempting to boot your backup device with a cartridge that has a NUS-CIC-6102 bootchip, and the program that you are attempting to boot uses a different chip, such as a NUS-CIC-6105. Since the boot code in the 6105 program image does not work with the 6102, the Nintendo 64 will not allow the program to run.
A NUS-6105 Boot CIC
At the beginning, each game with a different bootchip would be cracked in order to work with a different boot chip (Star Fox 64 was the first game to use a different boot chip than the standard 6102), but as the games with alternate bootchips grew in number, this process soon became tedious, and sometimes the cracks would not work 100%, causing crashes or save problems.
The solution that Nintendo 64 scene members and backup unit BIOS developers came up with is called the boot emulator. This is a program that is loaded into Nintendo 64 RAM and executed before the emulated cartridge ROM is accessed. It needs a 6102 cartridge to run (since it has its own boot code), and the result of the boot emulator will be that the Ninetdno 64 is soft-rebooted, and the cartridge data is available to the Ninetdno 64 regardless of the bootchip it was designed for.
There are boot emulators that have been created by scene members for individual bootchips, but these are of little use now. LaC (Andy Cunningham), one of the foremost contributing members of the Ninetndo 64 scene, developed in 2000 a Universal Boot Emulator, which is able to boot almost any Nintendo 64 cart. This makes it quite easy for a backup unit to run almost any game, as only the Universal Bootemu has to be loaded first.
Another feature of some backup units is that they have a boot emulator built into the BIOS of the unit, a program that is already running on the Nintendo 64. The Z64 and CD64 have this feature when working with the on screen display. As a result, you can seamlessly load any game that works with the built in boot emulator of the BIOS. Even when you run across a game that you cannot boot with the BIOS boot emulator, you can either use the universal boot emulator by LaC, use a game-specific boot emulator, or use a crack that replaces the boot code in the program image.
So, to sum up, if you are having problems running a program on a backup unit, check to make sure that your boot cartridge has the same CIC chip as that of the program you are booting. If not, you must find a crack for it, or use a boot emulator that is either a file that is loaded separately from the game, or built in to the BIOS of the backup unit.
Also, if you have a Doctor V64, you must use an "Emulation Adapter" to prevent the Nintendoo 64 from reading the ROM from the cartridge. Otherwise, the Nintendo 64 will simply boot the cartridge and ignore the backup unit. Other units prevent any access to the cartridge ROM by the Nintendo 64, and pass through only the CIC and save lines.
The other significant problem to playing backed-up Nintendo 64 games is the save chip. There are five different types of data saving in Nintendo 64 games: EEPROM (512 bytes), 4X EEPROM (2Kbytes), SRAM (64Kbytes), FlashRAM (128Kbytes), and the Controller Pak (256Kbytes). The Controller Pak plugs into the Nintendo 64 controller, and is the easiest to deal with. All of the other chips are built into individual game cartridges, and thus require specific support to be handled by a backup unit.
In a nutshell, if the save type of the game that you are using is not emulated internally by your backup device (like the Z64 and CD64 do), you must use a boot cartridge with the proper save type, a Protected Cartridge Decoder (PCD) that UFO sells in order to mix and match boot and save types, or find a crack for the game that changes its save type.
The first option is easy. Find the save type that the game you are loading uses from this page. Then use the following chart (recommended by many) to find out what cartridge to use, if you can use a boot emulator for the game:
4KB EEPROM - Super Mario 64
16KB EEPROM - Star Wars Episode 1 Racer
SRAM - Mario Golf
FlashRAM - Command and ConquerIn this case, remember that each game you run will overwrite the save data with its own. So make sure to use the appropriate utility for your backup unit (SRAM Manager for V64, EvekII for V64jr, Ghemor for CD64) to transfer the data to a controller pak or to your computer, for later use. Z64 is not affected by this problem as it saves directly on the Zip Disk.
If you decide to use a PCD (Protected Cartridge decoder), you insert the cartridge with the boot chip that you want in the slot that is straight out from the PCD's "cartridge" insert, and the cartridge with the save type that you want in the slot that forms a 90 degree angle with the card. This device was created because the CD64 cannot boot at all with a non-6102 host cart. It allows access to the boot CIC of the cart that is facing down, while redirecting ROM and save chip access to the cart that is at the 90 degree angle. So for instance, if you wanted to play Perfect Dark, which has a 6105 boot chip and 16KB EEPROM, you could place another 6105 cartridge in the straight slot, and Star Wars EP1 Racer in the 90 degree slot, and use the contraption to boot a V64jr or Z64 without a boot emulator and with proper saving. (This won't work on a CD64, since it requires a 6102 boot cart.)
The last option is to find a crack for the game that has problematic saving. LaC made a series of cracks for FlashRAM games in particular to save to SRAM instead. This makes it much more convenient to use on a CD64 or Z64, which have built-in SRAM management, but can't handle FlashRAM and would otherwise need to use the PCD on the CD64, or have a boot cart with FlashRAM on the Z64.
The final problem facing us is software protection built into the programs of some game cartridges. These protections, mostly on games from RARE company, generally check the boot chip after the game has booted in order to see if it is really what it claims to be. If you are using a boot emulator, this check will fail, and the game will do whatever weird things it is designed to do.
In Jet Force Gemini, the game will boot, but you will not be able to run, jump, or shoot.
In Banjo Tooie, the game will not completely boot under a boot emulator, and furthermore will not save unless a real 4X EEPROM is present.
Donkey Kong 64 was reported to have problems, but according to fab, the problems were all related to a bad dump.
Software protection can only be gotten around in two ways: using a crack to defeat the protection, or using a boot cartridge that actually has the real boot CIC of the game you are booting. (These games all have 6105 boot chips) Luckily, only a few games have this sort of protection, and cracks exist for most of them.Click on the images for detailed info / downloads / mods for the various Backup Units
