HyperHacker
07-08-2010, 03:18 PM
I just picked up a "broken" CD64 (HW rev 1.3, BIOS 1.30). After some testing it became evident that A) the drive was dead and B) it seems to have some sort of power supply issue.
I can get it working , but it's extremely finicky. I have to use a process like:
1) Power on the unit, and wait for the drive's access LED to go out.
2) Attempt "Load CD64 File". This will fail, but gets the drive to spin up.
3) Wait no less than 7 seconds, then attempt again. This time it usually works and will load the game.
What has me baffled is the power issue. There doesn't appear to be anything wrong (no voltage fluctuation I could detect, components look OK), but if I simply plug the drive in normally, it will never spin for more than a few seconds, making it unable to load games. (With luck it might read a megabyte before erroring out.) If I power the drive from an external 12V supply and follow this process, it works fine. (Except it only lists the first 28 games on the disc - crappy software, I suppose?)
(I did of course try several disc drives, and lower speed settings. BTW, despite what some say, mine works fine with a DVD drive, though only reads CDs.)
Anyway after reading everything I could find, experimenting with it a bit, and examining the board and specs (some official hardware info is under "circuit" here (http://n64.icequake.net/mirror/www.cd64.com/)), I figure I could turn this into a nice dev unit.
My first concern is the 32MB ROM limit. Looking at the specs, the unit maps all of B0xxxxxx-B7xxxxxx to RAM - that's 128MB. Apparently the only reason for this limit is the way the unit maps its I/O - in mode 0 (menu mode) only the lower 32MB of RAM is mapped, and you can't write to it in mode 5 (run-from-RAM mode). It also doesn't look like you could ever switch out of mode 5 or 7 (the I/O range is now mapped to RAM/cart), but I'm told it can dump 64MB games, so that must be possible somehow...
Anyway I have numerous ideas as to how to defeat that limit, but since the unit only has 32MB installed, I can't try them until I can find a larger DRAM stick.
Looking at the memory map, only three modes are listed - 0 (menu), 5 (play RAM) and 7 (play cartridge). There's the possibility that one of the other modes might be useful. Since the board uses a big CPLD, perhaps it's also possible to reprogram that and create a mode which maps all to RAM but allows writing, and then simply switch back and forth, using the console's RAM as a temporary buffer.
Of course hacking the CPLD can be a somewhat risky move (and I don't have the tools), but another idea comes to mind: simply connect a switch to the upper address line(s) of the RAM. When open it functions normally, when closed that line is tied high. So you would load 32MB, flip the switch, load another 32MB, flip it back, and go. This could be done without any software hacking by breaking the ROM into 32MB files, or to the other extreme, the switch could be software-controlled. With two switches you should theoretically be able to load even 128MB ROMs (of which there are none to my knowledge).
If the DRAM address lines are not simply one to a wire (i.e. multiplexed somehow) then a simple switch won't work, but still it should be possible with some simple logic circuit to achieve this effect.
An even crazier idea is to power the RAM with a small battery, pull it out, plug it into a PC, and populate it there. Not exactly ideal, but hey, it's something. ;-)
Then there are questions of power. I'm not sure what's up with it but it seems like I need an external 12V power supply for the disc drive - with three power inputs now, it's getting awfully clunky, which is why I thought of building a new case for it in the first place (which then led to most of these other maniacal ideas). A PC power supply should have no trouble powering the console, CD64 board, disc drive, and perhaps a fan for that voltage regulator.
Furthermore, if the CD64 is no longer powering the disc drive, then I don't think it needs 12V at all anymore and so I could eliminate (or at least disable) the voltage regulator entirely and significantly reduce heat output. I don't think 12V is needed to keep the RAM alive, but the 12V from the N64 should be able to manage that. Or...
I'd love to attach a battery to the RAM. I have several around so it would just be a matter of connecting it in place of the CD64's power input, and building a charge circuit so the power supply can run the RAM and keep the battery charged when it's on. This shouldn't be especially difficult.
I couldn't help noticing, next to the unused video connector, two pairs of holes, L and R. These connect directly to the audio inputs on the cartridge connector. Basically every CD/DVD drive has analog audio outputs... enough said. The only question here is, are they always enabled, or does the game have to enable them? (Easily done with a Gameshark code probably anyway.)
Then of course there's that unused spot where a 44-pin connector would have gone (even still a removable cover on the case for it). The company's website says they originally planned to release an MPEG decoder add-in card to allow playing VCDs (thus the video connector). This connector could be very useful for mods. It seems to be a proprietary connector, and is oddly numbered - one side is pins 5-27, the other is 36-58; 1-4 and 28-35 are nowhere to be found.
I've been tracing it with a multimeter, but haven't got many sensible readings, probably because any address/data lines are going through the CPLD. I intend to toss together a small test ROM to help probe for those, though I'll have to look up how to either display video in a homebrew ROM (only done hacks before, never dealt with video directly) or break into Mario Kart's opening routine (where I can easily use the game's built-in text routines). The built-in memory editor won't do - I need to be able to read or write one byte, word or dword at a time at an arbitrary address.
I'm not sure how, but people have mentioned being able to load and run a ROM in mode 0, which would give it access to everything. Possibly just by loading it as a boot emulator (which has some unknown size restriction), or somehow switching back into mode 0 after starting. If nothing else, the built-in memory editor can edit main RAM, so I could patch into the menu program if I need to. From there, I can read/write arbitrary addresses and probe the connector to see what reactions I get.
Pins I know so far:
5: Video connector, "L-R"
6: Video connector, "composite"
7: Ground
17: /RD from cartridge connector (also connects to #OE of all flash chips)
26: Probably +5VDC
27: Probably ground
36: Video connector, "L+R"
37: Ground
57: /WR from cartridge connector (also connects to #WR of all flash chips)
58: Probably ground
Pins 7 and 8 of the video connector (Video Y and Video C) aren't connected to anything. 3.3V from the cartridge connector doesn't seem to go anywhere (you'd think at least to the actual cartridge?) None of these pins appear to be 12V.
This leaves 34 unknown, which is just more than enough for 8 data, 24 address. As it happens the memory map shows B1xxxxxx and B6xxxxxx as reserved, so it's entirely likely one of those maps directly to this connector and would have controlled the MPEG decoder. The other two could be clock and reset?
I've been working from the assumption that the N64's EXT connector is identical to the cartridge connector, which seems to be panning out so far. (I'd have to wonder how you could have both the 64DD and a cartridge plugged in - some software magic, I guess?)
I'm not sure what all I'd use this connector for if I mapped it out, but probably I'd hook up a microcontroller to work as an address decoder, which offers virtually infinite possibilities. Two ideas I'd definitely like to implement are some general-purpose switches (think GS Button on steroids) and LEDs, and perhaps a small LCD screen and/or some 7-segment displays. Ethernet and/or CF/SD would be badass.
Then there's the parallel port. Apparently this thing required some type of adaptor to connect to a PC. Looking at the schematic (http://n64.icequake.net/doc/cd64-ppa/parallelportadaptor.html), it looks like only some buffers and latches that would offer some convenience in the software design, but I'm no expert on ICs so I'm probably wrong. :) Either way, I'd like to either build this adaptor right in (is there any reason you'd want the port without?) or hack some code to work without it. The manufacturer was so kind as to publish a circuit diagram, showing which I/O addresses map to which pins, and it looks useful enough as it is for a GPIO port.
CIC is another thing to look at. The device requires a 6102 cartridge to boot (I suppose you can remove the cart after booting, if you can get enough grip to pull the bugger out without damaging it); it might be worth sticking a few CICs right in on a switch. However I suppose just keeping the cartridge slot (and making it more like the N64's so you can actually pull the damn things out) may well be enough.
On top of that, there was a "protected cartridge decoder (http://n64.icequake.net/mirror/www.cd64.com/cd64_decoder.htm)" accessory that, by the looks of it, uses the CIC and save of one cartridge to run the game and the CIC of a 6102 to boot. They unfortunately are big clunky things that have them sticking way out in two different directions. If I could get my hands on one of these, I imagine I could simply build two cartridge slots into my new case, eliminating this issue. (Maybe even a third, from the N64 itself, if that's of any use.)
Finally, I would have to hack together a new BIOS to make some of this insanity work. This would be the fun part. Since the BIOS is stored on two socketed flash ROMs (and a third, which I guess is the 128KB "SROM", whatever that is) and software-upgradeable, and the I/O is fairly well documented, this may not be too difficult. (Even just bootstrapping, using the original menu program to load my new BIOS in mode 0 until it's ready to flash.) A lot of this device's limitations seem to just be software issues, so there are some interesting things that could be done here...
Say, perhaps, adding support for more IDE devices, such as DVD burners (why not?), hard drives, Compact Flash, even Blu-ray just for irony's sake. (5 copies of every game on one disc, hell yeah.) Or just making it suck a little less and not give up so easily at reading the damn disc.
Or zip/other archive support for compressed ROMs (and compression of saves on controller pak).
Or adding support for bootable CDs (skip the menu and boot directly to a program).
Or some proper Gameshark support (with an actual GS Button tied to one of the aforementioned general-purpose switches).
Or hell let's just get a Lua interpreter going.
I wonder too if it could accept larger flash ROMs for the BIOS. (Meh, 128K is probably enough, but still...)
Then, as long as I've got the N64 opened up (for the PSU mod and to fit it in the case nicely), maybe I can do some mods in there. I'd love to have a D-SUB or component video output.
Anyway I thought I'd post this mainly to see if anyone has feedback and/or additional information about that unused connector (or a better way to map its pins) and power supply issues.
I can get it working , but it's extremely finicky. I have to use a process like:
1) Power on the unit, and wait for the drive's access LED to go out.
2) Attempt "Load CD64 File". This will fail, but gets the drive to spin up.
3) Wait no less than 7 seconds, then attempt again. This time it usually works and will load the game.
What has me baffled is the power issue. There doesn't appear to be anything wrong (no voltage fluctuation I could detect, components look OK), but if I simply plug the drive in normally, it will never spin for more than a few seconds, making it unable to load games. (With luck it might read a megabyte before erroring out.) If I power the drive from an external 12V supply and follow this process, it works fine. (Except it only lists the first 28 games on the disc - crappy software, I suppose?)
(I did of course try several disc drives, and lower speed settings. BTW, despite what some say, mine works fine with a DVD drive, though only reads CDs.)
Anyway after reading everything I could find, experimenting with it a bit, and examining the board and specs (some official hardware info is under "circuit" here (http://n64.icequake.net/mirror/www.cd64.com/)), I figure I could turn this into a nice dev unit.
My first concern is the 32MB ROM limit. Looking at the specs, the unit maps all of B0xxxxxx-B7xxxxxx to RAM - that's 128MB. Apparently the only reason for this limit is the way the unit maps its I/O - in mode 0 (menu mode) only the lower 32MB of RAM is mapped, and you can't write to it in mode 5 (run-from-RAM mode). It also doesn't look like you could ever switch out of mode 5 or 7 (the I/O range is now mapped to RAM/cart), but I'm told it can dump 64MB games, so that must be possible somehow...
Anyway I have numerous ideas as to how to defeat that limit, but since the unit only has 32MB installed, I can't try them until I can find a larger DRAM stick.
Looking at the memory map, only three modes are listed - 0 (menu), 5 (play RAM) and 7 (play cartridge). There's the possibility that one of the other modes might be useful. Since the board uses a big CPLD, perhaps it's also possible to reprogram that and create a mode which maps all to RAM but allows writing, and then simply switch back and forth, using the console's RAM as a temporary buffer.
Of course hacking the CPLD can be a somewhat risky move (and I don't have the tools), but another idea comes to mind: simply connect a switch to the upper address line(s) of the RAM. When open it functions normally, when closed that line is tied high. So you would load 32MB, flip the switch, load another 32MB, flip it back, and go. This could be done without any software hacking by breaking the ROM into 32MB files, or to the other extreme, the switch could be software-controlled. With two switches you should theoretically be able to load even 128MB ROMs (of which there are none to my knowledge).
If the DRAM address lines are not simply one to a wire (i.e. multiplexed somehow) then a simple switch won't work, but still it should be possible with some simple logic circuit to achieve this effect.
An even crazier idea is to power the RAM with a small battery, pull it out, plug it into a PC, and populate it there. Not exactly ideal, but hey, it's something. ;-)
Then there are questions of power. I'm not sure what's up with it but it seems like I need an external 12V power supply for the disc drive - with three power inputs now, it's getting awfully clunky, which is why I thought of building a new case for it in the first place (which then led to most of these other maniacal ideas). A PC power supply should have no trouble powering the console, CD64 board, disc drive, and perhaps a fan for that voltage regulator.
Furthermore, if the CD64 is no longer powering the disc drive, then I don't think it needs 12V at all anymore and so I could eliminate (or at least disable) the voltage regulator entirely and significantly reduce heat output. I don't think 12V is needed to keep the RAM alive, but the 12V from the N64 should be able to manage that. Or...
I'd love to attach a battery to the RAM. I have several around so it would just be a matter of connecting it in place of the CD64's power input, and building a charge circuit so the power supply can run the RAM and keep the battery charged when it's on. This shouldn't be especially difficult.
I couldn't help noticing, next to the unused video connector, two pairs of holes, L and R. These connect directly to the audio inputs on the cartridge connector. Basically every CD/DVD drive has analog audio outputs... enough said. The only question here is, are they always enabled, or does the game have to enable them? (Easily done with a Gameshark code probably anyway.)
Then of course there's that unused spot where a 44-pin connector would have gone (even still a removable cover on the case for it). The company's website says they originally planned to release an MPEG decoder add-in card to allow playing VCDs (thus the video connector). This connector could be very useful for mods. It seems to be a proprietary connector, and is oddly numbered - one side is pins 5-27, the other is 36-58; 1-4 and 28-35 are nowhere to be found.
I've been tracing it with a multimeter, but haven't got many sensible readings, probably because any address/data lines are going through the CPLD. I intend to toss together a small test ROM to help probe for those, though I'll have to look up how to either display video in a homebrew ROM (only done hacks before, never dealt with video directly) or break into Mario Kart's opening routine (where I can easily use the game's built-in text routines). The built-in memory editor won't do - I need to be able to read or write one byte, word or dword at a time at an arbitrary address.
I'm not sure how, but people have mentioned being able to load and run a ROM in mode 0, which would give it access to everything. Possibly just by loading it as a boot emulator (which has some unknown size restriction), or somehow switching back into mode 0 after starting. If nothing else, the built-in memory editor can edit main RAM, so I could patch into the menu program if I need to. From there, I can read/write arbitrary addresses and probe the connector to see what reactions I get.
Pins I know so far:
5: Video connector, "L-R"
6: Video connector, "composite"
7: Ground
17: /RD from cartridge connector (also connects to #OE of all flash chips)
26: Probably +5VDC
27: Probably ground
36: Video connector, "L+R"
37: Ground
57: /WR from cartridge connector (also connects to #WR of all flash chips)
58: Probably ground
Pins 7 and 8 of the video connector (Video Y and Video C) aren't connected to anything. 3.3V from the cartridge connector doesn't seem to go anywhere (you'd think at least to the actual cartridge?) None of these pins appear to be 12V.
This leaves 34 unknown, which is just more than enough for 8 data, 24 address. As it happens the memory map shows B1xxxxxx and B6xxxxxx as reserved, so it's entirely likely one of those maps directly to this connector and would have controlled the MPEG decoder. The other two could be clock and reset?
I've been working from the assumption that the N64's EXT connector is identical to the cartridge connector, which seems to be panning out so far. (I'd have to wonder how you could have both the 64DD and a cartridge plugged in - some software magic, I guess?)
I'm not sure what all I'd use this connector for if I mapped it out, but probably I'd hook up a microcontroller to work as an address decoder, which offers virtually infinite possibilities. Two ideas I'd definitely like to implement are some general-purpose switches (think GS Button on steroids) and LEDs, and perhaps a small LCD screen and/or some 7-segment displays. Ethernet and/or CF/SD would be badass.
Then there's the parallel port. Apparently this thing required some type of adaptor to connect to a PC. Looking at the schematic (http://n64.icequake.net/doc/cd64-ppa/parallelportadaptor.html), it looks like only some buffers and latches that would offer some convenience in the software design, but I'm no expert on ICs so I'm probably wrong. :) Either way, I'd like to either build this adaptor right in (is there any reason you'd want the port without?) or hack some code to work without it. The manufacturer was so kind as to publish a circuit diagram, showing which I/O addresses map to which pins, and it looks useful enough as it is for a GPIO port.
CIC is another thing to look at. The device requires a 6102 cartridge to boot (I suppose you can remove the cart after booting, if you can get enough grip to pull the bugger out without damaging it); it might be worth sticking a few CICs right in on a switch. However I suppose just keeping the cartridge slot (and making it more like the N64's so you can actually pull the damn things out) may well be enough.
On top of that, there was a "protected cartridge decoder (http://n64.icequake.net/mirror/www.cd64.com/cd64_decoder.htm)" accessory that, by the looks of it, uses the CIC and save of one cartridge to run the game and the CIC of a 6102 to boot. They unfortunately are big clunky things that have them sticking way out in two different directions. If I could get my hands on one of these, I imagine I could simply build two cartridge slots into my new case, eliminating this issue. (Maybe even a third, from the N64 itself, if that's of any use.)
Finally, I would have to hack together a new BIOS to make some of this insanity work. This would be the fun part. Since the BIOS is stored on two socketed flash ROMs (and a third, which I guess is the 128KB "SROM", whatever that is) and software-upgradeable, and the I/O is fairly well documented, this may not be too difficult. (Even just bootstrapping, using the original menu program to load my new BIOS in mode 0 until it's ready to flash.) A lot of this device's limitations seem to just be software issues, so there are some interesting things that could be done here...
Say, perhaps, adding support for more IDE devices, such as DVD burners (why not?), hard drives, Compact Flash, even Blu-ray just for irony's sake. (5 copies of every game on one disc, hell yeah.) Or just making it suck a little less and not give up so easily at reading the damn disc.
Or zip/other archive support for compressed ROMs (and compression of saves on controller pak).
Or adding support for bootable CDs (skip the menu and boot directly to a program).
Or some proper Gameshark support (with an actual GS Button tied to one of the aforementioned general-purpose switches).
Or hell let's just get a Lua interpreter going.
I wonder too if it could accept larger flash ROMs for the BIOS. (Meh, 128K is probably enough, but still...)
Then, as long as I've got the N64 opened up (for the PSU mod and to fit it in the case nicely), maybe I can do some mods in there. I'd love to have a D-SUB or component video output.
Anyway I thought I'd post this mainly to see if anyone has feedback and/or additional information about that unused connector (or a better way to map its pins) and power supply issues.