How to Make "Improved" Master Codes

Tony Hedstrom
Threw this together kinda quickly, so excuse any typos.

How To Make "Improved" Genesis Master Codes (Game Genie)

(AKA: How to Get Rid of the Blank/Red Screen)

Version 0.8 Nov 22, 2010

Written by Tony Hedstrom - [email protected] (no ads on this site)

What are "Master Codes"? Master codes are sometimes needed on games when you
use Game Genie codes, or hack ROMs. You'll know if you need a master code
because you'll usually get a blank/red screen, and the game won't run.

This is a quick guide on how to make improved/faster Master Codes for Genesis
and Mega Drive games. These Master Codes will not only get rid of the blank/
red screen if you use Game Genie codes or hack a ROM, but they also make the
game load MUCH faster than with a regular master code.

Without a master code, the game has to go through the normal checksum process of
adding up every single byte in the ROM, and then comparing that number to the
known checksum of the ROM. If the two numbers don't match, the game won't run
(usually a blank/red screen). The checksum process can take several seconds to
complete. You'll see this as a 1 to 5 second delay (black screen) when the game
first starts. The larger the ROM size, the longer the delay.

With regular master codes, the game still goes through the entire checksum
process, but ignores the fact that the two checksums don't match. The improved
master codes completely skip the entire checksum process, which makes the game
start instantly (no 1 to 5 second delay).

I will also explain how to make "regular" master codes for those who don't want
to go the extra mile to make "improved" master codes.

There'll be a lot of 68000 assembly language in this guide, but don't let that
discourage you if you're not familiar with it.

NOTE: This method will not work on all games (specifically 'Electronic Arts'

I'm going to use a game called 'Red Zone' as an example.

If you started Red Zone with a regular master code, there would be a 4 to 5
second delay before the game starts. If you start Red Zone with our improved
master code, the game will start instantly.

Here's a list of what you'll need:

1) A ROM of 'Red Zone' (check the "Link" section on my website).

2) Gens Tracer:

3) A Game Genie to hex conversion program ("Download" section on my website).

The first thing we need to do is make an assembly trace log using Gens Tracer.

Just open up Gens Tracer, press the "/" key, load the Red Zone ROM, then as soon
as you see the first text appear on the screen (about 5 seconds), press the "/"
key again. Close Gens Tracer. The "/" key starts and stops the assembly trace

You should now have a file called "trace.log" in your Gens Tracer folder.
open up this file with MSWord, or some other good text program.

What you're looking at is the programming that the game goes through when it
first starts up. We need to find the checksum programming. There are several
different checksum methods used, but I'm going to show you how to find the most
popular method.

In MSWord (or whatever text program you're using), click on "Edit/Find", and
type in: ($018E) and click on "Find Next". In our example (Red Zone), there is
only one match. If you're using a different ROM and don't get any matches, try
searching for $018E. If still no matches, try 018E. If still no matches, then
this method probably won't work for your ROM.

$018E is the ROM address that most games use for the correct checksum of the
game. If the game adds up all the bytes of the ROM and it doesn't match the
value at ROM address $018E, then the checksum will fail and the game won't run.

OK, in our example (Red Zone), here is what our search of ($018E) turned up:

06:60AE B0 78 CMP.W ($018E),D0

What this is doing is comparing (CMP.W) the value at ROM address $018E to the
value in register D0. If you look at the value in D0 (which is right below
our match), this is what you see: D0=000092A9. If you open up your Red Zone
ROM with a hex editor and go to ROM address $018E, the value there is: 92A9.
A perfect match.

The next instruction in our assembly trace is:

06:60B2 67 28 BEQ #$28 [06:60DC]

This means Branch if Equal (BEQ) 28 bytes. Well, they were equal, so it will
branch 28 bytes to ROM address 06:60DC.

At address 06:60DC, the instruction is: 4E 75 RTS. This just makes the program
return to its original location after a BSR or JSR (special branches or jumps
that remember their current location so they can come back later).

OK, that is how the programming works if the checksum check passes. But what
happens if the checksum check fails (ie. you hacked your ROM)? Well, the
program will do its compare (CMP.W), but when it gets to the Branch if Equal
(BEQ), it will NOT be equal, so it won't branch the 28 bytes, and the checksum
check will fail (and our game won't run).

All we have to do is make it so that the program will ALWAYS branch the 28 bytes
after the compare. This is very easy to do with a single Game Genie code. The
instruction there is: 67 28. To make it so that it ALWAYS branches 28 bytes,
use 60 28 instead. So the hex codes we enter into the Game Genie to hex
conversion program (which you can d/l from my website) are 0660B2:6028. The
0660B2 is the ROM address, and the 6028 is the branch instruction. The Game
Genie code it gives you is: FBTA-NA7W.

That is how you make a "regular" master code. If you try that one, you will
see that there is a 4 to 5 second delay before that game starts. Next, I'll
show you how to make an "improved" master code.

To make an improved master code, we need to figure out how to completely bypass
the entire checksum process. It's fairly easy to do. Using the same search
results from above, here is where we start:

06:60AE B0 78 CMP.W ($018E),D0


06:60B2 67 28 BEQ #$28 [06:60DC]


06:60DC 4E 75 RTS



It compares the two values, branches 28 bytes if equal, then returns to where it
came from which is 06:5BF6. We are interested in the RTS, and where the RTS
goes. This tells us where we need to make our code. The RTS goes to ROM
address 06:5BF6. Start scrolling your assembly trace upwards (towards the top)
and watching for the first JSR (or BSR) you see. The first JSR (or BSR) we see
when scrolling upwards is:

06:5BF0 4E B9 JSR

As you can see, the ROM address (06:5BF0) is very close to the ROM address our
RTS was going to (which was 06:5BF6).

So here's what's going on...

06:5BF0 4E B9 JSR ($00066098)

That is making the program jump (JSR) to ROM address $00066098, which is the
start of the checksum process. When the checksum process is finished, it
returns to the NEXT instruction after the JSR (which is at ROM address 06:5BF6).

All we have to do is figure out how to make it so that it doesn't jump (JSR).
Easy to do with a single Game Genie code. We'll just change the JSR to a branch
instruction instead. We are going to branch from 06:5BF0 to 06:5BF6, so we
would use 6004 as our new branch instruction. You might be asking, why the hell
are we using an instruction that branches 4 bytes, but we need to branch 6
bytes? That's just the way 68000 assembly is. The branch instruction actually
starts counting AFTER the branch instruction itself (if that makes any sense).

Anyways, here's our improved master code:

The ROM address is 06:5BF0, and the instruction is 6004. So here is what our
Game Genie conversion program spits out: 065BF0:6004 = AVPT-NA9T. If you test
our new Game Genie code, you'll see that the game starts instantly, and no more
blank screen when using GG codes, or after hacking the ROM.

Hope this guide helps. Email me if you have any questions.

Tony Hedstrom - [email protected]