HLE, High-Level-Emulation der Firmware
HLE ist die Art, wie PS5PCEM die Firmware-Aufrufe beantwortet, die ein Titel importiert. Jede numerische NID wird zu einer Zig-Funktion auf einem Host-Stack, wobei die System-V-Aufrufkonvention des Gastes unter Windows erhalten bleibt.
Repository-Notizen bis 10. Oktober 2026
Warum die Firmware nicht im Spiel liegt
Ein PlayStation-5-Titel trägt das Betriebssystem, das er aufruft, nicht bei sich. Seine Importe sind Kennungen aus 11 Zeichen. PS5PCEM berechnet jede Kennung aus dem Exportnamen: SHA-1 des Namens plus ein festes Salt, danach die ersten acht Digest-Bytes in einer Base64-Variante. Eine Implementierung registriert sich unter dem lesbaren Namen und kann die Kennung verlangen, die dieser Name erzeugen muss, sodass ein falsch geschriebener Export beim Bauen des Moduls scheitert.
Der dynamische Linker sucht die Kennung zusammen mit der Bibliothek, dem Modul und ihren Versionen. Dieselbe Kennung kann in mehr als einer Bibliothek vorkommen. Eine Suche nur nach der Kennung gibt es für Importe, die keine brauchbaren Metadaten mitbringen, und dieser Rückfall gilt als letztes Mittel, weil er mehrdeutig ist.
Der Aufruf läuft auf einem Host-Stack
Der Gast ruft die Firmware direkt auf, daher beginnt der Aufruf auf dem Stack des Gast-Threads, oft ein Megabyte groß, weil der Titel genau das angefordert hat. Host-Arbeit wie das Öffnen einer Datei braucht einen viel größeren Stackframe. Der Compiler reserviert diesen Frame beim Eintritt, vor jedem frühen Rücksprung. Ein Firmware-Rumpf kann daher über den Gast-Stack hinauslaufen, bevor er die Zeile erreicht, die den Platz brauchte, und der Fehler landet außerhalb jeder Gast-Abbildung.
Jeder HLE-Aufruf wechselt für die Dauer der Host-Arbeit auf einen eigenen Host-Stack je Thread. Die Argumente gehen durch den Speicher, daher bedient ein einziges Assembler-Stub jede Signatur, einschließlich Rückgaben von Gleitkommazahlen und Aggregaten. Verschachtelte Firmware-Aufrufe bleiben auf dem Stack, den der äußere Aufruf bereits eingerichtet hat. Unter Windows nutzt der Gast die System-V-AMD64-Konvention, der Host dagegen Microsoft x64, daher wird jede vom Gast aufrufbare Funktion mit der Gastkonvention deklariert. Fehlt diese Deklaration, kompiliert der Code trotzdem und liest die Argumente danach aus den falschen Registern.
Was die HLE-Oberfläche abdeckt
Auf dieser Maschinerie stellen die Firmware-Bibliotheken direkten und flexiblen Speicher, Modul-Handles, pthreads, Synchronisation, Dateien, Spielstände, Fibers, Schriften, PNG, die Uhr, Pads, AudioOut, AJM, NGS2, ACM, AvPlayer, APR und AMPR bereit. Netzwerk, SSL und die NP Web API behalten die Lebensdauer ihrer Kontexte und Anfragen und liefern deterministische Offline-Fehler. Dialoge, die eine System-Shell brauchen, enden sofort mit einem stimmigen Ergebnis ohne Oberfläche.
Der Validierungslauf vom 10. Oktober bestand die vollständige ReleaseSafe-HLE-Suite, 606 von 606 Tests. Diese Zahl ist die Firmware-Suite. Sie verzeichnet für sich genommen weder eine neue Bildrate noch einen neuen abgeschlossenen Durchlauf.
Was umgesetzt ist
- NID-Berechnung, eine versionierte Symbolregistrierung und ein Wechsel auf den Host-Stack für jeden Firmware-Aufruf.
- System-V-Aufrufe des Gastes unter Windows, wo die Host-Konvention Microsoft x64 ist.
- Speicher, Dateien, Threads, Spielstände, Medien, Audio-Codecs und der Befehlspfad von APR und AMPR.
- Dialoge ohne Oberfläche und ein Offline-Netzwerkprofil, das keine Host-Sockets öffnet.
Was noch fehlt
- Bibliotheken, die der Titel importiert und die PS5PCEM nicht implementiert hat, lassen den Import weiterhin fehlschlagen.
- Wirklich bedarfsgesteuertes Laden eines Moduls, das nicht im veröffentlichten Graphen stand, liefert einen Fehler.
- Plattformdienste, die eine echte Shell, ein Konto oder eine Netzwerkgegenstelle brauchen, bleiben nicht verfügbar.
Verwandte Mechanismen
Worum es auf diesen Seiten geht