Detectando emuladores de PS2: quando 1*X não é igual a X

• A multiplicação de ponto flutuante da VU do PS2 tem um erro operacional de 1 bit, então, para certos valores, 1 * X pode ser diferente de X
• Segundo o manual de desenvolvedor da VU, X * 1 tem precisão garantida, mas 1 * X não tem a mesma garantia; essa diferença vira um sinal de detecção de emulador
• O exemplo usa 129.5f, um dos valores problemáticos encontrados por força bruta, para verificar a diferença de comportamento entre um PS2 real e emuladores
• A implementação tem uma estrutura simples: no modo macro da VU0, multiplica 129.5f por 1 e compara apenas se o resultado difere da entrada original
• PCSX2, Play!, DobieStation e hps2x64 atualmente não emulam esse comportamento, e a dificuldade de detecção é avaliada como 1/5

---

Erro de 1 bit na multiplicação da VU do PS2

• Este método é o segundo item da série sobre detecção de emuladores de PS2 e pode ser usado na VU1, no modo micro da VU0 e no modo macro da VU0
• O exemplo usa o modo macro da VU0 para simplificar a implementação
  • Como a VU0 é usada como um coprocessador, é possível executar diretamente pela CPU EE
  • Não é necessário lidar com um programa VU separado
• Nas instruções de multiplicação como MUL e MULi do manual de desenvolvedor da VU, há uma observação de que existe um erro operacional de 1 bit
  • 1 * X pode ser diferente do valor original X
  • Ao usar VF[fs] como multiplicando, a precisão do resultado no formato X * 1 é garantida
• Não se sabe exatamente por que o bit é perdido

Valor de detecção e forma de implementação

• Para detectar esse erro, é necessário um número que provoque o problema, e o método de busca mais simples é a força bruta
• O autor criou no passado uma lista dos primeiros 250 números que causam o problema em intervalos de 0,5, e publicou essa lista em um gist
• O código de exemplo usa 129.5f como o número-alvo da detecção
  • Define 129.5f em VF1 com QMTC2
  • Cria 1 em VF2 com VADDw
  • Calcula VF1 = 1 * 129.5f com VMUL
  • Traz o resultado para o lado da EE com QMFC2 e o compara com a entrada
• O valor de retorno é in[0] != out[0]; se o valor original e o resultado da multiplicação forem diferentes, conclui-se que o erro de multiplicação da VU está presente

Impacto por emulador

• Atualmente, PCSX2, Play!, DobieStation e hps2x64 não emulam esse comportamento de multiplicação da VU do PS2
• Como basta multiplicar um único número por 1 e verificar apenas o resultado, a dificuldade desse método de detecção fica no nível 1/5

[GN⁺]

Comentários no Hacker News

• Um dos truques mais simples para detectar emulação ARM antiga, que acho que também era usado em proteção contra cópia no Game Boy Advance: armazenar uma instrução-armadilha na posição PC+4, ou seja, logo na próxima instrução
  Um ARM real, por causa do pipeline, lê PC+8 enquanto está executando no PC e decodificando PC+4, então a instrução recém-armazenada não deveria ter efeito. Um emulador que não emule o pipeline de hardware acabaria executando essa instrução
  Um texto que explica isso em mais detalhes, junto com várias técnicas antiemulação de 2004: https://mgba.io//2014/12/28/classic-nes/
  • O processador digital de sinais TI320C40 da Texas Instruments tinha problemas de pipeline ainda mais estranhos: havia delay slots de desvio (https://en.wikipedia.org/wiki/Delay_slot), em que uma ou mais instruções após um desvio eram executadas antes do desvio de fato, e também delay slots de carga, nos quais um valor armazenado em um registrador só aparecia algumas instruções depois
    Acho que, por alguns ciclos, o valor do registrador ficava indefinido. Escrever código assembly rigidamente otimizado para esse tipo de chip era bem horrível, como jogar um clone da Zachtronics de gosto especialmente duvidoso
  • No x86, a fila de prefetch também criava um comportamento parecido, mas, quando a Intel decidiu detectar código automodificável em CPUs a partir do Pentium, modificar uma instrução que seria executada em breve passou a sempre surtir efeito
    Muito mais tarde, alguém encontrou outro caso de borda que não era detectado: uma instrução repetitiva de string que sobrescrevia a si mesma
    https://silviocesare.wordpress.com/2009/02/02/anti-debugging...
  • Algumas CPUs com pipeline mantêm compatibilidade com código automodificável: se você sobrescrever uma instrução que já está no pipeline, elas detectam isso e esvaziam o pipeline
    O x86 tem esse mecanismo, mas não sei ao certo se ele acabou sendo removido nas variantes de 64 bits
  • Será que era por isso que a ROM de Dragon Ball Z: The Legacy of Goku II às vezes não funcionava no VisualBoyAdvance?
• É exatamente por isso que a emulação que mira 100% de precisão é um campo de artesanato na indústria
  Você não só precisa conhecer todos os comportamentos peculiares do hardware e do software originais, como também precisa reproduzi-los exatamente, por mais bizarros que sejam. Isso já é difícil por si só, mas ainda é preciso considerar o impacto no desempenho
  • Emuladores precisam ser realistas quanto à precisão. Ao emular sistemas mais modernos, normalmente é impossível mirar ao mesmo tempo 100% de precisão de hardware e desempenho utilizável; então acabam sendo aceitos compromissos que são tecnicamente diferentes do hardware real, mas que quase não apresentam diferenças observáveis na prática
    Usar um recompilador JIT não pode ser perfeitamente preciso ciclo a ciclo em relação ao hardware original, mas, a menos que o código do jogo tenha sido feito de propósito para quebrar emuladores, em geral isso não é um problema
    O Dolphin também precisou lidar com esse equilíbrio quando alguns jogos comerciais de Wii incluíram código antiemulador que explorava detalhes do comportamento de cache da CPU real do Wii. Em teoria, seria possível emular o cache da CPU real e rodar o jogo sem problemas, mas a sobrecarga de desempenho provavelmente deixaria tudo umas 10 vezes mais lento, tornando o jogo injogável; então a opção foi usar patches de contorno
    https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-rep...
• Como alguém começa em emulação? Parece um nicho absurdamente difícil mesmo dentro de software
  Parece que, na prática, é preciso entender eletrônica e uma magia profunda de programação
  • Como em qualquer outra coisa, é só começar gradualmente
    No começo — e, na maior parte, até no fim — você não precisa entender nenhuma magia profunda. Em geral, basta olhar a especificação e implementar aquilo. É preciso ter habilidade para estruturar o código de modo que ele não vire uma bagunça, mas existem padrões comuns, e tudo fica muito mais fácil depois de escrever um ou dois emuladores
    Quase nunca é preciso entender eletrônica. O que você emula é o comportamento. Quando se descobre um bug no comportamento do hardware original, normalmente basta colocar um tratamento especial no emulador. Conhecimento de eletrônica pode ajudar a entender por que aquele comportamento surgiu, mas isso é mais interesse histórico do que algo prático
    Há dificuldades próprias. Quando surge um problema, normalmente você acaba depurando três coisas ao mesmo tempo: seu entendimento do hardware, a implementação do emulador e o jogo que está sendo emulado. Pode ser difícil restringir a causa exata. Ainda assim, recomendo simplesmente fazer uma versão aproximada. Não é bonito, mas todo emulador está cheio de tratamentos especiais para fazer jogos populares rodarem de algum jeito. Se alguns hacks sujos fazem o jogo rodar, então faça isso. Você não precisa implementar com precisão o comportamento do hardware original; precisa fazer o jogo rodar
  • Você pode começar lendo a documentação do hardware, e não precisa entender a máquina no nível de circuito eletrônico. Não é uma simulação de circuito digital, então não precisa ser tão complexo
    Uma CPU de 8 bits é uma máquina de estados simples com alguns bytes de estado, isto é, registradores. Você lê o programa byte a byte e imita o que a CPU faria depois de ler aquele byte. São operações muito simples, como somar e subtrair números ou ler e armazenar bytes
    http://www.6502.org/users/obelisk/6502/registers.html
    http://www.6502.org/users/obelisk/6502/instructions.html
    Um emulador da CPU 6502 lê os próximos bytes do programa, interpreta esses bytes como instruções e executa as instruções. Nesse processo, ele atualiza alguns registradores ou contadores da CPU, realiza operações aritméticas ou bit a bit e, quando necessário, lê ou armazena 1 byte de dados de uma posição para outra. Esse processo se repete em um loop infinito

Isto é uma simulação do ciclo de busca-decodificação-execução
https://en.wikipedia.org/wiki/Instruction_cycle

• Depende do que você quer dizer com emulação
  Antigamente, para tocar arquivos de música SID, portei um interpretador 6502 do UNIX para o Classic Macintosh. Como bastava rodar rápido o suficiente, a precisão de ciclos de clock não era importante
  Funcionava chamando código C a partir do interpretador
• Quando tentei começar nisso há muito tempo, a orientação era começar por algo bem simples e bem documentado, e ir desenvolvendo habilidade a partir daí
  Ainda tenho vontade de tentar, mas não tenho tempo
• Fazendo um pouco de divulgação, apresentei uma palestra sobre esse tema no último FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-...
  Fora isso, o comentário irmão do @xcv123 está absolutamente correto
• É um exemplo interessante do tipo de coisa que, em emulação por software, provavelmente não vale muito a pena se preocupar. Emular até esse bug deixaria tudo bastante mais lento
  Se um dia se tornar possível replicar o PS2 em FPGA, descobrir como esse comportamento acontecia será um projeto divertido para alguém
  • Implementações em FPGA também muitas vezes são feitas com base no código ou na documentação de projetos de emulação por software
    Não há garantia de que uma versão em FPGA do PS2 não implemente bugs iguais ou parecidos
  • Depende de esse bug quebrar jogos ou não
  • Corrigir esse bug será parte do trabalho de corrigir vários outros bugs de ponto flutuante, mais especificamente problemas de arredondamento e saturação
    Ponto flutuante em software seria lento, mas a solução comum provavelmente seguiria o emulador de PS2 do PS4: colocar em uma whitelist, para cada jogo, os trechos de código em que o caminho de ponto flutuante em software é permitido
  • Qual seria o motivo para querer emular uma CPU MIPS antiga e ruim em um FPGA relativamente caro? O ponto principal de emular consoles antigos é poder jogar jogos antigos no computador ou no celular, independentemente do hardware
• Mais alguém ficou confuso pelo título, pensando por que um mouse ou teclado teria que fazer matemática?
  Demorei demais para perceber que isso falava do PlayStation 2, não da porta Personal System/2 que conecta mouse e teclado
  • Um é PS2; o outro é PS/2
  • Para quem deu voto negativo: só porque é claro para você não quer dizer que seja claro para todo mundo
    Siglas de três letras podem dificultar muito a identificação do contexto, porque, ao jogar só a sigla no Google, com bastante frequência a maior parte dos resultados é quase irrelevante