How were PSP cheat codes created before PPSSPP existed?
- Thread starter Gamerboi28
- Start date
- Views 1,076
- Replies 2
Without emulators there are three general approaches for any given system
1) Hardware debugging.
The PSP in this case allowing a measure of debugging via USB cable. Home consoles as they are known today tend to sit a bit aside from old "home computer" type things that might well have hard exposed hardware -- see something like the multiface series of devices.
2) Software debugging.
Make something that injects its own code into the game (or a higher level) and allows you to stop, compare memory regions for before and after, search for things and whatever else.
Arguably good for 1) and 2) but I will leave it for this one. The principle is generally the same though and you have breakpoints, memory dumps and comparisons as per cheat finding for any given system ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial https://doc.kodewerx.org/ https://fceux.com/web/help/Debug.html https://www.romhacking.net/documents/361/ ).
3) Code disassembly.
Arguably the backwards way of going about it (normally you find the cheat code and use that to inform a disassembly effort) but if you can get a binary suitable for disassembly (decompilation might also be an option for some devices) and indeed run an altered binary you can spend a long time pondering things that you have there (maybe also with a normal save dump for reference) to in turn create a cheat. A workflow might look like make some kind of on screen memory viewer (fairly basic homebrew, presumably you can run custom code in this scenario), maybe make a memory viewer respond to a button press, and from there you can figure what touches different parts of memory and ultimately end up at a cheat.
1) Hardware debugging.
The PSP in this case allowing a measure of debugging via USB cable. Home consoles as they are known today tend to sit a bit aside from old "home computer" type things that might well have hard exposed hardware -- see something like the multiface series of devices.
2) Software debugging.
Make something that injects its own code into the game (or a higher level) and allows you to stop, compare memory regions for before and after, search for things and whatever else.
Arguably good for 1) and 2) but I will leave it for this one. The principle is generally the same though and you have breakpoints, memory dumps and comparisons as per cheat finding for any given system ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial https://doc.kodewerx.org/ https://fceux.com/web/help/Debug.html https://www.romhacking.net/documents/361/ ).
3) Code disassembly.
Arguably the backwards way of going about it (normally you find the cheat code and use that to inform a disassembly effort) but if you can get a binary suitable for disassembly (decompilation might also be an option for some devices) and indeed run an altered binary you can spend a long time pondering things that you have there (maybe also with a normal save dump for reference) to in turn create a cheat. A workflow might look like make some kind of on screen memory viewer (fairly basic homebrew, presumably you can run custom code in this scenario), maybe make a memory viewer respond to a button press, and from there you can figure what touches different parts of memory and ultimately end up at a cheat.
Similar threads
- No one is chatting at the moment.
