Retail Cart Live IPS/BPS/etc... Patching.

I've been through this site & many others through google. In an attempt to find any possibility of live patching on SNES hardware using a pass-through & a retail cart. I have found little to nothing about any such possibility. Best example I can give for practical application. Would be a SMW "hack". Load said hack onto a host board, plug SMW retail cart onto that & insert into SNES. Which in effect would make the hack playable on real hardware.

In addition to this applying a hack/mod patch. I would like it to convert the retail game to Fast ROM. If it would even be possible. My intent there is to aid small lags & glitches. Which are present in the retail copy of the host game. Let alone a mod.

My intent is to produce these adapter carts. In order to distribute mods and/or hacks I have made. In a slightly more legal manner than making a reproduction cart. Which involves distributing a copy of the copyright material.

Any help or insight is greatly appreciated.

I've thought about such a device before. You could do it, but it would be pretty challenging/impossible as a TRUE adapter.

My approach (idea) was to basically use a flash cart with a mcu/processor of some sort. The processor on the flash cart would do the same thing your IPS (patching application) does on your PC. The patch could be stored on some sort of removable media accessible to the processor. So the processor would fetch the ROM from the cart plugged into the female connector, apply the patch to the ROM and temporarily store the patched rom in the flash/RAM connected up to the console. I think it would be a pretty legit device and arguably legal. It'd be a pretty complex though, and more expensive than a flash cart if done properly. So really it'd only be of interest to people interested in spending more money to be legal.

Converting a slow ROM game to fast ROM using lock-on wouldn't work because all the reads from the lock-on cart would still go to the slow ROM chips inside the lock-on cart. What you could do is put all the new parts in a fast ROM and have the existing parts run from the existing slow ROM. Only the parts stored in the patch bank would run fast. It'd probably be less expensive just to create an original platformer engine than to design and build the Game Genie-style circuitry to make the extensive patches that would be needed to hook your own total conversion into SMW's engine.

I reckon it would be possible to do it (albeit unpractical if you as me) with a device similar to the Super UFO flash cart.

Distributing IPS patches is normally legal, unless the patch itself contains copyrighted material. I don't see what building cart-reading or cart-passthrough hardware does for you, legally speaking. If someone owns the cart, they're usually entitled to have a ROM copy, so the extra hardware seems unnecessary to me, if you're just looking to do something legal.

Taking advantage of FastROM is not straight forward though. Many SlowROM games are going to have all the addresses used in the lower ($00-$7D) banks which aren't FastROM anyway. You'll have to patch every single absolute long jump and any other bank changes to be ORed with $80. And the FastROM boost in speed may not be enough to overcome many slowdowns anyway. From what I've read SNES CPU timing changes based on the memory accessed each opcode or maybe it's each cycle. So even with SlowROM areas, some cycles may be executed at the Fast (6 master clocks?) speed and not the slow (8 master clocks?) speed or xtra slow (12 master clocks?).

I tried to see if Gradius III hacked to take advantage of FastROM would help. I don't know how far I got but it didn't seem like it helped much.

But they have to make that ROM copy themselves with a Retrode, not download it through the Internet.

There are other ways to backup your game than the Retrode. Devices like EPROM programmers, Game Doctor SF, Wildcard, Pro Fighter, or a homemade cartridge reader.

I like the idea of a device that uses the original cartridge to play translations or hacks. But when you look at just how much is changed in a game that is hacked or translated it is more than a simple Game Genie you need. I guess you could have a system where depending on what Bank of ROM is accessed you could switch between the original cartridge ROM and the RAM containing the patched ROM. It's not like you'd have every single bank modified. The same device with a *patch* could be used as a Flash Cartridge since you can certainly make a patch to turn one game's binary into another. Before designing such a device you'd have to really examine just how many worthwhile hacks and translations are out there and how many you are certain you could support. I think there are enough out there that it would be pretty cool. You could even use the Final Fantasy III bug fix on your legitimate FF3 cartridge.

This is a silly distinction for them to make, as the ROM itself will usually bear no indication of its origins. It's nearly pointless to make such rules if enforcement is so tedious and grey-area.

This phrasing I think leaves plenty of leeway to allow someone else to make the backup for you, e.g. download a ROM.

Can you find legal precedent for suing someone who downloads someone else's software backup rather than making their own? Though apparently in Britain until 2010 you weren't even entitled to back up your own audio CDs, which I find quite bizarre.

Anyhow, while I think a Sonic & Knuckles style plug-in cart would be kinda fun, I think doing this will increase your production costs quite a bit. Possibly you could make the carts to order, letting the customer provide a base ROM which you discard after building the cart. I'm reminded of this funny article about bit colour.

A patcher is a nice idea, but silly. The hardware would cost more than a flash cart to run the post-patched game. The legality is the same either way: you're violating the Berne Convention with a patch or with a patched ROM.

> Converting a slow ROM game to fast ROM using lock-on wouldn't work because all the reads from the lock-on cart would still go to the slow ROM chips inside the lock-on cart.

What's crazy is that I tried to emulate the behavior of a fast read from a SlowROM chip, and despite trying everything possible, I couldn't get a single errant read even after several minutes of executing tight loops that way. Tried on a dozen different known SlowROM boards.

There -must- be some boards where this will fail, but damned if I can find one.

This isn't really that surprising. The chips are rated at worst case temp, voltage, noise, command pattern, data topology, loading, slew rate, etc. You're likely not hitting any of these worst case scenarios so it's pretty easy for the majority of the memory you can get your hands on will easily come close to doubling their rated speed. All the rating on the chip means is that's the fastest it was verified to work under worst case conditions. It's not proven/tested to work at fastROM speeds, but given the conditions it's not surprising that it does.

I don't have a good idea of what the actual situation was in the market back then. But knowing what I do about current memory marketing it's completely possible that while the SNES was being designed it was a little more challenging and thus expensive to produce 120nsec mask-roms so they designed the SNES accordingly. But by the time it actually hit the market and was in full production a few years later processes would have evolved to the point where it was easy to produce faster memories even if you didn't have a market to sell it at the faster speed. You just etch whatever speed on the memory that the customer wants to buy as long as you know it's at least that fast. Even today The vast majority of memory that goes out the door of a manufacturer can perform several speed ratings faster than it's labeled, especially under ideal circumstances...

You also have to consider the delay that your patching circuit will add. Even if you are operating within tolerances, you might not be if you insert the patcher in the path.

That's why I'd suggest having RAM with a copy of the patch banks (not all would be patched) and just refer to it if the bank being accessed is on the list of patched banks.

The SNES may have been originally designed with only 64K of RAM and had it doubled by the time it actually was released so it's no surprise if the CPU speed and ROM speed had a similar situation where they were more conservative at the time of design and could have done more by the time of release. It's a shame the CPU hadn't been a tad faster.