/vr/ - Retro Games

>>10337162
https://www.youtube.com/watch?v=y983TDjoglQ

>>2484743
>>2469079

Ok, I've never hacked the PSX, but here is what I would do...

The first thing you want to do is map out where the interrupt vectors are for the PSX and where they point to. Next you need to find the interrupt that updates the graphics registers, it's probably a NMI (Non Maskable Interrupt). Use system documentation to map out the update routine, identifying graphics registers and where their corresponding RAM counterparts are. This will help you map out per frame things, like graphics output, but also controller I/O.

1) To fix the awkward controls I assume you just want to remap the controller rather than alter anything gameplay wise. In that case it would be trivial to hack. If you can find the subroutine that reads in the controllers (use the documentation to find the appropriate hardware registers, and a debugger to set read/write breakpoints at those addresses), then you can find where the RAM for the controllers is, then you can set read/write break points to find where the data is processed and read in for input. Finally you can edit in the address of your own function to remap the controls, find a location in memory to dump it, call it, but also call the replace function from yours, almost like it was never replaced, and now you've hacked in a controller edit hack.

2) One useful way to find state for a player is to look at save data. Saves need to be small, and when loaded into memory, target very specific parameters that often strike at the heart of player data. You can set breakpoints for addresses known to access SRAM, use the debugger to step out of the save program so that you can identify it, and reverse engineer from there. Corrupting data is a useful way to find player state too, although often times save data has checksums to verify data, so you'll need to disable any such tests by NOPing out (No Operation) assembly instructions.