2600 Cheats?

[NE146]

Does anyone here know of a way, either patches, modding, external programs, emulator interface whatever... to CHEAT in any 2600 games (i.e. infinite lives, skipping levels, etc.)

 

Some emulators like Mame, or Zsnes have a Pro-Action-Replay type of interface that allows you to search for cheats using various methods. But I was wondering if anyone knew of any such cheating techniques for 2600 games either by playing them via an emulator or patching a bin file for play on a cuttlecart/supercharger.

 

I'd also imagine that this may be possible using the dissasemblers or perhaps the now infamous editgrafx (or whatever it's called) to modify the files somehow but I'm at a loss as to how to do it.

 

And if you're wondering, I am specifically looking for a cheat to get infinite lives in PB Frogger.

[Atari-Jess]

there really isn't a way besides modifiying the binary file in someway to get cheats like infinite lives in most (not all) games.

 

and sides, are you THAT bad?

[NE146]

quote

and sides, are you THAT bad  

 

Hahaha I was expecting something like that to be said

 

Nah I rock at Frogger and have always been able to flip the screens rotation since I mastered it as a kid many many moons ago...

 

err.. well maybe it's a *little* tougher for me now that I'm 31, but that's not the point!

 

[ 10-26-2001: Message edited by: NE146 ]

[Atari-Jess]

hehe you use 'thats not the point' alot too?

i own frogger 2 and its fun to play.

[jsoper]

Look at the Cheetah stuff on Bob Colbert's

web page which is in the links section.

 

I posted this to the other question by mistake, sorry. John

[Nukey Shay]

OK...a couple of tips :

Although 2600 games are among the smallest files to search in, it can be very frustrating to someone who hasn't a clue what those strange instructions do (heck, sometimes more so once you do!).

The easiest way to examine game code is to run PCAE with the debugger turned on.

When searching for cheats, the easiest way to do this is to start with what you DO know, and work backward from there. Since Frogger gives you five lives to start with, you might want to search for an instructions like LDA #05, and try changing the number to see what happens. The byte pertaining to "lives" often gives itself away if the game awards lives after collecting a certian amount of points. Programmers often use decimal mode to update the score, so these routines are easily found by searching for a SED instruction. Just beyond the routine and maybe a few instructions that begin with the letter "B", there might be an instruction like INC $FE (this tells the game to bump up a value by 1). So how does that help with keeping lives from going down? Search again, but this time look for an instruction that subtracts 1 from the same location...like DEC $FE (or whatever the location was named in the INC instruction). An easy way to remove an instruction without messing up the rest of the game is to replace that instruction and it's argument with the byte $EA. $EA instructions, or NOP's, are like REM's in basic...the cpu simply ignores them. Be sure to use one EA instruction for each byte used by the original instruction (LDA $FB00 uses 3 bytes...one for LDA, one for FB and one for 00...so you would patch 3 EA instructions over that). The only exception to this rule is most instructions that begin with the letter "B"...which only use 2 bytes). If you don't understand how those branching instructions work, don't worry about it...just experiment patching over suspect LDA's, INC's, and DEC's). Mame cheats function pretty much the same way, either by forcing a value to be in a memory location or telling the cpu to ignore a location.

[StanJr]

I'd like to state for the record that Nukey Shay is scary smart.

 

Dude, you were over my head by the time we got to $EA. Then again, I'm just starting to learn what all those codes (INC, LDA, SED, etc)mean.

 

Speaking of which, is there a handy list of them and their functions somewhere? I'll compiling a list as they learn, but It'd be nice to have a reference.....

 

Rookie Programmer, Stan

[Nukey Shay]

I don't want to get too deep, but just think of the 6502 only having 3 variables that it can work with...A, X, and Y. These are called registers...and almost all instructions are either reading or writing values to them. I just searched for 6502 OPCODES and came up with a few charts...I'll post a explaination of them if I can find one (but even an old dog-eared copy of the Apple II reference manual would be handy).

 

6502 menomic chart (by byte value)

 

6502 menomic chart (alphabetical)

 

"Illegal" opcode instruction usage

 

BTW another way to cheat that I forgot to mention is to erase the sprites that kill your character. Since jumping across the river in Frogger is pretty easy, just erase the cars and snake sprites using 2600GFX.

 

[ 10-26-2001: Message edited by: Nukey Shay ]

[StanJr]

Thanks Nukey, I think I even have the first one bookmarked. I'm trying to find something that describes these codes in more "plain" language. Something like "INC: increases value of register." Most I have been fairly well able to "decode" but there are a good many that I have no real clue what they do.

 

I apologize for the broken language of my last post. I had a brief moment of idiocy.

 

Would a public Library have a copy of that Apple Manual?

[Nukey Shay]

Here ya go...

What do they mean??

 

BTW (#) = # of bytes used...

 

(1)"Implied" means that the instruction is only one byte long (the argument is part of the instruction itself).

 

(1)"Accumulator" means that the instruction is affecting the A register directly (much like "implied" does).

 

(2)"Immediate" instructions load the value from the following byte into the register...this is noted in disassemblies by a # character. LDA #01 literally means to put a value of 01 into the accumulator.

 

Addressing :

 

(2)"Relative" is a branching term, and it means to jump up to 128 bytes forward or backward depending on the value of the next byte. Think of 00 as middle ground right at the memory location where the argument ends, with $01-$7F jumping forward and $FF-$80 jumping backward (BEQ $FE would be equal to basic's 10 IF RESULT=0 THEN GOTO 10...jumping to itself for eternity). BEQ 00 would seemingly have no effect at all, since it would just jump to the next instruction, just as if the branch never existed (I've always wished that the 6502 would perform larger jumps if FF or 00 were encountered in this manner, but oh well). The advantage that these "B" instructions have over JMP is their "if-then" nature. And since the jump location is relative to where you currently are, you can move code that use them without having to change all your jump vectors (like stepping down from a car is the same regardless of where you are parked).

 

(2)"Zero page" the instruction is performed on the single-byte memory location specified by the argument. Zero page consists of the very first 256 memory locations, but you probably won't see a program there. Just like the first page of a book lists the table of contents to show you where things are, it's speedy compared to having to thumb your way to what you need. Be very thrifty here, the hardware itself usually uses most of this area (usually holding vectors for anything that needs to be done at top speed).

 

(2)"Zero page,X" the instruction is performed on the zero page address that is X number of bytes from the argument (there have been reports of early 6502 computers having problems with wrap-around when the resulting address would be out of zero page, But I've never seen it).

 

(2)"Zero page,Y" the same as the above instruction...but using Y as an offset.

 

(3)"Absolute" the address in the argument is two bytes long. The low byte is followed by the high byte in memory...reverse of how it appears in a disassembly (the address $D013 is actually stored in memory as 13 D0).

 

(3)"Absolute,X" or "Absolute,Y" are much like the zero page instructions above, except 2 bytes are needed to hold the address, and the instruction is performed X or Y number of bytes from that address.

 

(3)"Indirect" is only used for a JMP instruction, and rarely at that. The argument specifies the address where the actual address is held that the program should jump to. This might be useful as a conditional jump if the distance is too great for a relative branch to handle, but reliability may be a problem. There is a bug in the way that the address is aquired. If the low byte of the address that the cpu is fetching the values from is $FF, the high byte will not carry to the next page. Example: $D0FF=$13, $D100=$D0, $D000=$00. If you JMP $(D0FF), the address jumped to would be the combination of the values at $D0FF and $D000! Instead of jumping to $D013, you will crash and burn at $0013.

 

(2)"(Indirect,X)" is also rarely used, and the instruction is performed X number of bytes from the zero page location specified by the argument. Handy if a table happens to be in a zero page group of bytes (however unlikely, since zero page is too useful to waste on something static like a table).

 

(2)"Indirect,(Y)" looks similar to the above instruction, but it is actually the most sophisticated method of addressing that the 6502 can do. The instruction is performed Y number of bytes from the ABSOLUTE address listed at the zero page location specified and it's following location

For example...if Y held 02 and the locations $FE and $FF held $13 and $D0...then INC $(FE,Y) would cause the value at memory location $D015 to go up by one ($D013+Y=$D015). This effectively creates a new jump address as you change the Y register. Expect to use this one often.

 

Basically, the X register is used as a counter in loops and as some offsets. The Y register is used in even more offsets (virtually all of the indirect ones), and just sometimes as a counter. The accumulator is usually programmed to handle all the rest (since more instructions made for this are only available to the accumulator).

 

Note that the "illegal" opcodes listed at that third link may or may not work with certian chipsets. Some are so specialized that they are impossible to use, but there are a couple of gems in there (like the ones that seem to affect two memory locations at the same time). How AXA and TAS squeeze so much code into 5 cycles seem impossible. The effects of each is listed at the top of the page...and addressing modes are given at the bottom.

 

[ 10-27-2001: Message edited by: Nukey Shay ]

[StanJr]

You are my personal 6502 god.

[Nukey Shay]

No prob...but I'm no Dan Boris or DEBRO. I know just enough to fake my way through games that I'm too lazy to beat

BTW yeah, a lot of libraries probably still have those old manuals...since Apple ruled over schools before clones took over...and PET's ruled before them. Any 6502-based computer's manual should work just as well.

[NE146]

Excellent info Nukey. Thanks

[Ze_ro]

I found that list of undocumented opcodes quite interesting... anyone know if DASM will accept these as easily as regular INC's and LDA's? Some of them actually seem pretty useful...

 

--Zero

[Ze_ro]

Oh yeah, and to provide something a little more on-topic.... I challenge anyone on this board to create a Game Genie for the VCS! Personally, I think it would be a fairly simple device, given the small memory space of the VCS. The main problem would be writing some form of ROM that would let you enter the codes....

 

--Zero

[Albert]

quote:

---

Originally posted by Ze_ro:

Oh yeah, and to provide something a little more on-topic.... I challenge anyone on this board to create a Game Genie for the VCS! Personally, I think it would be a fairly simple device, given the small memory space of the VCS. The main problem would be writing some form of ROM that would let you enter the codes....

---

 

If you want Game Genie functionality in the 2600 I can see two ways of doing this. One is by modifying a 2600 emulator to allow you to enter codes that then modify certain memory locations when the emulator loads a ROM (I assume this is all the Game Genie does). This would work fine for emulators.

 

What would be more fun is to do the same thing for the Cuttle Cart. The software that ships with the Cuttle Cart that allows you to load a binary could be modified to allow you to enter a code that would do the same thing before transfering the image.

 

I've never owned a Game Genie so I don't know what the codes look like and exactly what they do to the cart. If someone has some more information that would be great. For the 2600 I imagine you'd just want to be able to patch certain memory addresses, which would result in modifying the program code and/or data to produce the desired effects (like giving you infinite lives, making the game easier/harder, etc.)

 

The fun part would actually be coming up with all the codes that you could then use in your favorite games. Once it's possible to enter codes (either in an emulator or Cuttle Cart), I'm sure people would quickly disassemble their favorite 2600 games to figure out interesting ways to modify them. Then they could try out their new codes and post them for others to enjoy. We could certainly add that information to our database.

 

..Al

[Nukey Shay]

The GG functioned like those "expander" carts from days gone by. It functioned by way of interrupt. It would leave the line open, and showed it's own screen where you would enter cryptic "codes"...which were groups of six or eight** letters out of sixteen (each letter representing a hexadecimal digit. Dunno why Galoob used letters only instead of hex...for readability? To keep them even more cryptic? **I know that the psuedo-hex used would automatically recognise the length of the address by the second digit entered, so maybe it was done to keep the codes from being mistaken as actual hex?). From what I've read, this took some time to figure out. Anyway, this was actually a set of three active interrupts (i.e. it would constantly be forcing those values desired into the console RAM. I -think- that they stated that the ROM code could not be masked over...can anyone verify this?). When you pressed start, the GUI would close and the game cart would boot up. The interrupt codes would remain active until you powered down.

It could be challenging to do this on 2600 hardware, but if so it could also be done by way of an LCD display. But the biggest hurdle I see would be to get the cart to work with the varying bankswitching techniques used on carts. Also much more limited, since ram was in serious short supply on the 2600.

BTW did anyone know that you can link two NES Game Genies together to double your codes? This does not work with three however (or with the Sega/SNES versions), but with emulation the point is moot. The ability to save codes in emulators was also a good idea.

Ze-ro--

The instructions themselves should work on compatable hardware, although the assembler would list them as .byte if those instructions were not supported by it. Trying to enter the menomics outright would cause input errors on most assemblers. Nice way to hide code! The reason that they were left off the instruction set was because of the unpredictability, I think...but even some "official" ops had problems (BMI BPL JMP($xxxx) for example). SAX sounds very useful, as well as SKB and SKW (when testing multiple conditions)...and OAL could be used as a random-number seed value due to it's apparent high level of variance.

 

[ 10-27-2001: Message edited by: Nukey Shay ]

[The Night Phantom]

It might be worth pointing out that a Game Genie-type of device already has been made for the VCS. It's called the Personal Game Programmer and was produced by Answer. Unfortunately, this accessory is super-rare; so, it would be worth creating a new such device that could be had at a reasonable price.

[Nukey Shay]

It may look like the program is jumping to a data area, but that is how programs are loaded into memory on some platforms. Atari dos itself uses FF's at the start of a binary program to indicate start, init, and run addresses. While these do not look like jumps at all, they do mean something to the dos that loads the rest of the program. So it might seem that the first part of the program contains gibberish, when in fact it is actually jumping past all of that to the run address. Since the opcodes use the same values as raw data, it is often confusing trying to figure out where the program areas actually are. The only real solution is to start disassembly at the run address, and follow the jumps from that. In 8-bit carts, I've often seen jump tables used that deal with different parts of a game seperately. Here's a jump table from the 800 cart Dig Dug... (comments added by me)

 

;*=$8000

LDA #$FF

STA $D40E

JSR $8892 ;create game playfield

JSR $806F ;"attract mode"

;

LDX #$FF

TXS

INX

STX $DD

;

LDA $DC ;wait here to

BEQ $FC ;correct timing

INC $DD ;and

LDX #$00 ;continue after 1/60

STX $DC ;sec. has passed

;

JSR $A0CE ;display P/M objects

JSR $B6DA ;check function keys

LDA $0A3A

BNE $E5

STA $3FFC

JSR $A7DB ;deal with player shooting

JSR $AB9E ;deal with veggies

JSR $8EFB ;deal with rocks

JSR $AD33 ;move "ghosts"

JSR $ADB9 ;check boundries

JSR $B2C5 ;move player

JSR $ACA4 ;check enemy/player collision

JSR $A5DB ;face miner correct direction

JSR $808B ;auto move miner (when you start)

LDX $F9

BEQ $04

DEX

STX $0665

JSR $830D ;dig trails

INC $0A6F

JSR $9E08 ;deal with Fygar's fire

LDA $D40B

BMI $04

CMP #$48

BPL $03

JSR $94FA

JMP $800B ;go back to LDX #$FF above

 

As you can see, the main part of the program is jumping to different subroutines that deal with different things independantly. How did I get those comments? I did it the slow way of NOP'ing over each JSR instruction, and then playing the game to see what changed. An interesting cheat here is to change the JSR $ACA4 to 3 NOP instructions...your miner will be invincible (except to rocks).

You probably won't see many of these "jump tables" in a 2600 cart...but it's another thing to look into when discovering cheats.

[Nukey Shay]

BTW by using the above cheat, you can see an example of counter rollover on the 800. At level 128, the veggie becomes a white Pooka worth a lot of points. When you roll the levels over after 256 screens, the next level has no vertical tunnel (since normally it is dug for you when you begin a new game).

 

Also,

Simply erasing the sprites in Frogger won't work...the game does not use the collision registers. (oops)

 

[ 10-27-2001: Message edited by: Nukey Shay ]

[Ze_ro]

quote:

---

Originally posted by Nukey Shay:

The instructions themselves should work on compatable hardware, although the assembler would list them as .byte if those instructions were not supported by it. Trying to enter the menomics outright would cause input errors on most assemblers. Nice way to hide code!

---

 

A while back, my brother was working on cracking the protection on various PC CD games (He was actually fairly successful, and released a number of patches). He was looking at the disassembly of one program, and it was all a giant mess! Nothing seemed to really work together, and things JMP'ed, CMP'ed, etc to seemingly random values. Eventually he found the source of the problem: Earlier in the program, there was a JMP instruction that actually jumped into an opcode! Of course the program had been written to take this into account, and worked perfectly... but any disassembly of the code would be a complete mess! That still blows my mind as one of the craziest assembly things I've ever heard.

 

Albert: As far as I can tell, the way the Game Genie works is that it intercepts all memory calls, and (depending on the codes you enter) will provide different values. For example, if you know the amount of lives you start off with is stored in $01A6, and you start off with 3 lives... you could tell the Game Genie to replace this memory location with FF, which would give you 256 lives. However, as mentioned, the bankswitching schemes pose a difficulty here (Damn, I completely forgot about that). So, I'm not completely sure how this might even work on a real VCS...

 

--Zero

[Ze_ro]

quote:

---

Originally posted by Nukey Shay:

It may look like the program is jumping to a data area, but that is how programs are loaded into memory on some platforms.

---

 

I think you're missing the point... this was done on purpose so that people trying to crack the protection (like my brother) would get confused and give up. Even the code you posted is quite obviously useful to some degree, it doesn't contain illegal opcodes or any other strangeness like I'm sure my brother found.

 

quote:

---

Atari dos itself uses FF's at the start of a binary program to indicate start, init, and run addresses.

 

LDA #$FF

STA $D40E

---

 

If these two lines of code are what you're talking about, I think what's actually happening here is that it's setting a reset vector of some sort (Though I could be wrong... usually reset/interrupt/etc vectors are held at the end of memory in addresses like $FFF9). The point is that when a certain event occurs (an interrupt, a reset, a hardware trap, etc), there is a table of values that the processor looks at to decide what it should do. It just loads these into the program counter and JMP's there effectively.

 

quote:

---

You probably won't see many of these "jump tables" in a 2600 cart...but it's another thing to look into when discovering cheats.

---

 

Why not? The only real arguement I can think of against using stuff like this would be because JSR and RTS take up quite a few cycles, and they toss things on the stack, which would waste memory on the VCS. I suppose these are good enough reasons... but as long as you account for it in your code, jump tables like this are definitely an easy way to organize things, and depending on the task, you may not miss the memory.

 

--Zero

[Nukey Shay]

a--

What I meant was that if disassembly is started on the wrong memory address, the program will look like slop until it works it's way past the unknown opcodes. Programmers/compilers in general are a lot less organized than they used to be (given the vast amount of memory now available to them)...so it's not uncommon to see data tables and vectors wedged between lines of code.

b--

Those two lines came from a cartridge (it's actually setting the vblank vector). What I was referring to was programs on a disk. The first line on an Atari disk file dump might look like FF FF 00 30 8F 30 a5 00...etc. The double-FF signifies that it's the start of a file segment, 00 30 is the memory location where the file begins ($3000), and 8F 30 is the file's run address ($308F). The remainder of the file segment is the data that loads to the start address.

c--

"Probably won't" because I haven't seem many of these types of tables used in 2600 games. Partly because of the low amount of memory, but I think mostly because of the way the 2600 works...timing is more sensitive than on computers, and the display turns to crap if too much time is spent doing a group of subroutines in one go. You could still NOP over a JSR instruction in a 2600 cart, but the effects were less noticable in my experience. Still worth a try, but you will probably have to take more than a few blind shots before you get anything useful (sort of a last-ditch effort).

[flavoredthunder]

(like stepping down from a car is the same regardless of where you are parked).

 

[Chris++]

Now that's a REALLY unsuccessful game of Frogger. Can't even see the poor little green guy.