Emulador PSP Allegrex para God of War: Chains of Olympus

Sobre o projeto

Este projeto e um emulador experimental de PSP, escrito principalmente em C, com suporte auxiliar em C++ para componentes de PRX. O objetivo principal e executar God of War: Chains of Olympus de forma nativa em um dispositivo ARM64 de baixo custo, especialmente o R36S/RK3326, usando recompilacao estatica (AOT) quando houver blocos traduzidos e mantendo um interpretador Allegrex como fallback e ferramenta de diagnostico.

O projeto esta em desenvolvimento e ainda nao e um emulador PSP completo. A substituicao recente dos arquivos ativos pelos do backup removeu a recuperacao estreita de projection 2D: os quads da interface voltaram a colapsar no eixo Y. A correcao foi restaurada e coberta por teste; tambem foi corrigida uma flag de depth descartada indevidamente ao selecionar repetidamente o mesmo alvo. Os testes sinteticos passam. O Run309 voltou a capturar a cartela legal sem faults, mas nao recebeu entrada; ainda falta uma captura do menu real com entrada controlada para confirmar cores e posicoes estaveis. Run291 ja havia mostrado o menu apos Circle/X, seguido da tela de dificuldade, mas nao chegou a cena do Kratos. Os draws anotados como transformados usam projection ortografica de interface; nao sao evidencia de geometria 3D de gameplay.

Autoria do codigo

Conforme declarado pelo responsavel pelo projeto, todo o codigo de implementacao deste projeto foi produzido por inteligencia artificial; nao houve escrita manual de codigo. Isso se refere ao codigo proprio do emulador, aos scripts e aos testes deste projeto. O diretorio PPSSPP/ contem codigo de terceiros/upstream usado como referencia e/ou dependencia; esse codigo nao e apresentado como autoria original deste projeto.

Arquitetura

O fluxo principal e:

1. main_v35.c inicia o processo, carrega o jogo e conecta os subsistemas.
2. O estado MIPS_CPU representa registradores e memoria do PSP.
3. A execucao de codigo Allegrex e encaminhada ao dispatcher AOT quando ha um bloco traduzido registrado; caso contrario, pode seguir pelo interpretador.
4. Syscalls e modulos importados sao atendidos por implementacoes HLE.
5. As chamadas GE alimentam uma maquina de estado de display lists.
6. O renderer decodifica vertices, texturas e estado de framebuffer e desenha por SDL2/OpenGL ES.
7. A camada de audio recebe/mistura buffers PCM atraves de SDL2.

Area	Arquivos principais	Responsabilidade
Inicializacao e carregamento	main_v35.c, mips_reloc.c, mips_prx.c, mips_prx_runtime.cpp	Inicializacao, leitura do jogo, relocacoes de modulos e suporte a PRX.
Estado e memoria da CPU	mips_cpu.h, mips_cpu.c	Registradores Allegrex, RAM/VRAM/scratchpad, traducao de enderecos e instrumentacao de memoria.
Interpretador	mips_interpreter.c, mips_interpreter.h	Execucao de uma instrucao Allegrex por passo; inclui GPR, COP1 e VFPU em diferentes niveis de cobertura.
Recompilacao estatica/AOT	aot_recompiler_v5.py, gow_core_aot.c, mips_dispatcher.c, mips_dispatcher.h	Geracao/registro de blocos traduzidos e despacho para AOT ou fallback interpretado. O AOT atual e especifico ao executavel de GOW.
HLE e sistema PSP	mips_hle.c, mips_hle.h, sceKernelThread.c, sceKernelThread.h, sceSysMem.c, sceSysMem.h	Syscalls, I/O, threads, sincronizacao, memoria e servicos PSP implementados em software.
Graphics Engine	mips_ge.c, mips_ge.h	Registradores GE, comandos e fluxo de display lists, vertices, matrizes, framebuffer, texturas e estado CLUT.
Renderizacao	mips_video.c, mips_video.h, mips_video_pixel.h, mips_video_texture.h	SDL2/OpenGL ES 3.2, conversao de pixels, leitura/decodificacao de texturas e rasterizacao de primitivas.
Audio e SAS	mips_audio.c, mips_audio.h, mips_sas.c, mips_atrac_decoder.cpp	Mixer SDL2 PCM com canais PSP e SRC Output2; decoder ATRAC3/ATRAC3+ ligado ao sceAudiocodec e HLE ATRAC para decode, loop e refill circular. A reprodução não-zero do GOW e a saída audível ainda aguardam validação em runtime.
Testes	tests/python/	Testes de regressao de CPU, memoria, VFPU, GE/video e mixer/SAS de audio.
Artefatos	artifacts/runs/, artifacts/reports/	Logs, traces e relatorios usados nas investigacoes.
Referencia externa	PPSSPP/	Codigo upstream PPSSPP consultado para comparar formatos e semantica; nao confundir com o core proprio do projeto.

Estado tecnico consolidado

O core ja possui interpretador Allegrex parcial, blocos AOT especificos ao GOW com fallback interpretado, HLE de I/O/threads/memoria e um caminho GE que desenha primitivas e texturas via OpenGL ES. Isso ainda nao e compatibilidade completa: ha imports em fallback, cobertura parcial de COP1/VFPU, SAS sem sintese PSP completa, estados GE incompletos e divergencia entre draws GLES e framebuffer guest. O GOW ainda nao foi confirmado como visualmente jogavel, e os runs de Ozone/2048/Cave History devem ser lidos conforme suas limitacoes documentadas.

No decoder GE, posicoes nao-through S8 e S16 agora sao interpretadas como valores signed normalizados por 1/128 e 1/32768; S8 em through mode produz posicao zero. A regressao tests/python/test_video_3d_basic.py valida essa decodificacao por pixels GLES. Essa correcao de formato nao confirma mudanca na abertura do GOW, cujos draws iniciais capturados usavam float/through. O mesmo harness agora valida perspectiva com divisao homogenea por W e clipping de um triangulo que cruza o limite lateral; isso e uma base sintetica, nao evidencia de paridade 3D em uma cena real.

O inventario detalhado de syscalls implementadas versus simplificadas/stub, comandos GE, cobertura da CPU, ponte AOT e evidencias dos runs esta em General progress.md. Para separar fatos medidos de hipoteses, consulte tambem tools/STATUS.md.

Estado da CPU e memoria

MIPS_CPU guarda os 32 registradores GPR, PC, HI/LO, FPR, FCR31, os 128 registradores VFPU, controles COP0, estado de excecao/trace e ponteiros para RAM, VRAM e scratchpad. A memoria PSP e mapeada em buffers contiguos no host, com helpers para traduzir enderecos virtuais PSP e registrar acessos relevantes. O estado VFPU inclui os 16 controles PSP e reset de prefixes/CC/RNG alinhado ao PPSSPP; o interpretador cobre um subconjunto crescente de operacoes, conversoes, branches e acessos de memoria VFPU, com regressao para os casos recentemente fechados. Isso ainda nao prova paridade completa nem melhora visual no GOW.

O interpretador e importante tanto como fallback para blocos que ainda nao foram traduzidos quanto como caminho de diagnostico: instrumentacoes locais colocadas em mips_interpreter_step nao necessariamente executam quando o despacho vai diretamente para um bloco AOT.

Build

O script principal e build_fixed_v38.sh. O modo padrao tenta construir o emulador hibrido; --interpreter forca o modo interpretador puro para diagnostico:

./build_fixed_v38.sh --interpreter

O script espera GCC/G++, SDL2, OpenGL ES e as dependencias de sistema usadas pela compilacao. Ele grava o executavel em output/main. Um build feito em WSL/x86-64 e um executavel para o host WSL; nao e automaticamente o binario ARM64 que deve ser copiado para o R36S. Para executar no aparelho e necessario compilar no proprio aparelho ou usar um cross-toolchain ARM64 apropriado e validar as bibliotecas/ABI do destino.

Controles de teclado

O renderer atual traduz teclado para sceCtrlReadBufferPositive e sceCtrlPeekBufferPositive: setas controlam o direcional, Z/X/A/S mapeiam Cross/Circle/Square/Triangle, Enter e Shift direito mapeiam Start/Select, Q/E mapeiam L/R e o teclado numerico 4/6/8/2 controla o analogico. Ao perder o foco da janela, as teclas pressionadas sao limpas. Para receber um aviso imediato quando Z for pressionado/solto na janela, use MIPS_INPUT_TRACE=1; o log mostra Z pressed -> PSP Cross e o valor 0x00004000, sem depender de o jogo consultar o controle naquele instante. MIPS_CTRL_TRACE=1 e diferente: registra mudancas de botoes/analogicos observadas quando o jogo chama os imports de controle, o que ajuda a verificar se a entrada chegou ao polling HLE.

Exemplo no WSL (crie a pasta antes do redirecionamento; Bash abre o arquivo de log antes de iniciar o emulador):

mkdir -p artifacts/runs/Run271-GOW-input
MIPS_INPUT_TRACE=1 ./output/main umd0/PSP_GAME/SYSDIR/EBOOT.BIN \
  > artifacts/runs/Run271-GOW-input/console.log 2>&1

O modo interpretador e recomendado para os traces que instrumentam mips_interpreter_step; traces colocados somente ali nao demonstram que um bloco executado via AOT tomou o mesmo caminho.

No build hibrido, os shards de codigo AOT sao compilados com -O2. A configuracao de otimizacao e armazenada em output/gow_core_aot_optimization.txt para invalidar os objetos em cache quando o nivel mudar. Para medir o ritmo real de apresentacao sem o custo de captura de frames, use MIPS_PERF_TRACE=1; o log imprime a cada cinco segundos FPS apresentados/draws GE por segundo, contadores de dispatch AOT versus interpretador, e tempo de CPU gasto na submissao de draws do renderer (nao espera o termino da GPU). As mensagens frequentes de troca de contexto e timeout do scheduler ficam desativadas por padrao e podem ser reativadas com MIPS_THREAD_TRACE=1. O trace de vertices das primitivas GE tambem fica desativado por padrao, pois imprimir coordenadas de cada draw dominava o log; use MIPS_GE_TRACE_VERTICES=1 quando precisar dessa auditoria.

Exemplo de medicao sem capturas:

mkdir -p artifacts/runs/Run288-GOW-performance
MIPS_PERF_TRACE=1 timeout --kill-after=2s 120s \
  ./output/main umd0/PSP_GAME/SYSDIR/EBOOT.BIN \
  > artifacts/runs/Run288-GOW-performance/console.log 2>&1

Investigacao atual: logos de abertura do GOW

Sintoma observado

O Run252 (interpretador puro, com a nova entrada de teclado) foi executado por ate quatro minutos. A janela e as capturas mostram preto/cinza, sem as logos da Sony ou da Ready at Dawn. O run nao prova que o jogo aceitou a tecla Z. O log confirma que frontend_assets.bin foi aberto e que splash_screens.bin (72.012 bytes) foi lido integralmente; isso nao prova que os dados tenham sido decodificados nem que tenham chegado a um draw visivel.

As primeiras nove primitivas GE sao faixas through que cobrem a tela. O draw #10 e um quad preto sem textura: embora seus NDCs variem de -480 a 480 e de -272 a 272, isso significa que o quad abrange o clip volume visivel, nao que esteja totalmente fora da tela. O draw #11 usa uma fonte CLUT8 e fica fora do clip volume. sceMpegInit retorna sucesso, mas os imports de sceVideocodec nao registram chamadas no resumo do run. O scanner do asset nao encontra assinaturas PSMF/MPEG comuns; isso nao prova qual e o formato proprietario dos dados.

Run253–255 confirmaram que os arquivos chegam a memoria guest, mas o primeiro draw texturizado (#11) usa um atlas de fonte, nao uma logo. A inspecao do Pack de splash encontrou dois recursos RADI v5 de 512x64 com dados compatíveis com textura CLUT8 swizzled; os previews estao em artifacts/runs/Run256-GOW-pack-images/decoded/. Isso identifica imagens no pacote, mas ainda nao associa esses recursos a um draw visivel. O draw #1 do Run254 tambem nao traz cor por vertice: o renderer usava branco fixo, enquanto o GE usa a cor ambiente (MATERIALAMBIENT/MATERIALALPHA) nesses casos. Essa divergencia foi corrigida e ganhou regressao de pixels, mas nao prova que ela seja a causa das logos ausentes. O EBOOT.PBP nao esta no workspace; o executavel extraido umd0/PSP_GAME/SYSDIR/EBOOT.BIN esta disponivel e foi usado nos runs posteriores.

O proximo passo continua sendo ligar os recursos de splash a um draw e validar o resultado visual no GOW. Nao ajustar gameplay 3D sem um frame comparavel.

Resultados dos Runs258-260

Run258 usou o EBOOT.BIN extraido, build puro de interpretador, e salvou 20 capturas de apresentacao e dumps de framebuffer guest em artifacts/runs/Run258-GOW-opening/. As capturas continuam sem logos: mostram preto e uma regiao cinza que clareia durante as primeiras apresentacoes. Os dumps de framebuffer guest permanecem inteiramente zerados. O log registra 26.867.711 instrucoes e encerra com faults=0; sceMpegInit e as consultas de memoria/ringbuffer retornam, mas todos os imports sceVideocodec terminam com zero chamadas.

O GE submete as nove primeiras faixas em through mode. O dump do draw #1 no Run260 mostra posicoes de tela de (0,0) a (480,32), coerentes com a faixa. O draw #10 do Run259 e um quad nao-through cujos NDCs variam de -480 a 480 e de -272 a 272: a geometria engloba o clip volume, portanto nao deve ser descrita como simplesmente fora da tela. O draw #11 usa um atlas CLUT8 de fonte 128x256, mas fica em X≈374..396, Y≈-23..3, fora do volume visivel. Para os vertices capturados, um calculo independente da conversao de viewport (escala/centro/offset) produz os mesmos NDC que o renderer local; nao ha evidencia para alterar essa transformacao.

Resultado do Run263: textura do splash associada a draw GE

O Run263 registra o draw #21666 (PC 0x08480628) consumindo uma textura CLUT8 swizzled de 512x64 em 0x09117600 e CLUT em 0x09117200. Ambas as faixas sobrepoem diretamente a leitura de splash_screens.bin em 0x09116980, respectivamente nos offsets 0xC80 e 0x880; a CLUT comeca 0x20 bytes depois do marcador RADI conhecido em 0x860. Portanto, o pacote RADI chega ao GE como fonte de textura, superando a correlacao indireta/inconclusiva do Run262.

Isso ainda nao prova que o draw apresenta uma logo visivel nem que o jogo aceitou Z. As 20 capturas deste run sao apenas as apresentacoes 21–40 e todas mostram a mesma imagem preta/branca; elas nao incluem o draw #21666, que ocorre mais tarde no log. O proximo passo e capturar apresentacoes posteriores e estado/vertices do draw #21666, confirmando ao mesmo tempo a transicao de input. Sem chamadas de decode observadas, nao priorizar MPEG; sem divergencia matematica com PPSSPP, nao alterar a transformacao.

No Run264, o dump do draw #21666 confirmou que a textura resolvida contem um grafico vermelho/laranja. Seus vertices transformados chegam a NDC X ±512 e Y 28/−100, mas isso nao significa que a primitiva inteira esteja fora da tela: o quad enorme atravessa o viewport e e recortado. A analise posterior do Run267 mostrou que a regiao visivel desse recorte amostra apenas texels transparentes.

O Run265 capturou as apresentacoes 121–140. O draw #21666 ocorre entre as apresentacoes 126 e 127; as imagens posteriores (#127–140) continuam pretas, sem a logo, apesar da textura e do draw ativos. O trace de input confirma tres leituras de Cross (buttons=0x00004000) nos samples 376, 389 e 401, cada uma seguida de soltura; a primeira ocorre apos 376 chamadas de sceDisplaySetFrameBuf. Isso confirma que Z chega ao caminho de polling do jogo, mas nao que o jogo aceitou a transicao.

O Run266 registrou Cross nos samples 176, 221, 251, 284, 307, 332, 369 e 384, com solturas. As capturas, porem, foram das apresentacoes 361–380 e todas ficaram pretas; a amostra 369 aparece antes da apresentacao 375, e a 384 depois da ultima captura. O trace de comandos GE atingiu o limite de 256 linhas, terminando em 0x084805D0. Ele registrou uma ocorrencia anterior de 0x08480628 como END, mas nao a execucao tardia que corresponde ao dump do draw #21666, que tambem indica esse PC. Portanto, a captura nao prova ainda que as transforms estao erradas: falta correlacionar o comando GE realmente executado no draw com seu estado. O run terminou com exit_requested=true, faults=0.

O Run267 com faixa de comando estreita registrou no mesmo PC 0x08480628 o comando efetivo 0x04050004: triangle fan com quatro vertices. O 0x9C000000 observado anteriormente era outra ocorrencia desse endereco, em outro contexto de display list. A verificacao independente do dump confirmou a transformacao registrada. Embora os vertices extremos cheguem a NDC X ±512 e Y 28/−100, o quad cruza o viewport; a pequena regiao visivel mapeia para U≈0,499–0,501 e V≈0,211–0,227. Os texels RGBA (x=255–256, y=13–14) tem alpha zero, o que explica a invisibilidade desse draw no estado capturado; a alpha dos vertices tambem e baixa (15/255) e blending esta ligado. Isso ainda nao prova se esse estado transitorio e esperado pelo jogo ou diverge do PPSSPP. As apresentacoes 171–190 ficaram todas pretas e pixel-identicas. O unico Cross do run ocorreu nos samples 274–276, depois da janela capturada; portanto nao ha correlacao entre a tecla e essas imagens. O trace de matrizes atingiu 512 registros antes do draw tardio. O processo encerrou com exit_requested=true, faults=0.

Resultado do Run268: capturas ampliadas e Cross

O Run268 salvou as apresentacoes 101–160. A imagem em dois tons clareia de branco para cinza e fica totalmente preta na apresentacao 122, permanecendo preta ate a 160. O dump do draw #21666 foi produzido entre as capturas 122 e 123; textura, CLUT e estado coincidem com o Run267. Isso confirma que o draw com a amostragem transparente ocorre na transicao para preto, mas nao revela os draws/estados posteriores que possam apresentar as logos.

O trace de controle registrou Cross (buttons=0x00004000) em sceCtrlPeekBufferPositive no sample 943 e soltura no sample 946. Ambos vieram depois da ultima captura salva (apresentacao 160). Portanto Z chegou ao polling do jogo, mas este run nao mostra o que ocorreu visualmente apos a tecla nem permite concluir que o jogo ignorou o input. O trace GE limitado tambem atingiu seu limite de 256 eventos. O processo encerrou com exit_requested=true, faults=0.

Resultado do Run269: Cross foi lido, mas nao houve captura

O console do Run269 registra Cross (0x00004000) em sceCtrlPeekBufferPositive no sample t=170, com soltura em t=172. Esse t conta chamadas de polling HLE, nao apresentacoes. A pasta do run contem somente console.log: nao ha registros [Video Capture] nem imagens. A recomendacao anterior de MIPS_VIDEO_CAPTURE_SKIP=500 confundiu o contador de polling com o de apresentacoes e foi inadequada; o log nao permite ver a tela depois da tecla. A fonte CLUT8 do draw #21666 continua com os mesmos enderecos e hashes; os fallbacks de sceVideocodec e sceMpegbase tiveram zero chamadas. O dispatcher encerrou normalmente, sem faults.

Comparacao de implementacao: o PPSSPP tambem mapeia Z para CTRL_CROSS (0x4000), entao a traducao do botao no emulador esta confirmada. O PPSSPP amostra controles em VBlank e mantem buffers circulares, enquanto o HLE local devolve um snapshot atual em cada chamada e retorna uma amostra para Read e Peek. Essa diferenca e uma possivel lacuna de fidelidade, mas nao explica por si so a ausencia de mudanca visual e nao deve ser alterada sem uma captura que confirme o comportamento do jogo.

Resultado do Run270: Cross capturado no trace, fora da janela de imagens

O Run270 salvou as 120 capturas solicitadas (apresentacoes 1–120). Sao quadros pretos com uma faixa uniforme cinza/branca que entra e sai; nenhuma das tres logos de referencia aparece. Cross (0x00004000) foi lido por sceCtrlPeekBufferPositive em t=189 e solto em t=194. Esse contador mede chamadas de polling, nao apresentacoes: ambas as amostras foram registradas depois da apresentacao 120, quando o limite de captura ja tinha sido atingido. O dump/fonte de textura do draw #21666 tambem aparece depois da ultima captura. Assim, as imagens confirmam a ausencia das logos antes do Cross, mas nao registram a tela depois dele.

Depois do Cross, o trace GE registra novos recursos de textura nos draws 29771–30145, incluindo texturas RGB apoiadas em VRAM. Isso demonstra atividade de renderizacao posterior, mas nao prova que Cross causou uma mudanca de cena nem que essa atividade produziu uma imagem visivel. O mapeamento local Z → Cross (0x4000) coincide com o PPSSPP. O PPSSPP usa amostras em ring buffer atualizadas por VBlank e respeita nBufs; o HLE local fornece um snapshot atual por chamada. Essa diferenca merece revisao se a proxima captura mostrar que o jogo nao reage, mas ainda nao prova a causa da tela preta. O run encerrou sem faults.

Os prints de referencia PPSSPP fornecidos pelo usuario (1, 2, 3) mostram, em ordem: aviso legal da Sony, logo Ready at Dawn Studios e menu de God of War com Kratos. O emblema laranja presente na textura resolvida do draw #21666 coincide visualmente com o simbolo da tela 2.

Resultado da captura PPSSPP Run003

A captura foi feita em PPSSPP v1.20.3, sem injetar Cross. A primeira tela preta da tentativa anterior era causada pelo debugger: cpu.status mostrou a CPU em stepping, com zero ticks, na entrada do jogo. Depois de cpu.resume, o boot seguiu normalmente: frames 001-007 mostram o aviso Sony, 008-014 a logo Ready at Dawn e 015-024 o menu/titulo de GOW.

O dump GE dessa sessao contem 95 draws; o draw 11 corresponde ao quad local #21666 pela primitiva, VTYPE, vertices, UVs, textura CLUT8 512x64 e CLUT. A comparacao das matrizes revelou o bloqueio concreto deste quad: world/view coincidem, mas a projection PPSSPP usa aproximadamente [1/240, 1/136, -1, -1], enquanto Run267 local usa [-2, -2, 0.0577345, 2, 480, 272, ...]. Aplicando o estado gravado, PPSSPP coloca o quad em x=-15.94..496, y=86..150; o estado local o projeta em x=-122640..123120, y=-3672..13736, totalmente fora do target. A comparacao completa esta em artifacts/runs/PPSSPP-Run003-GOW-boot-capture/draw11-matrix-comparison.txt.

O Run271 tambem rastreou 195 stores no alpha do vertice: a rotina guest em 0x089A4CCC escreve valores que sobem ate 0xFF, fazem fade e passam por 0x0F. Portanto o alpha baixo observado em Run267 era uma fase do fade, nao evidencia de decoder de cor ou interpreter quebrado. O draw PPSSPP usa blend mode 0x32 (SRC_ALPHA/ONE_MINUS_SRC_ALPHA); os avisos 10/10 do renderer local nao estao ligados a esse quad.

O Run272 confirmou que, no draw local, o GE le da lista guest em 0x08480354 os comandos da projection divergente (-2 nos indices 0/5, 480/272 nos indices 12/13). O handler local consome os words existentes na lista; o watch teve 5.644 leituras e nenhum store. O PC 0x08B05BBC do registro e o PC CPU remanescente durante a leitura GE, nao identifica quem montou a lista. Portanto, nao ha evidencia de perda/reordenacao no handler GE para esse draw, mas a origem guest/HLE da lista e a comparabilidade temporal com PPSSPP continuam abertas. Ver artifacts/runs/Run272-GOW-projection-source/analysis-summary.txt. Nao hardcode a matriz PPSSPP nem alterar UV/CLUT. O jogo PPSSPP alcancou o menu sem Cross; input nao e pre-condicao para fazer as logos aparecerem.

Runs280/282 rastrearam os loads: frontend_assets.bin vai para 0x09092740 e splash_screens.bin para 0x09116980 (72.012 bytes; hash da origem igual ao destino). Isso nao e um load direto na lista GE. O draw #21666 segue na lista iniciada em 0x084801F0, e o Run282 confirmou projection divergente no draw. O watch anterior do Run279 estava em 0x084A0348, ou seja, na lista alternada, nao na lista do draw; seus zero stores nao valem como evidencia sobre a projection. O Run282 corrigiu o alvo para 0x08480348..0x08480394: uma leitura encontrou comandos 0x2B000000 e outra encontrou words da projection, mas nenhum store MIPS foi capturado. Isso ainda deixa aberta uma escrita/copia por caminho C/HLE que nao passa por mips_write*. Relatorio: artifacts/runs/Run282-GOW-list-writer-corrected/analysis-summary.txt.

Prioridade imediata: localizar quem constroi/atualiza a lista GE da Ready at Dawn e comparar o mesmo estagio com PPSSPP. Depois, se a logo Sony continuar ausente localmente, investigar seus draws separadamente.

O Run273 do 2048 mostrou 14 aparicoes do fundo vermelho do tile novo no PPSSPP; cada uma dura 5–6 frames a 30 fps. Os 120 frames locais nao contem pixels vermelhos. A mesma execucao chamou sceRtcGetCurrentTick 402 vezes e o handler local devolvia o valor em v0/v1, embora a API escreva o tick de 64 bits no ponteiro a0; corrigi esse ABI em main_v35.c. Run274 foi um smoke test sem moves. A captura seguinte com jogadas, Run275, mostra o tabuleiro avancando ate score 12, mas segue sem pixels vermelhos, e o timer continua 0:0. A comparacao PPSSPP tambem revelou uma divergencia GE 2D real: no primitivo sprite, PPSSPP usa a cor e profundidade do segundo vertice para todo o retangulo; nosso renderer interpolava esses atributos. Corrigi a expansao e adicionei teste de pixels. Ainda falta novo run para saber se isso afeta o spawn vermelho; comparar o draw/atlas do tile novo antes de alterar blend. Relatorios: artifacts/runs/Run273-2048-spawn/analysis-summary.txt e artifacts/runs/Run275-2048-tick-fix-moves/analysis-summary.txt. Audio nao e bloqueio evidenciado para a abertura.

O que foi corrigido e medido

1. Opcode VFPU3 0x1B. A tabela local do PPSSPP confirma que o opcode primario 0x1B seleciona o grupo VFPU3; os sub-opcodes validos da tabela sao vcmp, vmin, vmax, vscmp, vsge e vslt. O interpretador agora executa essas seis operacoes, incluindo prefixos VFPU e condition codes de vcmp. tests/python/test_vfpu3.py cobre as seis operacoes. O Run192 e anterior a essa correcao; um novo run e necessario para verificar o efeito no jogo.
2. Tabela Allegrex SPECIAL. Comparando com as tabelas e semantica do PPSSPP presente em PPSSPP/, foram corrigidos no interpretador: CLZ/CLO, MADD/MADDU, MAX/MIN, MSUB/MSUBU e as formas codificadas de ROTR/ROTRV. Antes, alguns functs eram interpretados como operacoes diferentes ou nao eram tratados.
3. Cor ambiente GE sem atributo de cor. Vertices que nao carregam cor agora usam os registradores GE MATERIALAMBIENT e MATERIALALPHA, como no caminho through-mode do PPSSPP. A regressao GLES verifica os bytes RGBA lidos de volta; os testes de framebuffer/2D, textura e transformacao 3D tambem passam. Isso corrige o estado de cor dos draws sem atributo, mas nao confirma que o pipeline de abertura do GOW esteja completo.
4. Trace de instrucoes candidatas. A variavel MIPS_TRACE_ALLEGREX_SPECIAL=1 ativa linhas [ALLEGREX SPECIAL] deduplicadas por PC, com instrucao e operandos. Esse trace so cobre o caminho pelo interpretador.
5. Regressao de CPU. tests/python/test_allegrex_special.py verifica os resultados dos encodings afetados; o teste e compilado e executado por Python usando GCC.
6. Run191 contra Run190. O Run191 observou quatro PCs executando CLZ, e nao mostrou os outros functs candidatos no trecho. Nos mesmos primeiros draws texturizados, o renderer registrou CLUT8 swizzled como 128x256 no Run191; no Run190, o estado GE cru TSIZE0=0x002020 era decodificado e registrado como 1x1. A coincidencia temporal indica uma mudanca efetiva no estado da textura, mas a cadeia exata entre a instrucao corrigida e o comando GE ainda nao foi demonstrada.
7. Coordenadas dos draws. Os primeiros quads texturizados reportam aproximadamente x=373..396, y=-23..3 em NDC e estao fora da area visivel. Isso descreve o resultado do estado GE capturado, nao prova um erro do renderer. No Run259, os vertices, escala/centro/offset de viewport e NDC recalculados pela formula PPSSPP coincidem numericamente com os do renderer local. O quad do draw #10, com NDC de ate ±480/±272, engloba a area visivel. A captura JSON registra VTYPE, vertices, matrizes float24, viewport, offsets e estagios clip/NDC/pixel; tools/check_ge_coordinates.py valida a conta local. O proximo alvo e rastrear o consumidor dos recursos RADI ate o upload e o draw, nao ajustar a transformacao sem discrepancia demonstrada.
8. Video/MPEG. O Run191 registra sceMpegInit e consultas de memoria MPEG, e abre/le o arquivo splash_screens.bin. No trecho verificado nao foi encontrada uma chamada de decode MPEG/AVC. Isso nao prova que o splash nao seja video, nem que nenhuma chamada ocorreu fora do trecho analisado.
9. Display lists e texturas. Runs anteriores registraram uma display list com B8002020, formato CLUT8, modo swizzled, CLUT de 1024 bytes e UVs variados. O watch de memoria existente encontrou leituras no endereco observado, mas nao exclui escritores que contornem mips_write*, como copias diretas do HLE/carregamento.
10. VFPU VSCL e cobertura do interpretador. A comparacao do dispatcher PPSSPP identificou que 0x19/format=2 (VSCL) nao tinha handler local, embora o GOW o execute durante calculos vetoriais. O handler foi implementado com broadcast escalar, mapas fisicos e prefixos; o teste tests/python/test_vfpu_vscl.py, a bateria VFPU e o build puro passaram. O Run285 alcancou essa rotina, mas encerrou por timeout na apresentacao 20 antes do draw da logo. Permanecem lacunas relevantes em VSBN, VCRS, VDET, operacoes monadicas e de matriz como VMSCL/VROT; veja a tabela de cobertura na secao de CPU em General progress.md.

Resultados dos runs 193–196

1. Run193 GOW foi hibrido/AOT, nao Interpreter puro. O log confirma [BUILD MODE] HYBRID_AOT_INTERPRETER e correspondencia da assinatura AOT do GOW. Portanto, zero avisos Unsupported opcode nesse run nao validam diretamente os handlers novos do mips_interpreter.c. O jogo executou 318 enqueues de display list, registrou 11 fallbacks de blend 10/10 e encerrou com faults=0. O visual gravado permaneceu preto.
2. Os dumps guest do GOW estao vazios. Os 20 buffers de display do Run193, cada um com 480x272 RGBA e stride 512, contem somente bytes zero. O dump do draw #11 registra vertices com X em clip/NDC aproximadamente 374–396, fora do intervalo GLES visivel. Isso e uma divergencia concreta a comparar com o PPSSPP, nao prova isoladamente qual etapa tem o erro.
3. Ozone demonstra geometria visivel, mas nao framebuffer guest. O Run195 foi Interpreter puro, produziu milhares de vertices em primitivas GE e o video mostra, por volta de 225–240 s, uma cena tridimensional em tons de cinza, visivel mas distorcida/recortada. Os 20 dumps de framebuffer guest do mesmo run tambem contem apenas zeros. Isso confirma que o caminho que pinta a janela GLES pode produzir geometria sem escrever a imagem de volta ao framebuffer PSP; nao e uma comparacao pixel-a-pixel sincronizada. Run349, no renderer atual, apresenta uma tela branca de loading com barra verde; os frames apresentados #18/#20 coincidem em RGB com os dumps guest dos FBPs correspondentes. Quatro vertices amostrados em cada um de quatro draws 3D coincidem com as equacoes de viewport do PPSSPP. Isso afasta um erro de scanout nesses frames, mas nao valida todos os vertices nem a cena 3D: o draw #8 emite um quad branco quase opaco sobre o viewport como parte do loading. Run350 capturou as presentations 2801–2860; o loading avancou para "PRESS ANY KEY TO CONTINUE". Run355 enviou Cross depois do loading; o trace HLE confirma buttons=0x00004000, mas o texto some e a saida fica totalmente branca nas 120 capturas seguintes. O trace de 32 draws 3D ainda coincide com as equacoes de viewport do PPSSPP. Isso nao distingue uma transicao intencional de um defeito de composicao; falta uma imagem PPSSPP do mesmo ponto. Nao alterar matrizes sem essa comparacao.
4. Cave History e 2048 nao chegaram a uma prova visual do renderer. O Run194 tem tres capturas de display, e o Run196 tem duas; todas sao zero. Nenhum desses logs contem registro [GE Renderer] GE draw ou encerramento limpo. O Run196 fica em loop no PC 0x08990C24, depois de enfileirar duas listas GE. A causa do loop ainda nao foi isolada.
5. Chamadas fallback com maior contagem. Run193 conta 638 chamadas ao NID 0x79D1C3FA (sceKernelDcacheWritebackAll na tabela local do PPSSPP). Run195 historicamente contou 906 chamadas a sceRtcGetCurrentTick; Run273 contou 402 chamadas durante 2048 e revelou um ABI local incorreto. O handler foi corrigido para escrever o tick u64 no ponteiro guest e retornar PSP_OK, conforme PPSSPP. Ainda falta validar tempo/animação em gameplay pós-fix. Esses imports devem ser avaliados por efeitos esperados antes de atribuir causalidade visual.
6. Próxima comparação: executar o GOW em --interpreter para uma linha de base com as correções recentes e, em seguida, executar o mesmo GOW em AOT. Fazer 2048 primeiro na próxima rodada, mas só considerar esse jogo um teste do renderer se o log registrar draws GE. Encerrar cada processo pela janela para obter o resumo de fallback; Ctrl+Z suspende e não conclui o processo.

Validacao mais recente

Os testes direcionados de diagnosticos, VFPU3, Allegrex, COP1, framebuffer e GLES passaram:

python -m unittest tests.python.test_diagnostic_tools tests.python.test_vfpu3 tests.python.test_vfpu_vsub tests.python.test_allegrex_special tests.python.test_cop1_differential tests.python.test_video_framebuffer tests.python.test_video_texture_pipeline
python -m unittest tests.python.test_vram_to_png

O build local do modo interpretador tambem terminou com sucesso:

wsl bash -lc 'cd /mnt/c/Users/onysi/Downloads/GOW && ./build_fixed_v38.sh --interpreter'

O build mostrou warnings preexistentes/fora do escopo (incluindo avisos de tipos e VFPU) mas nao terminou com erro. O sucesso de compilacao e dos testes nao significa que o GOW ja renderiza corretamente nem que a build WSL seja a build ARM64 do R36S.

Para gerar um resumo repetivel de um log e verificar a tabela VFPU3 contra a referencia local:

python tools/summarize_log.py artifacts/runs/RunNNN.console.log
python tools/analyze_png_abort.py artifacts/runs/RunNNN-2048-Interpreter.console.log
python tools/audit_vfpu3.py
python tools/blend_factor_table.py
python tools/check_ge_coordinates.py artifacts/runs/RunNNN-draw11_draw11_state.json
python tools/imports_report.py artifacts/runs/RunNNN.console.log artifacts/runs/RunNNN-imports.csv
python tools/scan_splash.py umd0/PSP_GAME/USRDIR/data/splash_screens.bin
python tools/decode_ge_list.py artifacts/runs/RunNNN-ge-list.bin --base 0x084A0000

The script blend_factor_table.py outputs all 121 source/destination factor pairs and marks PSP doubled-alpha factors and separate FIXA/FIXB constants that cannot be represented exactly by one GLES glBlendFunc call. analyze_png_abort.py validates data/take.png (PNG CRCs and decompression), compares each logged take.png read against the matching source bytes using the guest FNV-1a hash, and reports whether the run reached any GE draw.

Runs201–204 traced the abort through png_create_read_struct_2 and longjmp to zlib's incorrect data check error in png_read_row. Run204 is a pure interpreter run: all 50 logged take.png reads match the local asset, and no unsupported opcodes were reported. The expected IDAT Adler-32 is 0xE5673AB0, while the guest's calculated checksum at the failure is 0x51B242D9.

Runs206–208 narrowed the cause further. The first two 577-byte scanlines passed byte-for-byte; scanline 3 first differs at byte 6 (guest=0x01, expected 0x00). The output byte is written by guest inflate_fast at 0x08936C90. The follow-up trace and comparison with PPSSPP identified incorrect little-endian merge semantics in the interpreter's LWL/LWR/SWL/SWR operations. These were corrected and covered at every byte alignment. Run212 reports all three captured scanlines matching the host output, and Run214 reaches at least 24,576 GE draws before exiting with status zero. The 2048 PNG issue is resolved for this test; it was an interpreter/memory issue, not GE, 3D, or audio.

compare_inflate_output.py compares the bytes read by the guest Adler-32 routine with the host's decoded PNG scanlines. A trace for this tool should use the exact guest addresses for the zlib Adler function and output buffer:

mkdir -p artifacts/runs
MIPS_TRACE_FILE=artifacts/runs/RunNNN-adler.trace \
MIPS_TRACE_WATCH_PC=0x0893AAE0 \
MIPS_TRACE_WATCH_EVERY=1 \
MIPS_TRACE_WATCH_SAMPLES=5 \
MIPS_TRACE_WATCH_TRACE_AFTER=4 \
MIPS_TRACE_WATCH_TRACE_STEPS=10000 \
MIPS_TRACE_WATCH_ONLY=1 \
MIPS_TRACE_WATCH_ADDR=0x09496220 \
MIPS_TRACE_WATCH_SIZE=0x241 \
timeout --kill-after=2s 240s ./output/main TesterGames/2048PSP/EBOOT.PBP \
  > artifacts/runs/RunNNN-adler.console.log 2>&1
python tools/compare_inflate_output.py \
  TesterGames/2048PSP/data/take.png artifacts/runs/RunNNN-adler.trace

This capture is intentionally bounded to the first scanlines reaching adler32. It remains useful for regressions; the known mismatch in Runs206–208 was caused by the interpreter's unaligned word merge operations and was fixed before Run212. A mismatch on a future run should be investigated as a new regression rather than treated as an unresolved 2048 failure.

Set MIPS_DISPLAY_DUMP_PREFIX to capture the first 20 raw guest display buffers submitted through mips_video_set_framebuffer. The .bin files include complete rows with stride. Convert a dump to PNG with:

For captures after the game's confirmation input, also set MIPS_VIDEO_CAPTURE_AFTER_CONFIRM=1 and MIPS_DISPLAY_DUMP_AFTER_CONFIRM=1; raw display dumps then start after the same Z/X keypress instead of including boot screens.

python tools/vram_to_png.py artifacts/runs/RunNNN_display01_0408C000_f3.bin \
  artifacts/runs/RunNNN-display01.png --width 480 --height 272 \
  --stride 512 --format 3

The output directory must already exist, and PNG conversion requires Pillow. New runs also print a [HLE Fallback Summary] for each registered fallback; the import report includes exact counts from these summaries. Historical logs without those lines show fallback calls as unknown.

The current renderer presents the guest buffer through mips_video_begin_frame, but GE primitives are drawn directly to GLES rather than rasterized back into guest VRAM at FBP/FBW. The synthetic framebuffer test verifies buffer upload/scanout only; it is not an end-to-end PSP GE framebuffer write test.

GE display lists are now accumulated into one GLES frame and presented at sceDisplayWaitVblankStart() / sceDisplayWaitVblankStartCB(), instead of presenting every sceGeListEnQueue() call as a separate frame. This fixes a confirmed frame-cadence bug and has a regression check for preserving earlier draws across successive lists. Run215's screenshot now shows a visible checkerboard region, but not a recognizable 2048 board. Run216 submitted many GOW lists/draws, while the user saw only the untouched gray window. The old logs do not count successful VBlank calls, so set MIPS_TRACE_VBLANK=1 on the next run to distinguish a missing presentation from off-screen/empty draws. The trace prints the first eight waits, then every 60th wait.

Proximos diagnosticos sugeridos

• Prioridade atual: Ozone, com foco exclusivo nos graficos, nao na gameplay. Run349 confirma que scanout/RGB reproduzem o framebuffer guest na tela de loading; Run355 confirma que o Cross chega ao jogo, mas a imagem apos o prompt fica branca. Os traces amostrados batem com as equacoes PPSSPP; obter uma referencia PPSSPP no mesmo estado e comparar a composicao antes de corrigir rasterizacao ou alterar matrizes.
• Depois de estabelecer a paridade visual do Ozone, retomar a abertura do GOW (primeiro a logo Ready at Dawn, pois ha um draw ligado ao asset RADI; investigar a logo Sony como caminho separado se continuar ausente) e avancar ate o menu. Capturas/input sao instrumentos de diagnostico, nao um objetivo.
• PSP Revolution e os outros jogos sem imagem precisam primeiro de um trace que determine se chegam a submeter draws GE utilizaveis; nao confundir falta de draw com defeito de rasterizacao.
• O 2048 esta praticamente correto na avaliacao visual do usuario: manter como regressao de GE 2D, nao como bloqueio nem como foco de prioridade.
• Run267 confirmou que 0x08480628 executa um triangle fan de quatro vertices no draw #21666. A geometria atravessa o viewport, mas a regiao recortada amostra somente texels com alpha zero (x=255–256, y=13–14) na textura resolvida. Comparar o mesmo instante/estado e os draws seguintes que usam a textura com PPSSPP antes de alterar transform, UV, alpha ou blend.
• Run268 capturou 101–160; o draw #21666 saiu entre 122 e 123 e a tela ficou preta desde 122. Cross foi amostrado em t=943, depois da ultima captura.
• O trace de entrada imediato pode ser ativado com MIPS_INPUT_TRACE=1; MIPS_CTRL_TRACE=1 registra o que o jogo consulta. Use-os apenas para correlacionar entrada quando isso ajudar a diagnosticar a tela/menu, nao como pre-condicao para investigar o splash ou a cena 3D.
• Priorizar HLE de video somente se aparecer uma chamada de decode ou evidencia equivalente.
• A comparacao de Run259 ja mostrou que a conversao de viewport dos vertices capturados coincide com a formula PPSSPP; revisitar transforms apenas se um novo draw/estado produzir uma divergencia equivalente.
• Run262 encontrou somente a fonte CLUT8 durante sua janela curta. Run263 encontrou depois a textura RADI diretamente em splash_screens.bin; nao generalizar o resultado inicial do Run262 para toda a execucao.
• Manter a correcao de dimensoes CLUT8; nao substituir TSIZE0 nem forcar a posicao dos quads para apenas fazer a imagem aparecer.

Capturas opcionais do draw e de I/O

Para capturar a imagem apresentada na janela, defina MIPS_VIDEO_CAPTURE_PREFIX; por padrao, o renderer salva as primeiras 20 apresentações como RGBA. MIPS_VIDEO_CAPTURE_SKIP=N descarta as primeiras N apresentações antes de começar a capturar, e MIPS_VIDEO_CAPTURE_COUNT=N configura quantas capturas salvar (1–120). O limite maior permite correlacionar uma janela de inicialização com uma tecla sem alterar o comportamento padrão; cada captura é um arquivo RGBA sem compressão. Para capturar a transicao de cena acionada por um botao de confirmacao, use MIPS_VIDEO_CAPTURE_AFTER_CONFIRM=1; a captura comeca apos Cross/Z ou Circle/X. MIPS_VIDEO_CAPTURE_AFTER_Z=1 continua aceito por compatibilidade. Com MIPS_VIDEO_TRACE_3D=1 MIPS_VIDEO_TRACE_3D_AFTER_CONFIRM=1, o trace de ate 32 draws 3D tambem comeca de novo apos qualquer um desses botoes. MIPS_VIDEO_TRACE_3D_AFTER_Z=1 continua aceito por compatibilidade. Para o diagnostico temporizado de audio/menu, defina MIPS_AUDIO_KILL_THREAD_AFTER_Z_RELEASE_MS=10000; apos soltar Z no teclado, o HLE limpa o PCM pendente e termina a thread guest que fizer a proxima chamada de saida de audio, usando o scheduler. O nome antigo MIPS_AUDIO_STOP_AFTER_Z_RELEASE_MS continua aceito como alias. Combine com MIPS_VIDEO_CAPTURE_AFTER_CONFIRM=1 e MIPS_VIDEO_CAPTURE_INTERVAL_MS=500 para salvar uma imagem apresentada a cada 500 ms desde o pressionamento de confirmacao, incluindo o intervalo antes e depois da terminacao. Esse encerramento e somente para diagnostico. sceAudioOutputBlocking tambem cede o scheduler enquanto aguarda o PCM ja enfileirado tocar; a thread de audio volta a executar e repete a syscall quando o prazo estimado da fila termina, sem bloquear as demais threads guest.

O renderer pode salvar os dados efetivamente usados por um draw, sem alterar o estado do jogo. MIPS_GE_DUMP_DRAW seleciona o indice da chamada mips_video_draw_prim (começando em 1); MIPS_GE_DUMP_PREFIX define o prefixo dos arquivos. Para jogos cujo indice varia entre execucoes, MIPS_GE_DUMP_PC seleciona o primeiro draw cujo PC do comando PRIM coincide com o valor informado (por exemplo, 0x09000368). Se ambos os seletores forem definidos, o primeiro que corresponder gera o dump. Para capturar o draw #11 e o caminho de leitura dos assets. O draw selecionado tambem registra um pixel e seu valor RGBA antes/depois da rasterizacao para ajudar a localizar rejeicao por testes de fragmento; os estados de depth test tambem sao registrados no dump. MIPS_GE_DUMP_DISABLE_DEPTH_TEST=1 desativa temporariamente o depth test somente durante o draw selecionado, para diagnosticar rejeicao por depth; nao e uma correcao geral de renderizacao: MIPS_GE_DUMP_DEPTH_SAMPLE=1 usa o readback de depth existente para capturar, sem escrever na memoria guest, o u16 do pixel correspondente a amostra RGBA imediatamente antes do draw selecionado. O log inclui o mapeamento GL/PSP, ZBP/ZBW, valor e estado de depth; esta leitura diagnostica nao altera o estado GPU do depth target nem buffers de cor sobrepostos. No fim de uma display list, a sincronizacao automatica exporta a cor, mas mantem no cache depth que possa aliasar framebuffers. Operacoes que precisam ler VRAM solicitam explicitamente a sincronizacao de depth.

Para acompanhar a geometria de cada ocorrencia de um draw (em vez de salvar apenas o primeiro dump), MIPS_GE_TRACE_PC aceita o PC do comando PRIM; all registra todos os draws GE. O log registra FBP/display, viewport, offset, bbox transformado e as primeiras quatro vertices brutas e transformadas:

MIPS_GE_TRACE_PC=0x09000368 ./output/main TesterGames/Ozone/EBOOT.PBP

MIPS_VIDEO_TRACE_FB_SYNC=1 registra, nas primeiras 64 exportacoes de framebuffer, os valores RGBA no FBO e na VRAM guest apos a sincronizacao, para os pontos PSP (48,131) e (48,234). Use-o para distinguir divergencia de rasterizacao, writeback e scanout sem mudar os pixels renderizados; o log tambem identifica o FBO usado.

MIPS_VIDEO_TRACE_FB_PIXELS=1 registra qual draw altera esses mesmos pontos, incluindo PC/FBP, indices/IDs de FBO, estado de clear/blend/alpha/cull/textura e valores RGBA antes/depois. Registra no maximo 256 transicoes por ponto. Sem MIPS_VIDEO_CAPTURE_AFTER_CONFIRM=1, comeca no primeiro draw; com essa opcao, comeca somente depois da confirmacao.

Os ponteiros GE FBP/ZBP sao offsets de VRAM alinhados a 16 bytes, como no PPSSPP (fbptr & 0x001FFFF0); nao se deve desloca-los novamente por quatro bits ao resolver o endereco guest.

MIPS_GE_DUMP_DRAW=11 \
MIPS_GE_DUMP_PREFIX=artifacts/runs/Run192-draw11 \
MIPS_GE_DUMP_DEPTH_SAMPLE=1 \
MIPS_GE_TRACE_IO_DATA=1 \
MIPS_GE_TRACE_TEXTURE_STATE=1 \
MIPS_DISPLAY_DUMP_PREFIX=artifacts/runs/Run192 \
./output/main > artifacts/runs/Run192.console.log 2>&1

MIPS_GE_TRACE_TEXTURE_STATE=1 registra uma linha [GE TEX SOURCE] por assinatura distinta de textura/CLUT (ate 512), com endereco PSP resolvido, bytes, dimensoes, formato e hashes FNV-1a. Correlacione o log com:

python3 tools/trace_asset_texture_links.py \
  artifacts/runs/RunNNN/console.log

Sem sobreposicao direta, o jogo ainda pode ter copiado ou convertido os dados; o relatorio nao descarta esse caminho.

Para executar no modo interpretador:

MIPS_GE_DUMP_DRAW=11 \
MIPS_GE_DUMP_PREFIX=artifacts/runs/Run192-draw11 \
MIPS_GE_TRACE_IO_DATA=1 \
MIPS_DISPLAY_DUMP_PREFIX=artifacts/runs/Run192 \
MIPS_TRACE_ALLEGREX_SPECIAL=1 \
./build_fixed_v38.sh --interpreter

O segundo exemplo compila, nao executa o jogo; depois da compilacao, inicie ./output/main com as mesmas variaveis de ambiente. O diretório indicado no prefixo precisa existir. As capturas do draw incluem bytes crus da textura, indices CLUT8 em PGM, paleta e textura RGBA em PPM/raw, estado dos registradores GE, matrizes, bytes dos quatro primeiros vertices e as etapas de coordenadas registradas pelo renderer. MIPS_GE_TRACE_IO_DATA=1 registra até 128 leituras de splash_screens.bin, frontend_assets.bin, data/take.png (usado pelo homebrew 2048), arquivos .wav e .AT3/.at3, incluindo offset, tamanho, destino PSP e hashes FNV-1a. Leituras ATRAC têm limite independente de 64 eventos para não serem ocultadas pelo limite dos outros assets. Em leituras síncronas, o hash de origem do host nao fica disponível porque o HLE lê diretamente para a memória do guest; o hash do destino ainda é registrado. Esses arquivos podem ser grandes ou conter dados do jogo; compartilhe somente os artefatos necessários para o diagnóstico.

Testes

Os testes Python em tests/python/ constroem pequenos harnesses C ou verificam comportamento de modulos. Exemplos:

python -m unittest tests.python.test_diagnostic_tools
python -m unittest tests.python.test_allegrex_special
python -m unittest tests.python.test_cop1_differential
python -m unittest tests.python.test_ge_clut_load
python -m unittest tests.python.test_video_framebuffer
python -m unittest tests.python.test_video_texture_pipeline

Alguns testes do caminho GLES dependem de bibliotecas/contexto grafico disponiveis no ambiente; um teste ignorado por dependencia ausente nao deve ser interpretado como validacao visual.

Estado do versionamento

O workspace usado na investigacao nao foi reconhecido como repositorio Git. Portanto, nao e possivel verificar commits nem aplicar um fluxo de um commit por correcao sem antes disponibilizar o historico Git correto. Nenhuma inicializacao de repositorio ou commit foi feita automaticamente.