This adds a tool that writes a snapshot of the full PS3 guest address
space to disk for offline analysis.
This tool produces a flat image that any hex editor or script can index
directly by guest address. It dumps allocated PS3 guest memory only, not
RPCS3 host-process memory, host registers, or GPU-side state.
What it does:
1. Pauses emulation and waits up to five seconds for every PPU, SPU, and
RSX thread to settle. If they do not settle, nothing is written.
2. Copies every allocated guest page into an intermediate buffer on a
named worker thread, then writes it to a sparse `guest_memory.bin` whose
file offset equals the PS3 effective address. Reads go through
`vm::g_sudo_addr` so guest protected pages are captured too.
3. Saves each live SPU thread's 256 KB local store to its own file, with
its ID, LV2 ID, PC, and type recorded.
4. Writes `manifest.json`, listing every allocated region with its
addresses and permissions, the storage mode, and the SPU local-store
table.
5. Resumes emulation.
The menu entry is under Utilities next to Memory Viewer and is enabled
while a game is loaded. Free space is checked before writing. If sparse
file setup fails, the incomplete attempt is removed and the user can
choose another destination or cancel. Failed or cancelled dumps remove
their output folder instead of leaving a partial image.
Tested on Windows using an NTFS destination with a build from this
branch: dumped a running game with 479,535,104 allocated guest bytes
across 76 regions and five SPU local stores. The image was sparse, its
offsets matched guest addresses, and emulation resumed cleanly. The
sparse file failure path was also exercised with a temporary local test:
choosing another location reopened the destination picker, while
cancelling aborted the attempt without leaving partial output. Runtime
behavior on Linux and macOS is untested.
The first draft of this implementation was AI assisted. I reviewed and
adjusted the code and tested the Windows/NTFS path myself. I am happy to
rework anything or answer any questions.
Follow up of #18345 to add support (currently only on `Windows`; see
notes below) for playing a PS3 disc game directly from a Blu-Ray Disc
Drive.
### HOW IT WORKS:
- The BD drive can be added as any other game so from `VFS games` or
from `Add Games` menu. In case it is selected from `VFS games`, any
attempt to write files is discarded, e.g. file `Disc Games Can Be Put
Here For Automatic Detection.txt`
- It scans the default redump keys folder `<rpcs3>/data/redump` (it
currently needs to be manually created due it is not yet provided by
rpcs3 installation) to find a matching decryption key
### NOTES:
- Support is currently provided on `Windows` where I can fully test it.
I cannot test under other OS. However, the additions needed for the
other OS are limited only on `fs::file.h/cpp`. In particular inside the
following new functions:
- `bool is_optical_raw_device(const std::string& path);`
- `bool get_optical_raw_device(const std::string& path, std::string*
raw_device = nullptr);`
- Icons etc. are always refreshed (ISO cache cannot be used due `mtime`
on raw device is not available and any cache check would always fail)
- Code in `ISO.h/cpp` needed some rework to properly manage a read on a
raw device (alignment on offset, size and memory is mandatory). The BD
drive needs to be detected as a file, not as a folder
### MINOR FIXES:
- Fixed wrong specifier used in logging on `ISO.h/cpp`
On empty mounted drives CreateFileW may return a valid handle even if the drive is not usable.
We have to check the file handle early. Otherwise other functions may fail later as a result.
Adds infrastructure to read files/data from ISOs.
Also adds classes extending fs::device_base and fs::file_base in order
to allow reading files through fs namespace functions. This approach
should allow ISO data to be read by the emulator with the least changes
to existing code.
fix compile errors on Mac and provide reviewed changes
fix wrong resolved conflict
removed duplicate
cleanup after latest merged PRs
minor cleanup
rename and move get_existing_dir() to File.cpp
apply reviewed changes
File descripor ID with 2 provided ways to compare between them:
1. is_mirror_of():
Test if identical:
For example: when LHS writes one byte to a file at X offset, RHS file be able to read that exact byte at X offset)
2. is_coherent_with():
Test if both files point to the same file:
For example: if a file descriptor pointing to the complete file exists and is being truncated to 0 bytes from non-
-zero size state: this has to affect both RHS and LHS files.
caner
Antonino Di Guardo
Elad
Megamouse
Functionable
digant73
DH
oltolm
Steveice10
Eladash