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] http://www.angelfire.com/games2/codehut/ http://codehut.gshi.org/ (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' games). 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: http://GameHacking.org/downloads/Gens2.12aR2Tracer.zip 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 logger. 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 then 06:60B2 67 28 BEQ #$28 [06:60DC] then 06:60DC 4E 75 RTS then 06:5BF6 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]