How to find memory addresses to be used with both read and write breakpoints in both No$psx 2.0 and pSX 1.13 PlayStation emulators?

[GAMEBOYADVANCETEMPORARY]

I see that both No$psx 2.0 and pSX 1.13 PlayStation emulators allow me to set both read and write breakpoints at any memory address but I don't see in their interfaces any way to scan the memory and filter out results like both DuckStation, PCSX-Redux and Cheat Engine do.

I wanted to use DuckStation instead of No$psx and pSX but unfortunately DuckStation only supports execute or PC breakpoints right now. There is no any read or write breakpoints in DuckStation. Also DuckStation doesn't have the "Change instruction" context menu that No$psx does another reason that I can't use DuckStation. With DuckStation I can freeze any memory address though but I want to do much more than this by changing MIPS instructions and change the flow control and logic of any PSX game that I am playing.

Right now I can achieve what I want to achieve with PCSX-Redux but unfortunately PCSX-Redux, like DuckStation, also doesn't have the "Change instruction" context menu that No$psx does and I have to use an online MIPS assembler to assemble all MIPS instructions and patch the new MIPS instructions with the memory editor of PCSX-Redux all manually which is very inconvenient for me.

I have already started a new feature request to add both read and write breakpoints to DuckStation and "Assemble" to the context menu of Assembly window in PCSX-Redux but I don't know when the developer(s) of both DuckStation and PCSX-Redux will implement these features and update their PlayStation emulators to add these features in the future.

Meanwhile I want to use No$psx temporarily to use it's "Change instruction" context menu which is much more convenient for me until the "Assemble" feature request is implemented and added to PCSX-Redux. Even when DuckStation can add new, remove existing and support both read and write breakpoints I still have to start another feature request to add "Assemble" command also for DuckStation which also lacks it currently.

With both No$psx 2.0 and pSX 1.13 I found the memory addresses with Cheat Engine 7.4 but they are different than these that I found with both DuckStation Memory Scanner and PCSX-Redux Memory Observer Delta-over-time search for the same variables like health and hearts in Castlevania Symphony of the Night and also the read and write breakpoints of both No$psx and pSX don't work on these addresses that I found with Cheat Engine 7.4.

Also when I close and reopen both No$psx and pSX and boot the same PS1 rom the addresses of the same variables change in Cheat Engine but not in DuckStation Memory Scanner and PCSX-Redux Memory Observer Delta-over-time search.

With PCSX2 1.6.0 I don't have this problem. Any address that I find with Cheat Engine 7.4, I just change the most left digit from 2 to 0 and add a read or write breakpoint at this address with the Debugger of PCSX2 1.6.0 and this works great.

Also if I close and reopen PCSX2 1.6.0 and boot the same PS2 rom again, the memory address of the same variable does not change on Cheat Engine unlike No$psx 2.0 and pSX 1.13.

I wanted to both play and hack PS1 roms with PCSX2 and Cheat Engine because not only Cheat Engine memory scanner can be used with PCSX2, not only PCSX2 can add new, remove existing and support both read and write breakpoints but PCSX2 also has "Assemble Opcode" context menu which is both equivalent and identical to the "Change instruction" context menu of No$psx but the problem is that PCSX2's PS1 compatibility is both awful, bad and terrible and right now PS1 roms can't be played well with PCSX2 at the moment and it doesn't seem in the near future that the developer(s) of PCSX2 are going to improve the PS1 compatibility with PCSX2 since PCSX2 is mainly a PS2 emulator, not a PS1 emulator, and improving PS2 compatibility is more important even though at least 98% of PS2 roms are already playable with the most recent nightly build and release of PCSX2 though.

I wanted to save the state of both No$psx (snapshot) and pSX and temporarily switch to DuckStation or PCSX-Redux to use their Memory Scanner or Memory Observer Delta-over-time search and then go back to No$psx or pSX but unfortunately the save states of both No$psx and pSX are not compatible with DuckStation and PCSX-Redux and this means that both DuckStation and PCSX-Redux can't load any save state of both No$psx and pSX!

I can use memory cards instead but the problem with memory cards is that they are modified by the in-game save function and the in-game save function is not always available unlike emulator's save state feature!

Another problem with memory cards is that NOT every modified memory, especially modified executable code, is saved to memory cards unlike save states which do save all modified memories including executable code!

BizHawk's Nymashock core doesn't support any debugger at all and BizHawk's Octoshock core supports a very limited debugger without even able to Step In, Step Over and Step Out!

BizHawk does have a "Set Libretro Core..." submenu but it is currently experimental and it does not seem to even working on any core that I downloaded from buildbot.libretro.com at all!

Although BizHawk does provide excellent tools to find any memory address and watch, poke and even freeze them! But as I said earlier I want to do much more than just freezing memory addresses like changing MIPS instructions and change the flow control and logic of any PS1 rom that I am playing.

I do wish that BizHawk can load any states saved by both No$psx 2.0 and pSX 1.13 so BizHawk's memory search can be used for both No$psx 2.0 and pSX 1.13 though.

According to my research and from all what I have read about Mednafen, Mednafen should have and support everything that I need EXCEPT a convenient GUI like that of both DuckStation, PCSX-Redux, BizHawk and PCSX2!

Both MedGui Reborn, Mednaffe and MedLaunch help me to launch Mednafen and start playing my PS1 rom on a normal window size (not too small) without hiding my mouse cursor (MedGui Reborn only) but there is NO a convenient GUI to use Mednafen cheat system and debugger! Not even a convenient GUI to bind all DualShock buttons to my keyboard keys!

It seems that RetroArch has a cheat search and a feature to use existing cheats but not a debugger that supports both read and write breakpoints.

What is the point to be able to add both read and write breakpoints with both No$psx 2.0 and pSX 1.13 PlayStation emulators but unable to quickly and easily find any memory addresses to be used with both read and write breakpoints? And unlike PCSX2, their memories are both changing, dynamic and random and not even compatible with Cheat Engine!

Also pSX 1.13 like both DuckStation and PCSX-Redux also doesn't seem to have any "Assemble Opcode" or "Change instruction" context menu that both No$psx and PCSX2 do which is also annoying.

I have already asked this question in ngemu.com yesterday but it is:

Awaiting approval before being displayed publicly.

too much time and I am starting to lose my patience!

I also wanted to ask this question in psxemulator.proboards.com but:

Registration is disabled on this forum.

I also wanted to ask this question in gamehacking.org but:

You may have to register before you can post: click the register link above to proceed.

And when I do click the register link above to proceed:

Sorry, registration has been disabled by the administrator.

I also wanted to ask this question in guidedhacking.com but when I click to register I see this:

Attention: Posting was disabled on March 1st, 2022.

• Everything is the same, but regular users are not able to post.

• Our staff will continue to produce content but regular people will not be able to post.

So I am asking this question here!

Please don't tell me that I did NOT do any research before asking here because I did A LOT of research before asking here!

 

[FAST6191]

I don't know how many are that intimately familiar with PS1 emulators around here (GBA, DS, GB/GBC maybe, Switch, Wii, GC... all fine but PS1 is rarely talked about at those levels), equally 1 day is too long for a complicated question?

Anyway interesting workflow you have adopted, don't know how many particularly use change instruction in anything I have particularly dealt with but then again most things I deal with are cartridge based so even if it makes sense (the DS injects its code into RAM exclusively, and the GBA still had bits of it for faster code) to the point of being key to workflow. It makes sense and I can see it working for some. Same for phraseology; I understand their meaning well enough (guess the nerds that write emulators are averse to proper nouns, no bad thing you) but I don't know that I have seen them anywhere else before.
Equally if you are coming to us from the IDA, ghidra, x64dbg PC world with all that such things afford then you will find us console hacking peasants happy to play in the mud huts and stone tools comparatively, and would probably look on at ollydbg as a step up in the world. This goes double for anything as dubiously emulated as the PS1, PS1 only just entering a golden age after being stuck under the boot of epsxe and its plugins for years, even more for anything not popular either.

"PC breakpoints"
As in program counter or more generally run to line? I don't know that I have seen them as distinct from break on execute before but hey.

Usual three ways to find addresses.

Cheat search. Be it internal cheat search in the emulator, external with something like emuhaste/artmoney/cheat engine, savestate based (looking for deltas works well, and is almost mandatory for pointers but more on that later), possibly external debugger driven (don't know what GDB stubs exist for PS1 emulators offhand but that is the usual thing https://wrongbaud.github.io/posts/ghidra-debugger/ ).

Static disassembly. Grab a savestate/memory dump (might be incomplete but will usually be uncompressed and unencrypted if that is a problem for your device) or otherwise find the binary and disassemble it. Using a cheat derived address or something then search for anything writing that and you have your breakpoint. Primitive and prone to not working very well but can also yield things quickly so many keep it in the back pocket.

Key off something else. Plenty of things will play a sound, happen in response to a button press, change some aspect of graphics, possibly read a file on the CD you found by whatever means (relative search, magic stamps, corruption, file swapping, other analysis... it matters little how you know but that you do)... all of which are known locations (give or take debounced button presses but that is hardly major as much as an extra step) you can look up in your chosen hardware docs
http://problemkaputt.de/psx-spx.htm
Fire up the real time memory viewers of those things (graphics might be harder as they don't have some of the nice 2d things I am used to for a lot of things, and channels might be more random depending upon background events but go to quiet place is the same).

In other emulators you might have a last executed new instruction/subroutine https://fceux.com/web/help/CodeDataLogger.html
Don't know if such a thing exists for the PS1 at this point and the logs will be huge compared to most of the things I have seen with them but that is also a way. Here you usually start the logger, do everything you reasonably can except what you want (say want to know jumping mechanic in a platformer, everything but) such that it has seen idle poses, music, timers and whatever else before then, when you jump you get something new to look at and there is your thing to look at.

Changing addresses is odd.
The PS1's major claim to fame was the ability to write in C so it would not be unusual to see memory allocated and released (or not in the case of you chasing a memory leak) such that things might vary depending upon what else was happening or what had not been released (can be as simple as waiting a bit longer at the start menu, or going to the options menu first, or some other in game menu). This throws most in the world of pointer cheats where the "easy" way is find several cheats in presumably different locations over different boots/runnings of that area, note location and make a savestate of the whole RAM, tools then exist to find whatever was pointing at that location between boots and hopefully then your pointer. Nested pointers can be found this way but obviously takes a bit longer and is far from ideal. The "hard" way if you already know enough assembly to be dangerous is it will have to calculate the pointer somewhere in the code so standard debugging procedure.
It not happening for other emulators and you mentioning using an external cheat engine means it might be the emulator itself changing location it allocates to the memory of the system it is editing. Find either the pointer (cheat engine I am not so familiar with but most tools I have used like it include plugins/scripts/ini files/whatever to allow end users to update with respect to new versions, such a thing would necessarily include the PC pointer) or some fixed unique location such that you can key off the cheat engine search/memory dump and find the new location, or indeed some obvious tell in the game's own memory setup that you can move relatively similar to how people might convert cheats between regions that shuffled things around a few bytes (say 8 bit names rather than 16) but still use substantially the same layouts and encodings for everything else.

I am equally surprised no$psx does not have much for cheats to edit memory with. His other emulators have some pretty good cheat search options (maybe not as much as some others, and others use external tools) and I would have thought equivalents get made before some of the higher end debugging features make an appearance. I am not on a Windows machine to test right now though so I will take your word for it.

With DuckStation I can freeze any memory address though but I want to do much more than this by changing MIPS instructions and change the flow control and logic of any PSX game that I am playing.

If the binary being in RAM and not generally being refreshed outside of whatever the PS1 uses for dynamic code (I don't know offhand, overlays were still being used on the DS and with all else I have seen on the PS1 I would be surprised if it was full on Windows/xbox/modern OS style dynamic) and give or take some anti piracy the world had gotten over its little fetish for self modifying code by the time of the PS1 as well, though even then PS1 cheats should do an IF ELSE/if equal to then arrangement so you can drop that in as an thing to key off whatever is unique about the dynamically loaded area of code to alter your chosen instructions. Backwards work around maybe but I did mention us console hacking peasants earlier, and should be pretty quick never the less, not to mention have the web page (or whatever) on your second screen and it is probably no harder than scanning over to your reference for the instruction set (though if you memorised the set, suitable quirks and timings, something normally only seen on 6502 and z80 worlds where that is a more reasonable feat, then I will take it back/defer accordingly and hail the second coming of mel https://prog.world/the-story-of-mel-a-real-programmer/ )
It could also be an anti cheat measure as cycling addresses (up to something someone might describe using similar terms to round robin) is a thing. Though if the existing cheats are not quite a few lines long and probably obvious from context then probably not.

PCSX2's PS1 compatibility is both awful, bad and terrible

To the point of it being unworkable for hacking purposes or indeed hacking purposes for the game(s) you are presently interested in?

As far as save state cross compatibility then that is super rare unless intentional. That said it is usually not so bad to convert (it is an arrangement of memory dumps, padding, maybe byte ordering), though I don't know what goes for dynarec in savestates for these PS1 emulators offhand which could make things harder if that is carried through.