This page is about the Nintendo 64 game console. It has information about the following topics:
The Nintendo 64, originally known as the Ultra 64, was released in the US by Nintendo in 1996. It was Nintendo's third game console, and the first one on the market with a fully 64-bit CPU. (The Atari Jaguar, though advertised as 64-bit, had a 16-bit main processor.)
The Nintendo 64 has the following hardware:
The RCP is a powerful multimedia processor that handles the 3D rendering and sound output for the console. Its display capabilities are comprised of two parts: the RSP (Reality Signal Processor), a microcode-upgradable vector and audio processor, and the RDP (Reality Display Processor), the texture mapping unit and framebuffer device. A vector processor such as the RSP is one that can operate on many sets of data in one pass, which makes it ideal for crunching the linear equations that are used in 3D polygon setup.
The MIPS R4300i CPU has a 64-bit execution unit and a 32-bit data path. Thus, it is able to perform complex 64-bit calculations in full stride, while maintaining interface compatibility with 32-bit peripherals that are in mass production. According to an online magaizine, the N64 can execute 125 Dhrystone MIPS and is rated at 60 SPECint92 and 45 SPECfp92.
The N64 is an interesting machine because it is the most powerful console that is based on cartridge format. This could be a blessing or a big problem, depending on how you look at it. On one hand, it is free of the load times that plagued CD-ROM based consoles such as the PSX and Saturn. It is also extremely difficult to damage the media. However, ROM chips used in cartridges are quite a bit more expensive than CD-ROM discs. This caused the price of most N64 games to be in the $50-70 range as opposed to the $30-50 range that PSX and Saturn games sold for. It also limited the size of the cartridges; the average N64 cart was 128 megabits to 256 megabits (16-32MB), and the biggest N64 cartridges made were 512 megabits (64MB). So there isn't much room for voice acting or cutscenes.
However, many people (myself included) believed that the N64 upheld Nintendo's traditional values in its design. It was designed to play games; not interactive movies, or have lots of glitzy cutscenes to attract people impressed by such things. The cartridge format provided instantaneous action; the four controller ports and memory pack interface meant that it was a piece of cake to organize 4-player get-togethers with friends. And the cartridge saving meant that we didn't have to worry about losing the contents of our memory cards on most Nintendo-developed games.
Since Nintendo wasn't interested in impressing the layman through multimedia, it focused on creating some of the best games ever, and it succeeded exquisitely. Unfortunately, the N64 proved in the end to be a market failure, showing once again that good engineering and a passion for gaming does not necessarily win the market.
Here is a neat little invention to come out of Hong Kong. The Tristar 64 allows you to play Super NES and NES games on your N64. Unfortunately, the video quality is sort of poor, and it won't play SNES games that originally had a coprocessor on the cartridge, but it can be found pretty cheap now.
Here is a mirror of Zaphod's Tristar 64 pictures, and a dump of the Tristar 64 BIOS.
One of the greatest things about the society we live in today is the balance of forces. For every action, there is an equal and opposite counteraction. The reaction to the N64 was lukewarm for many people who believed that there were more advantages to the CD-ROM format, and were irate at the high prices that Nintendo charged for its games. Thus, the console got a number of Taiwanese and HK manufacturers to build units that would interface with the N64 console and emulate a game cartridge that wasn't really there.
The four N64 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 N64 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 N64. 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 locked-out from the N64 booting them.
Backup unit users are really not all the scumbag pirates that Nintendo would have you believe. As CrowTRobo of Obsidian would agree, the people that have spent money on a backup unit also must own a real N64, and thus are much more likely to buy original Nintendo software than the idiots who swarm around the N64 emulation "scene" and 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 N64, 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.
Also, the N64 backup-scene (main hub at www.dextrose.com -- I'm known as "runderwo" over there) employs many talented coders and otherwise intelligent individuals who are dedicated to advancing the N64 and helping each other. This is the kind of partnership that you will never see in the N64 emulation world, as the people are typically lame consumers looking to score a free game and not caring about anything else.
That said, I really do think that backup units are neat toys and are worth investing in, at the price of only a few game cartridges.
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 N64, it will refuse to boot the game that is inserted. So, without a proper CIC at all, the N64 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 N64 will not allow the program to run.
At the beginning, each game with a different bootchip would be cracked in order to work with a different boot chip (according to fab, Star Fox 64 was the first US 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 N64 scene members and backup unit BIOS developers came up with is called the boot emulator. This is a program that is loaded into N64 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 N64 is soft-rebooted, and the cartridge data is available to the N64 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, one of the foremost contributing members of the N64 scene, developed in 2000 a Universal Boot Emulator, which is able to boot almost any N64 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 N64. 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. The CD64 boot emulator seems to boot more games successfully than the Z64 boot emulator. 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 N64 from reading the ROM from the cartridge. Otherwise, the N64 will simply boot the cartridge and ignore the backup unit. Other units prevent any access to the cartridge ROM by the N64, and pass through only the CIC and save lines.
The other significant problem to playing backed-up N64 games is the save chip. There are five different types of data saving in N64 games: EEPROM (512 bytes), 4X EEPROM (2Kbytes), SRAM (32Kbytes), FlashRAM (128Kbytes), and the Controller Pak (256Kbytes). The Controller Pak plugs into the N64 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 to find out what cartridge to use, if you can use a boot emulator for the game:
4KB EEPROM - Super Mario 64, or DX256 SuperSaver 16KB EEPROM - Star Wars Episode 1 Racer SRAM - Mario Golf, or DS1 FlashRAM - Command and Conquer
In 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.
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.
However, Rocco submits the following:
PS, about that Donkey kong 'problem'. Yes, the first release was a bad dump. However, the good dump was released and TK (CZN) did a crack. However he missed a protection that "wiped" the save when you got a certain distance into the game. We never saw titanik again. A year later, LaC released a similar crack. This crack ALSO missed the sneaky protection that wiped your save later in the game. A week later, LaC released another crack, this time it was 100% working.
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, to my knowledge.) Luckily, only a few games have this sort of protection, and cracks exist for most of them.
I own both a Z64 and CD64, and have used a V64jr in the past. I will attempt to explain what is good and bad about all these units, from my knowledge.
**You can find schematics for the CD64 Parallel Port Adaptor (PPA) here, or here as a tarball. Thanks chrism.
**Go here for CD64 troubleshooting and miscellaneous CD64 tech info.
The CD64 was developed by UFO/Success Company and released in 1998. There are a few different versions of the CD64 unit. The original CD64 had a black case, and shipped with 128 megabits of RAM. Eventually, UFO began shipping the CD64 with 256 megabits of RAM, and called it the "CD64 Plus". Later, some of the design was altered, and the case was changed from solid black to a translucent grey. These are the units that are still shipping today.
To begin with, many users have complained about low quality of the CD64, from units being DOA, to eventual problems that develop. These problems tend to be more prevalent in the earlier black units, though there are plenty of black units that are still functioning perfectly.
Anyway, with all the fixes mentioned in the CD64 help doc, you might think this is a pretty crappy unit, but the problems are pretty easy to solve, and when the unit is working fine, it is pretty nice to use.
The CD64 can load N64 programs from the CD drive (obviously) and accept sends via the parallel port. Using Ghemor by CrowTRobo, you can send or receive any save data or the cartridge ROM.
Since the CD64's BIOS runs as a N64 program, it requires a 6102 boot cart to even power on. Normally, this means that you would only be able to load 6102 programs, but fortunately, the CD64 BIOS has an excellent boot emulator built-in that will boot nearly any game with no problem. The only problem I have encountered is that occasionally a 6105 game will not detect the expansion pack. Usually this can be gotten around by re-loading the game and attempting the boot again. For Perfect Dark, however, you may have to use LaC's universal bootemu. Otherwise, the CD64 automatically detects the bootcode for a given game and runs the proper boot emulator, so the loading process is completely transparent to the user.
The CD64's save management is not a problem either. It will save EEPROM, 4X EEPROM, and FlashRAM directly to the boot cart if the boot cart has the correct save type. In addition, it comes with an SRAM Manager that will allow you to transfer SRAM to and from your controller pak and a cartridge with SRAM. (Thanks CrowTRobo.) Using Ghemor however, it is trivial to back up and restore any type of save information to and from your PC.
The CD64 also has a built in PAL-fixer. I would say that 99% of all games boot and save on the CD64 without any intervention besides matching the save cart.
One drawback to the CD64 is its susceptibility to software protection. Since it relies completely on a boot emulator to boot non-6102 carts, any carts that have software protection must be cracked, since it is physically impossible to operate the CD64 with the proper boot chip for protected software. Fortunately, these games are few and far between.
The CD64 also tops out at 256 megabits of RAM. While this is fine for the vast majority of N64 games, some games such as Conker's, Mario Story, Ogre Battle, all Pokemon games, and Resident Evil 2 will not work on the CD64. This really isn't a big deal, and most of these games are worth buying anyhow. (besides Pokemon, hehe). However, the CD64 is capable of dumping >256Mbit carts through the comms port with Ghemor, even though it can't play them.
Read this post from CrowTRobo on Dextrose to find out why the CD64 will never support 512Mbits in any way, shape or form.
Also, parallel port sends are quite slow, and will take 5 to 10 minutes for a 256Mbit game. If you're not using Ghemor, the original cd64comm utility is pretty bad at dropping sends.
Right now, the CD64 is unique in that it is the only N64 backup unit still being sold and supported. You can buy one at www.cd64.com.
I would summarize the CD64 as the hacker's unit. It's not something I would suggest to a friend to buy, but I would not trade it for any other unit to do development or game hacking with. The CD64 is definitely best used with a PC nearby, for save management and cart dumping.
Here are high-quality scans of the Z64 HW2.0 manual (warning, 300-400K apiece):
 |
 |
 |
 |
Also, the Z64 HW2 manual in M$ Word format here.
The hard to find unofficial 2.18 BIOS for the Z64 is here. Blame Zaphod if it hoses your box, he sent it to me.
Here is fab's unofficial Z64PATCH.DAT that should properly crack/fix all USA games to play on the Z64.
Here is Zaphod's method to add a hard drive to your Z64 without making a mess.
The Z64 is manufactured in Taiwan and was distributed in the US by Harrison Electronics. It uses a Zip drive to store and load cartridge and save information. The system is based around a i386 compatible computer; the Z64 BIOS is actually an image of a FAT filesystem, and it boots an MS-DOS clone internally. Thus, it is pretty trivial to hack, and people have produced upgrades to the BIOS that add hard drive support or support for other removable drives like the Orb. The program Z64.EXE operates the on-screen display and loads the BIOS into memory for the N64 to access if it is turned on.
The Z64 came in three models, referred to as HW1, HW2, and HW3. HW1 only supported 128Mbits of DRAM. HW2 upgraded to 256Mbits of DRAM, and HW3 simplified the design in order to lower the price to 299.00 from $399.00US.
A Zip disk can hold approximately 750Mbits of information; that is, it just barely doesn't have enough room for three 256Mbit images.
One word that I would use to sum up the Z64 is "convenience". The Z64 is extremely easy to use. It has a nifty LCD display that you can use to load a game before the N64 is powered on, or to load a boot emulator or back up the cart in the slot (in case it is not a 6102 cart). In addition, if you turn the N64 on before loading a game, the Z64 has a nice BIOS menu that runs as a N64 program, like the CD64 BIOS. (You can only use the Z64 BIOS menu with a 6102 boot cart though.) In this case, you have a small advantage over the CD64, since you are not forced to operate with a 6102 boot cart only; you can choose whether to use the BIOS or operate the LCD menu depending on what you want to do.
The Z64 also has a boot emulator built into the BIOS like the CD64, and can boot most games regardless of the host cart. The hacked 2.18 BIOS uses code from LaC's Universal boot emulator, and corrects problems with some 6105 games not detecting the expansion pak.
In the Z64 menu, you can set up options for each individual game, such as what boot chip it uses, slowdown function, tell it to redirect controller pack saves to the zip disk (for transfer to PC or copy to friends), or to PAL-fix it. The information is saved in an INI file on the zip disk. You can also set global options that are stored in the eprom of the Z64, like automatic patching, cheat loading, saving, etc. File management is pretty easy too, you can copy programs to another Zip disk, delete, and such.
Saving is handled by redirecting the save to the zip disk for each game. The Z64 can handle EEPROM, SRAM, and 4X EEPROM natively. However, SRAM and 4X EEPROM can be quirky. (Zelda Ocarina of Time will not boot without a crack, due to bugs in the SRAM emulation.) FlashRAM games must be cracked. The Z64 will attempt to download the first 64k of from a flashram cart, but this is only because the Z64 thinks it's actually handling SRAM. You can't depend on this "feature", and FlashRAM games certainly will not work with it. (Thanks fab.)
If you have automatic saving turned on in the menu, the save process is completely transparent and quite convenient. The manual claims you must use a boot cart with EEPROM in order to save EEPROM and SRAM games. This seems to work fine for the most part. There are the occasional SRAM and 4X EEPROM games that will need to be cracked. And FlashRAM games are best off being cracked.
Also, the Z64 can automatically load APS or IPS patch files for trainers, intros, or cracks. No more hand-patching on your PC, just name the patch file with the same base name as your program file (i.e. zelda64.rom, name the patch zelda64.aps or zelda64.ips depending on the type) and the Z64 will automatically apply the patch after loading the program. The Z64 can load Z64/CD64 format (big endian) files, and like the CD64, it can also load Doctor V64 (little endian) format files.
The Z64 is an extremely well-constructed unit. This may be due to the fact that it is built in Taiwan, where the CD64 and Bung units are built in Hong Kong and China. It is solid and looks very nice on top of your N64. It definitely does not have as many quality problems as the CD64 has had. (There was a problem with some HW3.0 units where a transistor needed to be replaced to correct freezing problems.) However, this quality does come at a high price.
The Zip drive is a standard PC ATAPI Zip drive, and can be easily replaced if anything goes wrong with it. The RAM is standard PC EDO RAM like the CD64, and can be replaced with standard type 72-pin SIMMs.
The Z64's biggest advantage is that there is literally no PC needed for most tasks. You can back up, copy, bootemu, save, delete, etc all from within the unit itself. Since the saves are on zip disk, there is no shuffling save data via the PC link. The only time I've needed to use a PC is for loading patch files for problematic games. (See below.)
Now for the bad. In addition to the transistor that may need to be replaced in some units, the Z64 also has a flaw inherent to its design. Since it sits on top of the N64, it completely blocks the vent on top of the N64 that would normally allow air to circulate. It also partially impedes airflow around the expansion pack. This combination is not good; the Rambus memory that the N64 uses gets quite hot, and when the expansion pack is being used and the N64 is being stressed concurrently, it's not uncommon to lose a game session to the N64 freezing up. Removing the cover from the expansion pack slot seems to have helped with my Z freezing up, but I can't make any guarantees. If anyone has any ideas on how to improve this situation, I'm all ears.
The Z64 supports 256MB only, like the CD64. Obviously this is only a problem for a few games, so it's not that big a deal. Also like the CD64, it can dump >256Mbit carts, even though it cannot play them.
No PC connection. Unfortunately, there is no way to connect a PC to the Z64 at all. So doing things that are possible with the CD64 like editing memory, running a debugger, downloading save information directly from a cart, etc, are not possible. This may or may not be a big deal. Personally, it's a trade-off between simplicity of use and flexibility between the Z64 and CD64. The Z64 is designed to be operated by a couch potato, where the CD64 will require some computer knowledge and manual intervention to get the most from.
At $399.00, dropped to $299.00 at HW3 revision, the Z64 has always been the most expensive unit. Even the upgrades from Harrison were expensive. You might say that there is a price to pay for quality, but price alone may warrant the buyer to look elsewhere. (The CD64 is less than $200.) I'm not sure if I would ever have gotten a Z64 if I hadn't found a HW3 being sold for $100. :P
All in all, I would summarize the Z64 as the ideal playtime or living room unit. It's very portable, works well for almost all game-playing tasks, won't break down easily, and is brain-dead easy to use. The only real drawbacks relate to the price, and the lack of a PC connection, which was by design anyway.
The V64jr was the successor to the Doctor V64, both manufactured by Bung. It is a simple device, shaped just like a N64 cartridge. It has a slot in it for the boot cartridge, a connection for PC link, some EDO DRAM inside, and an Altera ASIC. The memory is backed up by 6 AA batteries and can last up to 8 hours or so without N64 power.
The V64jr's main advantage at the time it was being manufactured (Late 1999) was its price. For $179 you would have the only device capable of playing 512Mbit carts. (Z64 and CD64 can back them up but not play them.) In addition, it's the most portable backup unit, as it's basically just a bigger and taller N64 cart. Since the unit does not have a BIOS, you are not constrained as to what you load onto it. Using the excellent EvekII by WT_Riker/Obsidian, you can load a ROM and simultaneously crack it, PAL-fix it, load your previous save, and retrieve the save when you're done.
However, the drawbacks start to mount when we examine the V64jr closely.
Again, like the Z64, the V64jr's main drawback is by design. As the Z64 was designed to be used completely without a computer, the V64jr _requires_ a computer. This can be inconvenient if your computer and N64 room are nowhere near each other. Also, if you're at a friends house, you only get to bring 1 game with you on the V64jr.
Another annoyance with the V64jr is load time. Since you dont have the choice to load from media such as CD or zip, you have to wait for the parallel transfer on EVERY load. This gets old quickly, especially when you're trying different patches to try to get a certain 256Mbit game to run. V64jr is definitely not the most optimal unit for playing games on, and this is where the CD64 has an advantage: it has nice dev features, but is also very usable for gaming time.
Also, due to the V64jr's cost-cutting design (you'd swear you're holding a toy), we have the same sort of problem that the CD64 related to passive components. I'm not sure of the exact problem, but there is a mod posted on Dextrose that takes care of it. It doesn't help that Bung is no longer in business, so there is no way to get a V64jr repaired in case you would have problems with it.
In the end, the V64jr was a great buy in its day, but it's difficult to recommend one now, especially since they are selling for almost $300US at online retailers. If you come across one cheap, go for it, but I would recommend a CD64 over the V64jr for hacking and overall flexibility, given the current price points.
However, the V64jr has one advantage over the rest -- it's the only unit that will play 512Mbit carts. The list of 512Mbit carts is:
In reference to V64jr send times, hcs writes:
As for V64jr send rates, I pulled up the results of an old experiment I did:
First, I took a byteflipped (.v64) Resident Evil 2 rom (64 MB) and sent it with both evek and DrJrWin2.0 twice. The average time for DrJrWin was 97.5 seconds and for elim 87.055 seconds. This works out to 672.16 kB/s for DrJrWin and 752.81 kB/s for elim.
Then, I took a byteflipped zelda 64 rom (32 MB) and sent it twice with both programs. The average time for DrJrWin was 45.4 and the average time for elim was 44.105. The speed for DrJrWin was 720.18 kB/s and the speed for elim was 742.95 kB/s.
*Then* I took a non-byteflipped (.rom) version of the zelda 64 rom (32 MB) and sent it. For DrJrWin it took an average of 46.5 seconds and for elim it took an average of 44.685 seconds. DrJrWin transferred at 704.69 kB/s and elim transferred at 733.31 kB/s.
DrJrWin2.0 average transfer rate: 699.01 kB/s Elim average transfer rate: 743.02 kB/sElim enjoys a 6% speed advantage over DrJrWin.
Note that I used my own figures for the elim speed calculation. It calculates its own speed, but it is rather higher (by about 100 kB/s) than mine. Maybe its is more accurate . . .
aleste adds:
timethis DRJRDOS castle~1.n64 TimeThis : Elapsed Time : 00:00:20.540 timethis JRSEND castle~1.n64 TimeThis : Elapsed Time : 00:00:19.550 timethis ELIM castle~1.n64 TimeThis : Elapsed Time : 00:00:17.140 timethis ELIM castle~1.n64 --nocrc TimeThis : Elapsed Time : 00:00:16.100 timethis start /w wjrwrite /send castle~1.n64 TimeThis : Elapsed Time : 00:00:18.350
(Castlevania 64 is a 128Mbit image in ABCD [big-endian] format.)
The overall best N64 backup unit, given price, flexibility, features, and support, appears to be the CD64. At the lowest price point, it has something for coders, cheats, pirates, and gamers, and really there isn't much that it isn't capable of doing well.
Is the CD64 best for you? Not necessarily. Remember that due to the quality concerns, there is a reason that you are paying less. Compare the CD64 to buying an Apex DVD player at Walmart, compared to a Sony at Best Buy. Yes, it's got a lot of great features at a low price, but you have to be ready to put up with possible problems. If quality is your top concern, I would suggest trying to find a Z64 instead. However, be sure that you can have a guarantee that it works fine, or else you might be getting a "freezer" that Harrison won't fix for you anymore.
That's it. Hope I got all the facts right.
If you are an official Nintendo developer, go to warioworld.com.
I wrote a library called libcd64 which is now part of uCON64. It provides access to the CD64 through any known mechanism and is portable to any system. It can use either the CD64 BIOS or Ghemor as the CD64 slave. Still in progress is a CD64 debug stub for gdb.
Tototek's N64 flash cart was never released due to developer failure, which disappointed me. Also creating a free firmware for the Z64 once I figure out how to program the Z64 from the N64 side.
Another thing I'm messing with currently is adding functionality to libn64, which should eventually be an open source replacement for libultra, the proprietary library developed by Nintendo and SGI that nearly all commercial N64 software is linked against. Once some more core functionality is in place, we can begin adding RSP support to it based on source code from N64 emulators, and enable some real 3D homebrew action.
A last project I'm messing around with is getting a Linux kernel to boot on the N64. This may not be as crazy as one might think at first: it would make coding and debugging trivial with standard GNU tools. The hard part is getting console input into the N64. I believe it will be possible to do via serial console, connecting one of the controller ports to a host PC through a Wishtech Adaptoid. (This depends if it is possible to have low-level access of any kind to the SI interface; the PIF may be in the way.) It would also be possible to set up a SLIP network connection through the Adaptoid and log into the N64 that way. The N64 could NFS-mount a filesystem on the host PC. If the SI cannot be accessed so directly, then a method of controller-based keyboard input could be devised, and a cramfs can be used as root. Difficulty is the lack of system memory on the N64, a maximum of 8MB doesn't leave much to work with especially with a ramdisk. You could have a large filesystem in ROM, but only a small portion would be cached in RAM. Exaggerating this problem is the fact that MIPS binaries are quite large, even though we don't use 64-bit pointers on the N64. Executable compression may help here. One could swap onto copier memory if it is available....
More documentation and more time is needed. :-)
If you are looking for N64 ROM images, go here. This N64 ROM image collection is second only to TCSR. (Note, this site is a joke)
Blame Zaphod.
Here are some high quality scans of the N64 Jumper Pak. It is a terminator for the RAMBUS memory in the N64 and is composed of some resistor packs and SMD capacitors. [front] [back]
Here are all the mirrors of sites that I've collected. You can also download tarballs of each individual site.
Thanks go out to all of the crew at Dextrose for making the N64-scene such an enjoyable and honorable place, even after 5 years now! There is hardly anywhere else on the web that is so free of lameness these days.
Thanks to all the releasers who made the N64 scene alive in its early days. (You can see an archive of release .nfo files here, or download them all in one zip file here.
All the N64 scene coders: LaC, CrowTRobo, WT_Riker, Titanik, Wildfire, Lemmy
The "tech support" crew at Dextrose: _kid, fab, handy/Sarah, CTR again, Onnichiwa
Those guys that you just couldn't do without: PeRoY, Hectic, SJoS, arrid, the doctor, aleste, Zaphod, erm...Schweino, <your name here>
And the rest of the oldschool N64 crowd: Actraiser, JL_Picard...
...and most of all RedboX -- the single handed champion of the N64-scene! Without his endless contributions, it'd be difficult to imagine where we would be today.
You may freely redistribute any information on this site that is authored by me according to the following license. Please credit either myself or www.dextrose.com if you reuse portions of this site.
[an error occurred while processing this directive]
