He starts out with a 190 in 1 game cartridge, where he found a neat Famicom game never released in the US. He decided he would patch the ROM he found on the multicart in order to have an English menu, and then create his very own cartridge from the image. He discusses how to identify which EPROM chips you will need in order to construct your cartridge, as well as some helpful ways of finding a donor cart that has a similar enough board to house your components.

[Callan] also provides a quick walkthrough of erasing and burning your new EPROM chips, before discussing some post-soldering troubleshooting steps you might need to take before your game will work properly.

While we can’t comment on the legality of these game clones, we still think it’s pretty awesome.

Be sure to check out his site for a far more in-depth discussion of the process if this is something that interests you.

Actually, it begs the question: why a UV EPROM instead of just an EEPROM? With a EEPROMs and a header (or two) on the cart connected to the programming wires, the cart could be written without taking it apart once modded and assembled.

Maybe HAD readers will be able to answer this questions that has been bothering me. Why hasn’t anyone used a cheap uC and some flash based memory to make a NES cart like this? Is there something in the cartridge design or execution that prevents a uC from emulating the cartridge and allowing something like a 200-in-1 cart to read from an SD card?

I could see where treating a flash memory source like the ROM would fail when switching banks, since the NES hardware probably expects it to happen within a certain time-frame. But with the ROMs being small enough to fit into the RAM of some uCs, I just wonder if I am missing something or if I need to get to work making this happen.

@quin:
I can create a commercially available one with usb/sd cart (did this before for other systems)
while in my country its perfectly legal i don’t like nintendo to sue me nonetheless (too much hassle even if i’m right)
i could imagine manufacturing them b2b though

>>Is there something in the cartridge
>>design or execution that prevents

There is nothing to prevent it.. but it’s not as easy as sticking some SRAM on the nes’ address bus. You need to emulate the various mappers.

>>flash memory source like the ROM would fail
>>when switching banks, since the NES hardware

Why would it fail? Real NES carts use Mask roms and mappers, there is no reason why flash won’t work in place of mask roms as long as they aren’t slower than mask rom. If I was going to build such a device I would use SRAM on the NES side anyhow.

>>into the RAM of some uCs, I just wonder

You need to present the data on the NES data bus in the same timeframe as a maskrom can. You aren’t going to manage that with an Arduino and some shift registers.

>>if I am missing something or if I need

Cheap MCU’s don’t have an external address/data bus.. and if you have an address/data bus it is meant to be driving the bus and not being driven in most cases. You can solve that with dual port SRAM or something.. you still need to be able to emulate the mappers though and I don’t think it’s worth trying to do that in software to be honest.. a small FPGA is the way to go.

Unless you’re hunting for rare carts you can probably pickup all the carts you want for less than you could build/buy a flash cart for.

TBH, buffering plus some kind of MUXing or OE disabling before the NES is connected are much better options than a DP SRAM. Tristate logic is pretty old technology by now. The PowerPak seems to use a CPLD to do the heavy lifting, since a MCU is not going to work easily (or at all) for a general-purpose mapper emulator.

i don’t know why videogames haven’t moved to something like SD(besides the ease of pirating games on SD) but i for one am not buying another console until they use flash memory again instead of scratchable, breakable, just plain damageable optical media.

There is a simple reason they still use “scratchable, breakable, just plain damageable optical media.”

In theory, if any of the above occurs, you will open your wallet and go buy another copy of the same game. Even if they came up with their own proprietary flash based system that was un-hackable (yeah right) and could never be copied illegaly (yeah right) they would still be better off using a medium with a shorter life expectancy. We see this across many many industries – i work in the automotive industry, and recall reading a very interesting article on the matter. A Major car manufacturer trying to source relays for their vehicles from an equally major electronics company, was given the specs and told the serviceable life of the relay was 1,000,000 cycles. The car manufacturer responded that this was unacceptable, they required the life cycle to be no more than 100,000 cycles. Just one example, but one that I believe carries throughout many industries. Same train of thought that leaves us with hardware that will support features that the manufacturer leaves completely out of the firmware…

@abobymouse: I think a zif socket might start bumping into the height available within the cartridge. Although, with a top loader Nintendo, having a cart with holes and chips sticking out of it would probably be ok.

@cantido
See, it’s that mapper part of the nes carts that I was not familiar with. I has wrongly assumed that the cartridges just packed the ROM in a way that the system could access, with the mappers just doing normal hardware memory bank managing. If all a uC-cart had to do is read the address and respond with the correct data, a high-pin-count uC should be enough; I didn’t expect an 8-pin ATTiny to do that.

Guess I need to add FPGA dev-board to my list of things to get and study.

How does an emulator know how any random ROM is mapped? Does the ROM indicate the mapping method internally? Do emulators include code to provide the functionality of multiple mappers? I think the ultimate setup would be a board with a cartridge header that is directly soldered inside the original NES console (to eliminate the infamous card edge connector problems) This header board would contain some sort of flash (CF or thumbdrive) that ROMs can be easily loaded onto. The remaining question is how to do the mapping? Couple potential ideas… Either a 32bit micro like an ARM or an FPGA or, as an alternative approach, including a single mapper hardware chip (one of the more popular mappers) and writing a script to remap ROMs to suit that particular mapper. Is that even possible? Food for thought.

Thanks to everyone for reading my page and engaging in some discussion!

As many people have pointed out, there are a number of ready-made solutions that involve a lot less work than the good ol’ fashioned rom replacement, but I think this is most economical fashion if you’re interested in playing these unreleased or prototype games on the real thing.

Im sure major comanies incourage these things as they seek employment opportunities.. though when i do say major companies i mean smaller ones, lests face it major companies, most all dont no jack but except there subdevisions …