SHOW / HIDE

How to Fix/Tweak Out your CD64

Hardware Problems

**If you think you have bad memory, run the CD64 Tester to help figure out what is going on. Checksum errors, send errors, glitches during play, and dumping errors are all symptoms of bad or dodgy memory.

Doesn't run at all. Actually, this is a common mistake. The CD64 manual indicates that it can run using only the power supply from the N64, with no need for an external supply. This was true with earlier units (to a limited extent, many people had problems anyway), but will not work at all with the newer units. So, you will need an external 12V 750mA power adapter to power the CD64. The CD64 takes the 12V input and uses it to supplant the 12V rail it gets from the N64 power supply, when the N64 is turned on. When the N64 is turned off, the 12V rail does not operate (so you can't use the CD), but the 5V rail is still in operation, so that the EDO DRAM is powered and the program in memory is saved until the next power-on session. The fact that the CD64 is converting a 12V input to 5V through a simple transistor leads up to another problem, discussed shortly.

Another possible cause of the black screen:

SteveT writes:

Thanks for everyones advice. I took the thing apart and made sure everthing was tight and I beleive what was wrong was it was not setting right on the cd64 and the connection was loose, I widened the connectors on the cd64 so it had a better connection and it is working now. I am keeping my fingers crossed.

and CrowTRobo responds:

Yes, anytime you just get a black or green screen when you turn on your cd64, it's most likely due to a loose connection. Just press down on the N64 and turn it back on again.

Shows 0Mb RAM or does not access CD. This is very common. There is nothing to secure the memory or the drive cable in the CD64, so when it gets bumped around in shipping, these things tend to come loose. Fortunately, it is trivial to open up your CD64 and re-seat the memory and IDE cable. This alone fixes most CD64 problems that occur after shipping.

Bad solder on power supply. The power supply connector is your typical AC adapter connector (takes 12V input). However, there is poor quality soldering on some CD64 mainboards where this is attached, and as a result, the CD64 gets no power or intermittent power. This is pretty easy to fix too, just reflow the solder and get it seated right.

Overheating. This can be a difficult problem to solve, and is a function of the CD drive that is in your CD64 mainly. The problem is that the CD64 uses cheap regulators to regulate the voltage delivered to the 5V parts of the unit. The regulators simply take the excess voltage and discard it in the form of heat. When the CD drive is running, it is pulling a lot of current through those regulators, and they get pretty hot. Eventually, depending on your unit, it can get hot enough to bubble the PCB and cause solder joints to crack up. The 12 volts from the power supply is just too much to passively regulate to 5V without creating a large amount of waste heat. In addition, even when the unit is not being used, it is drawing current on the 5V rail to keep the EDO memory refreshed, so it doesn't necessarily even have to be in use for heat to be a problem.

There are two easy solutions to this.

One last problem relates to the PAL chips that implement the parallel interface. Some people in the past have had problems with the original units dropping sends or not responding at all through the communication port. The solution was to contact UFO for a set of GAL chips to replace the PALs that were originally used (and were damaged), which fixed the problem.

If you are attempting to change the memory in the CD64, be aware that not all memory will work in it. Best thing to do is have access to a lot of different EDO SIMMS, to be able to try a whole mess of them at once. Also remember to run Garth Elgar's memory tester to ensure that the memory has no timing difficulties or any other odd problem. You need EDO 5V 72-pin SIMM memory, 60ns or better, in size from 8MByte to 32MByte. No other type will do.

As well, if you are changing the CDROM drive, be aware that not all CD drives will work. Compatibility is a lot more likely than with the memory, but it's not a given. I have used a Toshiba 32X, an Afreey 50X, and an Afreey 56X drive with no problems in the CD64. The Afreey drives work well and read CD-RW ISO9660 discs without issue.

Other things you should be aware of

You must use a 6102 boot cart. The CD64 will not boot with any other cart. If you need to dump or save onto a cart with a different bootchip, you will need to use a PCD. It is not possible to run the few games with software protection (Jet Force Gemini, Banjo Tooie) without a crack.

About cart dumping errors, Qcoder writes:

I can confirm what was said about dumping carts on the CD64. Especially with Mario 64. I can never get it to dump that cart correctly. The problem is not the RAM. Most likely it's the connection to the cart being too long and/or too electrically noisy. I think the newer roms have better tolerances because it will dump newer carts okay. But not my year-1996 Mario.

More tech info; CrowTRobo writes:

The SROM that the CD64 refers to is where all the settings (I think the Xterminator codes too) are saved. I don't know what the actual chip is though, I'm guessing it's the latter, another eeprom.

The BIOS accesses the comm port, cd-drive, etc. through "registers" that are just N64 memory locations (0xb78xxx??). For specifics you can check out the CD64 memory map on the CD64 site. I'm assuming the Altera chip handles those accesses, so when you write a byte to the comm port out address, the Altera chip kicks in and sends it out.

To get Garth Elgar's CD64 Tester to work properly on a NTSC display, use PALadin to "fix" the image to MPAL. PALadin thinks the image is NTSC already because Garth Elgar used bootcode from USA Mario 64, but his code sets the video mode to PAL.

The CD64 BIOS image does not contain boot code (as it is copyrighted by Nintendo). From 0x40, it has FFFF's in place of the boot code. This is because, Qcoder writes:

The CD64 doesn't have any bootcode from 0x40-0x1000; instead this memory area is mapped to the bootcart.

The reason non-6102 carts don't work is due to the checksum being wrong.

Theoretically, then, you could inject other bootcode into the CD64 BIOS image, fix the checksum, and zap the bootcode to FFFF again, flash the bios, and then you could use a cart with a different boot chip (like 6105) to boot the CD64 instead. Note that this has not been tried, and you'd better have an EPROM burner around if you do decide to try. :-)