APR-Dateikennungen und Lesevorgänge
APR löst eine Titeldatei einmal auf und trägt danach eine prozesslokale Kennung in späteren Befehlspuffern. Aufgeschobene AMPR-Lesevorgänge öffnen dieselbe nur lesbare Datei unter /app0 erneut, ohne einen Host-Deskriptor dauerhaft zu behalten.
Repository-Notizen bis 10. Oktober 2026
Kennungen statt Pfade
Die Beschleuniger-API will nicht in jedem Befehl einen Pfad. Der Titel löst einen Pfad auf, erhält eine kompakte Dateikennung und setzt diese Kennung in die Lesebefehle, die er später einreicht. PS5PCEM hält den Pfad und die Dateigröße neben der Kennung. Die Tabelle ist prozesslokal. Host-Pfade werden dem Gast nicht zurückgegeben.
Die Dateien stammen aus dem nur lesbaren /app0-Mount des Titels. Ein aufgelöster Eintrag kann erneut geöffnet werden, wenn ein aufgeschobener Lesevorgang läuft, sodass der Emulator nicht jeden Deskriptor über die ganze Lebensdauer des Prozesses halten muss. Die zwischengespeicherte Tabelle fasst bis zu 64 Dateien.
Befehlspuffer
Eine Einreichung ist ein Befehlspuffer des Gastes, kein einzelner Leseaufruf. PS5PCEM akzeptiert bis zu 32 gleichzeitig vorhandene Befehlspuffer. Jeder Puffer ist begrenzt: 32 Lesevorgänge, 32 Schreibvorgänge, 32 Abbildungen, 32 Abschlussdatensätze und 128 Operationen. Bis zu 64 Einreichungen können gleichzeitig offen sein, und ein automatischer Pool hält acht Puffer. Ein Lesevorgang nennt die Dateikennung, ein Gastziel, eine Größe und einen Dateioffset und kann eine Adresse nennen, die die Bytezahl empfängt.
Der Leser weist eine unbekannte Kennung, eine fehlende Datei, einen zu kurzen oder falsch ausgerichteten Befehlspuffer und eine Anfrage zurück, die über die Datei oder das Ziel hinauslaufen würde. Ein einzelner Lesevorgang ist auf 4 GiB begrenzt. Das ist die Grenze der Schnittstelle, kein Versprechen, dass ein Titel so große Lesevorgänge absetzt. Map-Befehle nutzen die AMM-Seitengröße von 16 KiB, die der Gast erwartet.
Wie APR und AMPR zusammentreffen
APR besitzt die Dateitabelle und die Lebensdauer der Befehlspuffer. AMPR besitzt die Zähler, die Wartebedingungen und die Abschlussereignisse, die dem Titel mitteilen, dass die Arbeit fertig ist. Ein Titel kann viele Dateilesungen einreihen und dann auf einen Zähler warten, den der Abschlussbefehl aktualisiert. Der erste Start von Grand Theft Auto III ist der große beobachtete Fall: Die Lesevorgänge laufen über diesen Pfad, und die Abschlussereignisse kommen über die AMPR-Warteschlange zurück.
Asynchrone Ein- und Ausgabe des Kernels, die andere Datei-API, ist eine eigene Seite. APR ist der Befehlsstrom des Beschleunigers. Die Batch-API des Kernels ist die Anforderungsliste im POSIX-Stil.
Was umgesetzt ist
- Prozesslokale Dateikennungen für nur lesbare Pfade unter /app0, mit einer Größe, die für spätere Lesevorgänge erhalten bleibt.
- Begrenzte Befehlspuffer für Lesevorgänge, Schreibvorgänge, Abbildungen und Abschlussdatensätze.
- Aufgeschobene Lesevorgänge, die dieselbe Titeldatei erneut öffnen.
- Geprüfte Ablehnung unbekannter Dateien, von Überläufen und fehlerhaften Puffern.
Was noch fehlt
- Der Pfad ist eine Softwareausführung des Befehlspuffers, nicht die DMA-Engine der Konsole.
- Beschreibbare Paketdateien liegen außerhalb von /app0. Spielstände laufen über den Spielstand-Mount.
- Eine Datei, die der Auflöser noch nicht gesehen hat, lässt sich nicht aus einer nackten Kennung erfinden.
Verwandte Mechanismen
Worum es auf diesen Seiten geht