Identificadores y lecturas de archivo de APR
APR resuelve un archivo del título una vez y después lleva un identificador local al proceso en los búferes de comandos posteriores. Las lecturas diferidas de AMPR reabren ese mismo archivo de solo lectura de /app0 sin conservar un descriptor del anfitrión para siempre.
Notas del repositorio hasta el 10 de octubre de 2026
Identificadores en lugar de rutas
La API del acelerador no quiere una ruta en cada comando. El título resuelve una ruta, recibe un identificador de archivo compacto y pone ese identificador en los comandos de lectura que envía después. PS5PCEM guarda la ruta y el tamaño del archivo junto al identificador. La tabla es local al proceso. Las rutas del anfitrión no se devuelven al invitado.
Los archivos provienen del montaje de solo lectura /app0 del título. Una entrada resuelta puede reabrirse cuando se ejecuta una lectura diferida, así que el emulador no tiene que retener cada descriptor durante toda la vida del proceso. La tabla en caché admite hasta 64 archivos.
Búferes de comandos
Un envío es un búfer de comandos del invitado, no una sola llamada de lectura. PS5PCEM acepta hasta 32 búferes de comandos vivos. Cada búfer está acotado: 32 lecturas, 32 escrituras, 32 mapas, 32 registros de finalización y 128 operaciones. Pueden estar en vuelo hasta 64 envíos, y un pool automático contiene ocho búferes. Una lectura nombra el identificador de archivo, un destino del invitado, un tamaño y un desplazamiento en el archivo, y puede nombrar una dirección que recibe el número de bytes.
El lector rechaza un identificador desconocido, un archivo ausente, un búfer de comandos corto o no alineado, y una petición que se saldría del archivo o del destino. Una lectura individual tiene un tope de 4 GiB, que es el límite de la interfaz, no una promesa de que un título emita lecturas tan grandes. Los comandos de mapa usan el tamaño de página AMM de 16 KiB que espera el invitado.
Cómo se encuentran APR y AMPR
APR posee la tabla de archivos y el ciclo de vida del búfer de comandos. AMPR posee los contadores, las esperas y los eventos de finalización que dicen al título que el trabajo terminó. Un título puede encolar muchas lecturas de archivo y después esperar un contador que actualiza el comando de finalización. El primer arranque de Grand Theft Auto III es el caso grande observado: las lecturas pasan por esta ruta, y los eventos de finalización vuelven por la cola de AMPR.
La E/S asíncrona del kernel, la otra API de archivos, es una página distinta. APR es el flujo de comandos del acelerador. La API de lotes del kernel es la lista de peticiones al estilo POSIX.
Qué está implementado
- Identificadores de archivo locales al proceso para rutas de solo lectura de /app0, con el tamaño conservado para lecturas posteriores.
- Búferes de comandos acotados para lecturas, escrituras, mapas y registros de finalización.
- Lecturas diferidas que reabren el mismo archivo del título.
- Rechazo comprobado de archivos desconocidos, desbordamientos y búferes mal formados.
Qué falta todavía
- La ruta es una ejecución en software del búfer de comandos, no el motor de DMA de la consola.
- Los archivos de paquete con escritura quedan fuera de /app0. Las partidas pasan por el montaje savedata.
- Un archivo que el resolutor no ha visto no puede inventarse a partir de un identificador desnudo.
Mecanismos relacionados
Qué describen estas páginas