I want to create a cartridge similar to Sonic & Knuckles or a Game Genie so that the text files loaded from the ROM or DEPROM of an original Famicom cartridge can be replaced with alternate English ones.

I was researching the lock-on technology of the Sega Megadrive/Genesis, which replaces assets of a game by loading alternative ones into the ram. This seems like it could work. Or maybe the ROM can be physically overridden by a flashable battery, as is done in cartridge mods, through the lock-on cartridge, which would be the easier option.

I'm an engineering student with sufficient programming and soldering experience for this project, but I have hardly any knowledge of this specific subject. So essentially, I'd like to know how replacing game assets through lock-on technology would work, and the easiest way to achieve this with Famicom cartridges.

  • Not quite. I read that but it only touches on the general technology and how it works with Sonic 3. I want to specifically change the text assets but I don't know how exactly to do that. The replies are also hard to understand for someone unfamiliar with the subject. – Dylon Gallagher Apr 26 '20 at 18:52
  • 1
    I don't believe these questions are duplicates. One is asking 'how did lock-on work', the other is asking 'how can I use it for this purpose'. – knol Apr 28 '20 at 0:52
  • And also my answer isn't Famicom specific (so not too helpful), nor is the duplicate. (I can't edit my comment?) – knol Apr 28 '20 at 2:25

I'll assume you only want to modify small parts of the game, rather than the entire game. (If you wanted to modify the entire game, you'd just make a new cartridge holding the entire image.)

Your objective: replace some but not all of the words* of the game with a new set, leaving the majority of the game unchanged.

(* as in addressable data units, not textual words)

In the simplest case, like a Sega Mega Drive cartridge, your original game is stored on a mask ROM that receives an address A and a read signal and outputs a predetermined 16-bit value ROM(A). On a read signal, OUT = ROM(A). Something like a M27C800 8Mbit (512K words x 16bit) chip would have this interface and is compatible with the Mega Drive's cartridge port.

Your passthrough cartridge will have the same exposed interface, but a different function: you want it to receive the address and read signal and output either your modified value NEW(A) or the original ROM value ROM(A) based on a stored flag whether the word in question is 'modified' - store this flag in MOD(A). Your cartridge has to store NEW(A) and MOD(A) somewhere on board.

On a read signal directed at the cartridge (!CARTREAD = !CE + !OE) you'll have to perform the logic DATA OUT = IF MOD(A) THEN NEW(A) ELSE ROM(A). (This isn't proper system description language, but you see the concept.)

In the simplest case, you can use a 1-bit ROM to store NEW and use this as a Chip Select to select between the two possible data sources:

Your cart has a 16-bit ROM for NEW. You wire this to the data and address buses, as well as linking both these buses to your passthrough slot. The 1-bit ROM for MOD is also linked to the address bus but not the data bus.

On a Mega Drive (!CE OR !OE) is the read signal I'll call !CARTREAD. Link !CARTREAD to the !OE of both NEW and the passthrough slot. Now the two data sources will only ever be enabled on a valid read. Now we need to determine which of the two data sources' !CEs is enabled. This is the job of MOD.

Link !CARTREAD to both MOD!CE and MOD!OE so on a valid read it outputs the value of MOD(A) inside the cart. We use this to generate Chip Selects for the two data sources: Send this MOD(A) value to the !CE signal of the passthrough slot unmodified so when a valid read occurs and MOD=0 then ROM!CE and ROM!OE are Low and the output data is ROM(A). Send NOT MOD(A) to the !CE signal of NEW so when a valid read occurs and MOD=1 then NEW!CE and NEW!OE are Low and the output data is NEW(A).


  • If !CE is High then !CARTREAD is high and neither NEW nor ROM respond, the data bus is high impedance. MOD is idle too.
  • If !OE is High then !CARTREAD is high and neither NEW nor ROM respond, the data bus is high impedance. MOD is idle too.

  • If !CE is Low and !OE is Low then MOD is enabled, MOD(A) is output inside the cart:

  • If !CE is Low and !OE is Low and MOD(A) == 0, then ROM is enabled and data bus = ROM(A).
  • If !CE is Low and !OE is Low and MOD(A) == 1, then NEW is enabled and data bus = NEW(A).


This isn't the best or fastest way to do this, but I think it's the conceptually simplest. On a read, we want to output something. Look up which something in a table, and enable the appropriate ROM of the two. It's somewhat like bankswitching but on an address-granularity determined by your MOD rom data. If you can spare increased current draw and board space, you can use a (huge) 16-bit 2-to-1 multiplexer selecting on MOD(Y) instead of the enable logic, eliminating any worry about MOD(Y) and NOT MOD(Y) being staggered by a propagation delay. For more complicated systems than the Mega Drive which use mappers rather than flat ROM, this system falls apart.

This isn't how a Lock-On cartridge works, by the way. A Lock-On cartridge holds all of its special game logic (S3+K, Knuckles S2, Blue Sphere) inside itself, and uses the passthroughed game as a data source mapped into the Mega Drive's address space after the S&K cart.

If you wanted to follow the Lock-On concept, I think you'd have to make a whole new game* which refers to data stored in your locked-on cartridge as a data source. You couldn't just boot into the locked-on game, because either it would be in the wrong address space and all its stored pointers would be wrong, or it'd be in the right address space and you'd just boot into the unmodified game. :) (* your 'whole new game' could be just the functional code of the original game with all the stored assets zeroed-out and pointers modified to refer to their locked-on original counterpart except the text blocks you want to modify, which is what I believe the KnucklesS2 ROM is within the S&K cartridge if you were to isolate it, but by that point you're going to great lengths to make a highly questionable, very involved derivative of the entire game image.)

Modifying game data on an address-by-address basis is what Game Genie does; you should look up how their hardware works!

  • Thanks for the response. You're right that I'm only looking to change one part, and yeah similar the Game Genie but with more than just small bytes of code. I will look it up. Would it not be possible to replace the character ROM (Most NES games stored images as font along with text, and in the text/character ROM) with another almost identical one with alternate characters? It can be done in mods by physically desoldering the one ROM chip and replacing it with another. Maybe my "lock-on cart" could intercept the pins on a hardware level if the NES accesses the rom directly or something. – Dylon Gallagher May 5 '20 at 17:01
  • As far as I know, the memory on NES carts is split into two roles: PRG with executable code and tables and CHR with tile graphics. The text indices you need to modify, the codes selecting which letter tiles to draw, will probably be contained in PRG ROM. This leads to the two cases in my answer: 1) alter the response on a data-word basis selecting old or new PRG ROM, or 2) provide a whole new base game ROM, reusing whatever parts of PRG ROM you could identify as useful. Unless your game doesn't letter tile graphics suitable for your new language you don't need to touch CHR ROM. – knol May 6 '20 at 6:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.