Precisão Demanda Poder: A Saga de 3GHz de Um Homem para Construir o Emulador Perfeito de SNES (III)
Table of Contents
1 Emulando os processadores adicionais
Um dos aspectos divertidos de um sistema baseado em cartuchos é que você está plugando um PCB diretamente no seu sistema. Portanto, você pode inserir processadores adicionais, geralmente processadores digitais de sinais, diretamente ao cartucho. Isto te dá uma vantagem extra contra os títulos de seus competidores. Os coprocessadores mais populares para o SNES foram o SuperFX para renderização de polígonos e rotação de sprites (usados em Starfox e Super Mario World 2) e o DSP-1 para matemática 3D (usado em Pilot Wings e Mario Kart).
Geralmente estes processadores são tão segregados do processador anfitrião que é possível implementá-lo usando emulação de alto nível1. Isto não é único aos coprocesssadores SNES; você também verá isto na emulação de microcódigo do N64, entre outras áreas.
A ideia aqui é não pensar em instruções individuais, mas no que um grupo inteiro delas faz em conjunto. Em outras palavras, pense sobre um programa em termos de funções como "renderize um triângulo nestes pontos" ou "gire este sprite de N graus". É possível então simular estas operações com sobrecarga virtualmente nula. Infelizmente, esta abordagem também descarta toda a informação de temporização requerida para a execução de cada instrução individual. E o pior de tudo, geralmente isto é tudo menos perfeito: pequenos casos limítrofes, idiossincrasias e falhas do jogo original são perdidas, resultando em uma operação sutilmente diferente.
A abordagem de emulação de baixo nível é tratar o DSP assim como um processador regular: execute cada instrução individual, uma por vez. Jogos não mais rodarão mais rápido do que realmente deveriam, e os casos excepcionais funcionarão todos corretamente. Mas isto é imensamente mais exigente. Enquanto Super Mario Kart com emulação de alto nível roda tão rápido quanto Super Mario World, um jogo sem coprocessadores, ele roda de 25% a 30% mais lentamente quando em emulação de baixo nível. DSPs são de fato bastante poderosos, tipicamente rodando a 21 MIPS ou mais, mesmo nos tempos do SNES.
Emulação de baixo nível também é uma operação bem dispendiosa, falando monetariamente: obter o código do DSP requer derreter o circuito integrado com ácido nítrico, escanear a superfície do chip com um microscópio eletrônico, e daí, ou pintar e ler manualmente, ou alterar fisicamente e monitorar os traços para extrair as ROMs de programa e de dados. Este tipo de serviço pode custar milhões de dólares para ser feito profissionalmente, devido ao conhecimento altamente especializado e ao equipamento envolvido. Graças aos esforços de um indivíduo que atente pelo nome "Dr. Decapitator", nós temos sido capazes de extrair estes dados de quase uma dúzia de chips apenas pelo custo dos materiais.
Uma vez terminado, você deve notar que DSPs são geralmente especialidades únicas. Os conjuntos de instruções devem ser reconstruídos com engenharia reversa de códigos binários e emulados com virtualmente nenhuma documentação afinal. Este é um processo custoso, e mostra o nível de dedicação necessário para emular precisamente estes jogos.
2 Preciso o suficiente?
Honestamente, mesmo com todos esses problemas acima listados, nós apenas arranhamos a superfície da emulação precisa. Tome o caso do DICE, o emulador de circuito digital integrado2. Este é um emulador que trabalha em nível de transistor para uma recriação absolutamente perfeita dos primeiríssimos video games já criados. Para rodar Pong em cerca de 5 a 10 fps, DICE requer um processador de 3GHz. Sim, você leu isso corretamente: nenhum processador de nosso tempo pode rodar Pong no nível de circuito em velocidade completa. Não é que DICE seja um programa lento; de fato ele é bastante otimizado. É que existe aqui uma sobrecarga enorme em simular cada delay de propagação de transistor.
Mas um dia isto será possível. E eu estarei feliz que este clássico tenha sido completamente replicado para as gerações futuras.
Aplicar a abordagem do DICE para sistemas mais modernos seria problemático, porém. Tome o caso do Visual6502. Alguns indivíduos geniais usaram uma técnica não muito diferente de nosso método de extração de DSP para escanear a superfície da CPU 6502, usada no Nintendo e no Commodore 64, entre outros. Eles vetorizaram os transistores e providenciaram uma simulação de alto nível do chip, a qual desconsidera os delays de propagação. Este código foi famosamente demonstrado em Javascript mas também foi portado para C e otimizado. Mesmo com os atalhos que ele toma, computadores ainda não são rápidos o bastante para usar esta implementação em emulação.
Assim como eu gostaria que todo emulador suportasse cada delay de propagação, na realidade isto simplesmente não é possível. Passa a ser honesto em dizer que nós jamais veremos hardware capaz de emular um N64 neste nível em taxas de frame jogáveis nos limites de nossas expectativas de vida.
De fato, é duvidoso que isto seja possível até mesmo para o SNES. Eu compreendo que em certo nível, o poder da computação moderna tem um peso em determinar o quão preciso os emuladores podem vir a ser.
O compromisso que eu tenho mantido foi o de construir um projeto tosco que poderia ser semelhante ao hardware real e isolar limpamente cada processador, compartilhando apenas o estado que os chips reais compartilham. Enquanto o objetivo é sempre casar os resultados de todas as operações em hardware real perfeitamente, minha abordagem pelo menos cria um sistema emulado que é virtualmente indistinguível do hardware real. Mas ao contrário do DICE, não é uma forma digital perfeita do projeto original exato do hardware.
O objetivo não é melhorar o hardware, o objetivo é chegar tão perto do hardware quanto possível. Quando se chega ao N64 e além, eu noto que mesmo essa abordagem não é mais prática. Eu não tenho respostas fáceis aqui, mas eu sei que ninguém pode realisticamente ter esperança de desenvolver um emulador que não possa rodar mesmo em um simples frame por segundo nos mais poderosos sistemas do mundo
3 Para Fechar
O que me preocupa é que, em sua maioria, os desenvolvedores temem até mesmo em utilizar metade do poder de processamento disponível nos sistemas atuais. Hardware antigo fica estigmatizado nos requisitos de sistema dos mais antigos e menos precisos emuladores, que se tornam benchmarks para futuros esforços.
Eu não vejo por que não devemos utilizar cada última gota de poder que temos disponível hoje – ou talvez mesmo um pouco mais em antecipação de um hardware mais veloz no futuro. Os emuladores antigos não vão desaparecer: eles ainda estarão aí para os camaradas com hardware mais antigo e mais lento.
Para aqueles que tenham sistemas mais poderosos, por favor deem uma chance aos emuladores mais precisos! Desenvolvedores precisam desesperadamente melhorar a fidelidade de sua emulação, e eles precisam de audiência que possa encorajá-los a continuar.
4 META
| Título Original | Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator |
| Autor | byuu |
| Link Original | http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/3 |
| Link Arquivado | http://archive.is/o76NN |
Created: 2018-03-24 sáb 20:03
Nenhum comentário:
Postar um comentário