PAR to GG

Main Page
Back to Hacking FAQs
-GSHI-
-On a possible Pro Action Replay to Game Genie conversion-
Written by Lazy Bastard
Note: This was taken almost entirely verbatim from a post I made on the GSHI YaBB in reply to a comment about PAR to GG conversion.
I once assumed there would be a way to universally convert PAR codes to those of GG...but then I began to ponder through things...and eventually made a few guesses, which basically turned out to be correct. The problem before was that I simply didn't have all the information I needed about either the PAR or the GG. I had most, but I was missing a few integral pieces. So, now that I have what I consider to be all the info I need, let me try a hand at translating my thoughts so that they make sense to someone besides myself, heh.
-What exactly is the problem?
You see, the GG affects the ROM. This is the actual hard, conventionally unmodifiable data of a game. In other words...it can't usually be changed. But a hardware GG plugs directly into the slot that games normally plug into, and games plug into the top of it. This allows the GG to intercept the entire game's data, and filter it through with a few slight modifications - the codes you enter.
The PAR can affect not only the ROM, but also the RAM, which is what is happening in the game, right now (in a nutshell).
On an SNES, the ROM data is contained within the game cartridge. It's constantly read from the cartridge by the SNES. The RAM data, however, is entirely contained within the memory of the SNES, and not at all dependent on the cartridge itself, at a particular moment. Now, of course, without a cartridge, the RAM would be emtpy, as there would be no data coming in from the cartridge for the processor to interpret; but for now, let's just dwell on the fact that if there were some way for you to trick the SNES, you could remove your game cartridge and, as long as nothing needed to be called up (as long as you didn't change rooms, enter a new menu, etc), your SNES would keep running as if nothing had happened. This is because the SNES stores its own RAM (it has to; I can't think of a video game system that doesn't), which is totally independent of the cartridge, and, hence, the ROM.
The stuff leading up to this moment has simply been an overview of SNES ROM/RAM, to give you a basic idea of how different they are. RAM and ROM are not simply System 1 and System 2 of memory storage, which can be easily converted with a simple subtraction/addition problem. In fact, they can't be converted with a complex algorithm, either.
Think of it this way...the ROM tells us what's available to be manipulated, and its properties. The RAM tells us what's happening to it at a precise moment in time.
So let's say we have in our possession the RAM and ROM of a soccer ball on a field at a specific moment.
The ROM tells us the weight, dimensions, density, and all forces permanently acting between the ball, the air, the ground, and anything else on the field. It tells us that the ball is spherical and weighs exactly 3 pounds, that the field is 100 meters long by 50 meters wide and totally flat, and so on.
The RAM tells us what's happening on the field at a particular moment. It tells us that the ball is three feet in the air, that it is at X coordinate 76 and Y coordinate 84 on the field, that it's travelling at an arc of 3 degrees, and so on.
Now imagine there's some way to affect interpretation of the ROM, and we have some coding that would cause one of the ball's permanent properties to be that it's 4 1/2 feet in the air. We have fun with this. Then one day our ROM-affecting device is eaten by a local dog, and all we can find to replace it with is a RAM-affecting device. This seems great, but then we try to use our old "Ball is 4 1/2 Feet in Air" code, and it doesn't work. We compare totally equivalent codes between the ROM and RAM-affecting devices, and find no consistent conversion method, even with multiplication/division, squares/square roots, and multiple step mathematical computations of various kinds we try inventing. We eventually give up, and start from scratch with the new RAM-affecting device.
The problem that we ran into was simply that it doesn't make logical sense to take the properties of something, and change that data into what's happening to that thing at a precise moment in time.
Another thing to note is addresses. RAM addresses change frequently. When one event's happening in a game, thing1 is at address "Blah". Then that event ends, and a new event begins, and suddenly thing2 is at address "blah", and thing1 either doesn't exist or is at a new address. ROM addresses, however, never change.
Think of the ROM as a printed out piece of paper with numbers on it: it always stays exactly the same. Perhaps instead of you reading it, someone else reads it aloud to you, and doesn't quite read it the way it was intended to be read (a rough analogy of a ROM editor, such as a GG), but in any case, if you look at that piece of paper, it will always say the same thing. Using this model, RAM would be something like the monitor you're using right now, only with numbers dynamically changing all over it, something like what you probably saw on The Matrix (or if you hold down on the Directional Pad in the Memory Editor of a PSX GSPro, heh). If you froze the RAM and wrote down every number on the screen at one moment, then unfroze it, waited a moment or two, froze it again, and wrote down every number on the screen, the two collections of numbers could possibly be exactly the same, or they could be different down to the last digit. This is because the RAM is dynamic.
Anyway, there's no simple conversion between RAM and ROM. Luckily, the PAR can modify both RAM and ROM. This means that every code that works with a GG can be converted to work with a PAR, but not every code that works with a PAR can be converted to work with a GG (info on conversion can be found here - <http://www.fortunecity.com/marina/embankment/1227/id124.htm> - although you'll have to do some reading...)
-So what can't be converted?
The 7E-7F CPU address area, for instance, is not part of the ROM, but part of the RAM. Therefore, even if you successfully follow the steps of a PAR/GG conversion, you can't convert a PAR code that begins with 7E/7F to work with a GG, because the GG never reaches the RAM; it can only affect the ROM.
Unfortunately, as far as I've seen, there are no SNES emulators with hacking support other than that of the RAM: 7E-7F (I've never seen a hacking interface that can modify ROM interpretation, which would essentially be a GGPro, heh). Both SNES9x and ZSNES can use PAR codes with non-RAM addresses, such as those in area 02, but neither can actually view, let alone search for values of, addresses other than those within 7E-7F.
Therefore, any codes you hack with an SNES emulator will work fine with a PAR, but won't work at all with a GG, as the GG can't reach the range of 7E-7F.
It's too bad no one's made an SNES 'ROM interpretation'-modifying hacking interface for emulation...if one existed, there could be actual hacking done for the GG.
If you have any further questions on Pro Action Replay to Game Genie conversion, please feel free to e-mail any one of us on the GSHI staff.
Credits
Lazy Bastard-Owner, Chief Admin: lazy@vvm.com
Ace-Administrator: warpudd@yahoo.com
RPGod-Administrator: afireinside@bad-ass-motherfucker.com
TruWizdom-Administrator: CodenGal@Yahoo.com
Munky-Administrator: ccjarvis@yahoo.com
Liquid Man Zero-Administrator: liquid_man_zero@yahoo.com
King Edgar 0-Administrator: kingedgar0@aol.com
DarkSerge-Administrator: bhults@infoblvd.net
SephiRon-Administrator: kool_guy_z@yahoo.com
Admins of the past:
CCV2k: ccv2k@hotmail.com
CzarDragon: czardragon@yahoo.com
HAcKen: HAcKen@HAcKensHAvEn.cjb.net
SolFire: sol_fire@hotmail.com
Alucard: gilgamesh112@hotmail.com
Greets to: ZoMBiE343, Heh[]heh, XKillingAngelX, Rainsphere, DrummerIX, NBCraftsman, floydfan, Eizneckam, MyTru, Magnum, Chip, the GSCCC team, the AGSCC team, and everyone else in the hacking scene.
-GSHI-
The GS Hackers Index©