Hex Editor, ASCII editor, cheats, memory card editor, assembler, disassembler, memory hacks, memory dumping and restoring.

ADormant commented 8 years ago

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/

simias commented 8 years ago

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.

ADormant commented 8 years ago

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.

ADormant commented 8 years ago

simias commented 8 years ago

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...

ADormant commented 8 years ago

ADormant commented 8 years ago

Okay I found other example in C++. As for GUI what about GTK+? it has good Rust bindings. https://github.com/kud1ing/awesome-rust https://github.com/gamazeps/Useful-Rust-Projects https://github.com/gtk-rs https://github.com/kenz-gelsoft/wxRust

ADormant commented 8 years ago

@simias Rust GUI resources https://github.com/kenz-gelsoft/wxRust

https://github.com/gtk-rs

https://github.com/crabtw/rust-bindgen

https://github.com/PistonDevelopers/conrod/blob/master/examples/all_widgets.rs

https://github.com/PistonDevelopers/conrod/blob/master/examples/custom_widget.rs

https://www.reddit.com/r/rust/comments/3rtvzg/what_would_be_the_best_way_to_make_a_rust_gui/

https://github.com/gtk-rs/gtk

https://github.com/gtk-rs/glib

https://github.com/gtk-rs/cairo

https://github.com/gtk-rs/sys

https://github.com/gtk-rs/pango

https://github.com/cyndis/qmlrs

https://github.com/PistonDevelopers/conrod

https://github.com/ctjhoa/rust-learning https://github.com/dschenkelman/rust-lang-resources https://github.com/kud1ing/awesome-rust https://github.com/gamazeps/Useful-Rust-Projects https://github.com/McNopper/OpenGL

ADormant commented 8 years ago

https://github.com/PistonDevelopers/conrod/blob/master/examples/custom_widget.rs

ADormant commented 8 years ago

simias commented 8 years ago

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.

simias commented 8 years ago

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.

simias commented 8 years ago

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 SLUS-00594 while disc 2 is SLUS-00776.

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:

SLUS-00594_Metal-Gear-Solid.mcr
SCPS-10031_Crash-Bandicoot.mcr
SCES-01438_Spyro-the-Dragon.mcr

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.

simias / rustation

Hex Editor, ASCII editor, cheats, memory card editor, assembler, disassembler, memory hacks, memory dumping and restoring. #22