[PT-BR] Importância dos Emuladores para a Preservação de Hardware - Parte 1

Hi! This is the part 1 of my monography"IMPORTANCE OF EMULATION FOR HARDWARE PRESERVATION", which I used for getting my bachelor degree at computer engineering. This part focuses on the definition of emulation, the difference between emulation and simulation, and the importance of preserving hardware.

This is the original, brazilian portuguese version of the paper. The paper also had the orientation of Prof. Guilherme Guindani, Ph.D and was evaluated by Prof. Laercio Carpes, MSc.

The english version is work in progress and will be made available soon.

Prefácio

Olá! Esta é a parte 1 da minha monografia "IMPORTÂNCIA DOS EMULADORES PARA A PRESERVAÇÃO DE HARDWARE", na qual foi requisito para finalizar o meu curso de bacharelado em engenharia de computação. Esta parte foca na definição da emulação, a diferença entre emulação e simulação e a importância da preservação de hardware.

Esta é a versão original, escrita em português brasileiro do trabalho de conclusão de curso. O trabalho teve orientação do Prof. Guilherme Guindani e foi avaliado pelo Prof. Laercio Carpes.

A versão em inglês está sendo feita e estará disponível em breve.

Abstract

Because a hardware is made of electronic components, it will likely fail through
the time. In addition, the time will make the electronic components obsolete, which,
usually, are harder to be replaced or maintained. If the source code (hardware
description), for whatever reason, is not available, there's a huge risk of losing the
device and its functions permanently. A solution is creating an emulator through
reverse engineering, either in software or hardware, that reproduces with accuracy
the original behavior of the device. It's possible, through some techniques, create accurate emulators that allows to a device be recreated even if using resources completely different from original, either at functional level, clock level or even at gate level. Videogames and devices that do specific functions are example of hardware that can get the benfits of emulation and reverse engineering.

Key words: emulator; hardware; reverse engineering; preservation.

Resumo

Um hardware, por ser constituído por componentes eletrônicos, irá apresentar falhas com o passar do tempo. Ademais, o tempo leva à obsolescência destes componentes eletrônicos, que, em geral, são mais difíceis de serem trocados ou mantidos. Caso não haja o código fonte (descrição de hardware), por qualquer motivo que seja, corre-se um risco de perder o dispositivo e suas funções permanentemente. Uma solução é criar um emulador, utilizando a técnica de engenharia reversa, seja em software ou hardware, que reproduza com precisão o comportamento original do dispositivo. É possível através de algumas técnicas criar emuladores apurados que permitem que um dispositivo seja recriado mesmo utilizando meios de produção completamente diferente do original, seja a nível funcional, a nível de relógio ou até mesmo a nível de portas lógicas. Videogames e dispositivos que realizam funções específicas são exemplos de hardware que podem se beneficiar da emulação e da engenharia reversa.

Palavras-chaves: emulador; hardware; engenharia reversa; preservação.

1 INTRODUÇÃO

Componentes eletrônicos de forma geral possuem um tempo de vida limitado. Todos os hardwares são propensos a falha ao longo prazo e sem um meio de preservar digitalmente o dispositivo, corre-se o risco de perdermos o equipamento, impossibilitando que ele seja futuramente reutilizado ou revisitado.

Nem sempre haverá o código fonte ou a descrição de hardware disponível, seja porque o código é fechado (closed source), seja que a empresa ou departamento tenha deixado de existir ou até mesmo tenha-se perdido o design do projeto, impossibilitando a recriação do mesmo, sem contar que talvez os componentes que façam parte do projeto não estejam mais disponíveis para comercialização ou foram obsoletos.

Uma solução e abordagem possível é a recriação do dispositivo através da emulação apurada, onde utilizando-se de técnicas de engenharia reversa é possível entender o funcionamento desde o mais básico até os pequenos detalhes comportamentais do hardware, podendo recriar em software ou hardware o dispositivo preservado, permitindo ser utilizado novamente sem perder suas características e comportamentos que apenas o hardware original possibilitava.

Dependendo do objetivo, das informações, e o nível de abertura do hardware (isto é, se é possível executar um software ou procedimento específico), diferentes técnicas podem ser utilizadas para realizar a engenharia reversa do dispositivo, onde o quanto mais profundo e preciso for o processo, mais apurado e preciso será o emulador.

Emuladores possuem diferentes níveis de precisão, sendo as mais comuns são: nível funcional, que possui foco nas principais funcionalidades e é normalmente associada a emulação de alto nível (HLE – high level emulation), nível de relógio, que realiza a emulação de ciclo em ciclo (cycle-accurate) e é considerado bastante apurado por ser de baixo nível (LLE – low level emulation) e nível de porta lógica, também considerado como LLE, que possui como objetivo trabalhar com um comportamento tão próximo que é capaz de interagir com outros dispositivos, através de PLDs ou FPGAs.

2 Por que se deve preservar hardware e software

A tecnologia está em constante evolução. Nas últimas décadas foram apresentados vários meios diferentes de se armazenar, transmitir e reproduzir conteúdo de áudio e vídeo. De formas analógicas, que poderiam se deteriorar rapidamente ou apresentar um certo nível de instabilidade, transitamos para um nível digital, onde o conteúdo é armazenado de maneira que os componentes elétricos não interferem a qualidade de imagem e som e permitem que o conteúdo seja apresentado em uma fidelidade muito superior em comparação com os formatos anteriores.

Figura 1 – Imagem de uma fita magnética utilizada, entre outros fins, para gravar e reproduzir áudio, uma forma bastante popular durante os anos de 1980 (UTMEL, 2021).

Da fita cassete, que ficou bastante popular na década de 1980, fomos gradualmente evoluindo para novos tipos de armazenamento de dados. As novas tecnologias de armazenamento de dados, além de serem mais resilientes e apresentarem uma durabilidade maior, os novos dispositivos possuíam uma capacidade de armazenamento muito superior, assim reduzindo o custo por megabyte. Por exemplo, enquanto uma fita magnética armazena cerca de 660 KB (kilobytes) em dados (UTMEL, 2021), um CD consegue armazenar cerca de 700 MB (megabytes) de dados (Eric G, 2022), uma diferença em mais de mil vezes em termos de capacidade de armazenamento.

Figura 2 – Imagem de um CD, que possui capacidade para até 700 MB de dados (Eric G, 2022).

Junto com a evolução dos armazenamentos de dados, também houve uma evolução nos dispositivos de reprodução e gravação de dados. Por consequência, gradualmente a maioria dos dispositivos deixaram de suportar formas legadas de armazenar dados para favorecer as tecnologias mais recentes. É algo esperado quando se há uma evolução em uma ordem de grandeza entre os tipos de armazenamento. Assim, surgiu a necessidade de migrar os dados de um formato antigo para o novo, de forma que seja possível reproduzir o som, vídeo ou acessar os dados armazenados que estavam originalmente em uma mídia antiga. Para tal tarefa, surgiram dispositivos especializados que faziam essa transição de um formato antigo para o novo, realizando a conversão (ou a transformação) dos sinais de áudio e vídeo para o formato novo.

Importante destacar – áudio e vídeo. São formatos, que apesar de possuírem algum tipo de estrutura ou codificação, ao decodificar se transformam em dados brutos que podem ser codificados em um novo formato e assim podendo migrar para os novos dispositivos sem prejuízo ou incompatibilidade entre os reprodutores de mídia, um processo conhecido como transcodificação. Canais de TV, empresas de conteúdo e produtoras gradualmente converteram o seu acervo para um novo formato, garantindo que o conteúdo se mantenha preservado. Graças a isso que pode-se reproduzir um filme feito um século atrás hoje em dia em um dispositivo novo, sem precisar ter que comprar um equipamento e uma mídia específica apenas para reproduzir um formato legado. Ou seja, é possível migrar os dados de um formato e uma estrutura antiga para um formato e estrutura mais atualizado com as tecnologias atuais, dispensando a utilização de dispositivos que possivelmente estariam obsoletos hoje em dia.

O mesmo não pode ser dito em relação a um software. Um software, apesar de em seu formato bruto ser composto por dados, assim como imagem e som, é composto por instruções, sendo que essas instruções foram feitas exatamente para a arquitetura do hardware na qual foi projetado. Até pouco tempo atrás, todo software era compilado e projetado para a arquitetura específica do hardware, utilizando recursos dedicados e exclusivos do dispositivo, para que assim seja possível extrair o potencial máximo do hardware, dado as limitações de desempenho. Por exemplo, o processador principal do Super Nintendo, o chip S-CPU, possui uma frequência máxima de 3.58 MHz (Evan G, 2012). Um software escrito para o Super Nintendo, portanto, precisa na medida do possível utilizar o máximo dos recursos especiais do hardware para que consiga ter um desempenho aceitável devido à baixa frequência de operação. Essa era a realidade na maioria dos hardwares construídos antes do século 21.

Figura 3 – Placa mãe de um Super Nintendo. Os softwares escritos para o Super Nintendo exploravam o máximo cada um dos chips presente nessa imagem (Near, 2020).

Uma possível solução para isso seria a migração dos softwares para um hardware mais recente. Essencialmente seria reescrever o software, incluindo suas estruturas de dados, chamadas de recursos e de hardware, para um dispositivo mais recente.

Apesar de ser um processo relativamente comum, especialmente em jogos (os chamados ports), requer um investimento considerável para reescrever todos os conteúdos para o novo formato, com conhecimento tanto no hardware anterior e no hardware mais recente, de forma que seja possível recriar o software. Porém além das questões de custo e de expertise, o novo software não será totalmente idêntico ao original, isto devido às peculiaridades de cada hardware, o áudio, vídeo e os dispositivos de interface humana serão distintos de um hardware antigo para o novo.

Além disso, um hardware pode ter centenas ou milhares de softwares escritos para o mesmo e devido às questões mencionadas acima, apenas uma pequena fração seria de fato migrada para um hardware novo, colocando em risco uma enorme biblioteca de games que ficariam eventualmente impossibilitadas de serem jogadas caso o hardware necessário para executar os jogos fique obsoleto ou falhe completamente devido ao tempo de vida limitado.

Figura 4 – Imagem de vários cartuchos de videogame, com destaque para os cartuchos de Super Nintendo. Dezenas que jogos que poderiam ser perdidos caso não haja preocupação em preservar tanto o software e o hardware utilizados para reproduzir os games (Near, 2020).

Um outro problema que precisa ser destacado é o fato de muito dos softwares (não apenas games) acabarem sendo completamente abandonado pela empresa detentoras dos direitos. Independente do motivo, seja por falência, desinteresse comercial, falta de expertise ou até mesmo estratégia, muito dos softwares criados na época nunca serão migrados para uma plataforma nova. Conhecido pelo termo Abandonware, o termo é frequentemente usado em discussões acerca de software que foram completamente abandonados pelas empresas ou sequer se sabe quem possui os direitos de um determinado software (Bernadette J, 2015).

Com todas as questões mencionadas acima, fica claro que ao contrário de conteúdos de som e vídeo, os softwares, especialmente os jogos de videogame, são muito mais vulneráveis ao tempo à medida que o hardware se degrada, podendo ter o risco de milhares de softwares serem erradicados caso não haja uma forma efetiva de preservar o conteúdo do software.

Apesar de não ser um problema relativamente complexo de salvar o conteúdo (dados) dos jogos para um formato digital, apenas tendo acesso aos dados é insuficiente para garantir a preservação, visto que esses dados são fortemente acoplado ao hardware na qual o software foi desenhado e compilado, sendo assim necessário não apenas encontrar uma maneira de preservar o conteúdo do software, mas também encontrar uma maneira de preservar o hardware para que seja possível executar esse software novamente.

Como já discutido anteriormente, um hardware eventualmente tornara-se obsoleto e o preço de desenvolver o hardware pode ficar inviável, gerando desinteresse comercial. Portanto, levando a complexidade de manter uma produção a longo prazo de um hardware, os emuladores são uma alternativa e uma solução eficaz para resolver o problema de preservação de software (e por consequência, do hardware).

3 O que são emuladores

Segundo a Biblioteca Nacional da Holanda (Koninklijke Bibliotheek, 2007), a emulação seria a imitação de uma certa plataforma de computação ou um programa dentro de uma outra plataforma na qual não foi inicialmente designada. De certa forma, um emulador permite que seja possível visualizar documentos ou executar programas em um computador que não possui compatibilidade, seja de hardware, arquitetura ou até mesmo de software (como sistemas operacionais).

Um programa (software) é desenvolvido levando em conta uma determinada arquitetura. Escrevemos o software utilizando uma linguagem de programação, que por sua vez, através de um compilador, é gerado um arquivo binário onde contém as instruções desse software. As instruções são montadas usando uma linguagem de máquina, que por usa vez depende de uma determinada arquitetura e de um processador para o seu correto funcionamento.

Percebemos, então, que há uma dependência entre o software (o arquivo binário, com suas instruções) e o hardware (que possui um processador e uma arquitetura específica). Ambos precisam ser compatíveis entre si para que a execução do software ocorra corretamente. Além dessa dependência, podem ter outros recursos necessários para a execução correta do software, como coprocessadores (placa de vídeo, placa de som, interfaces, etc.) e software intermediários (BIOS, firmwares, sistemas operacionais, kernel, drivers, etc.).

Podemos imaginar um emulador sendo uma camada intermediária entre um software que foi feito para uma arquitetura específica e o hardware onde o emulador está sendo executado. Mesmo que o hardware, sistema operacional ou qualquer outra camada intermediária seja completamente distinta para o software, este software conseguirá ser executado normalmente: as instruções são decodificadas e processadas corretamente, as chamadas de sistema funcionam como esperado e o comportamento está ocorrendo dentro do esperado. Na prática, o software continua entendendo que está sendo executado no ambiente na qual foi projetado, sem qualquer interferência no funcionamento.

Figura 5 – Exemplo de diagrama onde exibe um software feito para o SNES (Super Nintendo) sendo executado para uma arquitetura diferente do SNES (Intel x86).

Um emulador serve, portanto, como um componente que permite a utilização de software (programas) mesmo sem ter o hardware na qual esse software foi desenhado. Além do hardware, o emulador também pode ser utilizado para emular outros componentes, como BIOS, interfaces ou sistemas operacionais que possam estar ausentes e impeça a execução de um determinado software. Com esse software rodando corretamente, todas as funcionalidades atreladas ao software também funcionarão corretamente, como suporte a determinado tipo de arquivos ou uma experiência interativa (como um videogame).

Figura 6 – Windows 2000 sendo executado em um Windows XP, através de emulação (Koninklijke Bibliotheek, 2007).

Os emuladores são usados para revisitar um software que depende de um hardware na qual não está disponível. Podemos citar um hardware que se tornou obsoleto e não há mais produção disponível, um hardware que não está funcionando corretamente devido às limitações tecnológicas, por exemplo, um hardware que funciona apenas em uma TV de tubo (CRT) e não funciona em uma TV mais recente, um hardware que por algum motivo está defeituoso, e a um hardware que não é mais produzido por questão de custo ou limitação tecnológica. Por fim, emuladores também podem ser usados durante o processo de desenvolvimento de um software, na qual é possível testar as funcionalidades do software direto no ambiente de desenvolvimento, permitindo testar e validar funcionalidades onde através do hardware não seria possível com a mesma facilidade, como troca de estados, depuração ou a utilização de testes automáticos de funcionamento.

Quando um hardware se torna obsoleto, apesar de ainda ser comercialmente viável, um emulador torna-se uma alternativa interessante para redução de custos e simplificação de uma arquitetura. Um exemplo disso é o mini Super Famicom, que é simplesmente um hardware que emula o Super Nintendo e foi lançado oficialmente pela Nintendo em 2017.

Figura 7 – Imagem de uma caixa de um mini Super Famicom (Super Nintendo), lançado pela Nintendo em 2017 (Sam B, 2017).

O dispositivo vem com um processador ARM Cortex-A7 de 32-bits, que possui uma arquitetura completamente diferente do Ricoh 65C816 de 16-bits, utiliza um emulador para executar os jogos de Super Nintendo, já gravados na memória interna do dispositivo, dispensando o uso de cartuchos. Logo, emuladores não é apenas uma opção utilizada por pesquisadores e colecionadores, sendo também uma opção interessante para empresas que querem continuar usando um sistema que já se tornou obsoleto.

3.1 Diferenças entre emulação e simulação

Além da emulação, existe a simulação na computação. Um simulador é um programa que possui como objetivo, através de modelos matemáticos, encontrar um comportamento similar de um fenômeno (Eric W, 2013). Um exemplo disso são as simulações atmosféricas que possui como objetivo compreender e prever comportamentos atmosféricos dado uma janela de tempo (dias, semanas ou meses), podendo prever onde e como será o comportamento de um furacão, frente-fria ou uma onda de calor em um determinado local.

É esperado um certo nível de abstração durante uma simulação. Dependendo do objetivo que se tem em mente, pode-se abstrair alguns parâmetros para que a simulação ocorra o mais rápido possível. Existem situações em que é necessário simular cenários de vários dias em poucos segundos, o que pode tornar o processo inviável caso exista muitos fatores e variáveis a serem avaliados. Podemos imaginar a simulação como sendo um processo bem objetivo, onde na medida do possível expressamos fenômenos utilizando modelos matemáticos para realizarmos experimentos a nível de laboratório, renunciando a alguns fatores, mas sempre pensando em obter um resultado satisfatório.

A simulação não é limitada a fenômenos ou a modelos matemáticos naturais. No processo de design de hardware, é utilizado a simulação para validar o comportamento de uma descrição de hardware antes de seguir para as próximas etapas. Por ser um processo demorado que envolve custos elevados, a simulação é um mecanismo que ajuda a encontrar possíveis falhas ou comportamentos inesperados que podem prejudicar o andamento de um projeto. Entretanto, uma simulação bem-sucedida não garante que uma descrição de hardware funcionará no dispositivo final, portanto a simulação não garante que o comportamento será exatamente igual ao resultado, mas ajuda a encontrar falhas que economizam tempo e recursos.

Um emulador, apesar de não ser um requisito, espera que o comportamento seja o mais próximo possível ou exatamente igual em relação ao hardware. Isto é, dado um conjunto de entradas, um software executando um emulador deve produzir as mesmas saídas do que esse mesmo software sendo executado em seu hardware projetado. O software não deve ser capaz de diferenciar se está sendo executado no hardware final ou em um emulador, caso contrário o emulador não é considerado apurado o suficiente para emular o sistema. Existem ressalvas quanto tão próximo um emulador poderá se comportar em relação ao sistema original que serão explicados nos capítulos seguintes, mas assume que um emulador sempre terá a precisão como um dos requisitos de qualidade.

Há, portanto, uma divergência entre simulação e emulação, dado que a simulação não busca e nem se espera com exatidão os mesmos resultados em relação a um fenômeno ou ambiente real. Por envolver fatores complexos ou desconhecidos, é necessário abstrair diversos pontos para uma simulação bem-sucedida. Um emulador, por outro lado, possui como requisito a precisão, de maneira que um software possa executar de maneira similar ao seu sistema de origem, podendo renunciar a velocidade de processamento ou de conveniência caso seja necessário.

4 Preservação de hardware e relação com software

Conforme mencionado anteriormente, um software, quando compilado, é gerado um arquivo binário, executável, onde contém instruções para a execução do programa. O conteúdo binário é um arquivo, que possui dados, que podem ser armazenados de maneira digital, podendo ser replicado e copiado diversas vezes. Portanto, o conteúdo do software em si, em formato digital, pode ser facilmente preservado utilizando boas práticas de armazenamento, como dispositivos de armazenamento duráveis e a utilização de backup. Isso, porém, apenas é válido para software distribuído digitalmente, onde o consumidor pode efetuar o download do software.

Até pouco tempo atrás, boa parte dos softwares eram distribuídos exclusivamente através de mídias físicas. Podemos citar como exemplo: disquetes, CDs, DVDs, cartuchos, etc. Apesar de alguns tipos de mídia física serem compatíveis com a boa parte dos computadores (como CDs e DVDs), no ponto de vista de preservação, o uso de mídia físicas é um empecilho, pois por mais que um emulador seja capaz de reproduzir fielmente um sistema, caso a mídia em que o software esteja eventualmente falhe, não será mais possível utilizar o software no sistema designado, nem no emulador. É válido observar também que com o avanço contínuo da tecnologia, os tipos de mídia física também vão mudando, já é comum encontrarmos computadores sem leitor de disco, por exemplo. Assim, torna-se necessário encontrar maneiras de preservar o software digitalmente, sem precisar depender das mídias físicas.

As mídias possuem a finalidade de armazenar dados, logo utilizando-se um leitor ou dumper(copiador) que seja capaz de ler e validar a integridade dos dados é mais do que suficiente para preservar um software em mídia física. Como boa parte dos programas lançados possuem distribuição na casa de milhares de mídias, é possível realizar a leitura de várias delas, assim garantindo que os dados estão realmente corretos, pois caso alguma mídia tenha algum dado corrompido, é possível detectar isso comparando com as leituras feitas com outras mídias.

Figura 8 – The Mash Mods Retro Flash Cart, um dumper usado para copiar o jogo Stanley Cup do Super Nintendo (Evan G, 2010).

Entretanto, há algumas ressalvas. A primeira delas é o versionamento – como boa parte das mídias físicas é somente leitura, isto é, somente podem ser escritas uma única vez, é muito comum as equipes de desenvolvimento encontrarem falhas no software que façam com que sejam obrigados a lançarem uma nova versão do software com correções de bugs e melhorias. Por conta disso, não é incomum encontrarmos mídias com algumas versões diferentes de software. O processo de preservação precisa se atentar a isso e catalogar corretamente todas as versões disponíveis no mercado. A segunda ressalva é o fato de alguns tipos de mídia não armazenarem somente dados do software, mas também hardware adicional, que normalmente são recursos adicionais que o software precisa para executar corretamente. Dependendo desse hardware adicional, é necessário adaptar o emulador para que seja possível rodar o software corretamente devido ao hardware adicional.

4.1 Mídia física com hardware adicional

Um programa pode ser distribuído através de mídia digital e mídia física, conforme citado anteriormente. No caso da mídia física, precisamos nos preocupar em garantir que a mídia seja preservada digitalmente, devido ao fato de uma mídia física ter um tempo de vida limitado. Entretanto, existem mídias físicas que não possuem apenas uma unidade de armazenado – usado para armazenar o conteúdo do programa. Essa mídia pode ter incluso um hardware adicional que é necessário para que o programa seja executado corretamente.

Figura 9 – Cartucho de Super Nintendo, que além do armazenamento (U1, Mask ROM), possui memória adicional (U2, SRAM), um coprocessador RISC (U3, MARIO CHIP/Super FX), controlador de SRAM (U4, 74LS139) e um CI responsável pela trava de região (U5, CIC), do jogo Star Fox (Near).

Estes chips adicionais podem realizar diversas funções, dependendo do software que vem incluso no cartucho. Para o caso do Super Nintendo, os chips são usados principalmente para adicionar funcionalidades que o console do videogame não possui, como capacidade de processamento em 3D. Um bom exemplo disso é o jogo Star Fox, lançado em 1993, que conta com um chip baseado na arquitetura RISC chamado de MARIO chip (Mathematical, Argonaut, Rotation, & Input/Output) de 10.74 MHz, responsável por acelerar o processamento do jogo e em realizar renderização 3D, um recurso que não existia no console (Lucas R, 2017).

No caso do Star Fox, claramente podemos perceber que o chip incluso com o cartucho, apesar de não armazenar qualquer tipo de dados, desempenha um trabalho crítico no jogo, sendo que sem este chip não é possível sequer iniciar a tela de título. Logo, quando pensamos na perspectiva de preservar um software digitalmente, é indispensável também preservarmos o chip para que seja possível executar o software posteriormente. Porém, como o chip não possui qualquer tipo de código e é um circuito integrado feito com transistores, é necessário efetuar a engenharia reversa e criar um emulador específico que emule o chip em questão para que seja possível jogar o software em questão.

Figura 10 – Imagem do jogo Star Fox, de Super Nintendo (Lucas R, 2017).

Near (2011) menciona essa característica única de cartuchos com chips adicionais e a quantidade de possibilidades que isso permitiu ao Super Nintendo, “literalmente plugando uma PCB (placa de circuito impresso) em seu sistema”, podendo variar entre a adição de coprocessadores (como o Super FX), processadores de sinais digitais (como DSP ou CX4) e até relógios (RTC – real time clock), recursos onde os softwares podem utilizar para qualquer fim que seja. Devido a presença desses chips adicionais, a emulação torna-se um desafio interessante, visto que alguns deles são completamente desconhecidos, sem qualquer documentação ou datasheet disponível.

Em 2020, Near comentou que a emulação desses chips só se tornou viável após investimento de milhares de dólares, seja fazendo engenharia reversa do conjunto de instruções ou fazendo o decapping dos chips para visualizar os transistores ou para extrair o firmware dentro de um chip. Portanto, é um grande desafio lidar com cartuchos com chips especializados, que além de serem mais caros ao consumidor, também são mais caros conseguir realizar a engenharia reversa, visto que boa parte deles é usada em apenas algumas unidades de jogos e contam com quase ou nenhuma documentação disponível.

Uma alternativa viável, e que foi a única no começo dos anos 2000 foi a emulação de alto nível (high level emulation – HLE) desses chips. Sem se importar com as peculiaridades e o timing desses chips, emuladores focavam em apenas fornecer uma funcionalidade aproximada do chip de forma que esses poucos jogos funcionassem sem defeitos visíveis para quem estivesse utilizando. Porém como os pequenos detalhes são perdidos, muitas vezes essa técnica introduzia bugs e falhas que não existiam no software original, sendo oriundo dos emuladores, muitas vezes trazendo uma experiência negativa para quem joga através dos emuladores e motivo de preocupação com desenvolvedores que queriam desenvolver novos softwares através de emuladores, podendo ter o risco de utilizar recursos que funcionariam corretamente apenas no emulador ou apenas no hardware de origem.

Existe casos em que sequer a emulação de alto nível é possível. O jogo 早指し二段森田将棋２(Hayazashi Nidan Morita Shougi 2) para Super Nintendo, lançado apenas no Japão, utiliza um coprocessador chamado de ST018. Durante décadas, nenhum emulador era capaz de executar esse jogo, pois o coprocessador, responsável pela IA (inteligência artificial) do jogo, era completamente desconhecido, sem qualquer referência ou informação disponível, executando uma função crítica do jogo que é a tomada de decisões, onde não era possível emular em alto nível sem saber exatamente como que as decisões ou regras de negócio eram tomadas. Assim, por muito tempo, um único game de Super Nintendo ficou inviável de jogar em um emulador.

Figura 11 – Placa do cartucho Hayazashi Nidan Morita Shougi 2, de Super Nintendo. Com destaque ao chip ST018, na direita, que era responsável pela tomada de decisão do jogo (JohnDie).

Near descobriu em 2012, após extrair o firmware com as instruções dentro do coprocessador, que o ST018 era um ARMv3 de 32-bit, com uma velocidade de 21.47 MHz, e após implementar o chip no emulador BSNES, foi possível emular todos os jogos lançados comercialmente para o Super Nintendo. BSNES continua sendo o único emulador que é capaz de emular todos os cerca de 3.500 jogos já lançados (Near, 2020).

4.2 Software com periférico personalizado

Sob o ponto de vista de software, um periférico possui como objetivo ser uma entrada de dados, um sensor, que ajude o sistema a produzir saídas. Em um jogo de videogame, podemos imaginar um periférico sendo um controle, mouse ou teclado, por exemplo. Neste contexto, existem softwares que usam periféricos com certas peculiaridades que fazem com que a experiência seja completamente diferente, permitindo com que o usuário tenha uma interação que não seria possível com o uso de periféricos comuns.

Figura 12 – Imagem do console de videogame do Super Nintendo (Near, 2011).

Utilizando novamente o Super Nintendo como exemplo, o console possui entrada para dois controles. O protocolo de comunicação entre o console e o controle padrão (joypad) é ligeiramente simples e uma rotina do hardware executada 60 vezes por segundo automaticamente faz o escaneamento dos botões que estão sendo pressionados no instante atual. Entretanto, dos sete pinos da entrada do console, quatro dos pinos (Anomie, 2019) podem ser acessados diretamente pelo processador principal do Super Nintendo, fazendo com que seja possível utilizar esses pinos livremente, podendo desenvolver qualquer outro periférico que utilize esses pinos.

O mais comum foi utilizar os pinos para ler mais do que 2 controles. Utilizando um extensor chamado comercialmente de Super Multitap, alguns jogos conseguiram aumentar a quantidade máxima de controles possíveis de dois para cinco controles ao mesmo tempo, podendo assim mais pessoas jogarem o videogame ao mesmo tempo. Foi inicialmente lançado junto com o jogo Super Bomberman (Aurerio, 2012).

Figura 13 – O acessório Super Multitap, desenvolvido pela Hudson Soft (Aurerio, 2012).

Para emular o multitap, o desafio foi compreender como que o acessório funcionava. Por ser um periférico relativamente simples, o processo de engenharia reversa foi focado em compreender o protocolo do multitap, que era essencialmente um multiplexador de controles, e reproduzir o mesmo comportamento no emulador, onde uma emulação de alto nível é o suficiente. Praticamente todos os emuladores de Super Nintendo possuem suporte a multitap e para ativar, simplesmente basta configurar mais controles e o acessório é ativado de forma transparente.

Como é de se imaginar, com o grau de liberdade que os pinos de controle oferecem, foram lançados diversos outros jogos que acompanhavam seus próprios periféricos, muitas vezes difícil de adquiri-los pela quantidade pequena de unidades a serem vendidas. Entre os vários periféricos lançados, um em particular é destaque devido ao desafio de utilizar o mesmo hoje em dia: O Super Scope, lançado pela Nintendo em 1992 para diversos jogos.

Figura 14 – Imagem do Super Scope, periférico que simula uma bazuca para Super Nintendo (Evan G, 2016).

O Super Scope veio com o objetivo de possibilitar uma experiência imersiva em jogos de tiros em primeira ou terceira pessoa. Sendo um dos primeiros acessórios de vídeo game sem fio, o Super Scope não conectava diretamente ao Super Nintendo. Um receptor é conectado na segunda porta do console, que comunicava de maneira wireless ao Super Scope. O periférico, por não ser alimentado pelo próprio console, precisava de seis pilhas para funcionar (Evan G, 2016).

Funcionalmente falando, o Super Scope, sendo segurado pelo usuário, captura as coordenadas da tela de onde o usuário está mirando na TV e envia as coordenadas ao console junto com a informação se o botão de gatilho está sendo pressionado ou não naquele momento. O software, então, recebe essas informações direto dos registradores do Super Nintendo e assim efetua as ações de acordo com a posição e pressionamentos recebidos.

Internamente, porém, o Super Scope é bastante complexo. O periférico possui um sensor que é sensível aos fótons emitidos pela TV de tubo (CRT). Durante o processo de raster(rasterização) da tela, o chip gráfico do console do Super Nintendo fica acompanhando a posição de escaneamento da TV, de ponto em ponto, e de acordo com a posição, o chip do SNES envia qual será a cor de cada pixel a ser exibido na TV. Esse processo é feito em todos os pontos horizontais de desenho da TV e novamente repetido até finalizar todas as linhas (scanlines) da TV, cerca de 60 vezes por segundo. Durante o processo de refresh, onde todos os pontos são invalidados, o Super Scope começa a acompanhar o processo de desenho até perceber o momento exato que o pixel é desenhado na tela. Quando esse pixel é desenhado, o acessório aciona um latch em um dos pinos do controle, na qual envia um comando para o chip gráfico solicitando as coordenadas aproximadas no instante que é feito o desenho.

Figura 15 – Jogo Yoshi’s Safari, lançado para o Super Nintendo, utiliza o Super Scope como controle principal (Evan G, 2016).

Além da complexidade técnica, o método não funciona perfeitamente, por depender no brilho dos fótons da TV de tubo e devido a características físicas da TV, o Super Scope possui dificuldade maior em identificar pixels vermelhos e dependendo do modelo da TV, o acessório muitas vezes pega uma posição incorreta da tela. Para complicar, por justamente trabalhar com as características da TV de tubo, o Super Scope não é compatível com outros tipos de televisão.

Figura 16 – O jogo Yoshi’s Safari, ao contrário da maioria dos jogos do Mario (e sua própria tela de título), possui cores mais neutras e acinzentadas, para facilitar a detecção de fótons do Super Scope (Evan G, 2016).

Este é um caso em que a preservação do hardware contribuí um papel importante. Um acessório desses dificilmente pode ser utilizado hoje em dia caso não tenha todos os requisitos necessários e muita das vezes o uso de um emulador simplificará a experiência por emular o acessório em alto nível, podendo o usuário simplesmente usar um outro tipo de acessório que informa as coordenadas. Não será exatamente a mesma experiência de jogo, mas sem dúvidas funcionará até melhor do que através do hardware original. E sem a emulação, correria o risco de todos esses jogos ficarem simplesmente inviável de usar sem o acessório devidamente emulado.

Nota ao leitor

Esta é a parte 1 do trabalho. A parte 2 focará em métodos e desafios da emulação e será disponibilizada em breve. As referência bibliográficas abaixo se refere ao trabalho de conclusão de curso completo.

REFERÊNCIAS BIBLIOGRÁFICAS

Andreas L. Discovering New Paths Playing Old Games. Bibliotheksdienst, vol. 54, no. 5, 2020, pp. 313-344. Disponível em: <https://www.degruyter.com/document/doi/10.1515/bd-2020-0044/html>. Acesso em: 27 nov. 2022.

Anomie. Schematics, Ports, and Pinouts. Disponível em: <https://wiki.superfamicom.org/schematics-ports-and-pinouts>. Acesso em: 3 dez. 2022.

Aurerio. Plug and Blast: Super Multitap. Disponível em: <https://www.nintendoblast.com.br/2012/04/plug-and-blast-super-multitap.html>. Acesso em: 3 dez. 2022.

Bernadette J. How Abandonware Works. Disponível em: <https://computer.howstuffworks.com/abandonware.htm>. Acesso em: 1 dez. 2022.

Eric G. From Floppies to Solid State: The Evolution of PC Storage Media. Disponível em: <https://www.pcmag.com/news/the-evolution-of-pc-storage-media>. Acesso em: 30 nov. 2022.

Eric W. Computer Simulations in Science. The Stanford Encyclopedia of Philosophy. Disponível em: < https://plato.stanford.edu/archives/sum2013/entries/simulations-science/>. Acesso em: 27 nov. 2022.

Evan G. Mash Mods SNES Retro Flash Programmer/Retro Flash Cart. Canadá. Disponível em: <https://snescentral.com/article.php?id=0993>. Acesso em: 1 dez. 2022.

Evan G. SNES Chip List. Disponível em: <https://snescentral.com/chiplisting.php>. Acesso em: 1 dez. 2022.

Evan G. Star Fox. Disponível em: <https://snescentral.com/article.php?id=0636>. Acesso em: 3 dez. 2022.

Evan G. State of SNES Emulation - 2010. Disponível em: <https://snescentral.com/article.php?id=0995>. Acesso em: 30 nov. 2022.

Evan G. Super NES Technical Specifications. Disponível em: <https://snescentral.com/article.php?id=0088>. Acesso em: 1 dez. 2022.

Evan G. Super Scope. Disponível em: <https://snescentral.com/article.php?id=0017>. Acesso em: 3 dez. 2022.

Jeffrey H. Emulation for Digital Preservation in Practice: The Results. The National Library of the Netherlands, Holanda. Disponível em: < http://www.ijdc.net/article/view/50>. Acesso em: 27 nov. 2022.

John E. The internal workings of video game consoles: The GameBoy. Mälardalen University, Suécia. Disponível em: <https://www.diva-portal.org/smash/get/diva2:433485/FULLTEXT01.pdf>. Acesso em: 27 nov. 2022.

John McMaster. s-ppu1-5c77-01. Disponível em: <http://www.siliconpr0n.org/map/nintendo/s-ppu1-5c77-01/>. Acesso em: 4 dez. 2022.

John McMaster. s-ppu2-5c78-01. Disponível em: <http://www.siliconpr0n.org/map/nintendo/s-ppu2-5c78-01/>. Acesso em: 4 dez. 2022.

John. How to Write a Basic Verilog Testbench. Disponível em: <https://fpgatutorial.com/how-to-write-a-basic-verilog-testbench/>. Acesso em: 3 dez. 2022.

Koninklijke Bibliotheek. What is emulation?Disponível em: < https://web.archive.org/web/20110908070810/http://www.kb.nl:80/hrd/dd/dd_projecten/projecten_emulatiewatis-en.html>. Acesso em: 27 nov. 2022

Lucas R. Star Fox (SNES) e o Super FX. Disponível em: <https://jogoveio.com.br/starfox/>. Acesso em: 3 dez. 2022.

Near. 2011-02-28 - Why Accuracy Matters. Disponível em: <https://helmet.kafuka.org/accuracy/>. Acesso em: 3 dez. 2022.

Near. Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator. Disponível em: <https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/>. Acesso em: 1 dez. 2022.

Near. How SNES emulators got a few pixels from complete perfection. Disponível em: <https://arstechnica.com/gaming/2021/06/how-snes-emulators-got-a-few-pixels-from-complete-perfection/>. Acesso em: 1 dez. 2022.

Near. SHVC-1C0N5S-01. Disponível em: <https://snescentral.com/pcbboards.php?chip=SHVC-1C0N5S-01>. Acesso em: 1 dez. 2022.

Neil P. The 6502/65C02/65C816 Instruction Set Decoded. Disponível em: <https://llx.com/Neil/a2/opcodes.html>. Acesso em: 2 dez. 2022.

Sam B. Nintendo announces mini Super Famicom for Japan. Disponível em: <https://www.theverge.com/2017/6/26/15878004/nintendo-super-famicom-mini-japan-price-release>. Acesso em: 2 dez. 2022.

Stewart Granger. Emulation as a Digital Preservation Strategy. University of Leeds, Reino Unido. Disponível em: <http://www.dlib.org/dlib/october00/granger/10granger.html>. Acesso em: 27 nov. 2022.

UTMEL. The Evolution History of Storage Devices. Disponível em: <https://www.utmel.com/blog/categories/memory%20chip/the-evolution-history-of-storage-devices>. Acesso em: 2 dez. 2022.