APR file identifiers and reads
APR resolves a title file once and then carries a process-local identifier in later command buffers. Deferred AMPR reads reopen that same read-only /app0 file without keeping a host descriptor forever.
Repository notes through October 10, 2026
Identifiers instead of paths
The accelerator API does not want a path in every command. The title resolves a path, receives a compact file identifier, and puts that identifier in the read commands it submits later. PS5PCEM keeps the path and the file size next to the identifier. The table is process-local. Host paths are not handed back to the guest.
The files come from the title's read-only /app0 mount. A resolved entry can be reopened when a deferred read runs, so the emulator does not have to hold every descriptor for the whole process lifetime. The cached table holds up to 64 files.
Command buffers
A submission is a guest command buffer, not a single read call. PS5PCEM accepts up to 32 live command buffers. Each buffer is bounded: 32 reads, 32 writes, 32 maps, 32 completion records and 128 operations. Up to 64 submissions can be in flight, and an automatic pool holds eight buffers. A read names the file identifier, a guest destination, a size and a file offset, and it may name an address that receives the byte count.
The reader rejects an unknown identifier, a missing file, a short or unaligned command buffer, and a request that would walk off the file or the destination. A single read is capped at 4 GiB, which is the interface limit, not a promise that a title issues reads that large. Map commands use the 16 KiB AMM page size the guest expects.
How APR meets AMPR
APR owns the file table and the command-buffer lifetime. AMPR owns the counters, the waits and the completion events that tell the title the work finished. A title can queue many file reads and then wait on a counter that the completion command updates. Grand Theft Auto III's first startup is the large observed case: the reads go through this path, and the completion events come back through the AMPR queue.
Kernel asynchronous I/O, the other file API, is a separate page. APR is the accelerator command stream. The kernel batch API is the POSIX-style request list.
What is implemented
- Process-local file identifiers for read-only /app0 paths, with size retained for later reads.
- Bounded command buffers for reads, writes, maps and completion records.
- Deferred reads that reopen the same title file.
- Checked rejection of unknown files, overflow and malformed buffers.
What is still missing
- The path is a software execution of the command buffer, not the console DMA engine.
- Writable package files are outside /app0. Saves go through the savedata mount.
- A file the resolver has not seen cannot be invented from a bare identifier.
Related mechanisms
What these pages are