Criando um emulador perfeito de Super Nintendo - PARTE 3

Um dos aspectos divertidos em um console a base de cartuchos é que você literalmente pluga o PCB diretamente no seu sistema. Então você pode adicionar processadores extras, muitas vezes processadores de sinais digitais dentro dos cartuchos. Isto te dá um edge extra contra outros títulos. O co-processador mais popular do SNES foi o SuperFX para renderização de polígonos e sprite rotation (usado em Starfox e Super Mario World 2) e o DSP-1 para 3D math (usado em Pilotwings e Mario Kart.)

Embora, estes processadores sejam tão segregados do processador principal é possível implementá-los usando o high-level emulation (HLE). Isto não é algo unico dos co-processadores do SNES; você também encontra no N64 microcode emulation, bem como em outras áreas.

A idéia é não pensar em instruções individuais, mas sobre um grupo inteiro deles juntos. Em outras palavras, pensar em um programa em termos de funções como "renderizar um triângulo nestes pontos" ou "rotacionar estes sprites em N graus". É possível simular outras operações sem custos virtuais. Infelizmente, esta abordagem também descarta toda a informação de timing requerida para executação de instruções individuais. E o pior de tudo, é usualmente nada além da perfeição: minor edge cases, quirks, e flaws da implementação original são perdidas, resultando sutilmente uma operação diferente.

A abordagem low-level emulation (LLE) é para se tratar do DSP assim como um processador regular: executando cada e toda instrução, uma por vez. Jogos não rodam mais rápidos do que deveriam, e os edge cases funcionam corretamente. Mas isso é imensamente mais demandado. Aonde o Mario Kart roda tão rápido com HLE como Super Mario World, um jogo sem coprocessadores, mas roda 25-30% mais lerdo quando emulado com LLE. O chip Cx4 usado mais tarde em jogos do Mega Man X é tão poderoso que pode literalmente cortar a performance pela metade com o LLE. DSPs são de fato muito poderosos, tipicamente rodando a 21 MIPS ou mais, mesmo na época do SNES.

LLE é também uma operação muito custosa, monetariamente falando: para obter o programa código DSP requer o derretimento do circuito integrado com acido nítrico, escaneando a superfície do chip com um microscópio eletrônico, e então em cada mancha e manualmente ir lendo ou fisicamente alterando e monitorando os traços exatos do programa e dos data ROMs. Este tipo de trabalho pode custar milhões de dólares para ser feito profissionalmente, dependendo da complexidade do chip, devido ao conhecimento extremamente especializado e o equipamento envolvido. Graças ao esforço de um indivíduo que atende pelo nome de "Dr. Decapitor", nós estamos podendo extrair os dados de cerca de uma dúzia de chips apenas pelo custo do material.

Assim que finalizado, você deve perceber que DSPs são usualmente uma das partes especiais, sets de instrução devem ser revertidos com engenharia de binary blobs e emulado virtualmente sem documento algum. Isto demanda processo, e mostra o nivel de dedicação necessário para emular fielmente estes jogos.

Honestamente, mesmo com todos os problemas listados até então, nós somente arranhamos a superfície da emulação com perfeição. Pegue o cado da DICE, o digital integrated circuit emulator. Aqui é um emulador que trabalha a nível de transistor para absolutamente recriar com perfeição até os primeiros video games criados. Para rodar Pong a 5-10fps, DICE requer um processador de 3GHz. Sim, é isso mesmo: nenhum processador de computador até agora consegue rodar Pong em um nível de circuito em full speed. Não é que DICE é um programa lerdo; de fato, é bem otimizado. É que há um enorme custo para simular cara transistor e a propagação dos delays.

Mas um dia isto será possível. E para nossa felicidade um grande clássico poderá ser replicado para as futuras gerações.

Aplicando a abordagem DICE´s em mais sistemas modernos vem com uma problemática entretanto. Pegue o caso do Visual6502. Alguns indivíduos espertos usam uma técnica não parecida com a nossa de extração de DSP para escanear a superfície do CPU 6502, usado pela Nintendo e Commodore 64, entre outros. Eles vetorizam os transistores e provêem a high-level simulation do chip, com propagações erradas de delays. Este código é famosamente demonstrado no Javascript, mas também foi portado para C e otimizado. Mesmo o atalho que pega, computadores ainda não são rápidos o bastante para usar esta implementação em emulação.

Mesmo eu querendo que cada emulador suportasse até o ultimo transistor propagation delay, na verdade isto não é possivel. É dificil dizer que que nós nunca veremos um hardware capaz de emular um N64 neste nível de perfeição com framerates jogáveis, pelo menos não no meu tempo de vida.

Em fato, é duvidável que isto é possível para o SNES. Eu entendo que em algum nível, o poder da computação moderna dá uma mão na determinação de quão acurado o emulador pode se tornar.

Este compromisso que eu fiz foi de criar um design parecido com o hardware real e isolar cada processador, compartilhando somente o estado que os reais chips compartilhariam. Enquanto este objetivo resulta sempre em todas as operações de um hardware real perfeitamente, minha abordagem é de pelo menos criar um sistema de emulação que é virtualmente indistinguivel de um hardware real. Mas como DICE, isto não é uma forma digital perfeita do exato design do hardware original.

O objetivo não é aperfeiçoar o hardware, mas sim, chegar o mais próximo possível de ser fiel a ele.

Mas quando se trata do N64 e acima, eu me dei conta que esta abordagem não é praticável. Eu não tenho nenhuma resposta fácil para isso, mas eu sei que ninguém pode realmente esperar que se desenvolva um emulador que não pode rodar nem um frame por segundo no computador mais rápido do mundo.

O que me preocupa, na maioria das vezes, é que desenvolvedores tem medo de utilizar a metade do processamento disponível hoje. Hardware antigos ficam estereotipados nos requerimentos de sistema mesmo no mais antigo, e menos preciso emulador, que se torna um benchmark para esforços futuros.

Eu não vejo razão do porque não utilizar cada gota de poder que temos disponível hoje--ou talvez mesmo com um pouco de antecipação um hardware futuro. Os emuladores antigos não vão desaparecer: eles ainda servirão para pessoas com hardwares antigos e mais lentos.

Para aquelas que possuem um sistema mais poderoso, por favor dêem uma chance a emuladores mais precisos! Desenvolvedores desesperadamente precisam de usuários que melhorem a fé em suas emulações, e eles precisam de audiência para encorajar a continuidade de seu trabalho.