Nintendo 64 Rom swap

*Edit*
What i'm basically saying that is it possible to replace the rom that is on a OoT cartridge with the Master Quest rom that's floating around so I can have a master quest cartridge that I can just put into my n64 and play it like any other cartridge? Also I read up on it a little and seems hard but not impossible.

 

not sure i understand the question but, are you asking about just plain swapping rom images from the computer to sd card on the fly? (bin, rom, z64 etc)
if so, then YES!
i have a krikzz ed v2 (need to take down cic/pcb revision) and all legit rom dumps tested worked without hitch! played roughly twenty games without slaxx (conkers bad fur day and perfect dark being two of them)
if the rom image uses nv/sram, a file is generated by the same name as the rom image! (can have multiple instances of the same game even, just a different parent name)
hacked roms may work, but i haven't got around to trying it....can't see it being dangerous! (either it works, or it doesn't)
....
sorry if this is no help!
if it's an actual everdrive you're asking about it working on, visit the official support forum (krikzz.com) for objective help! (can't see why it wouldn't, but rom compatibility is a constant work, no comment for hacks)
...
[edit]
typo...
...
no archived roms (7z, lha, zip etc) just neat!
.....
[more edit]

^^ so am i getting warmer here?
you want to flash/dump/OVERWRITE a rom to a retail cartridge? NO!
not happening!
the retail cartridges are FIXED, hence the tla, 'read only memory' (rom) but you could swap game pcb's.....i know that's not what you asked! (if i misunderstood this, please say...new to me is this one)

 

well thanks! (^_^) I knew it would be very hard to do and highly unlikely. For some reason I am not a fan of the everdrive carts or 64drive, I just want a cart that's for OoT's Master Quest. So that'll never happen. I'll check out the other forum thanks for helping! (^_^)

 

Maybe if you ask nicely, Krikzz would give you a customized ED firmware that skips the menu and boots directly into the ROM? A bit over the top for a single game and not very cost effective, but still...

 

To be more specific, the N64 carts use maskrom. You can't just burn something onto a chip.

There are other backup units out there, but you're sort of stuck using one. You could always build a PCB designed to use eeprom--that's what dev flashcarts were--but at that point you might as well build a full backup unit like the ones commercially available.

The menu is a ROM. If you want to boot only one ROM, rename it to whatever the device's menu file is called. Should mostly work presuming there isn't a CIC mismatch. In that case you'd either need a bootrom, switch the crc calculation in the ROM to run with something else (necessary for Zelda), or change the CIC chip out.

 

Well I didn't know about Krikzz till now, so please?

 

Huh?

 

No, it's not impossible, but it's a lot more complicated than doing something similar on a SNES or a Genesis. The old systems used standard ROM chips - the pinouts were not exactly the same, but replacing the ROM with an EPROM or flash device just required moving a few signals to the right pins. The N64 uses a much more complicated protocol where the address is sent to the cartridge in two pieces and then the data is read back - it also has a burst mode where once you've latched the address you can address multiple sequential locations in the ROM just by cycling the /RD strobe. Since there is no programmable device that works like this, if you want to replace the ROM you need to use a combination of a programmable logic chip to handle the address latch/counter and a flash chip. This is pretty much the same hardware you would need in a reprogrammable flash cart, so the attraction of making a single-title repro cart is limited.

 

^^ to the average joe (me for one) minus a workshop and professional equipment to fabricate a pcb to spec then get chips and program them, extremely unlikely!
...
i've had a 'pirate' megadrive cartridge back in the day, nothing recent.
the pcb was a clear counterfeit as well as the rom chip, had a small red button atop the cartridge to select between games! (golden axe, streets of rage and columns, if i recall correct?) never seen a snes/n64 one though!
got a gbc pirate 'pokemon blue' cartridge and a '100-games-in-1' ngb (fixed/no save) cartridge in storage!
....
wasn't too clear on the exact specifics of why it isn't possible to make a 1/1 copy of a retail cartridge (for intermediate/average user) so thanks for explaining it in better detail! :friendly_wink:

 

There were a few pirate N64 carts - they typically replaced the ROM with two chips - one custom device that implemented the latch/counter stuff and the other being the actual ROM - most of the early ones didn't have a CIC in them, and you had to use a boot adaptor (like the EMS "N64 Passport") with an original cart plugged into the back of it. Later on, the CIC was cloned and there were a few pirate carts that would boot just like a legit one. By the time the CIC was cracked, the n64 cart copier devices were starting to hit the market, and they basically killed the market for the pirate carts.

This has led to the strange situation where even in HK the pirate carts are substantially less common than the real ones - and it's about the only Nintendo system I can think of where this is the case.

 

Very interesting! I'd assumed they would be the same as any other ROM based cart, thanks for posting!

 

No way to get the program code to clone the CIC and the custom device to do the latching?

 

The CIC is a seperate chip. One particular game uses a feature built in to generate the keys for decoding setup files, but other than that the big difference between them is the correction you need to make to the checksum in order to boot the ROM. That's a surprisingly simple matter to address though and can be done ROM-side. Way back in the day there was even a program to do it automatically for you.

Effectively bootemus do the opposite. They're a ROM that uses the standard CIC on the cart, then reboots the system using the new ROM and rerunning the PIFROM with the base CIC value for the chip you're targetting. So, the original game ROM doesn't need to be altered since you're effectively going through the boot process the same way but with the target game's CIC's response.

Come to think of it though, I don't know if anyone's just tried manually setting the returned CIC value in the bootstrap. Pretty sure you can't just bypass the infinite loop it causes on a bad checksum test though.

 

The custom device is pretty simple - it would fit into a 32 macrocell CPLD with no problems.

What you need is a 32 bit up counter with the ability to load the upper and lower 16 bits separately - the interface with the N64 consists of a 16 bit wide multiplexed Address/Data bus, two address latch lines and a read strobe.

The N64 puts the upper bits of the address on the bus, then drives one of the address lines high (the other is high already), it then drives the other latch line low and puts the low word of the address on the bus, then drives the first ALE strobe low again. At this point, the address is latched, and when the read strobe is driven low the first world will be emitted - just increment the counter on the rising edge of read, and gate out the next word when it goes low again.

The CIC was definitely cloned at one point, but I don't know if it was reversed in a functional or physical way (I suspect the latter).

 

Sounds simple to someone familiar with CPLDs but unfortunately not for me. But assuming we had a CPLD programmed with that logic is that all we need to do to load the ROM? Zoinkity mentions that the CIC isn't necessarily needed or am I reading it wrong?

 

Yeah, basically you would need a 16 bit wide ROM device, and a CPLD - the AD<0:15> lines from the cart port wire to the CPLD and the Q<0:15> lines from the ROM, the READ/ line goes to the CPLD and the OE/ pin of the ROM. The two ALE lines go to the CPLD and then the CPLD generates the address lines and CS/ lines for the ROM. It looks like it would end up being a I/O bound design:

AD<0:15>: 16 lines
/RD: 1 line
/ALE<0:1>: 2 lines
A<0:24>: 25 lines (based on a 64MB max cart size)
/CS<0.n>: ? lines (depending on how many ROMs you want to support)

So you end up with a minimum of 45 I/O lines - meaning that it won't fit in the smallest parts, which typically only have about 30-35 user I/O pins. Something like a Altera EPM240 would work - although I just had a look and the Xilinx XC9572XL in a 64 pin package has enough I/O and is a lot cheaper, so that might be a good fit.

And you will still need a CIC - what that hack he's talking about does is patch the game so it will boot with a different CIC than the one it was intended to use - unless there is a CIC of some kind in the cart, the system never comes out of reset.

 

@ TriMesh.
regarding your second response:
it would explain why england didn't see many snes/n64 pirates! (if any? surely one at least? we're NOT the '50hz brigade' anymore)
....
thanks for the additional... :friendly_wink:

 

One of the anomalies of the HK game market was that - although HK used PAL for their TV broadcasts - the majority of the consoles were NTSC Japanese grey imports. As a result, most of the pirate carts were designed to be compatible with NTSC machines and hence tended not to end up in Europe. There were a lot of SNES pirates around, though - most of them were built using COB (aka "Glob Top") construction where the chip was bonded directly to the PCB, they tended to look like this (the DIP chip on the end of the board marked "U2" is the cloned CIC). Also note the complete lack of decoupling caps, despite the fact there are spaces on the board for them.



They weren't all like that, though - this is a much nicer bootleg version of Super Mario Kart built using all packaged devices and with no apparent corner cutting - on this board, the chip marked "TEN-E" (U5) is the CIC clone and the "5458A" (U1) is the DSP-1 clone. It also has proper memory protect circuits (copied from the Nintendo cart) and even has a socket for the battery. Bootleg carts built this well were unusual, though.

 

If you'd like an example of a commerical "game" that fudged it, look no futher than Datel's Gameshark / Pro Action replay. The split 16bit addressing issue creates a unique situation when it goes to read or write its own eeprom. They have to manually load/store each short to one of two addresses ranges, depending on if they're writing the left or right word.

It does one other rather unique thing. It's method of injecting itself in the middle of the boot sequence is probably tied to address mirroring. It executes just after PIFROM, and its two hardware address ranges only differ from the PIFs by a bit. This could also explain why it's the only known case where code can be executed directly off ROM space while within the exception handler. Outside is fine, but within it normally won't work.

 

And since there is no CIC it will only boot by "Borrowing" the inserted game CIC correct? Makes sense now, and thanks for all the info Trimesh.