Wiki - GameHacking.org - User contributions [en]

Assembly Hacking

2010-04-18T02:15:07Z

Ugetab: /* FCEU */ NSF program suggestion changed

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://fceux.com FCEUX] is the most up-to-date version of the FCEU* line of builds. It has taken several lines of FCEU offshoots and combined them into a single application. Even I(ugetab) have had the opportunity to contribute code, changes and fixes to it. If you were having trouble with any games while using FCEUXDSP, you can try FCEUX. If FCEUX has trouble with games, you can report the issue and, if someone gets interested in fixing it, you may end up seeing it repaired. It is currently compatible with FCEUXDSP's debugger files. If you want to use FCEUXDSP, see below.

[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of an emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, FCEUX is currently the best option.

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

F10 = Reset 
F11 = Hard Reset (Power Switch style)

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) (Type new values after original, press enter. Quicker.) 
Space = Set/Unset Execution Breakpoint 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints (Enter EA for "NOP", etc. Use 6502 ASM table mainly)

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

SA1

2010-03-25T05:34:59Z

Ugetab: Added a new mapping possibility to 'Memory Mapping Comparison'

== Overview ==
The SNES SA1 chip is an expansion chip added to an SNES cart that both contains a portion of the game's coding, and executes that portion of code to affect normal SNES RAM, and the additional RAM accessed primarily by the SA1 chip programming. The additional RAM is also accessible by the SNES CPU's instructions.

There is no current information concerning hardware-based tests with Game Genie codes that change portions of ROM residing within the SA1.

== Memory Mapping Comparison ==
Region 30:0000 - 30:3FFF is SA1 related due to the fact that some RAM is 00 mapped for SA1-using games:

Writes from the SNES CPU to 00:0000 - 00:3FFF region to change a mirrored region at 30:0000 - 30:3FFF region

00:0000 - 00:3FFF 
30:0000 - 30:3FFF

SA1 code such as "STA $DE" can access address 00:30DE, and show up in the log file as a line like... 
$C2:D286 85 DE . STA $DE . [$00:00DE]

The above may not always hold true, but it should be known that not all addresses will appear exactly as expected. 

SA1 Address:
Reads/Writes to these addresses from the SA1 CPU translate to the below CPU-accessible addresses in SNES memory 
00:4000 - 00:7FFF 
CPU Address: 
40:0000 - 40:3FFF 

Jikkyuu Oshaberi Parodius has the following in the SNES native CPU as well: 
00:676C writes going to 40:076C 

SA1 Address Testing: 
If you wish to test writes made by the SA1 to memory, and see what area is changed, you can use the following code with Super Mario RPG (US), while in a 3D stage. You should fall through the ground, and be unaligned with the map, but have the value FE written to the address you chose.

Test SA1 Memory Writes (2 byte addresses, 0xFE written) 
C9C374A9 
C9C375FE 
C9C378FF 
C9C3793F

Load value 0x00FE to write(could be made to load a 2-byte value) 
C9C374A9 
C9C375FE

Address to write to(Writes to 3FFF with these values) 
C9C378FF 
C9C3793F

[[Category:Hacking and Game Info]]

Assembly Hacking

2010-02-02T20:30:57Z

Ugetab: /* FCEU */ Added a link and notes on FCEUX

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://fceux.com FCEUX] is the most up-to-date version of the FCEU* line of builds. It has taken several lines of FCEU offshoots and combined them into a single application. Even I(ugetab) have had the opportunity to contribute code, changes and fixes to it. If you were having trouble with any games while using FCEUXDSP, you can try FCEUX. If FCEUX has trouble with games, you can report the issue and, if someone gets interested in fixing it, you may end up seeing it repaired. It is currently compatible with FCEUXDSP's debugger files. If you want to use FCEUXDSP, see below.

[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of an emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

F10 = Reset 
F11 = Hard Reset (Power Switch style)

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) (Type new values after original, press enter. Quicker.) 
Space = Set/Unset Execution Breakpoint 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints (Enter EA for "NOP", etc. Use 6502 ASM table mainly)

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Music Ripping

2009-08-29T01:37:11Z

Ugetab: /* NES - NSF (Nintendo Sound Format) */ Fleshed out DPCM a bit. Good reference info.

This is just a basic set of quick-start info for getting into any given format that someone is willing to provide information for.

It's not meant to be comprehensive, but just informative enough to give you something to quickly refer to until you can easily recall the basic information for actually finding the addresses.

Debugger-specific information can normally be found on the [[Assembly Hacking]] page.

I use the following code set distinctions: 
Sound Init (Basic register initialization. Often close to Song Init and/or Play address. Not all games use a distinctive Sound Init. Some run Play once or several times before running Song Init to achieve Sound Init) 
Song Init (If you feed this address the right number in the right register, sounds or music are played by the Play routine) 
Play (Executes the sound generation code, also good if you enter this by using sound registers and find RAM addresses related to sound to breakpoint for Song Init)

==NES - NSF (Nintendo Sound Format)==
I suggest FCEUXDSP: [[Assembly_Hacking#FCEU]]

$4000-$4009 = Sound Registers (Good for finding Play) 
$4010-$4013 = DMC / DPCM (This is a tricky addon. References info from $C000-$FFFF, and FCEUXDSP won't catch it reading this data unless you break on writes to $4012 for the start position '0x40 * value + 0xC000' and/or $4013 for length '(0x10 * value) + 1') 
$4015 = Channel Select (Good for finding Sound Init, sometimes Play) 
$4017 = Frame Cycle/Interrupt (If this is written once, write it once in the NSF with the value written. If it's written once for every time play is run, do that in the NSF. Match in the NSF any setup used in the original game. Games sound a bit off if you don't, and you might not notice on your own)

==Gameboy - GBS (Gameboy Sound Format)==
I suggest BGB: [[Assembly_Hacking#BGB]]

$FF24 = Volume (Good for finding Sound Init, sometimes Play) 
$FF25 = L/R (00 often means a failed init. Visible in BGB) 
$FF26 = Channel On/Off (00 often means a failed init. Visible in BGB) 

$FF13 = A good register to find Play with (Try $FF18/$FF1D/$FF22 if it doesn't break on $FF13)

$FF10-$FF23 Sound Register spread

==PC Engine / Turbo-Grafx 16 - HES (Hudson Entertainment System)==
I suggest Mednafen: [[Assembly_Hacking#Mednafen]]

[http://pages.interlog.com/~daves/pce_info/pcesound.txt Source for below]

$0800 = Voice Select (Good for sound init) 
$0801 = Main Volume (Probably also good for sound init) 
$0802 - Frequency (low) 
$0803 - Frequency (high) 
$0804 - Channel on/dda/volume - voice-dependent register 
$0805 - Pan volume ('balance') - voice-dependent register 
$0806 - Wave data 
$0807 = Note Frequency (Good for finding Play, which is itself good for finding Song Init by matching up to Sound RAM Addresses) 
$0808 - LFO Frequency 
$0809 - LFO Control

==N64 - USF (Ultra 64 Sound Format)==
I primarily suggest NEmu64: [[Assembly_Hacking#Nemu64]]

This is a considerably different bag of tricks to use.

I've written out a decent guide, and even put together some tool modifications to make the job easier. Check out usfbegin.txt for more in-depth info. The folder with this info is [http://www.gshi.org/ugetab/USF/ here]

AM_RANGE(0x04500000, 0x045fffff) AM_READWRITE(n64_ai_reg_r, n64_ai_reg_w) // Audio Interface

04500004 = When you hit this, step out until you're in an infinite loop, and you should be in the Play thread. Mark it down as such, so you know not to disable it completely.

If you break on the opcode "ERET", then you can fairly easily build a list of threads to crash-test, until you've killed off all of them that won't kill the music.

Finding music inits is considerably tougher in N64 coding. I usually brute-force my way. Play through the Play routine to find RAM, use File2File methods, sometimes both... Not exactly a walk in the park, but it's the best I've found, and it's just for the Init code that this needs to be done. Sound Tests make this a lot easier, because the value has to get from the temporary one in RAM to the sound routine in some fashion, and the temporary one used in a sound test is considerably easier to find with File2File and track through code than the pure coding method is.

04040010 is written to for DList events. In Kirby64, it uses 00002B00 for this. This can help you remove graphics processing code. Note that not all writes to this are for graphics, and can crash the music if accesses are just outright removed.

Music Ripping

2009-08-28T20:28:42Z

Ugetab: Tagged HES with the acronym meaning

This is just a basic set of quick-start info for getting into any given format that someone is willing to provide information for.

It's not meant to be comprehensive, but just informative enough to give you something to quickly refer to until you can easily recall the basic information for actually finding the addresses.

Debugger-specific information can normally be found on the [[Assembly Hacking]] page.

I use the following code set distinctions: 
Sound Init (Basic register initialization. Often close to Song Init and/or Play address. Not all games use a distinctive Sound Init. Some run Play once or several times before running Song Init to achieve Sound Init) 
Song Init (If you feed this address the right number in the right register, sounds or music are played by the Play routine) 
Play (Executes the sound generation code, also good if you enter this by using sound registers and find RAM addresses related to sound to breakpoint for Song Init)

==NES - NSF (Nintendo Sound Format)==
I suggest FCEUXDSP: [[Assembly_Hacking#FCEU]]

$4000-$4009 = Sound Registers (Good for finding Play) 
$4010-$4013 = DMC / DPCM (This is a tricky addon. References info from $C000-$FFFF, and FCEUXDSP won't catch it reading this data unless you break on $4012/$4013 writes here) 
$4015 = Channel Select (Good for finding Sound Init, sometimes Play) 
$4017 = Frame Cycle/Interrupt (If this is written once, write it once in the NSF with the value written. If it's written once for every time play is run, do that in the NSF. Match in the NSF any setup used in the original game. Games sound a bit off if you don't, and you might not notice on your own)

==Gameboy - GBS (Gameboy Sound Format)==
I suggest BGB: [[Assembly_Hacking#BGB]]

$FF24 = Volume (Good for finding Sound Init, sometimes Play) 
$FF25 = L/R (00 often means a failed init. Visible in BGB) 
$FF26 = Channel On/Off (00 often means a failed init. Visible in BGB) 

$FF13 = A good register to find Play with (Try $FF18/$FF1D/$FF22 if it doesn't break on $FF13)

$FF10-$FF23 Sound Register spread

==PC Engine / Turbo-Grafx 16 - HES (Hudson Entertainment System)==
I suggest Mednafen: [[Assembly_Hacking#Mednafen]]

[http://pages.interlog.com/~daves/pce_info/pcesound.txt Source for below]

$0800 = Voice Select (Good for sound init) 
$0801 = Main Volume (Probably also good for sound init) 
$0802 - Frequency (low) 
$0803 - Frequency (high) 
$0804 - Channel on/dda/volume - voice-dependent register 
$0805 - Pan volume ('balance') - voice-dependent register 
$0806 - Wave data 
$0807 = Note Frequency (Good for finding Play, which is itself good for finding Song Init by matching up to Sound RAM Addresses) 
$0808 - LFO Frequency 
$0809 - LFO Control

==N64 - USF (Ultra 64 Sound Format)==
I primarily suggest NEmu64: [[Assembly_Hacking#Nemu64]]

This is a considerably different bag of tricks to use.

I've written out a decent guide, and even put together some tool modifications to make the job easier. Check out usfbegin.txt for more in-depth info. The folder with this info is [http://www.gshi.org/ugetab/USF/ here]

AM_RANGE(0x04500000, 0x045fffff) AM_READWRITE(n64_ai_reg_r, n64_ai_reg_w) // Audio Interface

04500004 = When you hit this, step out until you're in an infinite loop, and you should be in the Play thread. Mark it down as such, so you know not to disable it completely.

If you break on the opcode "ERET", then you can fairly easily build a list of threads to crash-test, until you've killed off all of them that won't kill the music.

Finding music inits is considerably tougher in N64 coding. I usually brute-force my way. Play through the Play routine to find RAM, use File2File methods, sometimes both... Not exactly a walk in the park, but it's the best I've found, and it's just for the Init code that this needs to be done. Sound Tests make this a lot easier, because the value has to get from the temporary one in RAM to the sound routine in some fashion, and the temporary one used in a sound test is considerably easier to find with File2File and track through code than the pure coding method is.

04040010 is written to for DList events. In Kirby64, it uses 00002B00 for this. This can help you remove graphics processing code. Note that not all writes to this are for graphics, and can crash the music if accesses are just outright removed.

Assembly Hacking

2009-08-27T15:41:24Z

Ugetab: /* Mednafen */ F12 exited by default. Changed the settings to just remove escape from use

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

F10 = Reset 
F11 = Hard Reset (Power Switch style)

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) (Type new values after original, press enter. Quicker.) 
Space = Set/Unset Execution Breakpoint 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints (Enter EA for "NOP", etc. Use 6502 ASM table mainly)

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Music Ripping

2009-08-26T14:43:12Z

Ugetab: Created page with 'This is just a basic set of quick-start info for getting into any given format that someone is willing to provide information for. It's not meant to be comprehensive, but just i...'

This is just a basic set of quick-start info for getting into any given format that someone is willing to provide information for.

It's not meant to be comprehensive, but just informative enough to give you something to quickly refer to until you can easily recall the basic information for actually finding the addresses.

Debugger-specific information can normally be found on the [[Assembly Hacking]] page.

I use the following code set distinctions: 
Sound Init (Basic register initialization. Often close to Song Init and/or Play address. Not all games use a distinctive Sound Init. Some run Play once or several times before running Song Init to achieve Sound Init) 
Song Init (If you feed this address the right number in the right register, sounds or music are played by the Play routine) 
Play (Executes the sound generation code, also good if you enter this by using sound registers and find RAM addresses related to sound to breakpoint for Song Init)

==NES - NSF (Nintendo Sound Format)==
I suggest FCEUXDSP: [[Assembly_Hacking#FCEU]]

$4000-$4009 = Sound Registers (Good for finding Play) 
$4010-$4013 = DMC / DPCM (This is a tricky addon. References info from $C000-$FFFF, and FCEUXDSP won't catch it reading this data unless you break on $4012/$4013 writes here) 
$4015 = Channel Select (Good for finding Sound Init, sometimes Play) 
$4017 = Frame Cycle/Interrupt (If this is written once, write it once in the NSF with the value written. If it's written once for every time play is run, do that in the NSF. Match in the NSF any setup used in the original game. Games sound a bit off if you don't, and you might not notice on your own)

==Gameboy - GBS (Gameboy Sound Format)==
I suggest BGB: [[Assembly_Hacking#BGB]]

$FF24 = Volume (Good for finding Sound Init, sometimes Play) 
$FF25 = L/R (00 often means a failed init. Visible in BGB) 
$FF26 = Channel On/Off (00 often means a failed init. Visible in BGB) 

$FF13 = A good register to find Play with (Try $FF18/$FF1D/$FF22 if it doesn't break on $FF13)

$FF10-$FF23 Sound Register spread

==PC Engine / Turbo-Grafx 16 - HES==
I suggest Mednafen: [[Assembly_Hacking#Mednafen]]

[http://pages.interlog.com/~daves/pce_info/pcesound.txt Source for below]

$0800 = Voice Select (Good for sound init) 
$0801 = Main Volume (Probably also good for sound init) 
$0802 - Frequency (low) 
$0803 - Frequency (high) 
$0804 - Channel on/dda/volume - voice-dependent register 
$0805 - Pan volume ('balance') - voice-dependent register 
$0806 - Wave data 
$0807 = Note Frequency (Good for finding Play, which is itself good for finding Song Init by matching up to Sound RAM Addresses) 
$0808 - LFO Frequency 
$0809 - LFO Control

==N64 - USF (Ultra 64 Sound Format)==
I primarily suggest NEmu64: [[Assembly_Hacking#Nemu64]]

This is a considerably different bag of tricks to use.

I've written out a decent guide, and even put together some tool modifications to make the job easier. Check out usfbegin.txt for more in-depth info. The folder with this info is [http://www.gshi.org/ugetab/USF/ here]

AM_RANGE(0x04500000, 0x045fffff) AM_READWRITE(n64_ai_reg_r, n64_ai_reg_w) // Audio Interface

04500004 = When you hit this, step out until you're in an infinite loop, and you should be in the Play thread. Mark it down as such, so you know not to disable it completely.

If you break on the opcode "ERET", then you can fairly easily build a list of threads to crash-test, until you've killed off all of them that won't kill the music.

Finding music inits is considerably tougher in N64 coding. I usually brute-force my way. Play through the Play routine to find RAM, use File2File methods, sometimes both... Not exactly a walk in the park, but it's the best I've found, and it's just for the Init code that this needs to be done. Sound Tests make this a lot easier, because the value has to get from the temporary one in RAM to the sound routine in some fashion, and the temporary one used in a sound test is considerably easier to find with File2File and track through code than the pure coding method is.

04040010 is written to for DList events. In Kirby64, it uses 00002B00 for this. This can help you remove graphics processing code. Note that not all writes to this are for graphics, and can crash the music if accesses are just outright removed.

Assembly Hacking

2009-08-26T13:52:12Z

Ugetab: /* Mednafen */ More bits and bobs of info

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293~keyboard 123" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

F10 = Reset 
F11 = Hard Reset (Power Switch style)

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) (Type new values after original, press enter. Quicker.) 
Space = Set/Unset Execution Breakpoint 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints (Enter EA for "NOP", etc. Use 6502 ASM table mainly)

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-08-26T13:17:51Z

Ugetab: /* Mednafen */ (Forgot a debugging command)

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293~keyboard 123" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) 
Space = Set/Unset Execution Breakpoint 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-08-26T01:44:02Z

Ugetab: Added PC Engine/TG16 Debugger Info (Thinking of making some HES rips)

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==PC Engine / Turbo-Grafx 16==
===Mednafen===
This emulator can be found [http://mednafen.sourceforge.net/ here]

Esc = Exit Mednafen (Careful about it)

To use F12 to quit, and not the ESC key, edit this in mednafen.cfg: 
----
";Exit" 
"command.exit keyboard 293~keyboard 27" 
----
To this: 
----
";Exit" 
"command.exit keyboard 293~keyboard 123" 
----

F5 = Save State 
F7 = Load State 
0-9 = Select Save Slot

Alt + D = Toggle Debugger

In Debugger: 
Alt+1 = CPU debugger view 
Alt+3 = Memory editor 
R = Run 
S = Step 
Return = Goto Address(If on code)/Edit(If on register) 
Shift + Return = Edit watch address 
Shift + R = Edit Read Breakpoints 
Shift + W = Edit write breakpoints 
Shift + O = Opcode Breakpoints

See included Debugger.html file for complete command list

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-08-09T23:18:54Z

Ugetab: /* SNES */ - SuperFX logging emulator added

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

===FuSoYa's SNES9X SuperFX Instruction Logger===
This emulator can be found [http://www.gshi.org/downloads/snes9x1.43-FuSoYa-SFX_B2.zip here].

This emulator allows you to log SuperFX instructions being used by the emulator.

Press the NumLock button to start/stop logging.

Instructions will be logged to sfx_trace.txt, in the folder with the emulator.

Here's an example on how to interpret the results: 
00:e834 40 ldw (r0) r0=$0058 SRAM=00:5AAE 
00:e835 64 sub r4 r0=$0055 CY=1

First line Loads Word (SRAM=00:5AAE) to (r0). In Geiger's SNES9X Debugger, this is address 705AAE in the RAM viewer. In ZSNES, you can find this in a save-state at 0x4127F + 0x5AAE (= 0x46D2D). The result of this operation is on the same line.

Second line subtracts (r4) from (r0). This next result is on the same line as well. This can be coded out to give you Infinite Health in Doom, but it won't work as a Game Genie code. The file address would be either 6835 or 6A35. Only one address of those 2 will be 0x64.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-06-15T00:35:18Z

Ugetab: Visual Boy Tracer link added, spelling

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unnecessary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

===Visual Boy Advance Tracer===
See [[#Visual_Boy_Advance_Tracer_2]]

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still necessary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write check boxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-06-15T00:28:37Z

Ugetab: Game Gear/Master System debugger

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unneccesary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
===FCEU===
[http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP FCEUXDSP] is the result of a emulator first developed by Parasyte called FCEUD, which was then picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

====Setting breakpoints in ROM/RAM====
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try Ugetabs [http://www.angelfire.com/nc/ugetab edited version], which tends to play nicer with them

'Hex Editor' is a memory viewer/modifier.

==SNES==
===Geiger's SNES9X Debugger===
This emulator can be found at [http://geigercount.net/crypt/ Geiger's Crypt] and [http://www.zophar.net/snes/geiger-s-snes9x-debugger.html Zophar's Domain - Geiger’s Snes9x Debugger].

====Setting breakpoints in ROM/RAM====
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==

===Regen Debugger Build===
This emulator can be found [http://aamirm.hacking-cult.org/ here]

Backup: [http://www.gshi.org/downloads/Regen095D.zip Regen 0.95 Debugger]

If you've used FCEUXDSP, Geiger's Snes9x, BGB, Nemu08, pSX, or pretty much any other active debugger, you'll realize that this is along the same lines of those debuggers. This is certainly what Genesis hackers have been waiting for when it comes to a user friendly debugger.

It runs Genesis, Game Gear, and SMS files, but only debugs Genesis at the moment. Use [[#Emukon]] if you want to hack Game Gear or SMS.

===Gens Tracer===
This emulator can be found [http://www.romhacking.net/utils/337/ here].

No breakpoints, but adequate tracing. A guide has been written on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

===HazeMD===
This emulator can be found at [http://haze.mameworld.info/ this address].

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
===BGB===
This emulator can be found [http://bgb.bircd.org/ here]

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

Also, see below about Visual Boy Advance Tracer.

==Game Gear==
===Emukon===
This emulator can be found [http://emukon.kontechs.de/ here].

Backup: [http://www.gshi.org/downloads/Emukon105.zip Emukon 1.05]

This is basically a friendlier style of Logging Debugger the way I tend to use it, with Breakpoints to help figure out how code you find operates. I've used it to at least as much success as I've used the Hook_log debuggers, only this was more boring because I didn't have to fight with the emulator as much.

You can use a combination of Breakpoints and Log Files to debug games.

Breakpoints have their own management window, or you can right click lines in the debugger.

To use the log files effectively, you should focus on a single byte with a known effect, get to about where the setting you're looking for will change, go to the Debugger > Debugger menu, enable it if needed, then click the Clear Log button if you want a fresh start, and the Log button to start logging. Get the thing changed that you want, and then look under the DebugLogs folder for the game you're working on, and search the text logs for the address you want to check, whether it's the execution address by some chance or the memory address. Breakpoints and Logging work well together to discover the execution path to a piece of code.

It's not as exceedingly simple as some other debuggers, but it's quite useful, and it's my first choice for hacking Game Gear as well as SMS.

==Master System==
===Emukon===
See Game Gear section: [[#Emukon]]

==Gameboy Advance==
===Visual Boy Advance Tracer===
This emulator can be found [http://www.romhacking.net/utils/340/ here].

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. [[Ugetab]] used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, and it is still nessesary to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file.

===Visual Boy Advance===
This emulator can be found at [http://vba.ngemu.com/downloads.shtml this address].

Windows - SDL is required. Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats. Not documented.

==Playstation==
===PCSX 1.5 With Debugger===
This emulator is available [http://www.romhacking.net/utils/267/ here].

Press F11 to enter the debugger. On-screen aids should be apparent.

===PSX===
This emulator can be found at [http://www.romhacking.net/utils/311/ this address].

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

===PCSX Agemo debugger===
This emulator can be found [http://www.romhacking.net/utils/475/ here].

It could be favorable for some tasks, compared to the other debuggers.

==N64==
===Nemu64===
This emulator can be found [http://www.emulator-zone.com/doc.php/n64/nemu64.html here]

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write checkboxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes. The 1964 tracer can be useful, which is available [http://www.romhacking.net/utils/335/ here].

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

===Project64 debug build binary===
This emulator can be found [http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip here].

This version of the emulator has better support for games than Nemu64, and Ugetab used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
===Yabause===
This emulator can be found [http://www.romhacking.net/utils/482/ here].

This is one of the few Saturn emulators out there.

==Wonder Swan==
===Cygne Tracer===
This emulator can be found [http://www.romhacking.net/utils/244/ here].

A decent Tracing program.

===Oswan Tracer===
This emulator can be found [http://www.romhacking.net/utils/338/ here].

This is just another hook-log tracer.

==Playstation 2==
[The current author is too lazy to write this, but will get around to it later if no one else does]

[[Category:Hacking and Game Info]]

Assembly Hacking

2009-06-14T03:33:12Z

Ugetab: /* Genesis - Added Regen */

CRI ROFS

2009-05-31T18:11:54Z

Ugetab: Link names lost Jap chars

ROFS is a bulk data file structure developed by CRI Middleware Co., Ltd. It is greatly built off of the ISO-9660 standard. These are easily identified as having the file name extension of CVM.

__TOC__

== Random ==

Several official programs for handling CVM files are known to exist. Usage is not known and guessed below.

rofstoko.exe - ? Seemingly used to change existing data and perhaps conversion of some file types.
rofsedit.exe - ?
rofsgen.exe - ?
rofsbld.exe - ? Most likely the program used to compile an ROFS structure from a list of files.
rofsview.exe - ?

There are a few homemade programs created for interacting with CVM filesystems with various limited functionality.

'''Apache3''' - Badly named but effective for extracting the contents of a CVM (and several other disc image types such as GCM). It can also replace files inside the image. Has entirely no capacity to create new files from scratch.

[http://gshi.org/downloads/cvm_tools/apache3_setup.exe apache3_setup.exe v3.10.6 beta]

'''Daemon Tools (and some other disc mounting software)''' - If a 0x1800 block is removed from the start of the file, it can be mounted as a disc image. Other mounting utilities may not cooperate.

'''Abyss''' - A tiny custom tool made by darthi8nt for beating up the TO7BTL.cvm file from Tales Of The Abyss. It looks to be only for that specific file and no others.

[http://gshi.org/downloads/cvm_tools/abyss.zip abyss.zip]

[http://gshi.org/downloads/cvm_tools/abyss_update.zip abyss_update.zip]

'''VF4EXt_n_reb''' - Another tool from darthi8nt. Same deal as with Abyss, but for VF4STRMS.cvm on Virtua Fighter 4.

[http://gshi.org/downloads/cvm_tools/VF4EXt_n_reb.rar VF4EXt_n_reb.rar]

== Structure ==

This information is incomplete and may by itself not be of much help. Note also that it may not apply to all containers of this format being that there are known to be incompatible revisions.

=== Basic ===

As the format is built on top of the original Yellow Book standard, the file storage itself is well documented. Since both ISO and IEC are greedy bastards a relevant item to look up is ECMA-119. The ==Logical Block Size== is 2048 bytes.

At least two versions exist, perhaps not compatible with each other. One is '''''ROFSROFSBLD Ver.1.52 2003-06-09''''', another is '''''ROFSROFSBLD Ver.1.23 2001-10-17'''''.

From: [http://forum.xentax.com/viewtopic.php?p=22826#p22826 XeNTaX - ROFS Compression?Encryption? Method]

ROFS , By turning off the 0x1800 byte from the forefront of the file (header), and change the extension to .iso, Daemon tools can mount it.

With the header where 0x1800 is gone, then it seems that its retained with the file system ( ISO9660 )

ROFS (CVM) file format memo

B = byte (8bit)
W = word (16bit)
L = long word (32bit)

--
0x0000-0xb7ff
- ROFS version
- GAME TITLE and PUBLISHER_NAME etc.

offset 0xb800
1W: first data length = A
1L: START address START (little endian)
1L: START address START (big endian)
1L: FAT SIZE (little endian)
1L: FAT SIZE (big endian)
1B: 0x68??
1B: data length X
XB: ?? (date?)
4B: 01 00 00 01 ??
2B: 01 00 or 01 01
01 01 as for the FAT SIZE-related data end?

1W: next data length = B

here byte become A. Reading B Byte next, it processes.

However, because completely it has become the same contents as A in regard to data which is read next,
as for meaning in regard to data of B you do not understand well. For verification?

--
offset 0xb800 + A + B
1W: data length C

:DATA FIRST

1L: START address START (little endian)
1L: START address START (big endian)
FILE START address = 0x800*START + 0x1800
1L: file size (little endian)
1L: file size (big endian)

1B: 0x68 ??
1B: data length Y
YB: ?? (date?)
4B: 01 00 00 01 ??
1B: file name length Z
ZB: file name
2B: 3B 31 (flag?)

0 fill are done

last 1W: In case of data length of following data D
0x0000, it adjusts the length of the following data and is packed (?)There is a place where it is done. The data other than
0x00 appears to has the necessity to search.

The quantities of all to here byte become C. Reading D Byte next, it processes.
However, it adjusts and is packed (?)When it was done, data length stops being agreeable.

After returning to DATA FIRST, to FAT SIZE + 0x1800 it repeats processing.

From: [http://forum.xentax.com/viewtopic.php?p=24509#p24509 XeNTaX - - ROFS Compression?Encryption? Method]

struct ROFSRootEntry
{
int Offset;
short Unknown;
std::string Name;
};

struct ROFSEntry
{
unsigned short EntrySize; // Entry Header Size
unsigned int Address; // File start offset
unsigned int Size; // File Size
unsigned char Unk0[10];
unsigned short Unk;
std::string Name;
};

if I remember correctly the root entries are a listing of all directories in the file.
from there the rofsentry structure is used to navigate the actual directory and file structure.
a flag in the rofsentry structure tells if the entry is a directory(0x02) or a file(0x01) but I don't know
where that was ^_^; when the entry is a directory the offset leads to another listing of directories
or files. the file is padded to 4096 or 2048 I don't remember. (directories always have "." and ".." entries)

First read the root entries at offset ??? load them into memory and use that to get the entire
file list(with rofsentry structure) it is just a bunch of interconnecting nodes.

== Partial List of Games ==

=== Playstation 2 ===

Arcana Heart

Namcollection

Odin Sphere

Persona 3

Persona 3 FES

Persona 4

Sakura Taisen V

Sonic Gems Collection

Sonic Heroes

Tales of Symphonia

Tales of the Abyss

Virtua Fighter 4

Virtua Fighter 4 Evolution

== Links ==
*[http://www.cri-mw.co.jp/insidemw/rofs1/index_j.htm ＣＲＩ・ミドルウェア : インサイドミドルウェア : 第２話　インサイドROFS　「ROFSTOKO.EXE」:] - Japanese page roughly describing ROFS.
*[http://homepage1.nifty.com/~hin/rofs.html ROFS について] - Another page in Japanese, with actual information about the file structure.
*[http://apache3.net/ Apache3] - Site for Apache3, Munge Explorer, and several other programs.
*[http://www.mactech.com/articles/develop/issue_03/high_sierra.html The Ins And Outs Of ISO 9660 And High Sierra] - A rather detailed explanation of an ISO-9660 filesystem.
*[http://www.ecma-international.org/publications/standards/Ecma-119.htm ECMA-119 - Volume and File Structure of CDROM for Information Interchange 2nd edition (December 1987)]

[[Category:File Systems]]

GSCentral

2008-01-30T04:31:38Z

Ugetab:

== History ==

A [[Gameshark]] code site created in 1998 by a person going by the name [[Jim Reinhart]]. At some point much later a clone of the site was produced after [[Rune]] either was banned or left on his own (depending on who you wish to believe). The original lasted until sometime late 2005/early 2006, when it disappeared without any particular notice. The GSCentral.com domain is still owned by [[Stinky613]], presumably until March 10th, 2012.

As of early October, 2006, the majority of GSCentral's veteran members (and staff) left due to dislike of Rune's recent administrative actions, and his bullshit regarding when the code database would be up.

The exodus of the GSCentral members began when Rune took down the forum (the only thing left at GSCentral), and took away the administrative powers of the very people who made the site worth visiting. (Parasyte, Viper187)

Many call the actions Rune took that day '[[Batshit fucking insane]]!', which is indeed quite accurate considering in just one night, Rune got rid of all of the talented and capable individuals at GSCentral, and soon replaced them all with a bunch of clueless newbies.

Not too long after the exodus, the GSCentral Forums were hacked by unknown person(s).
It is unknown at this time whether or not those who did the hacking were ever caught, or found out.
But it is rumored to be the doing of a coalition between [[GameFAQs]], [[NSider]], and [[Haxxorworld]].

== Present ==
The reason given for taking the code database down was to prevent "thieves" from stealing their content. The irony of it all is that GSCentral gets the majority of its content from other sites, and often fails to give proper credit. Since then more codes have been added but it is not known whether or not the codes have been credited.

After a ridiculous amount of procrastination, the database was ''technically'' restored. There is no way to browse codes, and is only accessible though a buggy search box.

== Technical Information ==

The hosting is provided by the German host [http://all-inkl.com/eng/index.php?cna=&cnb= All-Inkl]. It runs on Apache Apache 1.3.36, and has PHP 4.4.2, FrontPage extension 5.0.2.4803, mod_fastcgi-SNAP-0404142202, mod_ssl 2.8.27, and OpenSSL 0.9.6i. Due to circumstantial evidence, it is presumed to have access to a MySQL database.

The newly added search function has a limitation of only accepting 3 or more characters. Non-alphanumeric characters are stripped. For example, you can't search for "C-12" and get the game "C-12 - Final Resistance", but the full name of the game gives results. The maximum search string is 8,197 bytes (8 kilobytes exactly). After this, the server gives an HTTP 414 error, complaining about the input being too large.

Each game is split into pages. Each page has a likely unique key generated and checked for by mcrypt. Each key is 32 characters in length. Invalid (but of the right length) keys give this error:

----
An error occurred. We are unable to satisfy your request. Please contact the webmaster to notify him of this error. Upon contacting us if you could provide the URL address you tried to access and details on where you found this hyperlink it would be greatly appreciated. Thank you. We apologize for the inconvenience.
----

It has been discovered that nowhere near the quantity of codes that should be up actually are. Recently however more codes have been added. It is not known whether or not the codes taken from other sites have been completey credited.

== External Links ==
[http://gscentral.org GSCentral Main Page] 
[http://gscentral.org/board/index.php GSCentral Forums]

GSCentral

2008-01-25T20:58:16Z

Ugetab:

== History ==

A [[Gameshark]] code site created in 1998 by a person going by the name [[Jim Reinhart]]. At some point much later a clone of the site was produced after [[Rune]] either was banned or left on his own (depending on who you wish to believe). The original lasted until sometime late 2005/early 2006, when it disappeared without any particular notice. The GSCentral.com domain is still owned by [[Stinky613]], presumably until March 10th, 2012.

As of early October, 2006, the majority of GSCentral's veteran members (and staff) left due to dislike of Rune's recent administrative actions, and his bullshit regarding when the code database would be up.

The exodus of the GSCentral members began when Rune took down the forum (the only thing left at GSCentral), and took away the administrative powers of the very people who made the site worth visiting. (Parasyte, Viper187)

Many call the actions Rune took that day '[[Batshit fucking insane]]!', which is indeed quite accurate considering in just one night, Rune got rid of all of the talented and capable individuals at GSCentral, and soon replaced them all with a bunch of clueless newbies.

Not too long after the exodus, the GSCentral Forums were hacked by unknown person(s).
It is unknown at this time whether or not those who did the hacking were ever caught, or found out.
But it is rumored to be the doing of a coalition between [[GameFAQs]], [[NSider]], and [[Haxxorworld]].

== Present ==
The reason given for taking the code database down was to prevent content. The irony of it all is that GSCentral gets the majority of its content from other sites, and often fails to give proper credit. Since then more codes have been added but it is not known whether or not the codes have been credited.

After a ridiculous amount of procrastination, the database was ''technically'' restored. There is no way to browse codes, and is only accessible though a buggy search box.

== Technical Information ==

The hosting is provided by the German host [http://all-inkl.com/eng/index.php?cna=&cnb= All-Inkl]. It runs on Apache Apache 1.3.36, and has PHP 4.4.2, FrontPage extension 5.0.2.4803, mod_fastcgi-SNAP-0404142202, mod_ssl 2.8.27, and OpenSSL 0.9.6i. Due to circumstantial evidence, it is presumed to have access to a MySQL database.

The newly added search function has a limitation of only accepting 3 or more characters. Non-alphanumeric characters are stripped. For example, you can't search for "C-12" and get the game "C-12 - Final Resistance", but the full name of the game gives results. The maximum search string is 8,197 bytes (8 kilobytes exactly). After this, the server gives an HTTP 414 error, complaining about the input being too large.

Each game is split into pages. Each page has a likely unique key generated and checked for by mcrypt. Each key is 32 characters in length. Invalid (but of the right length) keys give this error:

----
An error occurred. We are unable to satisfy your request. Please contact the webmaster to notify him of this error. Upon contacting us if you could provide the URL address you tried to access and details on where you found this hyperlink it would be greatly appreciated. Thank you. We apologize for the inconvenience.
----

It has been discovered that nowhere near the quantity of codes that should be up actually are. Recently however more codes have been added. It is not known whether or not the codes taken from other sites have been completey credited.

== External Links ==
[http://gscentral.org GSCentral Main Page] 
[http://gscentral.org/board/index.php GSCentral Forums]

SA1

2008-01-25T20:53:55Z

Ugetab: /* Memory Mapping Comparison */ (Added STA Z SA1 info)

== Overview ==
The SNES SA1 chip is an expansion chip added to an SNES cart that both contains a portion of the game's coding, and executes that portion of code to affect normal SNES RAM, and the additional RAM accessed primarily by the SA1 chip programming. The additional RAM is also accessible by the SNES CPU's instructions.

There is no current information concerning hardware-based tests with Game Genie codes that change portions of ROM residing within the SA1.

== Memory Mapping Comparison ==
Region 30:0000 - 30:3FFF is SA1 related due to the fact that some RAM is 00 mapped for SA1-using games:

Writes from the SNES CPU to 00:0000 - 00:3FFF region to change a mirrored region at 30:0000 - 30:3FFF region

00:0000 - 00:3FFF 
30:0000 - 30:3FFF

SA1 code such as "STA $DE" can access address 00:30DE, and show up in the log file as a line like... 
$C2:D286 85 DE . STA $DE . [$00:00DE]

The above may not always hold true, but it should be known that not all addresses will appear exactly as expected. 

SA1 Address:
Reads/Writes to these addresses from the SA1 CPU translate to the below CPU-accessible addresses in SNES memory 
00:4000 - 00:7FFF 
CPU Address: 
40:0000 - 40:3FFF

SA1 Address Testing: 
If you wish to test writes made by the SA1 to memory, and see what area is changed, you can use the following code with Super Mario RPG (US), while in a 3D stage. You should fall through the ground, and be unaligned with the map, but have the value FE written to the address you chose.

Test SA1 Memory Writes (2 byte addresses, 0xFE written) 
C9C374A9 
C9C375FE 
C9C378FF 
C9C3793F

Load value 0x00FE to write(could be made to load a 2-byte value) 
C9C374A9 
C9C375FE

Address to write to(Writes to 3FFF with these values) 
C9C378FF 
C9C3793F

Assembly Hacking

2008-01-16T07:52:13Z

Ugetab: /* Playstation */ added some more links

=Overview=

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unneccesary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
FCEUXDSP 
http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP

A project originated by Parasyte called FCEUd, picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

Setting breakpoints in ROM/RAM
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try my edited version, which tends to play nicer with them ( http://www.angelfire.com/nc/ugetab )

'Hex Editor' is a memory viewer/modifier.

==SNES==
Geiger's SNES9X Debugger 
http://geigercount.net/crypt/ 
http://www.zophar.net/snes.html

Setting breakpoints in ROM/RAM 
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==
Gens Tracer 
http://www.romhacking.net/utils/337/

No breakpoints, but adequate tracing.

I've written a guide on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

HazeMD 
http://haze.mameworld.info/

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
BGB 
http://bgb.bircd.org/

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

Also, see below about Visual Boy Advance Tracer. 

==Gameboy Advance==
Visual Boy Advance Tracer 
http://www.romhacking.net/utils/340/

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system. 

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. I(ugetab) used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, you still have to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file. 

Visual Boy Advance 
http://vba.ngemu.com/downloads.shtml 
Windows - SDL

Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats.

Not documented.

==Playstation==
PCSX 1.5 With Debugger 
http://www.romhacking.net/utils/267/

Press F11 to enter the debugger. 
On-screen aids should be apparent.

pSX 
http://www.romhacking.net/utils/311/

This can be a decent debugging alternative if a game doesn't work well in the above emulator.

PCSX Agemo debugger 
http://www.romhacking.net/utils/475/

An emulator I don't have any experience with. It could be favorable for some tasks, compared to the other debuggers.

==N64==
Nemu64 
http://www.emulator-zone.com/doc.php/n64/nemu64.html 
http://www.nemu.com/downloads.php (Expired) 

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write checkboxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes 
http://www.romhacking.net/utils/335/

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

Project64 debug build binary 
http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip

This version of the emulator has better support for games than Nemu64, and I've(ugetab) used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
Yabause
http://www.romhacking.net/utils/482/

No info yet

==Wonder Swan==
Cygne Tracer
http://www.romhacking.net/utils/244/

No info yet

Oswan Tracer
http://www.romhacking.net/utils/338/

Another hook-log tracer

==Playstation 2==

[The current author is too lazy to write this, but will get around to it later if no one else does]

GSCentral

2008-01-16T07:16:54Z

Ugetab:

== History ==

A [[Gameshark]] code site created in 1998 by a person going by the name [[Jim Reinhart]]. At some point much later a clone of the site was produced after [[Rune]] either was banned or left on his own (depending on who you wish to believe). The original lasted until sometime late 2005/early 2006, when it disappeared without any particular notice. The GSCentral.com domain is still owned by [[Stinky613]], presumably until March 10th, 2012.

As of early October, 2006, the majority of GSCentral's veteran members (and staff) left due to dislike of Rune's recent administrative actions, and his bullshit regarding when the code database would be up.

The exodus of the GSCentral members began when Rune took down the forum (the only thing left at GSCentral), and took away the administrative powers of the very people who made the site worth visiting. (Parasyte, Viper187)

Many call the actions Rune took that day '[[Batshit fucking insane]]!', which is indeed quite accurate considering in just one night, Rune got rid of all of the talented and capable individuals at GSCentral, and soon replaced them all with a bunch of clueless newbies.

Not too long after the exodus, the GSCentral Forums were hacked by unknown person(s).
It is unknown at this time whether or not those who did the hacking were ever caught, or found out.
But it is rumored to be the doing of a coalition between [[GameFAQs]], [[NSider]], and [[Haxxorworld]].

== Present ==
The reason given for taking the code database down was to prevent ''thieves'' from stealing their content. The irony of it all is that GSCentral gets the majority of its content from other sites, and often fails to give proper credit.

After a ridiculous amount of procrastination, the database was ''technically'' restored. There is no way to browse codes, and is only accessible though a buggy search box.

== Technical Information ==

The hosting is provided by the German host [http://all-inkl.com/eng/index.php?cna=&cnb= All-Inkl]. It runs on Apache Apache 1.3.36, and has PHP 4.4.2, FrontPage extension 5.0.2.4803, mod_fastcgi-SNAP-0404142202, mod_ssl 2.8.27, and OpenSSL 0.9.6i. Due to circumstantial evidence, it is presumed to have access to a MySQL database.

The newly added search function has a limitation of only accepting 3 or more characters. Non-alphanumeric characters are stripped. For example, you can't search for "C-12" and get the game "C-12 - Final Resistance", but the full name of the game gives results. The maximum search string is 8,197 bytes (8 kilobytes exactly). After this, the server gives an HTTP 414 error, complaining about the input being too large.

Each game is split into pages. Each page has a likely unique key generated and checked for by mcrypt. Each key is 32 characters in length. Invalid (but of the right length) keys give this error:

----
An error occurred. We are unable to satisfy your request. Please contact the webmaster to notify him of this error. Upon contacting us if you could provide the URL address you tried to access and details on where you found this hyperlink it would be greatly appreciated. Thank you. We apologize for the inconvenience.
----

It has been discovered that nowhere near the quantity of codes that should be up actually are. Recently however more codes have been added. It is not known whether or not the codes taken from other sites have been completey credited.

== External Links ==
[http://gscentral.org GSCentral Main Page] 
[http://gscentral.org/board/index.php GSCentral Forums]

Talk:Main Page

2008-01-16T07:14:55Z

Ugetab: Reverted edits by Cryptone (Talk); changed back to last version by Ace

Assembly Hacking

2008-01-09T19:36:46Z

Ugetab: added some sections, edited some links, a little maintainance

=Overview=

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unneccesary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
FCEUXDSP 
http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP

A project originated by Parasyte called FCEUd, picked up by bbitmaster and renamed to FCEUXD, and finally adopted as FCEUXD SP.

Setting breakpoints in ROM/RAM
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If you want to use this to deal with NSFs, try my edited version, which tends to play nicer with them ( http://www.angelfire.com/nc/ugetab )

'Hex Editor' is a memory viewer/modifier.

==SNES==
Geiger's SNES9X Debugger 
http://geigercount.net/crypt/ 
http://www.zophar.net/snes.html

Setting breakpoints in ROM/RAM 
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==
Gens Tracer 
http://www.romhacking.net/utils/337/

No breakpoints, but adequate tracing.

I've written a guide on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

HazeMD 
http://haze.mameworld.info/

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
BGB 
http://bgb.bircd.org/

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

Also, see below about Visual Boy Advance Tracer. 

==Gameboy Advance==
Visual Boy Advance Tracer 
http://www.romhacking.net/utils/340/

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system. 

Note that it has also been used to good effect for a small number of gameboy games that BGB doesn't support. I(ugetab) used this for GBS ripping, but with full code logging, and a save-state near when something changes, you could just as effectively search for a memory address in trace.log. Mind that while GB assembly doesn't pile up as quickly as GBA or N64, you still have to be relatively close to the change before activating logging, if you don't want to have to use a special text editor to open an enormous log file. 

Visual Boy Advance 
http://vba.ngemu.com/downloads.shtml 
Windows - SDL

Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats.

Not documented.

==Playstation==
PCSX 1.5 With Debugger 
http://www.romhacking.net/utils/267/

Press F11 to enter the debugger. 
On-screen aids should be apparent.

==N64==
Nemu64 
http://www.emulator-zone.com/doc.php/n64/nemu64.html 
http://www.nemu.com/downloads.php (Expired) 

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write checkboxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes 
http://www.romhacking.net/utils/335/

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

Project64 debug build binary 
http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip

This version of the emulator has better support for games than Nemu64, and I've(ugetab) used this tool in combination with nemu64 to edit USFs, as well as make a few codes that people using only a single emulation tool were having extremely hard struggles with.

==Saturn==
Yabause
http://www.romhacking.net/utils/482/

No info yet

==Wonder Swan==
Cygne Tracer
http://www.romhacking.net/utils/244/

No info yet

Oswan Tracer
http://www.romhacking.net/utils/338/

Another hook-log tracer

==Playstation 2==

[The current author is too lazy to write this, but will get around to it later if no one else does]

NSF

2007-07-20T05:28:01Z

Ugetab:

The basic idea is one rips the music/sound code from an NES game and prepends a small header to the data.

A program of some form (6502/sound emulator) then takes the data and loads it into the proper place into the 6502's address space, then inits and plays the tune.

Many of the same methods used for finding cheat codes are compatible with finding sound information. The extra work of getting the right code into the right place and setting up the header is the primary difference between ripping and cheat making.

(The following is a modified version of the text on the nesdev.parodius.org wiki)
== Header Overview ==

offset # of bytes Function
----------------------------
0000 5 STRING "NESM",01Ah ; denotes an NES sound format file
0005 1 BYTE Version number (currently 01h)
0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)
0007 1 BYTE Starting song (1=1st song, 2=2nd song, etc)
0008 2 WORD (lo/hi) load address of data (8000-FFFF)
000a 2 WORD (lo/hi) init address of data (8000-FFFF)
000c 2 WORD (lo/hi) play address of data (8000-FFFF)
000e 32 STRING The name of the song, null terminated
002e 32 STRING The artist, if known, null terminated
004e 32 STRING The Copyright holder, null terminated
006e 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, NTSC (see text)
0070 8 BYTE Bankswitch Init Values (see text, and FDS section)
0078 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, PAL (see text)
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
007b 1 BYTE Extra Sound Chip Support
bit 0: if set, this song uses VRCVI
bit 1: if set, this song uses VRCVII
bit 2: if set, this song uses FDS Sound
bit 3: if set, this song uses MMC5 audio
bit 4: if set, this song uses Namco 106
bit 5: if set, this song uses Sunsoft FME-07
bits 6,7: future expansion: they *must* be 0
007c 4 ---- 4 extra bytes for expansion (must be 00h)
0080 nnn ---- The music program/data follows

This may look somewhat familiar; if so that's because this is somewhat sort of based on the PSID file format for C64 music/sound.

== Loading a tune into RAM ==

If offsets 0070h to 0077h have 00h in them, then bankswitching is *not* used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.

Each bank is 1K in size, and that means there are 8 of them for the
entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.

Here's an example:

METROID.NSF will be used for the following explaination.

The file is set up like so: (starting at 070h in the file)

0070: 05 05 05 05 05 05 05 05 - 00 00 00 00 00 00 00 00
0080: ... music data goes here...

Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

Metroid has 6 1K banks in it, numbered 0 through 5. The 6502's address space has 8 1K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. In the Metroid NSF header, all banks start out loaded with the 6th 1K bank of data, which is 5. Each one of these is 1K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
This is should be done before every call to the init routine.

If the tune was not bankswitched, then it is simply loaded in at the
specified load address, until EOF

== Initalizing a tune ==

This is pretty simple. Load the desired song # into the accumulator,
minus 1 and set the X register to specify PAL (X=1) or NTSC (X=0).
If this is a single standard tune (i.e. PAL *or* NTSC but not both)
then the X register contents should not matter. Once the song # and
optional PAL/NTSC standard are loaded, simply call the INIT address.
Once init is done, it should perform an RTS.

== Playing a tune ==

Once the tune has been initalized, it can now be played. To do this,
simply call the play address several times a second. How many times
per second is determined by offsets 006eh and 006fh in the file.
These bytes denote the speed of playback in 1/1000000ths of a second.
For the "usual" 60Hz playback rate, set this to 411ah.

To generate a differing playback rate, use this formula:

1000000
PBRATE= ---------
speed

Where PBRATE is the value you stick into 006e/006fh in the file, and
speed is the desired speed in hertz.

== Properly Loading a Tune ==

* If the tune is bankswitched, go to #3.

* Load the data into the 6502's address space starting at the specified load address. Go to #4.

* Load the data into a RAM area, starting at (start_address AND 0fffh).

* Tune load is done.

== Properly Initializing a Tune ==

* Clear all RAM at 0000h-07ffh.

* Clear all RAM at 6000h-7fffh.

* Init the sound registers by writing 00h to 04000-0400Fh, 10h to 4010h, and 00h to 4011h-4013h.

* Set volume register 04015h to 00fh.

* If this is a banked tune, load the bank values from the header into 5ff8-5fffh.

* Set the accumulator and X registers for the desired song.

* Call the music init routine.

== Properly Playing a Tune ==
Call the play address of the music at periodic intervals determined by the speed words. Which word to use is determined by which mode you are in- PAL or NTSC.

== Changes Since This Guide Was Written ==
Some players no longer use the playback rate bytes.

== Adding DPCM ==
There is a large section on how to deal with DPCM samples in the [http://www.zophar.net/tech/files/NESAudioRipping.TXT NES Music Ripping Guide], but the basic information on DPCM is that writes to $4012 and $4013 access sample data stored at and between $c000 and $ffff.

Writes to $4012 determine the location of the sample data. The value written to $4012, multiplied by 0040h, plus 0c000h, is the point in ROM space the sample starts.

Writes to $4013 determine the length of the sample data. The value written to $4013, multiplied by 0010h, plus 1, is the length of the sample data.

If 00h is written to $4012 and $4013, the sample would be located at $c000, and would be 1 byte in length. If 0080h is written to $4012 and $4013, the sample would be located at $e000, and would be 0x801 bytes in length.

DPCM samples can be attached to an NSF by either relocating the neccesary data, or by including the banks with the DPCM data in the NSF. Relocating the data correctly will often lead to a smaller file size, but including the original data in it's original location is usually easier to do.

== Sound Chip Support ==
Byte 007bh of the file stores the sound chip flags. If a particular flag is set, those sound registers should be enabled. If the flag is clear, then those registers should be disabled. All I/O registers within 8000-FFFF are ''write only'' and must not disrupt music code that happens to be stored there.

=== VRCVI ===
* Uses registers 9000-9002, A000-A002, and B000-B002, write only. See [[VRC6 Audio]] for more information.
* Note: The A0 and A1 lines are flipped on a few games! If you rip the music and it sounds all funny, flip around the xxx1 and xxx2 register pairs. (i.e. 9001 and 9002) 9000 and 9003 can be left untouched. I decided to do this since it would make things easier all around, and this means you only will have to change the music code in a very few places (6). Esper2 and Madara will need this change, while Castlevania 3j will not for instance.

=== VRCVII ===
* Uses registers 9010 and 9030, write only. See [[VRC7 Audio]] for more information.

=== FDS Sound ===
* Uses registers from 4040 through 4092. See [[FDS Audio]] for more information.

Notes:
* 6000-DFFF is assumed to be RAM, since 6000-DFFF is RAM on the FDS. E000-FFFF is usually not included in FDS games because it is the BIOS ROM. However, it can be used on FDS rips to help the ripper (for modified play/init addresses).
* Bankswitching operates slightly different on FDS tunes. 5FF6 and 5FF7 control the banks 6000-6FFF and 7000-7FFF respectively. NSF header offsets 76h and 77h correspond to *both* 6000-7FFF *AND* E000-FFFF. Keep this in mind!

=== MMC5 Sound ===
* Uses registers 5000-5015, write only as well as 5205 and 5206, and 5C00-5FF5. see [[MMC5 Audio]] for more information.

Notes:
* 5205 and 5206 are a hardware 8*8 multiplier. The idea being you write your two bytes to be multiplied into 5205 and 5206 and after doing so, you read the result back out.
* 5C00-5FF5 should be RAM to emulate EXRAM while in MMC5 mode.

=== Namco 106 Sound ===
* Uses registers 4800 and F800. See [[Namco 106 Audio]] for more information.

=== Sunsoft FME-07 Sound ===
* Uses registers C000 and E000. See [[Sunsoft Audio]] for more information.

== Caveats ==
# The starting song number and maximum song numbers start counting at 1, while the init address of the tune starts counting at 0. To "fix", simply pass the desired song number minus 1 to the init routine.
# The NTSC speed word is used *only* for NTSC tunes, or dual PAL/NTSC tunes. The PAL speed word is used *only* for PAL tunes, or dual PAL/NTSC tunes.
# The length of the text in the name, artist, and copyright fields must be 31 characters or less! There has to be at least a single NULL byte (00h) after the text, between fields.
# If a field is not known (name, artist, copyright) then the field must contain the string "<?>" (without quotes).
# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.
# Do not assume the state of *anything* on entry to the init routine except A and X. Y can be anything, as can the flags.
# Do not assume the state of *anything* on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem above.
# The stack sits at 1FFh and grows down to 100h. Make sure the tune does not attempt to use 1E0h-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx) Tunes that do use this area are likely relying on direct lookup of stack values. Games that do this need to be debugged to find the location that pushes or writes this information.
# Variables should sit in the 0000h-07FFh area *only*. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx). Note that most recent players also support RAM at 6000h-7FFFh.
# Some games require A/X/Y to be 'cleaned' before running some code. This can be required during the Init routine, or before the Play address is run. In one case, all the songs in an NSF wouldn't loop because the Y register wasn't zeroed in the init routine.

== Using FCEUXDSP ==
Ripping can be made much easier by using this relatively new NES debugging emulator.

By breakpointing writes to $4015, then resetting the game, you can often find the part of code that initializes the sound registers(Sound Init), and see if it's doing anything unusual at that point.

Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.

Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually dissecting the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.

If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...

Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.

NSF

2007-07-17T02:22:35Z

Ugetab:

The basic idea is one rips the music/sound code from an NES game and prepends a small header to the data.

A program of some form (6502/sound emulator) then takes the data and loads it into the proper place into the 6502's address space, then inits and plays the tune.

Many of the same methods used for finding cheat codes are compatible with finding sound information. The extra work of getting the right code into the right place and setting up the header is the primary difference between ripping and cheat making.

(The following is a modified version of the text on the nesdev.parodius.org wiki)
== Header Overview ==

offset # of bytes Function
----------------------------
0000 5 STRING "NESM",01Ah ; denotes an NES sound format file
0005 1 BYTE Version number (currently 01h)
0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)
0007 1 BYTE Starting song (1=1st song, 2=2nd song, etc)
0008 2 WORD (lo/hi) load address of data (8000-FFFF)
000a 2 WORD (lo/hi) init address of data (8000-FFFF)
000c 2 WORD (lo/hi) play address of data (8000-FFFF)
000e 32 STRING The name of the song, null terminated
002e 32 STRING The artist, if known, null terminated
004e 32 STRING The Copyright holder, null terminated
006e 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, NTSC (see text)
0070 8 BYTE Bankswitch Init Values (see text, and FDS section)
0078 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, PAL (see text)
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
007b 1 BYTE Extra Sound Chip Support
bit 0: if set, this song uses VRCVI
bit 1: if set, this song uses VRCVII
bit 2: if set, this song uses FDS Sound
bit 3: if set, this song uses MMC5 audio
bit 4: if set, this song uses Namco 106
bit 5: if set, this song uses Sunsoft FME-07
bits 6,7: future expansion: they *must* be 0
007c 4 ---- 4 extra bytes for expansion (must be 00h)
0080 nnn ---- The music program/data follows

This may look somewhat familiar; if so that's because this is somewhat sort of based on the PSID file format for C64 music/sound.

== Loading a tune into RAM ==

If offsets 0070h to 0077h have 00h in them, then bankswitching is *not* used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.

Each bank is 4K in size, and that means there are 8 of them for the
entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.

Here's an example:

METROID.NSF will be used for the following explaination.

The file is set up like so: (starting at 070h in the file)

0070: 05 05 05 05 05 05 05 05 - 00 00 00 00 00 00 00 00
0080: ... music data goes here...

Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. In the Metroid NSF header, all banks start out loaded with the 6th 4K bank of data, which is 5. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
This is should be done before every call to the init routine.

If the tune was not bankswitched, then it is simply loaded in at the
specified load address, until EOF

== Initalizing a tune ==

This is pretty simple. Load the desired song # into the accumulator,
minus 1 and set the X register to specify PAL (X=1) or NTSC (X=0).
If this is a single standard tune (i.e. PAL *or* NTSC but not both)
then the X register contents should not matter. Once the song # and
optional PAL/NTSC standard are loaded, simply call the INIT address.
Once init is done, it should perform an RTS.

== Playing a tune ==

Once the tune has been initalized, it can now be played. To do this,
simply call the play address several times a second. How many times
per second is determined by offsets 006eh and 006fh in the file.
These bytes denote the speed of playback in 1/1000000ths of a second.
For the "usual" 60Hz playback rate, set this to 411ah.

To generate a differing playback rate, use this formula:

1000000
PBRATE= ---------
speed

Where PBRATE is the value you stick into 006e/006fh in the file, and
speed is the desired speed in hertz.

== Properly Loading a Tune ==

* If the tune is bankswitched, go to #3.

* Load the data into the 6502's address space starting at the specified load address. Go to #4.

* Load the data into a RAM area, starting at (start_address AND 0fffh).

* Tune load is done.

== Properly Initializing a Tune ==

* Clear all RAM at 0000h-07ffh.

* Clear all RAM at 6000h-7fffh.

* Init the sound registers by writing 00h to 04000-0400Fh, 10h to 4010h, and 00h to 4011h-4013h.

* Set volume register 04015h to 00fh.

* If this is a banked tune, load the bank values from the header into 5ff8-5fffh.

* Set the accumulator and X registers for the desired song.

* Call the music init routine.

== Properly Playing a Tune ==
Call the play address of the music at periodic intervals determined by the speed words. Which word to use is determined by which mode you are in- PAL or NTSC.

== Changes Since This Guide Was Written ==
Some players no longer use the playback rate bytes.

== Adding DPCM ==
There is a large section on how to deal with DPCM samples in the [http://www.zophar.net/tech/files/NESAudioRipping.TXT NES Music Ripping Guide], but the basic information on DPCM is that writes to $4012 and $4013 access sample data stored at and between $c000 and $ffff.

Writes to $4012 determine the location of the sample data. The value written to $4012, multiplied by 0040h, plus 0c000h, is the point in ROM space the sample starts.

Writes to $4013 determine the length of the sample data. The value written to $4013, multiplied by 0010h, plus 1, is the length of the sample data.

If 00h is written to $4012 and $4013, the sample would be located at $c000, and would be 1 byte in length. If 0080h is written to $4012 and $4013, the sample would be located at $e000, and would be 0x801 bytes in length.

DPCM samples can be attached to an NSF by either relocating the neccesary data, or by including the banks with the DPCM data in the NSF. Relocating the data correctly will often lead to a smaller file size, but including the original data in it's original location is usually easier to do.

== Sound Chip Support ==
Byte 007bh of the file stores the sound chip flags. If a particular flag is set, those sound registers should be enabled. If the flag is clear, then those registers should be disabled. All I/O registers within 8000-FFFF are ''write only'' and must not disrupt music code that happens to be stored there.

=== VRCVI ===
* Uses registers 9000-9002, A000-A002, and B000-B002, write only. See [[VRC6 Audio]] for more information.
* Note: The A0 and A1 lines are flipped on a few games! If you rip the music and it sounds all funny, flip around the xxx1 and xxx2 register pairs. (i.e. 9001 and 9002) 9000 and 9003 can be left untouched. I decided to do this since it would make things easier all around, and this means you only will have to change the music code in a very few places (6). Esper2 and Madara will need this change, while Castlevania 3j will not for instance.

=== VRCVII ===
* Uses registers 9010 and 9030, write only. See [[VRC7 Audio]] for more information.

=== FDS Sound ===
* Uses registers from 4040 through 4092. See [[FDS Audio]] for more information.

Notes:
* 6000-DFFF is assumed to be RAM, since 6000-DFFF is RAM on the FDS. E000-FFFF is usually not included in FDS games because it is the BIOS ROM. However, it can be used on FDS rips to help the ripper (for modified play/init addresses).
* Bankswitching operates slightly different on FDS tunes. 5FF6 and 5FF7 control the banks 6000-6FFF and 7000-7FFF respectively. NSF header offsets 76h and 77h correspond to *both* 6000-7FFF *AND* E000-FFFF. Keep this in mind!

=== MMC5 Sound ===
* Uses registers 5000-5015, write only as well as 5205 and 5206, and 5C00-5FF5. see [[MMC5 Audio]] for more information.

Notes:
* 5205 and 5206 are a hardware 8*8 multiplier. The idea being you write your two bytes to be multiplied into 5205 and 5206 and after doing so, you read the result back out.
* 5C00-5FF5 should be RAM to emulate EXRAM while in MMC5 mode.

=== Namco 106 Sound ===
* Uses registers 4800 and F800. See [[Namco 106 Audio]] for more information.

=== Sunsoft FME-07 Sound ===
* Uses registers C000 and E000. See [[Sunsoft Audio]] for more information.

== Caveats ==
# The starting song number and maximum song numbers start counting at 1, while the init address of the tune starts counting at 0. To "fix", simply pass the desired song number minus 1 to the init routine.
# The NTSC speed word is used *only* for NTSC tunes, or dual PAL/NTSC tunes. The PAL speed word is used *only* for PAL tunes, or dual PAL/NTSC tunes.
# The length of the text in the name, artist, and copyright fields must be 31 characters or less! There has to be at least a single NULL byte (00h) after the text, between fields.
# If a field is not known (name, artist, copyright) then the field must contain the string "<?>" (without quotes).
# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.
# Do not assume the state of *anything* on entry to the init routine except A and X. Y can be anything, as can the flags.
# Do not assume the state of *anything* on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem above.
# The stack sits at 1FFh and grows down to 100h. Make sure the tune does not attempt to use 1E0h-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx) Tunes that do use this area are likely relying on direct lookup of stack values. Games that do this need to be debugged to find the location that pushes or writes this information.
# Variables should sit in the 0000h-07FFh area *only*. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx). Note that most recent players also support RAM at 6000h-7FFFh.
# Some games require A/X/Y to be 'cleaned' before running some code. This can be required during the Init routine, or before the Play address is run. In one case, all the songs in an NSF wouldn't loop because the Y register wasn't zeroed in the init routine.

== Using FCEUXDSP ==
Ripping can be made much easier by using this relatively new NES debugging emulator.

By breakpointing writes to $4015, then resetting the game, you can often find the part of code that initializes the sound registers(Sound Init), and see if it's doing anything unusual at that point.

Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.

Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually dissecting the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.

If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...

Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.

CMGSCCC

2007-02-27T19:18:19Z

Ugetab: /* GSCCC, Incorporated */

A GameShark code site started on September 23rd, 1996 by Code Master. After battles with many enemies, such as the Girl Scout Council of Colonial Coast and InterAct Accessories, the site was renamed from GameShark Code Creators Club to Game Software Code Creators Club. Code Master eventually changed his own name to CMX, presumably to make it seem as though he's more like DMX.

At an unknown point, CMX accepted a position as Pelican's official code hacker and the site was converted over to being [[Code Breaker]] specific. Since then, the site has become heavily ad laden, requires becoming a member to view any codes, and has turned into a place to generally avoid.

More recently, though reports indicate this has been going on for around a year, an Internet Explorer exploit known as "EXP/Agent.B" was installed on the forums. A topic about this was made [http://forums.cmgsccc.com/showthread.php?t=16224 here]. Another topic about this was posted on GSHI's forums here: [http://gshi.org/vb/showthread.php?t=2031 CMGSCCC is spreading malware]. It has also been noticed that there are popups containing pornography on the GSCCC forums as of late.

== GSCCC, Incorporated ==
A domestic corporation in Waterloo, Illinois. The corporation is a "Single Owner Corporation," in that all officers of the corporation are the same. As CMX refers to himself as the President of GSCCC, Incorporated, it appears his name is Bryan Black.

From 2000 to 2005, the address of the corporation's registered agent was [http://maps.google.com/?q=5725%20Sportsman%20Rd%20Waterloo%20IL%2062298%20US 5725 Sportsman Rd, Waterloo IL 62298 US], which Mapquest high resolution imagery showed to be a farm house.

From 2005 to 2006, the address of the corporation's registered agent was [http://maps.google.com/?q=411+Park+St,+Waterloo,+IL+62298&ie=UTF8&z=15&ll=38.333712,-90.154924&spn=0.015182,0.043259&om=1&iwloc=addr 411 Park Street Suite C, Waterloo, IL 62298], which is the PDQ Tax Service in Waterloo.

The Illinois Secretary of State's website shows that GSCCC, Incorporated has never filed an annual report, and is a "corporation not in good standing," indicating that the corporation is not legally allowed to conduct business under that name for failing to obey Illinois Statutes.

== External Links ==
[http://www.cmgsccc.com CMGSCCC.com]

[http://web.archive.org/web/20010722015402/http://cmgsccc.com/ GSCCC index page as retrieved on 2001-07-22 by the Internet Archive]

Code Types

2007-01-15T21:51:55Z

Ugetab: /* '''Codebreaker Advance''' */

Explanation of what a code type is, and what they're used for here..

= Playstation Systems =

== Playstation 2 ==

==='''Code Breaker'''===
----

==='''GameShark (Interact)'''===
----

==='''GameShark (Mad Catz)'''===
----

==='''Xploder'''===
----

== Playstation ==

==='''Gameshark'''===
----
{| style="border:1px solid #000000; margin: 0; padding:0;" width="100%" cellspacing="0" cellpadding="5""
! Type !! Description !! Example !! Other

|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 30
| 8-bit constant write || 3XXXXXXX 00YY Writes YY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 80
| 16-bit constant write || 8XXXXXXX ZZYY Writes ZZYY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 50
| serial repeater || 5000XXYY 00ZZ TTTTTTTT VVVV Writes XX codes, with YY added to the address for each code after TTTTTTTT, and ZZZZ added to the amount for each code after value VVVV || Gameshark 2.2 and higher. May need to seperate pairs of serial codes with a 00000000 0000 code for disk-based gamesharks
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! E0
| 8-bit equal-to trigger || E0XXXXXX 00YY Activates next code if address 80XXXXXX is equal to YY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! E1
| 8-bit different-from trigger || E1XXXXXX 00YY Activates next code if address 80XXXXXX is different from YY || Gameshark 2.2(?) and higher.
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! E2
| 8-bit less-than trigger || E2XXXXXX 00YY Activates next code if address 80XXXXXX is less than YY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! E3
| 8-bit greater-than trigger || E3XXXXXX 00YY Activates next code if address 80XXXXXX is greater than YY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! D0
| 16-bit equal-to trigger || D0XXXXXX YYYY Activates next code if address 80XXXXXX is equal to YYYY || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! D1
| 16-bit different-from trigger || D1XXXXXX YYYY Activates next code if address 80XXXXXX is different from YYYY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! D2
| 16-bit less-than trigger || D2XXXXXX YYYY Activates next code if address 80XXXXXX is less than YYYY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! D3
| 16-bit greater-than trigger || D3XXXXXX YYYY Activates next code if address 80XXXXXX is greater than YYYY || Gameshark 2.2 and higher.
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! D4
| 16-bit universal joker || D4000000 YYYY Activates next code if the button presses equate to YYYY || Gameshark 2.41 and higher. Needs a button chart
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! D5
| 16-bit codes-on trigger || D5000000 YYYY Activates all codes if buton presses equate to YYYY || Gameshark 2.41 and higher. Needs a button chart
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! D6
| 16-bit codes-off trigger || D6000000 YYYY Activates all codes if buton presses equate to YYYY || Gameshark 2.41 and higher. Needs a button chart
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 10
| 16-bit incrementer || 10XXXXXX YYYY Increments value at address 80XXXXXX by YYYY || Gameshark 2.2 and higher. Use with a joker
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 11
| 16-bit decrementer || 11XXXXXX YYYY Decrements value at address 80XXXXXX by YYYY || Gameshark 2.2 and higher. Use with a joker
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 20
| 8-bit incrementer || 20XXXXXX 00YY Increments value at address 80XXXXXX by YY || Gameshark 2.2 and higher. Use with a joker
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 21
| 8-bit decrementer || 21XXXXXX 00YY Decrements value at address 80XXXXXX by YY || Gameshark 2.2 and higher. Use with a joker
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! C0
| enable all codes trigger || C0XXXXXX YYYY If value at address 80XXXXXX is equal to YYYY, enable all loaded codes in game. Affects all codes, not just the one this line is used in. || Gameshark 2.41 or higher.
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! C1
| codes-on delay || C1000000 YYYY Delays codes from being on by YYYY time when game starts. 4000-5000 should give 20-30 seconds. || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! C2
| copy memory || C2XXXXXX YYYY 80ZZZZZZ 0000 Copy YYYY bytes from 80XXXXXX to 80ZZZZZZ. Could be used for copying large sets of complex character stats from one character to another, like working-magic-only, if serial repeater won't work || NA

|}

==='''Xploder/Codebreaker'''===
----
{| style="border:1px solid #000000; margin: 0; padding:0;" width="100%" cellspacing="0" cellpadding="5""
! Type !! Description !! Example !! Other

|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 30
| 8-bit constant write || 3XXXXXXX 00YY Writes YY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 80
| 16-bit constant write || 8XXXXXXX ZZYY Writes ZZYY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 70
| 16-bit equal-to trigger || 70XXXXXX YYYY Activates next code if address 80XXXXXX is equal to YYYY || NA

|}

==='''Action Replay'''===
----

==='''Gold Finger'''===
----

==='''Caetla'''===
----

= Nintendo Systems =

== GameCube ==

==='''Action Replay'''===
----

== Nintendo 64 ==

==='''GameShark'''===
----

== GameBoy Advance ==

==='''Codebreaker Advance'''===
----
{| style="border:1px solid #000000; margin: 0; padding:0;" width="100%" cellspacing="0" cellpadding="5""
! Type !! Description !! Example !! Other

|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 0
| Master Code 1 || 0000XXXX YYYY XXXX is the CRC value (the "Game ID" converted to hex) Flags ("yyyy"): 0008 - CRC Exists (CRC is used to autodetect the inserted game) 0002 - Disable Interupts || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 1
| Master Code 2 || 1XXXXXXX YYYZ 'Z' is the CBA Code Handler Store Address (0-7) [address = ((d << 0x16) + 0x08000100)] YYY: 100 - 32-bit Long-Branch Type (Thumb) 200 - 32-bit Long-Branch Type (ARM) 300 - 8-bit(?) Long-Branch Type (Thumb) 400 - 8-bit(?) Long-Branch Type (ARM) 002 - Unknown (Odd Effect) XXXXXXX = ? || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 2
| 16-bit bitwise OR || 2XXXXXXX YYYY XXXXXXX = Address YYYY = Value to OR with || Tested on VBA, not tested on hardware
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 3
| 8-bit RAM Write || 3XXXXXXX 00YY XXXXXXX = Address YY = Value to write || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 4
| serial repeater || 4qqqqqqq xxyy XXYY#### ++++ qqqqqqq=Address to Start At xxyy = Start Value XXYY = Add To Value #### = Number of Address Iterations ++++ = Amount Added to each Address Iteration || XXYY portion tested in VBA, not tested on hardware
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 5
| Unknown || Unknown || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 6
| 16-bit bitwise AND || 6XXXXXXX YYYY XXXXXXX = Address YYYY = Value to AND with || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 7
| 16-bit equal-to trigger || 7XXXXXXX YYYY Activates next code if address XXXXXXX is equal to YYYY || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! 8
| 16-bit RAM Write || 8XXXXXXX YYYY XXXXXXX = Address YYYY = Value to write || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! 9
| Change Encryption Seeds (if used as first code) || 9YYYYYYY YYYY Details not researched || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! A
| 16-bit not-equal-to trigger || AXXXXXXX YYYY Activates next code if address XXXXXXX is not equal to YYYY || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! B
| Unknown || Unknown || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! C
| Unknown || Unknown || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! D
| Unknown || Unknown || NA
|- align="center" style="font-size: 105%; background-color:#cedff2; text-align: center; padding:0;"
! E
| Unknown || Unknown || NA
|- align="center" style="font-size: 105%; background-color:#d0d8e0; text-align: center; padding:0;"
! F
| Unknown || Unknown || NA

|}

==='''GameShark Advance (Interact)'''===
----

==='''GameShark Advance (Mad Catz)'''===
----

==='''Action Replay'''===
----

== Nintendo DS ==

==='''Codebreaker Advance'''===
----

= Sega Systems =

== Dreamcast ==

==='''GameShark CDX'''===
----

==='''Codebreaker'''===
----

== Saturn ==

==='''GameShark'''===
----

NSF

2006-12-12T05:29:01Z

Ugetab:

The basic idea is one rips the music/sound code from an NES game and prepends a small header to the data.

A program of some form (6502/sound emulator) then takes the data and loads it into the proper place into the 6502's address space, then inits and plays the tune.

Many of the same methods used for finding cheat codes are compatible with finding sound information. The extra work of getting the right code into the right place and setting up the header is the primary difference between ripping and cheat making.

== Header Overview ==

offset # of bytes Function
----------------------------
0000 5 STRING "NESM",01Ah ; denotes an NES sound format file
0005 1 BYTE Version number (currently 01h)
0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)
0007 1 BYTE Starting song (1= 1st song, 2=2nd song, etc)
0008 2 WORD (lo/hi) load address of data (8000-FFFF)
000a 2 WORD (lo/hi) init address of data (8000-FFFF)
000c 2 WORD (lo/hi) play address of data (8000-FFFF)
000e 32 STRING The name of the song, null terminated
002e 32 STRING The artist, if known, null terminated
004e 32 STRING The Copyright holder, null terminated
006e 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, NTSC (see text)
0070 8 BYTE Bankswitch Init Values (see text, and FDS section)
0078 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, PAL (see text)
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
007b 1 BYTE Extra Sound Chip Support
bit 0: if set, this song uses VRCVI
bit 1: if set, this song uses VRCVII
bit 2: if set, this song uses FDS Sound
bit 3: if set, this song uses MMC5 audio
bit 4: if set, this song uses Namco 106
bit 5: if set, this song uses Sunsoft FME-07
bits 6,7: future expansion: they *must* be 0
007c 4 ---- 4 extra bytes for expansion (must be 00h)
0080 nnn ---- The music program/data follows

This may look somewhat familiar; if so that's because this is somewhat sorta of based on the PSID file format for C64 music/sound.

== Loading a tune into RAM ==

If offsets 0070h to 0077h have 00h in them, then bankswitching is *not* used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.

Each bank is 4K in size, and that means there are 8 of them for the
entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.

Here's an example:

METROID.NSF will be used for the following explaination.

The file is set up like so: (starting at 070h in the file)

0070: 05 05 05 05 05 05 05 05 - 00 00 00 00 00 00 00 00
0080: ... music data goes here...

Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h
is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
This is should be done before every call to the init routine.

If the tune was not bankswitched, then it is simply loaded in at the
specified load address, until EOF

== Initalizing a tune ==

This is pretty simple. Load the desired song # into the accumulator,
minus 1 and set the X register to specify PAL (X=1) or NTSC (X=0).
If this is a single standard tune (i.e. PAL *or* NTSC but not both)
then the X register contents should not matter. Once the song # and
optional PAL/NTSC standard are loaded, simply call the INIT address.
Once init is done, it should perform an RTS.

== Playing a tune ==

Once the tune has been initalized, it can now be played. To do this,
simply call the play address several times a second. How many times
per second is determined by offsets 006eh and 006fh in the file.
These bytes denote the speed of playback in 1/1000000ths of a second.
For the "usual" 60Hz playback rate, set this to 411ah.

To generate a differing playback rate, use this formula:

1000000
PBRATE= ---------
speed

Where PBRATE is the value you stick into 006e/006fh in the file, and
speed is the desired speed in hertz.

== Properly Loading a Tune ==

* If the tune is bankswitched, go to #3.

* Load the data into the 6502's address space starting at the specified load address. Go to #4.

* Load the data into a RAM area, starting at (start_address AND 0fffh).

* Tune load is done.

== Properly Initializing a Tune ==

* Clear all RAM at 0000h-07ffh.

* Clear all RAM at 6000h-7fffh.

* Init the sound registers by writing 00h to 04000-0400Fh, 10h to 4010h, and 00h to 4011h-4013h.

* Set volume register 04015h to 00fh.

* If this is a banked tune, load the bank values from the header into 5ff8-5fffh.

* Set the accumulator and X registers for the desired song.

* Call the music init routine.

== Properly Playing a Tune ==

Call the play address of the music at periodic intervals determined by the speed words. Which word to use is determined by which mode you are in- PAL or NTSC.

== Adding DPCM ==
There is a large section on how to deal with DPCM samples in the [http://www.zophar.net/tech/files/NESAudioRipping.TXT NES Music Ripping Guide], but the basic information on DPCM is that writes to $4012 and $4013 access sample data stored at and between $c000 and $ffff.

Writes to $4012 determine the location of the sample data. The value written to $4012, multiplied by 0040h, plus 0c000h, is the point in ROM space the sample starts.

Writes to $4013 determine the length of the sample data. The value written to $4013, multiplied by 0010h, plus 1, is the length of the sample data.

If 00h is written to $4012 and $4013, the sample would be located at $c000, and would be 1 byte in length. If 0080h is written to $4012 and $4013, the sample would be located at $e000, and would be 0x801 bytes in length.

DPCM samples can be attached to an NSF by either relocating the neccesary data, or by including the banks with the DPCM data in the NSF. Relocating the data correctly will often lead to a smaller file size, but including the original data in it's original location is usually easier to do.

== Sound Chip Support ==
Byte 007bh of the file stores the sound chip flags. If a particular flag is set, those sound registers should be enabled. If the flag is clear, then those registers should be disabled. All I/O registers within 8000-FFFF are ''write only'' and must not disrupt music code that happens to be stored there.

=== VRCVI ===
* Uses registers 9000-9002, A000-A002, and B000-B002, write only. See [[VRC6 Audio]] for more information.
* Note: The A0 and A1 lines are flipped on a few games! If you rip the music and it sounds all funny, flip around the xxx1 and xxx2 register pairs. (i.e. 9001 and 9002) 9000 and 9003 can be left untouched. I decided to do this since it would make things easier all around, and this means you only will have to change the music code in a very few places (6). Esper2 and Madara will need this change, while Castlevania 3j will not for instance.

=== VRCVII ===
* Uses registers 9010 and 9030, write only. See [[VRC7 Audio]] for more information.

=== FDS Sound ===
* Uses registers from 4040 through 4092. See [[FDS Audio]] for more information.

Notes:
* 6000-DFFF is assumed to be RAM, since 6000-DFFF is RAM on the FDS. E000-FFFF is usually not included in FDS games because it is the BIOS ROM. However, it can be used on FDS rips to help the ripper (for modified play/init addresses).
* Bankswitching operates slightly different on FDS tunes. 5FF6 and 5FF7 control the banks 6000-6FFF and 7000-7FFF respectively. NSF header offsets 76h and 77h correspond to *both* 6000-7FFF *AND* E000-FFFF. Keep this in mind!

=== MMC5 Sound ===
* Uses registers 5000-5015, write only as well as 5205 and 5206, and 5C00-5FF5. see [[MMC5 Audio]] for more information.

Notes:
* 5205 and 5206 are a hardware 8*8 multiplier. The idea being you write your two bytes to be multiplied into 5205 and 5206 and after doing so, you read the result back out.
* 5C00-5FF5 should be RAM to emulate EXRAM while in MMC5 mode.

=== Namco 106 Sound ===
* Uses registers 4800 and F800. See [[Namco 106 Audio]] for more information.

=== Sunsoft FME-07 Sound ===
* Uses registers C000 and E000. See [[Sunsoft Audio]] for more information.

== Caveats ==
# The starting song number and maximum song numbers start counting at 1, while the init address of the tune starts counting at 0. To "fix", simply pass the desired song number minus 1 to the init routine.
# The NTSC speed word is used *only* for NTSC tunes, or dual PAL/NTSC tunes. The PAL speed word is used *only* for PAL tunes, or dual PAL/NTSC tunes.
# The length of the text in the name, artist, and copyright fields must be 31 characters or less! There has to be at least a single NULL byte (00h) after the text, between fields.
# If a field is not known (name, artist, copyright) then the field must contain the string "<?>" (without quotes).
# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.
# Do not assume the state of *anything* on entry to the init routine except A and X. Y can be anything, as can the flags.
# Do not assume the state of *anything* on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem, above.
# The stack sits at 1FFh and grows down. Make sure the tune does not attempt to use 1F0h-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx)
# Variables should sit in the 0000h-07FFh area *only*. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx).

== Using FCEUXDSP ==
Ripping can be made much easier by using this relatively new NES debugging emulator.

By breakpointing writes to $4015, then resetting the game, you can often find the part of code that initializes the sound registers(Sound Init), and see if it's doing anything unusual at that point.

Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.

Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually disecting the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.

If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...

Open a regular game rom, and open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the other copy, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixed can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF.

Code Types

2006-12-11T23:38:42Z

Ugetab:

Caetla

2006-12-11T23:35:35Z

Ugetab: Reverted edits by Goquendo (Talk); changed back to last version by LiquidManZero

Originally produced by kcomm for use as a development tool, it was soon leaked onto the internet. Later versions had a massive flaw in that they stored codes on a special memory card file. The problem with this is that the program to create the file seems not to exist.

Most versions of Caetla could be used to run out of region and pirated discs on an unmodified playstation.

Game Enhancer

2006-12-09T04:30:31Z

Ugetab:

A game enhancer is a device, usually a cartridge or a CD/DVD, which is used for altering a games memory, which allows access to hidden content or typical cheats.

== List of Game Enhancers ==
[[Action Replay]] 
[[Caetla]] 
[[Codebreaker]] 
[[Game Genie]] 
[[Gameshark]] 
[[Gold Finger]] 
[[Xploder]]

Unhacked: Playstation

2006-12-07T18:08:22Z

Ugetab:

{| border="1"
|+ Unhacked PlayStation Games
! Game !! License Code(s) !! Hacker(s) attempting hacks !! Attempt start date
|-
! Activision Classics
| SLUS-00777
|
|
|-
! [[Chronicles of the Sword]]
| SCUS-94700
SCUS-94701
|
|-
! Nova Storm
| SCUS-94404
SCUS-94707
|
|-
! Pshychic Detective
| SLUS-00165-7
|
|
|-
! Zoop
| SLUS-00078
|
|
|-
|}

== Related ==
*[[Unhacked: Index|Unhacked Games Index]]

SA1

2006-12-06T22:26:05Z

Ugetab:

== Overview ==
The SNES SA1 chip is an expansion chip added to an SNES cart that both contains a portion of the game's coding, and executes that portion of code to affect normal SNES RAM, and the additional RAM accessed primarily by the SA1 chip programming. The additional RAM is also accessible by the SNES CPU's instructions.

There is no current information concerning hardware-based tests with Game Genie codes that change portions of ROM residing within the SA1.

== Memory Mapping Comparison ==
Region 30:0000 - 30:3FFF is SA1 related due to the fact that some RAM is 00 mapped for SA1-using games:

Writes from the SNES CPU to 00:0000 - 00:3FFF region to change a mirrored region at 30:0000 - 30:3FFF region

00:0000 - 00:3FFF 
30:0000 - 30:3FFF

SA1 Address:
Reads/Writes to these addresses from the SA1 CPU translate to the below CPU-accessible addresses in SNES memory 
00:4000 - 00:7FFF 
CPU Address: 
40:0000 - 40:3FFF

SA1 Address Testing: 
If you wish to test writes made by the SA1 to memory, and see what area is changed, you can use the following code with Super Mario RPG (US), while in a 3D stage. You should fall through the ground, and be unaligned with the map, but have the value FE written to the address you chose.

Test SA1 Memory Writes (2 byte addresses, 0xFE written) 
C9C374A9 
C9C375FE 
C9C378FF 
C9C3793F

Load value 0x00FE to write(could be made to load a 2-byte value) 
C9C374A9 
C9C375FE

Address to write to(Writes to 3FFF with these values) 
C9C378FF 
C9C3793F

Main Page

2006-12-01T17:57:08Z

Ugetab:

Please follow the [[GSHI:Guidelines]] when contributing to the wiki 
<H1>Game Systems Headquarters International</H1>
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" width="25%" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#98FB98; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;"
| '''Featured Page'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em; text-align: center;"
|
 
[[Assembly Hacking]]
|}
<blockquote>GSHI is a longstanding collaborative group of code hackers, who have contributed many, many codes to the scene, for such cheat systems as Gameshark, Action Replay, CodeBreaker, and Game Genie. The website and forums were started by and are currently coadministrated by the member who calls himself Lazy Bastard. Many people who use these cheat systems and devices are unaware that the companies who manufacture and market them use websites and communities such as GSHI to produce and distribute the codes that cause them to be as popular as they are. The website is located here: http://www.gshi.org The community itself gathers at the website's home forums, located here: http://www.gshi.org/vb/</blockquote>
 
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#FFDEAD; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;" align="center"
| '''Pages that need information'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;"
|
* [[GSHI]]
* [[Code Types]]
* [[Game Genie]]
* [[Action Replay]]
* [[Codebreaker]]
* [[Gameshark]]
* [[Xploder]]
* [[GCNrd]]
* [[CMGSCCC]]
* [[GSCentral]]
|}

Help:Contents

2006-12-01T03:40:44Z

Ugetab:

A basic statement concerning why this wiki exists, and how it was intended to be used can be found here: 
http://www.gshi.org/wiki/index.php/GSHI:Guidelines

Several good explainations on how to effectively edit pages can be found here: 
http://en.wikipedia.org/wiki/Help:Contents/Editing_Wikipedia

If you wish to experiment, you are free to use your own user page to test editing methods. Using the preview button when testing changes to your own page and wiki articles will help prevent the need to edit pages multiple times to fix errors you make.

Wiki - GameHacking.org:Guidelines

2006-12-01T03:33:28Z

Ugetab:

The primary guidelines for using this wiki are that you should be providing information relavent to hacking, discussing said content, or simply viewing the content available.

This wiki is not a forum, and wasn't intended to be. Discussions that are limited to users' personal pages aren't strictly required to follow an orientation towards hacking, but are required to be civil.

I believe that the topic shown at wikipedia concerning their view of civility will suffice if you've never recognized civil behavior for yourself, or find the meaning unclear: 
[http://en.wikipedia.org/wiki/WP:CIV Civility]

Other wikipedia standards may be adopted in the future, if problems in comprehension arise.

User talk:Lemmayoshi

2006-12-01T02:38:40Z

Ugetab:

Leave the insults to The Pit in the forums.

Main Page

2006-11-30T22:09:03Z

Ugetab:

<H1>Game Systems Headquarters International</H1>
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" width="25%" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#98FB98; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;"
| '''Featured Page'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em; text-align: center;"
|
 
[[Assembly Hacking]]
|}
<blockquote>GSHI is a longstanding collaborative group of code hackers, who have contributed many, many codes to the scene, for such cheat systems as Gameshark, Action Replay, CodeBreaker, and Game Genie. The website and forums were started by and are currently coadministrated by the member who calls himself Lazy Bastard. Many people who use these cheat systems and devices are unaware that the companies who manufacture and market them use websites and communities such as GSHI to produce and distribute the codes that cause them to be as popular as they are. The website is located here: http://www.gshi.org The community itself gathers at the website's home forums, located here: http://www.gshi.org/vb/</blockquote>
 
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#FFDEAD; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;" align="center"
| '''Pages that need information'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;"
|
* [[GSHI]]
* [[Code Types]]
* [[Game Genie]]
* [[Action Replay]]
* [[Codebreaker]]
* [[Gameshark]]
* [[Xploder]]
* [[GCNrd]]
* [[CMGSCCC]]
* [[GSCentral]]
|}

Game Genie

2006-11-30T22:08:30Z

Ugetab: Game genie moved to Game Genie

Game Genie starter page.

Code Types

2006-11-30T21:59:42Z

Ugetab:

Code Types

2006-11-30T21:54:25Z

Ugetab: /* Playstation */

Explanation of what a code type is, and what they're used for here..

== Playstation Systems ==

=== Playstation 2 ===

'''Code Breaker'''
----

'''GameShark (Interact)'''
----

'''GameShark (Mad Catz)'''
----

'''Xploder'''
----

=== Playstation ===

'''Gameshark'''
----
{| style="border:1px solid #000000; margin: 0; padding:0;" width="100%" cellspacing="0" cellpadding="5""
! Type !! Description !! Example !! Other

|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! 30
| 8-bit constant write || 3XXXXXXX 00YY Writes YY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! 80
| 16-bit constant write || 8XXXXXXX ZZYY Writes ZZYY to Address XXXXXXX || NA
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! 50
| serial repeater || 5000XXYY 00ZZ TTTTTTTT VVVV Writes XX codes, with YY added to the address for each code after TTTTTTTT, and ZZZZ added to the amount for each code after value VVVV || Gameshark 2.41 and higher. May need to seperate pairs of serial codes with a 00000000 0000 code for disk-based gamesharks
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! E0
| 8-bit equal-to joker || E0XXXXXX 00YY Activates next code if address 80XXXXXX is equal to YY || NA
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! E1
| 8-bit different-from joker || E1XXXXXX 00YY Activates next code if address 80XXXXXX is different from YY || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! E2
| 8-bit less-than joker || E2XXXXXX 00YY Activates next code if address 80XXXXXX is less than YY || NA
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! E3
| 8-bit greater-than joker || E3XXXXXX 00YY Activates next code if address 80XXXXXX is greater than YY || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! D0
| 16-bit equal-to joker || D0XXXXXX YYYY Activates next code if address 80XXXXXX is equal to YYYY || NA
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! D1
| 16-bit different-from joker || D1XXXXXX YYYY Activates next code if address 80XXXXXX is different from YYYY || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! D2
| 16-bit less-than joker || D2XXXXXX YYYY Activates next code if address 80XXXXXX is less than YYYY || NA
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! D3
| 16-bit greater-than joker || D3XXXXXX YYYY Activates next code if address 80XXXXXX is greater than YYYY || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! D4
| 16-bit universal joker || D4000000 YYYY Activates next code if the button presses equate to YYYY || Needs a button chart
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! D5
| 16-bit codes-on joker || D5000000 YYYY Activates all codes if buton presses equate to YYYY || Needs a button chart
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! D6
| 16-bit codes-off joker || D6000000 YYYY Activates all codes if buton presses equate to YYYY || Needs a button chart
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! 10
| 16-bit incrementer || 10XXXXXX YYYY Increments value at address 80XXXXXX by YYYY || Use with a joker
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! 11
| 16-bit decrementer || 11XXXXXX YYYY Decrements value at address 80XXXXXX by YYYY || Use with a joker
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! 20
| 8-bit incrementer || 20XXXXXX 00YY Increments value at address 80XXXXXX by YY || Use with a joker
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! 21
| 8-bit decrementer || 21XXXXXX 00YY Decrements value at address 80XXXXXX by YY || Use with a joker
|- align="center" style="font-size: 105%; background-color:#ccffff; text-align: center; padding:0;"
! C1
| codes-on delay || C1000000 YYYY Delays codes from being on by YYYY time when game starts. 4000-5000 should give 20-30 seconds. || NA
|- align="center" style="font-size: 105%; background-color:#ffffff; text-align: center; padding:0;"
! C2
| copy memory || C2XXXXXX YYYY 80ZZZZZZ 0000 Copy YYYY bytes from 80XXXXXX to 80ZZZZZZ. Could be used for copying large sets of complex character stats from one character to another, like working-magic-only, if serial repeater won't work || NA

|}

'''Xploder/Codebreaker'''
----

'''Action Replay'''
----

'''Gold Finger'''
----

'''Caetla'''
----

== Nintendo Systems ==

=== GameCube ===

'''Action Replay'''
----

=== Nintendo 64 ===

'''GameShark'''
----

=== GameBoy Advance ===

'''Codebreaker Advance'''
----

'''GameShark Advance (Interact)'''
----

'''GameShark Advance (Mad Catz)'''
----

'''Action Replay'''
----

== Sega Systems ==

=== Dreamcast ===

'''GameShark CDX'''
----

'''Codebreaker'''
----

=== Saturn ===

'''GameShark'''
----

Assembly Hacking

2006-11-30T21:11:54Z

Ugetab: /* Overview */

=Overview=

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes that are entered into an NES Game Genie represent single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less is possible to implement with a single Game Genie. The SNES Game Genie allows up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-byte invincibility and infinite lives codes from appearing that could make it unneccesary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
FCEUXDSP 
http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP

Setting breakpoints in ROM/RAM
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If the 'Hex Editor' is opened in a normal game, then an NSF is loaded, you can use it to work on NSF RAM, in conjunction with the debugger.

'Hex Editor' is a memory viewer/modifier.

==SNES==
Geiger's SNES9X Debugger 
http://geigercount.net/crypt/ 
http://www.zophar.net/snes.html

Setting breakpoints in ROM/RAM 
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==
Gens Tracer 
http://www.romhacking.net/?Category=&Console=0&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=Gens+Tracer&dsearch=&page=utils&action=utillist

No breakpoints, but adequate tracing.

I've written a guide on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

HazeMD 
http://haze.mameworld.info/

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
BGB 
http://bgb.bircd.org/

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

==Gameboy Advance==
Visual Boy Advance Tracer 
http://www.romhacking.net/?Category=&Console=10&Game=0&Author=695&Recm=&Level=&utilsearch=++Go++&title=&dsearch=&page=utils&action=utillist

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Visual Boy Advance 
http://vba.ngemu.com/downloads.shtml 
Windows - SDL

Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats.

Not documented.

==Playstation==
PCSX 1.5 With Debugger 
http://www.romhacking.net/?Category=&Console=0&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=PCSX+1.5+With+Debugger&dsearch=&page=utils&action=utillist

Press F11 to enter the debugger. 
On-screen aids should be apparent.

==N64==
Nemu64 (Project64 debug version for testing, etc.) 
http://www.nemu.com/downloads.php 
http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write checkboxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes 
http://www.romhacking.net/?Category=&Console=27&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=tracer&dsearch=&page=utils&action=utillist

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

Assembly Hacking

2006-11-30T19:30:55Z

Ugetab:

=Overview=

Assembly hacking is the art of editing a compiled program. Without the source code, and without notes from the source code, one has to deduce almost everything about the underlying code, and how it works with RAM.

There are several emulators that can aid one in creating a modification for a game. Games for console systems fall into the category of compiled programs, and generally, the source code is unavailable for these games.

The use of making an assembly hack for a game can be found with the Nintendo Entertainment System (NES) [[Game Genie]].

The codes are were entered into an NES Game Genie represented single-byte assembly hacks. Any assembly hack that could be done with a change of 3 bytes or less was possible to implement with a single Game Genie. The SNES Game Genie allowed up to 5 codes, and 5 bytes of change. While this makes the possible usage of codes very limiting, it didn't prevent single-line invincibility and infinite lives codes from appearing that could make it unneccesary to use additional codes.

For more modern assembly hacking of the same systems, emulators that support 50 or more codes for any given game aren't uncommon. The ROMs have been turned into files that can be patched with all the changes needed to give the game a script in a new language. Emulators that aid in the process of making assembly hacks have appeared for many different emulated systems. The effect is that more people are now capable of starting their own projects, and existing projects can be modified and/or repaired more easily.

=Emulators=

==NES==
FCEUXDSP 
http://www.the-interweb.com/serendipity/index.php?/categories/9-FCEUXD-SP

Setting breakpoints in ROM/RAM
Tools>Debug

In the breakpoint window, 'Add' the Executable address or Memory address you want. 
ROM is 8000-FFFF 
RAM is 0000-07FF, 6000-7FFF 
0800-3FFF is mirrored from some part of RAM. 
4000-4015 can be breakpointed if working on an NSF. If the 'Hex Editor' is opened in a normal game, then an NSF is loaded, you can use it to work on NSF RAM, in conjunction with the debugger.

'Hex Editor' is a memory viewer/modifier.

==SNES==
Geiger's SNES9X Debugger 
http://geigercount.net/crypt/ 
http://www.zophar.net/snes.html

Setting breakpoints in ROM/RAM 
Open ROM, Click 'Breakpoints' 
In the breakpoint window, enter the Executable address or Memory address you want. 
Standard RAM: 7E0000 - 7FFFFF 
SA1 RAM: 400000-407FFF, 303000-303FFF 
HiROM - C00000 - FFFFFF 
LoROM - 808000-BFFFFF (**0000 - **7FFF doesn't exist)

If you use the [[SA1]] logger with an SA1-using game, and wish to find an address that changed an address in RAM, you can see if the conversion chart on the [[SA1]] page shows you the address to search for in the log file.

==Genesis==
Gens Tracer 
http://www.romhacking.net/?Category=&Console=0&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=Gens+Tracer&dsearch=&page=utils&action=utillist

No breakpoints, but adequate tracing.

I've written a guide on the specific usage of the emulator.

The idea is that you can trace-log writes to and reads from memory, and you can also log all commands, and determine what's happening from the full log, by using what you find from the hook logging.

HazeMD 
http://haze.mameworld.info/

This emulator is harder to get setup to use a ROM, but comes with a MAME-style debugger. MAME's debugger is well known for being so powerful, considering the number of systems it can be used with when compiled into a build of MAME. The Gens tracer tends to have slightly better compatibility, while the HazeMD emulator has more potential for cheat codes, already having a Cheat system designed to handle multiple CPUs, which could be used for 32x game ROM hacks, and RAM hacks.

==Gameboy==
BGB 
http://bgb.bircd.org/

Load a ROM, and right-click the screen. 
Other>debug mode enabled: to enable debugging 
Other>debugger to enter the debugger 

Setting breakpoints in ROM/RAM 
In the debugger window: 
Debug>breakpoints for execution breakpoints 
Debug>access breakpoints for read/write breaks. 

==Gameboy Advance==
Visual Boy Advance Tracer 
http://www.romhacking.net/?Category=&Console=10&Game=0&Author=695&Recm=&Level=&utilsearch=++Go++&title=&dsearch=&page=utils&action=utillist

This emulator uses the Hook Log system. Those familiar with the hook_log Genesis or N64 emulators should have little trouble adapting to this system.

Visual Boy Advance 
http://vba.ngemu.com/downloads.shtml 
Windows - SDL

Unfortunately, no cheat device exists that can change the assembly, so hacking it is more a matter of patching the ROM, and less a matter of using it for simple cheats.

Not documented.

==Playstation==
PCSX 1.5 With Debugger 
http://www.romhacking.net/?Category=&Console=0&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=PCSX+1.5+With+Debugger&dsearch=&page=utils&action=utillist

Press F11 to enter the debugger. 
On-screen aids should be apparent.

==N64==
Nemu64 (Project64 debug version for testing, etc.) 
http://www.nemu.com/downloads.php 
http://www.thegshi.org/downloads/Project64%20Build%2052%20Debug%20Binary.zip

Setting execution breakpoints 
Plugins>Debugger: Commands... 
To set a break on execution, go to the line that you want to break on, and click in the vertical bar to the left(<) of the address you want to breakpoint.

Setting breakpoints in RAM 
Plugins>Debugger: Memory... 
Enable the read and/or write checkboxes, and right-click the memory space you want to set, unset, or change an access breakpoint on.

Some games don't run in Nemu, so you may have to switch to this hook_log based emulator if you want the codes 
http://www.romhacking.net/?Category=&Console=27&Game=0&Author=0&Recm=&Level=&utilsearch=++Go++&title=tracer&dsearch=&page=utils&action=utillist

The hook_log system is a little bit more demanding to use than a visual debugger, but with compatibility issues, it's better than lucky to have a second usable debugging emulator. The save-states can be decompressed, and loaded in their decompressed form if needed

An issue with this emulator is that not all instructions are logged, but it's still worth knowing about for the fact that many instructions are logged, and it can be used with write logging.

SA1

2006-11-30T18:32:30Z

Ugetab:

==Overview==
The SNES SA1 chip is an expansion chip added to an SNES cart that both contains a portion of the game's coding, and executes that portion of code to affect normal SNES RAM, and the additional RAM accessed primarily by the SA1 chip programming. The additional RAM is also accessible by the SNES CPU's instructions.

There is no current information concerning hardware-based tests with Game Genie codes that change portions of ROM residing within the SA1.

==Memory Mapping Comparison==
Region 30:0000 - 30:3FFF is SA1 related due to the fact that some RAM is 00 mapped for SA1-using games:

Writes from the SNES CPU to 00:0000 - 00:3FFF region to change a mirrored region at 30:0000 - 30:3FFF region

00:0000 - 00:3FFF
30:0000 - 30:3FFF

SA1 Address:
Reads/Writes to these addresses from the SA1 CPU translate to the below CPU-accessible addresses in SNES memory
00:4000 - 00:7FFF
CPU Address:
40:0000 - 40:3FFF

SA1 Address Testing:
If you wish to test writes made by the SA1 to memory, and see what area is changed, you can use the following code with Super Mario RPG (US), while in a 3D stage. You should fall through the ground, and be unaligned with the map, but have the value FE written to the address you chose.

Test SA1 Memory Writes (2 byte addresses, 0xFE written)
C9C374A9
C9C375FE
C9C378FF
C9C3793F

Load value 0x00FE to write(could be made to load a 2-byte value)
C9C374A9
C9C375FE

Address to write to(Writes to 3FFF with these values)
C9C378FF
C9C3793F

SA1

2006-11-30T18:30:22Z

Ugetab:

==Overview==
----
The SNES SA1 chip is an expansion chip added to an SNES cart that both contains a portion of the game's coding, and executes that portion of code to affect normal SNES RAM, and the additional RAM accessed primarily by the SA1 chip programming. The additional RAM is also accessible by the SNES CPU's instructions.

There is no current information concerning hardware-based tests with Game Genie codes that change portions of ROM residing within the SA1.

==Memory Mapping Comparison==
----
Region 30:0000 - 30:3FFF is SA1 related due to the fact that some RAM is 00 mapped for SA1-using games:

Writes from the SNES CPU to 00:0000 - 00:3FFF region to change a mirrored region at 30:0000 - 30:3FFF region

00:0000 - 00:3FFF
30:0000 - 30:3FFF

SA1 Address:
Reads/Writes to these addresses from the SA1 CPU translate to the below CPU-accessible addresses in SNES memory
00:4000 - 00:7FFF
CPU Address:
40:0000 - 40:3FFF

SA1 Address Testing:
If you wish to test writes made by the SA1 to memory, and see what area is changed, you can use the following code with Super Mario RPG (US), while in a 3D stage. You should fall through the ground, and be unaligned with the map, but have the value FE written to the address you chose.

Test SA1 Memory Writes (2 byte addresses, 0xFE written)
C9C374A9
C9C375FE
C9C378FF
C9C3793F

Load value 0x00FE to write(could be made to load a 2-byte value)
C9C374A9
C9C375FE

Address to write to(Writes to 3FFF with these values)
C9C378FF
C9C3793F

Final Fantasy VI Advance (Hacking)

2006-11-29T21:50:55Z

Ugetab:

===Post Final Fantasy 6 GBA finds here===

----

{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" width="25%" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#FFDEAD; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;"
| '''Fly on Daryl's Airship'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em; text-align: center;"
|
[[image: Daryl2.png]] 
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em; text-align: center;"
|
----
32001E94 00FF 320011FA 0003 '''
----
On the World Map,''' access the main menu and exit it to be in the Airship. From there, press Start and you'll be on the deck of Daryl's Airship. - Ace
|}
02000056 - Change to 01 to call a battle (doesn't work on world map). It seems to call the last battle you were in. Ace's enemy group mod works with it. - KE

0200004C - Screen fade. F0 is normal brightness, 00 is pitch black - KE 
0200004D - Background brightness. 00 is normal, F0 is hellabright(tm) - KE 
0200004B - some digits start a brightness loop. F0 will give you a seizure - KE 
020000FF - Setting this to anything but 00 will put you in "oh chit KE hav to much sakeke" mode, world map only - KE 
'
 
02001CF5 - changes which party you are in control of. 01-03 are the normal parties (2 and 3 are only used in multiple-party scenarios), 00 puts you in a party with a character that has kefka's sprite on the world map, ghestal's portrait, and cyan in battle. - KE 

02026237 - Changes how many parties you can put your characters into at the party selection screen. - KE 

8200185E 5951 - before using code clear the 3rd and 4th slots of your party. with the code on they will be kefka and leo. both have sprites for normal maps and the world map, and work in battle. Kefka must be given commands before he can be used in battle.
 

== cadohacan ==
32001F64 00xx < room modifer looking for debug room right now

== Event Modifier/Activator ==
I think the primary Event Modifier/Activator address is 020000E7

F1 - Load Intro 
F4 - Call Ending Screen 
There's more that effects it. I've managed to call battles, shops, menus, etc with it. Right now it's all about figuring it out... 

'''Note 1: When I said I didn't know much about it, I meant it. :P '''
Note 2: These values will work in town without having to change anything else.. 

Anyway, There seems to be a lot of stuff that effects this. So expect mixed effects.... 


==External links==

*[http://gshi.org/?s=v2&sys=7&gid=6366 Codes for Final Fantasy VI (J) (GBA) on the GSHI]

Final Fantasy VI Advance (Hacking)

2006-11-29T04:53:51Z

Ugetab:

===Post Final Fantasy 6 GBA finds here===

----

{| border="1" cellpadding="0" align="center" width="75%"
|- style="background:#ffdead;"
|Fly on Daryl's Airship
|- align="center"
|http://gshi.org/ace/images/daryl.png
|- align="center"
|32001E94 00FF 320011FA 0003 
|-
|'''On the World Map,''' access the main menu and exit it to be in the Airship. From there, press Start and you'll be on the deck of Daryl's Airship. - Ace
|-
|}

02000056 - Change to 01 to call a battle (doesn't work on world map). It seems to call the last battle you were in. Ace's enemy group mod works with it. - KE

0200004C - Screen fade. F0 is normal brightness, 00 is pitch black - KE 
0200004D - Background brightness. 00 is normal, F0 is hellabright(tm) - KE 
0200004B - some digits start a brightness loop. F0 will give you a seizure - KE 
020000FF - Setting this to anything but 00 will put you in "oh chit KE hav to much sakeke" mode, world map only - KE 
'
 
02001CF5 - changes which party you are in control of. 01-03 are the normal parties (2 and 3 are only used in multiple-party scenarios), 00 puts you in a party with a character that has kefka's sprite on the world map, ghestal's portrait, and cyan in battle. - KE 

02026237 - Changes how many parties you can put your characters into at the party selection screen. - KE 

8200185E 5951 - before using code clear the 3rd and 4th slots of your party. with the code on they will be kefka and leo. both have sprites for normal maps and the world map, and work in battle. Kefka must be given commands before he can be used in battle.
 

----

===Event Modifier/Activator===
When I said I didn't know much about it, I meant it. :P 
Anyway, what I think to be the primary address is this: 020000E7 
'''NOTE 1: There seems to be a lot of stuff that effects this. So expect mixed effects.... NOTE 2: These values will work in town without having to change anything else..''' 
F1 - Load Intro 
F4 - Call Ending Screen 
There's more that effects it. I've managed to call battles, shops, menus, etc with it. Right now it's all about figuring it out... 

----


'''External Links:'''
 [http://gshi.org/?s=v2&sys=7&gid=6366 Codes for Final Fantasy VI (J) on the GSHI]

Main Page

2006-11-29T03:06:09Z

Ugetab:

<H1>Game Systems Headquarters International</H1>
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" width="25%" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#98FB98; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;"
| '''Featured Page'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;"
|
 
[[image: Kefka-t.png|center]]
* [[Hacking:FF6A|Final Fantasy VI Code Hacking]]
|}
<blockquote>GSHI is a longstanding collaborative group of code hackers, who have contributed many, many codes to the scene, for such cheat systems as Gameshark, Action Replay, CodeBreaker, and Game Genie. The website and forums were started by and are currently coadministrated by the member who calls himself Lazy Bastard. Many people who use these cheat systems and devices are unaware that the companies who manufacture and market them use websites and communities such as GSHI to produce and distribute the codes that cause them to be as popular as they are. The website is located here: http://www.gshi.org The community itself gathers at the website's home forums, located here: http://www.gshi.org/vb/</blockquote>
 
 
{| style="border:1px solid #aaaaaa; margin: 0; padding:0;" cellspacing="0" cellpadding="5" align="right"
|- valign="top" style="font-size: 105%; background-color:#FFDEAD; border-bottom:1px solid #aaaaaa; text-align: center; padding:0;" align="center"
| '''Pages that need information'''
|- style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;"
|
* [[GSHI]]
* [[Kodewerx]]
* [[Game genie]]
* [[Action Replay]]
* [[Codebreaker]]
* [[Gameshark]]
* [[Xploder]]
|}

Main Page

2006-11-29T01:44:26Z

Ugetab:

<H1>Game Systems Headquarters International</H1>
<div>
{| style="border:0; margin: 0;" width="25%" cellspacing="10" align="right"
| valign="top" style="padding:0; border:1px solid #aaaaaa; margin-bottom:5px;"
| <div style="font-size: 105%; padding:0.4em; background-color:#98FB98; border-bottom:1px solid #aaaaaa; text-align: center;">'''Featured Page'''</div>
<div style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;">
{| style="border: 0; margin: 0;" cellpadding="3"
| valign="top" |
| valign="top" |
 
[[image: Kefka-t.png|center]]
* [[Hacking:FF6A|Final Fantasy VI Code Hacking]]
|}
</div>
|}
</div>
<blockquote>GSHI is a longstanding collaborative group of code hackers, who have contributed many, many codes to the scene, for such cheat systems as Gameshark, Action Replay, CodeBreaker, and Game Genie. The website and forums were started by and are currently coadministrated by the member who calls himself Lazy Bastard. Many people who use these cheat systems and devices are unaware that the companies who manufacture and market them use websites and communities such as GSHI to produce and distribute the codes that cause them to be as popular as they are. The website is located here: http://www.gshi.org The community itself gathers at the website's home forums, located here: http://www.gshi.org/vb/</blockquote>
 
 
<div>
{| align="right"
| valign="center" style="padding:0; border:1px solid #aaaaaa; margin-bottom:5px;"
| <div style="font-size: 105%; padding:0.4em; background-color:#FFDEAD; border-bottom:1px solid #aaaaaa; text-align: center;" align="center">'''Pages that need information'''</div>
<div style="background:#ffffff; padding:0.2em 0.4em 0.2em 0.4em;">
{| style="border: 0; margin: 0;" cellpadding="3"
| valign="top" |
| valign="top" |
* [[GSHI]]
* [[Kodewerx]]
* [[Game genie]]
* [[Action Replay]]
* [[Codebreaker]]
* [[Gameshark]]
* [[Xploder]]
|}
</div>
|}
</div>