Add three freeze actions to the context menu of the Memory Editor

[ghost]

1. Freeze this byte.
2. Freeze this half.
3. Freeze this word.

The freeze commands change the state of the target memory from "not frozen" to "frozen".

When a byte is frozen then all the sb instructions that will write to this byte are totally ignored and won't be executed at all or be temporarily treated like a nop instruction until the sb instructions will write to other byte in memory that is not frozen.

When a half is frozen then all the sh instructions that will write to this half are totally ignored and won't be executed at all or be temporarily treated like a nop instruction until the sh instructions will write to other half in memory that is not frozen.

When a word is frozen then all the sw instructions that will write to this word are totally ignored and won't be executed at all or be temporarily treated like a nop instruction until the sw instructions will write to other word in memory that is not frozen.

Another definition of "frozen memory" is about how the read instructions are interpreted or treated instead of write instructions.

In the second definition:

When the PC encounters a lb or lbu instruction and this lb or lbu instruction is going to read a frozen byte then the value of the operand register is going to be the value of the referenced byte when the referenced byte became frozen and not the current value of the referenced byte.

When the PC encounters a lh or lhu instruction and this lh or lhu instruction is going to read a frozen half then the value of the operand register is going to be the value of the referenced half when the referenced half became frozen and not the current value of the referenced half.

In other words all the lbu and lhu instructions are temporarily treated like a li (ori $OutReg, $r0, 0x....) instruction and the lb and lh instructions are temporarily treated like a li (either addi, addiu, subi or subiu $OutReg, $r0, 0x....) (which the Assembly of PCSX-Redux shows as a move instruction whose source operand is an immediate) whose immediate operand is the value of the referenced byte or half when the byte or half became frozen until other byte or half that is not frozen is read.

When the PC encounters a lw instruction and this lw instruction is going to read a frozen word then the value of the operand register is going to be the value of the referenced word when the referenced word became frozen and not the current value of the referenced word.

In other words all the lw instructions are temporarily treated like a lui and ori instructions whose immediate operands is the high and low halfs of the referenced word when the word became frozen until other word that is not frozen is read.

The two definitions of frozen memory are in fact two different ways to implement the freeze commands but the first definition of frozen memory is the best and more preferable than the second definition in my opinion.

Right now PCSX-Redux users have to add a write breakpoint at the address of the byte, half or word that the user wants to freeze and replace all sb, sh and sw instructions that writes to this byte, half or word with a nop instruction as an inconvenient workaround and this is still bad because the game pauses AFTER the sb, sh or sw instruction was executed and NOT before which also must be fixed in a future build and release of PCSX-Redux!

Using the freeze context menu commands of the memory editor will be much more convenient for PCSX-Redux users and the executable code of the game doesn't have to be modified at all which means that this is much more safe to use the freeze context menu commands than the mentioned workaround above.

Also sometimes this is dangerous to replace a sb, sh or sw instruction with a nop instruction because this sb, sh or sw instruction may write to more than one address and this can be many different memory addresses.

Replacing a sb, sh or sw instruction with a nop instruction might affect all the memory addresses that this sb, sh or sw instruction writes to and this might break the game and require a load state to fix this or even worse a soft reset or hard reset if save state was not used at all.

This is exactly the same when using read breakpoints instead and then replacing all lbu and lhu instructions with a li (ori $OutReg, $r0, 0x....) and lb, lh and lw instructions with a li (either addi, addiu, subi or subiu $OutReg, $r0, 0x....), which the Assembly of PCSX-Redux shows as a move instruction whose source operand is an immediate, and this workaround won't work in cases the immediate operand of the li instruction has to be bigger than 0xFFFF!

If in the Memory Editor the user right clicks a byte that is already frozen then "Unfreeze this byte" appears instead of "Freeze this byte".

If in the Memory Editor the user right clicks a half that is already frozen then "Unfreeze this half" appears instead of "Freeze this half".

If in the Memory Editor the user right clicks a word that is already frozen then "Unfreeze this word" appears instead of "Freeze this word".

The unfreeze commands simply undo the freeze commands and change the state of the target memory from "frozen" to "NOT frozen".

The initial state of the entire memory is "NOT frozen" obviously when booting any game or rom.

Also all bytes, halfs and words that are frozen draw them in blue or cyan colors in the Memory Editor of PCSX-Redux so the user knows what memory is frozen and remains unchanged and what memory is not frozen.

Optionally you can add a new window to the Debug menu that shows all frozen addresses and their size (either Byte, Half or Word) and the ability to add a new address to freeze it and remove an existing address to unfreeze it.

To both Memory Observer and the Watch window suggested in https://github.com/grumpycoders/pcsx-redux/discussions/1071 you can add a fourth column with a button to freeze/unfreeze the address if you want.

To make the freeze commands working the interpreter must be used until breakpoints will work with recompiler one day.

The freeze feature can also be implemented the same way that Cheat Engine, DuckStation and BizHawk already do: Constantly and repeatedly write a given constant value at the frozen address but I don't like this implementation at all because this unnecessarily creates burden on the CPU and make the CPU more busy and cause other applications to take more time to respond to their user especially if the user of this feature freezed a lot of different memory addresses.

Syscalls, like or such as reading a file from disk to RAM, that also modify game memory must also be addressed and be taken into account and consideration and be interpreted in such a way so that the frozen memory and all values of the frozen addresses do not change at all.

[nicolasnoble]

I probably need to augment the Lua API a bit with some more information.

Most or all of this could be built using the ImGui + PCSX Lua API, really.

[ghost]

I probably need to augment the Lua API a bit with some more information.

Most or all of this could be built using the ImGui + PCSX Lua API, really.

Did you understand the feature request at all?