-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hex Editor, ASCII editor, cheats, memory card editor, assembler, disassembler, memory hacks, memory dumping and restoring. #22
Comments
I was hoping that the current debug interface (implementing the GDB protocol over a debug socket) could be extended to implement a cheat engine. I already use it to step through the assembly and display RAM values and it works decently well. That being said the GDB protocol might prove limiting for certain applications, or at least require a few hacks or extensions to work well. For instance I have no direct access to the video RAM at the moment. I think I'll have to try one of the existing cheat engines to see how it looks like and what's the best way to reimplement the same features. Memory cards should have their own issue I think, it's not directly related to the cheat/debugging interface. |
Yeah hex editor in particular would be very helpful for hacking. I doubt things like Hex editor , memory and framebuffer dumping can be done with just GDB. It'll probably need dedicated interface/GUI of some sort. |
It's using HTML/Javascript for the UI it seems which might make it a bit painful to integrate. Do you know which emulator is considered to have the best memory editor? I suck at UI design... |
Sorry if I didn't get back to you yet, I'm shoulders deep in the libretro port and I still have some work ahead of me. I have turned the Rustation code into a stand-alone library though so it should be possible to implement alternative frontends easily if libretro doesn't cut it for some of these things. |
I think I'm going to try to extend the GDB interface to implement GPU debugging. Now that I'm almost done converting the code into a libretro core I can't really implement a proper "internal" debugger since I can't really build a GUI in libretro. I'm thinking of having a separate application connect to the running emulators and fetch the necessary data for debugging. An other possibility would be having a stand alone version of the emulator for debugging but I don't feel like implementing and supporting both at this point. |
So I've been thinking about how to handle memory cards. It's a bit tricky to handle right. My current approach would be to have a game-specific memory card in slot 1 and a common memory card (always the same no matter the game you play) in slot 2. I think it's relatively straightforward and it would fit my particular needs I think. Maybe some people would prefer to have two game-specific memory cards though, if they like to make many saves for a given game. A potential problem is that "game-specific" can be tricky to do right, especially for multi-disc games. At first I thought I could use the serial number (it's normally the main binary name in all licensed PlayStation games). Unfortunately I've discovered that multi-disc games have a different serial number per-game. For instance MGS (USA) disc 1 is Mednafen handles this by using m3u playlists, but that seems pretty user-unfriendly. Unfortunately the only other approach I can think of would be to use a database containing all PSX games and use that to catch the multi-disc scenario. With a database we could decide to standardize on the serial number of the first disc for instance, that would give us files named like:
Having a DB could also avoid having to mess with m3u when changing discs, the emulator could just look for a disc image in the current directory with the correct serial number, although that might be a bit slow if you have a shitload of disc images in the directory. But that's an other problem. Serial numbers are different between regions, but that's probably a feature since we can't be sure that the memory card format would be compatible anyway. I'm going to try to compile such a database and see how it goes. |
I think these features would be very useful for cheats, translations, game hacking and memory hacks.
Plugin-based PSX emulators have a plugin called PSX Emulation Cheater(PEC) for it. I believe PSX/PSXFin has built-in Hex editor.
http://ngemu.com/threads/playstation-emulator-cheater-setup-guide.101186/
http://pec.duttke.de/
http://www.aldostools.org/pecedit.html
https://github.com/strobejb/HexEdit
https://github.com/evanmiller/hecate
http://www.zophar.net/utilities/hexutil.html
http://homepage.ntlworld.com/simon.mallion/PSXMemTool/
The text was updated successfully, but these errors were encountered: