A question for anyone who knows the workings of the NES

[Zork Nemesis]

Just a simple nerd question.

In one of the rare cases that Google has let me down for finding an answer to a question, I'm asking anyone here if they know something. I've recently found out about an old NES Game Genie code, The code IKAAAE specifically. Entering this code causes substantial issues to just about any NES game you try to use it with ranging from graphic spasms, freezes, crashes, audio glitches, and odd gameplay quriks, (for example, the graphics in Super Mario Bros turn to garbage, sprites are incorrect and broken, and gameplay slows for no apparent reason) and just about any game you use it with becomes nigh unplayable (as far as I can tell, Teenage Mutant Ninja Turtles 3 is the only game not affected off the bat). For no real reason I've been wondering what makes this such a dangerous code. I know how the Game Genie works, it creates values specified by the user that are read instead of those present on the ROM image.

My question is pretty much this, does anyone here know enough about the NES ROM structure to know or at least have some idea where IKAAAE is being read from and the potential effects of such?

[The Spanish Inquisition]

Step 1: decode game code
http://tuxnes.sourceforge.net/gamegenie.html

Step 2: find address in NES memory map
http://bit.ly/MQhxWo

[M's]

issues like this
www.youtube.com/watch?v=UmFfqy8joI0

And found this from 2007
http://www.famicomworld.com/forum/index ... pic=1402.0
ctrl F the code

[The Spanish Inquisition]

Code: Select all

var codeMap = 'APZLGITYEOXUKSVN'
var toHex = function(c){ return c.toString(16).toUpperCase(); }
var decode = function(code){
    var result = [];
    for(var i=0;i<code.length;i++){
        console.log(code.charAt(i)+" = "+ toHex(codeMap.indexOf(code.charAt(i))) );
        result.push(codeMap.indexOf(code.charAt(i)));
    }
    return result
};
 
var n = decode('IKAAAE');
var address = 0x8000 + ((n[3] & 7 ) << 12)|
                       ((n[5] & 7 ) << 8) | ((n[4] & 8 ) << 8) |
                       ((n[2] & 7 ) << 4) | ((n[1] & 8 ) << 4) |
                        (n[4] & 7 )       |  (n[3] & 8 );                       
var data = ((n[1] & 7) << 4) | ((n[0] & 8) << 4) | (n[0] & 7) | (n[5] & 8); 

console.log( 'address: '+ toHex(address)  + '\tdata: '+ toHex(data)) 

So here is some javascript to decode the game code. press f12 and you can run it in your browser.

The address turns out to be $8080 which when you look it up is only 128 bytes into the first memory bank of the game cartridge.
The data value was $4D.

So now you need the ROM code around $8080 to see what it does. Since the address is so close to the beginning of the lower memory bank and is aligned on a major memory row and you say weird behavior happens on many games, it's likely this is a common initialization point for many cartridges.

If $4D was an opcode on the 6502 it would be an ExclusiveOr operation with what it had in the accumulator register at the time (unknown) and whatever was at memory location $8081. EOR operations are commonly used in programming to toggle bits.

The 6502 uses 'little endian' addressing which means if $4D was part of an address then this is only the end of it. If memory location $8081 had a value of $FF then the effective address would be $FF4D. So it's also likely that location $8080 is part of a table of indirect addresses. A control flow part of the program reads the two bytes at address $8080-81 and then determines from that value which memory location to either 1) execute code at or 2) pull the value of data from that location.

[Crusty Juggler]

Damn, I wish I had the nerd knowledge of you guys.

[THE Flying chihuahua]

I am going to use that code on all of the games I have on the NES.

For SCIENCE!