Modding the crap out of a CD64

Discussion in 'Modding and Hacking - Consoles and Electronics' started by HyperHacker, Jul 8, 2010.

  1. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    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), 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, 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" 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.
     
  2. marshallh

    marshallh N64 Coder

    Joined:
    Mar 16, 2006
    Messages:
    663
    Likes Received:
    30
    Open up the power supply and check the capacitors. Check the 5v regulator inside the CD64. Odds are you will have to replace almost all the caps in either. My V64 showed weird symptoms (turning off randomly not working) recapping the PSU fixed it. I also fixed another guy's that the original CD drive broke in.


    http://n64.icequake.net/files/cd64-512.txt

    DRAM needs more than just power to stay alive, it has to be refreshed. To add more ram you would wire another SIMM socket and use /CS, or use a 64mb simm that has more rows/columns. The problem is the PLD on there won't know or care and it's a waste of time.

    You have a lot of ideas going on, pick one and start in. But I think past a certain point, you're wasting your time. Why not start over and building something yourself that doesn't have those limitations?
     
  3. splith

    splith Resolute Member

    Joined:
    May 2, 2010
    Messages:
    997
    Likes Received:
    4
    You want to do all that?
    By the end of all that, you'd be able to create your own schematics for something more powerful the a wii.
     
  4. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    Building my own dev system is pretty far beyond what I can do. This would be mostly just soldering and coding.

    I saw that post, and it explains why the 32MB limit exists, but doesn't say whether the unit can read 64MB. Just installing a 64MB stick would answer that; the hard part would be finding one. (I'm certainly not about to attempt soldering two in! o_O) All that really says is there doesn't seem to be a way to do it in software alone.
     
    Last edited: Jul 8, 2010
  5. splith

    splith Resolute Member

    Joined:
    May 2, 2010
    Messages:
    997
    Likes Received:
    4
    Err..

    You seem to be forgetting that going from 32 > 64 requires more addressing.
    Here's an example in binary; every time you go left once, you double the previous number.
    So; 32, 16, 8, 4, 2, 1...
    32 in this case has 6 binary lines though it's actually 5 as 1+2+4+8+16=31 possible numbers which always excludes 0 so therefore it can address 32., 64 would require another bit, 6 bits, which would make use of the 32.
    The chip probably doesn't have a spare address line, even if it did; the software isn't programmed to use it so connecting it would do nothing, you'd have to write your own software from scratch (unless they gave the source code out) and then program the PLA.

    Quite simply; I wish you all the best but it's really, REALLY not worth it, would save yourself much time and money by just selling your kit and getting something else like a doctor v64 (there's some on ebay uk now)
     
  6. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    ...Yes, I know how binary works. The software can be modded if necessary, but it shouldn't be an issue at all - the CPLD is doing all the address translation (which, during gameplay, would be simply passing it on to the RAM chips or cartridge slot). The CD64 software is only active at the menu, running on the N64 itself, and its inability to address more than 32MB is the entire problem, that the switch idea works around.

    The only real question is whether the CPLD passes those extra lines on to the RAM, and even that probably wouldn't be too hard to fix if it didn't. (Multiplexing is really the only complexity there.) Seeing how many other unused connectors are left on this thing, it wouldn't surprise me if they wired it all up already.

    Bypassing the memory limit is only one of the many things I want to attempt with this project. I'm not likely to be able to sell it (all the auction sites I know of require credit cards, most also require PayPal; I want nothing to do with either), and another unit isn't going to have a lot of the features that make CD64 so appealing for development.
     
  7. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    It's hardly difficult to decode the extra address line. You don't need to multiplex it because 64MiB doesn't fit the DRAM's square grid arrangement, instead 64MiB SIMMs are two banks of 32MiB. Decoding can be done externally so the CPLD integration isn't an issue. Because 64MiB will have the same amount of rows, refreshing twice the memory per period isn't an issue, you just need to further decode the bank. Whether both banks need to be selected while refreshing I don't know, but if necessary you'll have to hack the SIMM to refresh in parallel and then of course add logic to decode the banks while outside of refresh.
     
    Last edited: Jul 9, 2010
  8. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    Thanks for your helpful reply. I would definitely need to learn more about how SIMMs work to attempt such a mod. What I meant earlier though was demultiplexing that high address line from the cartridge bus if the CPLD isn't already doing that.
     
  9. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    To demultiplex the high address line you only need a 1-bit latch on AD8, enabled by ALEH.
     
  10. stuntpenguin

    stuntpenguin Spirited Member

    Joined:
    Jun 5, 2009
    Messages:
    121
    Likes Received:
    78
    Do you actually know what you're doing when it comes to modding bios? I ask because I've been trying to hack the bios to show a custom splash screen when it boots up, but I haven't had any luck, but then again, I don't really know what I'm doing. Have you figured this out at all?

    From what I can tell, the bios aren't encrypted or compressed, but later revisions have that crazy byte-swap thing. Is that the conclusion you came to? I've been looking for image files in the bios by searching for BM& or whatever it is that signifies a bitmap file, but the file doesn't seem to contain any.
     
  11. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    I probably wouldn't be modding so much as replacing. I've got an EEPROM programmer that will work with those chips just fine, and it looks like taking control of the hardware (even from game mode!) is a piece of cake, so all I'd have to do is learn how to actually work the N64 hardware. (I've just been using Mario Kart as a base for my test program! :p)
     
  12. marshallh

    marshallh N64 Coder

    Joined:
    Mar 16, 2006
    Messages:
    663
    Likes Received:
    30
    LOL. graphics are not stored as windows bitmaps. It is probably 5551 16-bit rgba data. there are some n64 disassemblers out there that can show rom data in this format.
    If the first word is 0x8037, you're good. If it's 0x3780, you need to byteswap it.
     
  13. HyperHacker

    HyperHacker Member

    Joined:
    Jan 31, 2010
    Messages:
    13
    Likes Received:
    0
    Yeah it's rare to find actual image files in these ROMs... since they don't have a filesystem it's usually just raw image data. Some games surprise you though; apparently a number of GBA games have entire JPEG files in them. I've been playing with the hardware registers and I can't get the parallel port to do anything useful (probably because I don't have the adaptor), but otherwise it seems like I can interface with everything just fine. Next I guess I'll need to learn how to talk to various IDE devices, and actually write my own graphics and input routines. Anyone know how to flush/invalidate cache? I can't seem to find much information. There's a CACHE opcode but I can't find any documentation of what its parameters are. So far I've been bypassing it entirely by writing and executing code at A0xxxxxx, but that's hardly ideal.
     
  14. BimboBoop

    BimboBoop Rapidly Rising Member

    Joined:
    Jul 7, 2016
    Messages:
    84
    Likes Received:
    12
    Dude, after 9 years I found your post. I dont know anything about electronics or programming but I own a couple of CD64 Plus machines and when I bought them, they haved power issues. Most of time overheating and stopping reading the discs. At the end I solved plugging a mole cable extension to the power input and then a power supply with a mole female connector, just to power one the CD drive. Apparently the power supply that came with my consoles doesnt offered the proper DC9V 800ma the consoles need to power both the board and the CD drive, so suplying power separately sound like an easy solution to me. Sadly the extra voltage gives a little interferance to my CD64 plus, so in order to turn it off I plugged the extra power supply to a surge supressor. SO I could turn it off as soon the ROM already loaded.
     

Share This Page