Copy Link
Add to Bookmark
Report
SNES Kart v1.6
SNES Kart v1.6
The most complete guide to a SNES cartridge worldwide
. .
______ ______ .
.:_\_ . \\_ .__\_::.
. .::./ ./ // ./__ .:::. .
:_<_____/<______>_:.
. .
Damaged Cybernetics Australia
It is a crime to redistribute this document in a commercial
venture of any kind without permission or a licensing agreement.
Contact us via email for more information on licensing.
This is freely distributable for non-commercial use, however we
require that you acknowledge the following:
SNES Kart 1.6 Copyright (c) 1995-1996 DiskDude. All rights reserved.
[Image]
None of the information contained in this text comes from any confidential
source. It was obtained from various sources on the Internet, but also the
product of my own investigation. Refer to the Acknowledgements section at
the end of this text.
Use this information for your own use, I will not take any responsibility
for your actions. All copyrights and trademarks are owned by their
respective owners, even if not acknowledged, no infringements intended.
I wrote this because all of this information is scattered in small files
everywhere, if existing at all, most of it outdated. This is an attempt to
conveniently bring all of the information to one place, and as up-to-date
as possible. If you find this useful, tell me! I love positive feedback.
Contents
Pin Layouts Cheat Device Decoding
* What is the cartridge pin * Pro Action Replay (hardware)
layout? * Gold Finger (software)
* What is the ROM pin layout? * Game Genie (hardware)
* What is the DSP1 pin layout? * Converting between CPU
* What is the MAD-1 and its pin addresses and ROM addresses
layout? * Easily converting between
* What is the pin layout of the codes
16kbit SRAM most commonly used
by Nintendo? SNES Copiers
Cartridge Addressing Schemes * What are copiers?
* Super Wild Card (SWC) header
* LoROM cartridges information
* HiROM cartridges * Pro Fighter (FIG) header
format
Embedded Cartridge Information * Game Doctor file name format
* Super Wild Card parallel port
* Game title (21 bytes) I/O protocol
* ROM makeup (1 byte)
* ROM type (1 byte) ROM Protection Schemes
* ROM size (1 byte)
* SRAM size (1 byte) * SlowROM checks
* Country (1 byte) * PAL/NTSC checks
* License (1 byte) * SRAM size checks
* Game Version (1 byte)
* Inverse ROM Checksum (2 bytes) IPS Patch Format
* ROM Checksum (2 bytes)
* Non Maskable Interrupt / VBL Acknowledgements
Vector (2 bytes)
* Reset Vector (2 bytes)
* How do I know if the ROM is
HiROM or LoROM?
Pin Layouts
What is the cartridge pin layout?
If the SNES doesn't detect the CIC while power is on, then it will not
continue to read the cartridge. Further details of this are not known to
me.
Super FX 01 32
02 33
03 34
04 35
GND 05 36 GND
F A11 06 37 A12
r A10 07 38 A13
o A9 08 39 A14
n A8 09 40 A15
t A7 10 41 BA0
A6 11 42 BA1
o A5 12 43 BA2
f A4 13 44 BA3
A3 14 45 BA4
c A2 15 46 BA5
a A1 16 47 BA6
r A0 17 48 BA7
t /IRQ 18 49 /CS
D0 19 50 D4
D1 20 51 D5
D2 21 52 D6
D3 22 53 D7
/RD 23 54 /WR
CIC out data (p1) 24 55 CIC out data (p2)
CIC in data (p7) 25 56 CIC in clock (p6)
RESET 26 57 nc
Vcc 27 58 Vcc
28 59
29 60
30 61
Left audio 31 62 Right audio
LoROM: 32kbyte pages/banks (A15 not used - assumed high)
HiROM: 64kbyte pages/banks
BA0-BA7 switch between a possible 256 banks/pages.
LoROM data is stored in the upper 32kbytes of the possible 64kbyte
bank/page (A15 is assumed high). Using 64kbyte pages, the SNES can address
a huge 16Mbytes or 128Mbits!
According to a SNES memory map, LoROM games can be as large as 16Mbit while
HiROM games are limited to 32Mbit... what about the 48Mbit game floating
around?
What is the ROM pin layout?
This pin layout was taken from a Donkey Kong Country 2 cartridge and seems
to be consistent with all their mask ROMs (some are 32pin, others 36pin).
A20 Vcc
A21 A22
A17 01 32 Vcc
A18 02 31 /OE
A15 03 30 A19
A12 04 29 A14
A7 05 28 A13
A6 06 27 A8
A5 07 26 A9
A4 08 25 A11
A3 09 24 A16
A2 10 23 A10
A1 11 22 /CS
A0 12 21 D7
D0 13 20 D6
D1 14 19 D5
D2 16 18 D4
Vss 16 17 D3
What is the DSP1 pin layout?
This was taken from a hacked Pilotwings cartridge with a switch on it -
possibly to select between HiROM and LoROM DSP1 games. I'm not 100% sure
that the following is correct or complete though.
Vcc 01 28 Vcc
Vcc 02 27 A14 (A12 - used for HiROM?)
nc 03 26 /CS
nc 04 25 /RD
nc 05 24 /WR
D0 06 23 ?
D1 07 22 ?
D2 08 21 Vcc
D3 09 20 Vcc
D4 10 19 Vcc
D5 11 18 Vcc
D6 12 17 GND
D7 13 16 /RESET (inverted RESET- SNES slot)
D8 14 15 CLOCK?
If you can verify/correct this, it would be greatly appreciated.
What is the MAD-1 and its pin layout?
The MAD-1 stands for Memory Address Decoder revision 1. It is used on the
Donkey Kong Country (1 and 2) cartridge and possibly other cartridges in
order to address one or two ROMs and a static RAM.
/HI 01 16 /LO
/SE 02 15 A13
03 14 A14
/RE 04 13 BA5
Vcc 05 12 A15
Vcc 06 11 /CS (p49 SNES slot)
Vcc 07 10 Vcc
GND 08 09 RESET (p26 SNES slot)
/RE - /CS on a 32Mbit ROM (possibly for MAD-1a only)
/LO - /CS on ROM1 (lower 16mbit)
/HI - /CS on ROM2 (upper 16mbit)
/SE - /CS on Static RAM
What is the pin layout of the 16kbit SRAM most commonly used by Nintendo?
It seems that Nintendo uses this SRAM in many of their games, mainly
because it is very cheap, only $A5 (retail) - much cheaper for Nintendo who
buys millions of them. It can address up to 2048 bytes or 16kbits.
A7 01 24 Vcc
A6 02 23 A8
A5 03 22 A9
A4 04 21 /WE
A3 05 20 /OE
A2 06 19 A10
A1 07 18 /CS
A0 08 17 D7
D0 09 16 D6
D1 10 15 D5
D2 11 14 D4
Vss 12 13 D3
Cartridge Addressing Schemes
LoROM cartridges: HiROM cartridges:
read ROM /RD, /CS, RESET low read ROM /CS, /RD, RESET low
/WR high /WR high
read SRAM /CS, /RD low read SRAM /RD low
RESET, /WR high RESET, /WR, /CS high
A15, BA4, BA5 high A13, A14, BA5 high
write SRAM /CS, /WR low write SRAM /WR low
RESET, /RD high RESET, /RD, /CS high
A15, BA4, BA5 high A13, A14, BA5 high
Would anyone like to verify this?
Embedded Cartridge Information
Most of the information in this section was obtained from Mindrape's SNES
ROM, available from http://www.futureone.com/~damaged/.
All values are in decimal unless specified with a trailing 'h'.
The starting offset for this information is located at the end of the first
page:
LoROM: offset 32704
HiROM: offset 65472
Game title (21 bytes)
The title is in upper case on most games.
ROM makeup (1 byte)
Upper nibble (4 bits):
Value ROM speed
0 SlowROM (200ns)
3 FastROM (120ns)
Lower nibble (4 bits):
Value Bank size
0 LoROM (32kb banks)
1 HiROM (64kb banks)
ROM type (1 byte)
Byte ROM type
0 ROM only
1 ROM and RAM
2 ROM and Save RAM
3 ROM and DSP1 chip
4 ROM, RAM and DSP1 chip
5 ROM, Save RAM and DSP1 chip
19 ROM and Super FX chip
227 ROM, RAM and GameBoy data
246 ROM and DSP2 chip
ROM size (1 byte)
Byte ROM size
8 2 MegaBits
9 4 MegaBits
10 8 MegaBits
11 16 MegaBits
12 32 MegaBits
At the time of writing, the largest SNES game is 48Mbit, while 8Mbit
cartridges are the most common. There are cartridge sizes of 10Mbit,
12Mbit, 20Mbit and 24Mbit, which are reported as 16Mbit, 16Mbit, 16Mbit and
32Mbit respectively.
Another way of calculating the ROM size is: 1 shl (ROMbyte-7) MegaBits
SRAM size (1 byte)
Byte SRAM size
0 (none)
1 16 KiloBits
2 32 KiloBits
3 64 KiloBits
64 KiloBit SRAM's are the largest Nintendo uses (except DOOM?), while most
copiers have 256 kiloBits on-board.
Another way of calculating the SRAM size is: 1 shl (SRAMbyte+3) KiloBits
Country (1 byte)
Byte Country Video system
0 Japan NTSC
1 USA NTSC
2 Australia, Europe, Oceania and Asia PAL
3 Sweden PAL
4 Finland PAL
5 Denmark PAL
6 France PAL
7 Holland PAL
8 Spain PAL
9 Germany, Austria and Switzerland PAL
10 Italy PAL
11 Hong Kong and China PAL
12 Indonesia PAL
13 Korea PAL
License (1 byte)
Byte Company Byte Company
1 Nintendo 131 Lozc
3 Imagineer-Zoom 132 Koei
5 Zamuse 134 Tokuma Shoten Intermedia
6 Falcom 136 DATAM-Polystar
8 Capcom 139 Bullet-Proof Software
9 HOT-B 140 Vic Tokai
10 Jaleco 142 Character Soft
11 Coconuts 143 I''Max
12 Rage Software 144 Takara
14 Technos 145 CHUN Soft
15 Mebio Software 146 Video System Co., Ltd.
18 Gremlin Graphics 147 BEC
19 Electronic Arts 149 Varie
21 COBRA Team 151 Kaneco
22 Human/Field 153 Pack in Video
23 KOEI 154 Nichibutsu
24 Hudson Soft 155 TECMO
26 Yanoman 156 Imagineer Co.
28 Tecmo 160 Telenet
30 Open System 164 Konami
31 Virgin Games 165 K.Amusement Leasing Co.
32 KSS 167 Takara
33 Sunsoft 169 Technos Jap.
34 POW 170 JVC
35 Micro World 172 Toei Animation
38 Enix 173 Toho
39 Loriciel/Electro Brain 175 Namco Ltd.
40 Kemco 177 ASCII Co. Activison
41 Seta Co.,Ltd. 178 BanDai America
45 Visit Co.,Ltd. 180 Enix
49 Carrozzeria 182 Halken
50 Dynamic 186 Culture Brain
51 Nintendo 187 Sunsoft
52 Magifact 188 Toshiba EMI
53 Hect 189 Sony Imagesoft
60 Empire Software 191 Sammy
61 Loriciel 192 Taito
64 Seika Corp. 194 Kemco
65 UBI Soft 195 Square
70 System 3 196 Tokuma Soft
71 Spectrum Holobyte 197 Data East
73 Irem 198 Tonkin House
75 Raya Systems/Sculptured Software 200 KOEI
76 Renovation Products 202 Konami USA
77 Malibu Games/Black Pearl 203 NTVIC
79 U.S. Gold 205 Meldac
80 Absolute Entertainment 206 Pony Canyon
81 Acclaim 207 Sotsu Agency/Sunrise
82 Activision 208 Disco/Taito
83 American Sammy 209 Sofel
84 GameTek 210 Quest Corp.
85 Hi Tech Expressions 211 Sigma
86 LJN Toys 214 Naxat
90 Mindscape 216 Capcom Co., Ltd.
93 Tradewest 217 Banpresto
95 American Softworks Corp. 218 Tomy
96 Titus 219 Acclaim
97 Virgin Interactive Entertainment 221 NCS
98 Maxis 222 Human Entertainment
103 Ocean 223 Altron
105 Electronic Arts 224 Jaleco
107 Laser Beam 226 Yutaka
110 Elite 228 T&ESoft
111 Electro Brain 229 EPOCH Co.,Ltd.
112 Infogrames 231 Athena
113 Interplay 232 Asmik
114 LucasArts 233 Natsume
115 Parker Brothers 234 King Records
117 STORM 235 Atlus
120 THQ Software 236 Sony Music Entertainment
121 Accolade Inc. 238 IGS
122 Triffix Entertainment 241 Motown Software
124 Microprose 242 Left Field Entertainment
127 Kemco 243 Beam Software
128 Misawa 244 Tec Magik
129 Teichio 249 Cybersoft
130 Namco Ltd. 255 Hudson Soft
Game Version (1 byte)
The version is stored as version 1.VersionByte and must be less than 128.
i.e. Less than 1.128.
Inverse ROM Checksum (2 bytes)
This is the same as XORing the two checksum bytes. i.e. The checksum bits
are inversed.
ROM Checksum (2 bytes)
The checksum is a 16bit word with the lower 8bits stored first, followed by
the upper 8bits.
The checksum is calculated by dividing the ROM into 4Mbit chunks then
adding all the bytes in these chunks together. Once you have the checksum
for each chunk, add them together and take the lower 32bits of the result.
With a non-standard image size, you do not get it equally divisible by
4Mbit (excluding 2Mbit images). e.g. 10Mbit = 4Mbit + 4Mbit + 2Mbit chunks.
Therefore, you must create a 4Mbit chunk from what is left over. Using the
same example, you would add the checksum of the following chunks to get the
ROM checksum:
4Mbit + 4Mbit + (2Mbit + 2Mbit)
or
4Mbit + 4Mbit + (2 x 2Mbit)
Non Maskable Interrupt / VBL Vector (2 bytes)
LoROM: at offset 33274
HiROM: at offset 66042
Reset Vector (2 bytes)
Where to start the ROM code.
LoROM: at offset 33276
HiROM: at offset 66042
How do I know if the ROM is HiROM or LoROM?
When you OR the checksum bytes of a disk image and the inverse checksum
bytes, the result should be FFFF hex. Therefore, to detect whether an image
is HiROM or LoROM, you must read those bytes, OR them, and see if they
equal FFFF hex.
The ROM's type depends at which location the OR'd bytes equal FFFF hex. If
it isn't found at either location, then the other way of checking is to see
at which location the title contains uppercase alphanumeric characters.
(But this fails with most Japanese cartridges)
Why don't you use the ROM Makeup Byte? You can, and some utilities do, but
some utilities allow you to change this byte, so incorrect results may
occur.
For the actual ROM, the embedded cartridge information is stored at the
same position for both LoROM and HiROM. In this case, you must use the ROM
Makeup Byte or read a 64kb page and see if both 32kb chunks (upper and
lower 32kb) are the same. If they are the same, it is LoROM (32kb pages -
A15 is not used, the data repeats itself) otherwise it is HiROM.
As a general rule of thumb, if you can't detect which ROM type it is,
default to LoROM, as these are the most common of cartridges.
Cheat Device Decoding
We'll start with the easiest first then work our way down. These codes work
by replacing a byte at a specific location in the ROM.
E.g. In the game F-Zero, at a particular position in the ROM, there is a
number 3 indicating 3 lives to start off with. What a cheat code will do is
replace this byte with, let's say, the number 9, so now when the game is
run, the player starts off with 9 lives.
Pro Action Replay (hardware)
Code format: AAAAAADD (8 digits)
A - Address
D - Data
These codes are in Hex, the address being a CPU address, not a direct ROM
location (more about this later).
Gold Finger (software)
Code format: AAAAADDDDDDCCW (14 digits)
A - Address
D - Data
C - Checksum
W - What to change (DRAM or SRAM)
This code was designed for the copiers, and are straight Hex characters.
Therefore the Address is a ROM address, not a CPU address. Data bytes are
arranged in 2 characters (2 D's per byte), which allows for 3 bytes. If a
byte is not being used, it is denoted by 'XX'. I have never seen a code
with three unused bytes - what's the point of one anyhow?
The address (A's) is a base address. The first data byte (D's) is to be
placed at this address. The second at address+1, the third at address+2 (if
to be used, that is, if they are not 'XX').
To calculate the checksum you must take the A's and D's, add a zero (0) to
the front of the shortened code, then divide into block's of 2 hex digits
(bytes). Add these hex digits together (2 characters per hex digit) then
minus 160 hex (352 decimal). Now AND this number by FF hex (255 decimal) to
get the lower 8 bits (byte). Convert this number to hex and you have your
checksum (C's).
W tells the copier whether to replace the byte in the DRAM (ROM image) or
the SRAM (Saved game static RAM) of the copier.
Value of W Where to place byte
0 DRAM (ROM image)
1 SRAM (Saved game image)
The rec.games.video FAQ specifies that there may be non- standard values of
2, 8, A, C, F for W, which may be converted to 0. I personally have only
seen Gold Finger codes with W = 0.
Game Genie (hardware)
Code format: DDAA-AAAA (8 digits)
A - Address
D - Data
This is the most difficult code to decipher out of the lot. It is as
follows:
First take the code in the form xxxx-xxxx and take out the dash ('-') to
form xxxxxxxx. Convert these characters (Genie Hex) to normal hex
characters using the following table:
Genie Hex: D F 4 7 0 9 1 5 6 B C 8 A 2 3 E
Normal Hex: 0 1 2 3 4 5 6 7 8 9 A B C D E F
The first two characters is the data byte in Hex. Now take the other 6
following characters (encoded address) and put it into it's binary form of
24 bits.
Now take each bit of the encoded address and rearrange to form the real
address:
24bit encoded address: ijklqrst opabcduv wxefghmn
8bit encoded data: ABCDEFGH
Rearrange as:
24bit address : 8bit data
abcdefgh ijklmnop qrstuvwx: ABCDEFGH
MSB LSB MSB LSB
Bit 23 of the encoded address (bit 15 of the real address) is always 1. The
reason being that the SNES CPU address must be 1 for it to access the ROM.
Converting between CPU addresses and ROM addresses
This is very easy once you understand how it is done. To convert from a CPU
address to a ROM address, all you need to do is remove bit 15. By doing
this, I don't mean just setting it to 0. I mean by removing it, then moving
all bits after it down one.
e.g. ROMaddress = (CPUaddress and 7FFFh) or ((CPUaddress and FF0000h) shl 1)
Therefore, to convert from a ROM address to a CPU address, you must insert
a high bit into position 15 (bit 15).
e.g. CPUaddress = (ROMaddress and 7FFFh) or ((ROMaddress and 7F8000h) shr 1) or 8000h
Easily converting between codes
I have made available two DOS programs with source code on my WWW pages
which allow you to convert between Game Genie and Gold Finger codes. These
are available freely from http://www.parodius.com/~diskdude/CartDisk/.
Note: Because the Gold Finger can only address upto 8Mbit of game data,
while other codes can address upto 64Mbit of game data, some Game Genie and
Action Replay codes may not be converted to Gold Finger.
SNES Copiers
What are copiers?
A copier is a device which sits on top of the SNES and allows you to backup
your cartridges as well as play your backed up games. It does this by
storing the ROM image of a cartridge to floppy disks via a 1.44Mb disk
drive. Most copiers also include a parallel PC port interface, allowing
your PC to control the unit and store images on your hard drive.
Copier's contain DRAM from 1 Megabyte to 16 Megabytes, 8MegaBits to
128MegaBits respectively. This is the reason why they are so expensive.
It is legal to own and use a copier for your own personal backup of
cartridges which you legally own in this point in time, although it is
illegal to distribute this copy (only one copy is allowed). This may vary
depending on where you live.
If you wish to make your own "home brew" copier for the SNES, and other
consoles, more information can be found at
http://www.parodius.com/~diskdude/CartDisk/.
Super Wild Card (SWC) header information
The SWC (Super Wild Card) image format consists of a 512 byte header. It's
layout is as follows (set unused bytes to 00h):
Offset Function
0 Lower 8 bits of size word
1 Upper 8 bits of size word
2 Image information byte
8 SWC header identifier (set to AAh)
9 SWC header identifier (set to BBh)
10 SWC header identifier (set to 04h)
The size word is calculated by multiplying the image size, not game size
(in MegaBits) by 16. e.g. Image is 4 Mbits, so size word would be 4*16=64.
Image information byte (in the form of 76543210):
Bit Description
7 1 - Run program in Mode 0 (JMP $8000)
0 - Run program in Mode 1 (JMP RESET Vector)
6 1 - Multi image (there is another split file to follow)
0 - Not multi image (no more split files to follow)
5 1 - SRAM memory mapping Mode 21 (HiROM)
0 - SRAM memory mapping Mode 20
4 1 - DRAM memory mapping Mode 21 (HiROM)
0 - DRAM memory mapping Mode 20
3/2 00: 256kbit SRAM
01: 65kbit SRAM
10: 16kbit SRAM
11: no SRAM
1/0 reserved
Pro Fighter (FIG) header format
This format is similar to the SWC. It consists of a 512byte header who's
layout is as follows (set unused bytes to 00h):
Offset Function
0 Lower 8 bits of size word
1 Upper 8 bits of size word
2 40h - Multi image
00h - Last image in set (or single image)
3 80h - if HiROM
00h - if LoROM
4 If using DSP1 microchip:
FDh - If using SRAM (SRAM size>0)
47h - If no SRAM (SRAM size=0)
77h - If not using DSP1 and no SRAM (SRAM size=0)
5 If using DSP1 microchip:
82h - If using SRAM (SRAM size>0)
83h - If no SRAM (SRAM size=0)
83h - If not using DSP1 and no SRAM (SRAM size=0)
Game Doctor file name format
The Game Doctor does not use a 512 byte header like the SWC, instead it
uses specially designed filenames to distinguish between multi files. I'm
not sure if it used the filename for information about the size of the
image though.
Usually, the filename is in the format of: SFXXYYYZ.078
Where SF means Super Famicon, XX refers to the size of the image in Mbit.
If the size is only one character (i.e. 2, 4 or 8 Mbit) then no leading "0"
is inserted.
YYY refers to a catalogue number in Hong Kong shops identifying the game
title. (0 is Super Mario World, 1 is F- Zero, etc). I was told that the
Game Doctor copier produces a random number when backing up games.
Z indicates a multi file. Like XX, if it isn't used it's ignored.
A would indicate the first file, B the second, etc. I am told 078 is not
needed, but is placed on the end of the filename by systems in Asia.
e.g. The first 16Mbit file of Donkey Kong Country (assuming it is cat. no.
475) would look like: SF16475A.078
Super Wild Card parallel port I/O protocol
I was given this information a while ago. It is supposed to be direct from
the company which makes SWC's and I have included this information because
a few people have been asking for it. If you have similar information for
other backup devices, it would be appreciated if you could send it to me.
[PROTOCOL USED IN PC]
* BYTE OUTPUT PROCEDURE
WAIT BUSY BIT = 1 STATUS PORT BIT7 (HEX n79, n7D)
WRITE ONE BYTE DATA LATCH (HEX n78, n7C)
REVERSE STROBE BIT CONTROL PORT BIT0 (HEX n7A, n7E)
* BYTE INPUT PROCEDURE
WAIT BUSY BIT = 0 STATUS PORT BIT7 (HEX n79, n7D)
READ LOW 4 BITS OF BYTE STATUS PORT BIT3-6 (HEX n79, n7D)
REVERSE STROBE BIT CONTROL PORT BIT0 (HEX n7A, n7E)
WAIT BUSY BIT = 0 STATUS PORT BIT7 (HEX n79, n7D)
READ HIGH 4 BITS OF BYTE STATUS PORT BIT3-6 (HEX n79, n7D)
REVERSE STROBE BIT CONTROL PORT BIT0 (HEX n7A, n7E)
* 5 TYPES OF COMMAND
* COMMAND LENGTH = 9 BYTES.
* COMMAND FORMAT
BYTE 1 D5 ID CODE 1
BYTE 2 AA ID CODE 2
BYTE 3 96 ID CODE 3
BYTE 4 00|01|04|05|06 COMMAND CODE
BYTE 5 al LOW BYTE OF ADDRESS
BYTE 6 ah HIGH BYTE OF ADDRESS
BYTE 7 ll LOW BYTE OF DATA LENGTH
BYTE 8 lh HIGH BYTE OF DATA LENGTH
BYTE 9 cc CHECKSUM = 81^BYTE4^BYTE5^BYTE6^BYTE7^BYTE8
* COMMAND [00] : DOWNLOAD DATA
al, ah = ADDRESS
ll, lh = DATA LENGTH
OUTPUT DATAS AFTER COMMAND
* COMMAND [01] : UPLOAD DATA
al, ah = ADDRESS
ll, lh = DATA LENGTH
INPUT DATAS AFTER COMMAND
* COMMAND [04] : FORCE SFC PROGRAM TO JMP
al, ah = ADDRESS
* COMMAND [05] : SET MEMORY PAGE NUMBER
al BIT0-1 = PAGE NUMBER
al BIT2-7 + ah BIT0-1 = BANK NUMBER
* COMMAND [06] : SUB FUNCTION
al = 0 INITIAL DEVICE
al = 1 PLAY GAME IN DRAM
al = 2 PLAY CARTRIDGE
ROM Protection Schemes
This section details ways of bypassing the FastROM, PAL/NTSC and SRAM size
checks implemented in many SNES games in order to stop people backing them
up using copiers.
Note: You don't necessarily have to find and replace all strings to remove
the check(s).
SlowROM checks
Most cartridges these days use 120ns ROM in order to get the most out of
the ageing SNES. However, there are still many copiers around which emulate
ROM at speeds of 200ns meaning they cannot backup the newer cartridges
correctly.
Changing the ROM code to bypass the SlowROM check, found in many, but not
all FastROM games, allows many people with SlowROM copiers to backup
FastROM games.
To patch a ROM and bypass the SlowROM check, you must find any of the
following strings in the image and replace it with the patch string: (all
codes in hex)
Search for Replace with
A9 01 8D 0D 42 A9 00 8D 0D 42
A9 01 8E 0D 42 A9 00 8E 0D 42
A2 01 8D 0D 42 A2 00 8D 0D 42
A2 01 8E 0D 42 A2 00 8E 0D 42
A9 01 00 8D 0D 42 A9 00 00 8D 0D 42
A9 01 8F 0D 42 00 A9 00 8F 0D 42 00
PAL/NTSC checks
Most SNES games have code which detects which video system the cartridge is
being played on and refuses to run if not in the right mode. This is to
stop people from buying games from other countries before they are released
locally.
To bypass the PAL/NTSC check the following patterns must be found and
replaced with the ones specified: (all codes in hex)
Search for Replace with
3F 21 29 10 C9 10 F0 3F 21 29 10 C9 10 80
3F 21 89 10 C9 10 F0 3F 21 89 10 C9 10 80
3F 21 29 10 F0 3F 21 29 10 80
3F 21 00 89 10 F0 3F 21 00 89 10 80
3F 21 00 29 10 F0 3F 21 00 29 10 80
3F 21 89 10 00 F0 3F 21 89 10 00 80
3F 21 29 10 00 F0 3F 21 29 10 00 80
AD 3F 21 29 10 00 D0 AD 3F 21 29 10 00 80
AF 3F 21 00 29 10 D0 AF 3F 21 00 29 10 80
AF 3F 21 00 29 10 00 D0 AF 3F 21 00 29 10 00 EA EA
AD 3F 21 29 10 D0 AD 3F 21 29 10 EA EA
AD 3F 21 29 10 F0 AD 3F 21 29 10 80
AD 3F 21 89 10 D0 AD 3F 21 89 10 80
AD 3F 21 29 10 C9 00 F0 AD 3F 21 29 10 C9 00 80
AF 3F 21 00 29 10 00 F0 AF 3F 21 00 29 10 00 80
AF 3F 21 00 89 10 00 F0 AF 3F 21 00 89 10 00 80
SRAM size checks
Some SNES games check to see how much SRAM is connected to the SNES as a
form of copy protection. As most copiers have 256kbits standard, the game
will know it's running on a backup unit and stop to prevent people copying
the games. However, the newer copiers get around this detection somehow.
To disable the SRAM size check in a ROM image, search for the following and
replace as appropriate.
Note: All codes are in hex, although 'xx' means anything, while a comma
means search for either of the two or more (enclosed in brackets).
Search for (8F, 9F) xx xx 70 (CF, DF) xx xx 70 D0
Replace with (8F, 9F) xx xx 70 (CF, DF) xx xx 70 EA EA (if SRAM size of game = 64kbit)
(8F, 9F) xx xx 70 (CF, DF) xx xx 70 80 (if SRAM size of game <> 64kbit)
Search for (8F, 9F) xx xx (30, 31, 32, 33) (CF, DF) xx xx (30, 31, 32, 33) D0
Replace with (8F, 9F) xx xx (30, 31, 32, 33) (CF, DF) xx xx (30, 31, 32, 33) 80
Search for (8F, 9F) xx xx (30, 31, 32, 33) (CF, DF) xx xx (30, 31, 32, 33) F0
Replace with (8F, 9F) xx xx (30, 31, 32, 33) (CF, DF) xx xx (30, 31, 32, 33) EA EA
Search for (8F, 9F) xx xx (30, 31, 32, 33) AF xx xx (30, 31, 32, 33) C9 xx xx D0
Replace with (8F, 9F) xx xx (30, 31, 32, 33) AF xx xx (30, 31, 32, 33) C9 xx xx 80
Many thanks to Chp for making his uCON v1.41 source publicly available,
from which these patterns came.
IPS Patch Format
This patch format is used a lot for patching SNES ROM images. Therefore I
have included it's format in this text. For a more detailed explanation of
the IPS format, please visit the Damaged Cybernetics WWW pages
http://www.futureone.com/~damaged/.
The format is as follows:
Description Size
IPS file identifier 5 bytes (characters PATCH)
Offset in file to place patch 3 bytes
Number of bytes in patch 2 bytes (allows 65535 patch bytes)
Patch byte(s) (specified by 'No. of bytes in patch')
. .
. .
Start again, looking 3 bytes (characters EOF)
for new offset, unless
and EOF is found.
Sample IPS file contents with 2 offset points:
PATCHooonn?ooonn?EOF
o - Offset in file
n - Number of bytes in patch
? - Data byte(s) (n number of bytes)
Acknowledgements
The following people have contributed to this text, whether they know it or
not. Many thanks to them for their wonderful contribution(s).
Donald Moore (moore@futureone.com)
Chp (ronaldm@netcom.com)
Thomas Rolfes (Thomas_Rolfes@ms.maus.de)
Jeremy Chadwick(yoshi@parodius.com)
Nigel Bryant (nbb@essex.ac.uk)
Also used for the creation of this text was the rec.games.video Frequently
Asked Questions (FAQ) file; a FAQ with a huge amount of information on
consoles in general.
[Image]
Special thanks to Mark for the midi!
[Image]
Questions, comments or complaints can be sent to DiskDude via e-mail.
Copyright � 1995-1996 DiskDude of Damaged Cybernetics. All rights reserved.
Last updated 1st January 1997
Damaged Cybernetics is not connected or affiliated with any mentioned
company in any way. The opinions of Damaged Cybernetics do not reflect the
views of the various companies mentioned here. Companies and all products
pertaining to that company are trademarks of that company. Please contact
that company for trademark and copyright information.
