Deixa eu ser preciso. Eu sempre soube que dava pra fazer. Duas máquinas Turing completas conseguem, em tese, rodar o código uma da outra. Você sempre consegue traduzir programa de uma arquitetura pra outra. O problema nunca foi possibilidade, foi custo. O NES roda um 6502, o Master System roda um Z80, e ao longo dos anos eu li em vários cantos que uma tradução direta de 6502 pra Z80 sempre acabava rodando muito mais devagar, por causa das diferenças de arquitetura e de hardware. Devagar o suficiente pra nunca compensar na prática.

E essa memória tem fundamento. Se você for atrás em fórum de retro-dev, tipo o NESdev, o consenso é que traduzir instrução por instrução é justamente o pior caminho: “cada instrução do código-fonte vira várias instruções no código objeto, e o programa resultante roda muito mais devagar e ocupa muito mais memória”. Não é só a CPU. O 6502 tem a zero page, um modo de endereçamento baratíssimo que o Z80 não tem equivalente, então você troca um acesso barato por uma sequência cara com IX/IY. E a parte gráfica é pior ainda: o PPU do NES e o VDP do Master System são bichos diferentes, com scroll, sprites e espelhamento de tela que não encaixam um no outro sem gambiarra cara.

Ou seja, todo mundo que já pensou nisso chegou na mesma conclusão: dá pra fazer, mas roda mal demais pra valer a pena.

Só que agora a gente tem LLMs de fronteira. E eu fiquei curioso: será que uma abordagem de força bruta, com uma LLM boa no meio do processo, consegue um resultado melhor do que a tradução ingênua de sempre? Comecei o projeto nes-to-sms no fim de maio, uns três meses atrás, pra descobrir.

O primeiro resultado foi exatamente o que a teoria previa: ruim. Uma tradução mais ou menos direta gerou código que roda, mas devagar demais. Eu consegui converter o Super Mario Bros inteiro, com sprites, fases, tudo, mas pra ficar minimamente jogável eu precisava rodar o emulador Mednafen com overclock de 500%. Depois de bater cabeça com Claude, GPT e outros modelos por um tempo, empaquei. Trabalhei firme por junho e julho, e em agosto pausei o projeto pra deixar a poeira baixar.

Por que Master System, e não NES?

Antes de explicar a parte técnica, preciso explicar a obsessão, porque ela é o motivo de tudo.

Eu sempre achei o Master System um console superior ao NES. Melhor CPU, melhor chip de vídeo, uma paleta de cores bem mais rica. O NES trabalha com 4 cores por tile de fundo e 3 por sprite. O Master System trabalha com paletas de 16 cores. Isso é uma diferença enorme na prática.

O problema é que a Nintendo tinha um monopólio brutal na época e não deixava as third parties lançarem pra outros consoles. Quem quisesse fazer jogo pro NES assinava um contrato de exclusividade. O resultado é que o Master System, tecnicamente melhor, ficou faminto de jogos. Praticamente só a própria Sega lançava, e a biblioteca da Sega nunca teve o peso de um Castlevania, um Mega Man, um Final Fantasy.

Imagina o que a gente perdeu. Dava pra ter tido aqueles mesmos jogos clássicos do NES, só que com a capacidade superior do Master System por baixo. Um Castlevania com mais cor, sprites melhores, som melhor. A gente nunca teve isso, e é exatamente essa frustração histórica que me fez querer converter NES pra SMS em primeiro lugar.

O port que provou a tese

Enquanto eu estava com o projeto parado, um outro desenvolvedor, o lackoftrack27, publicou um port de Super Mario Bros pro Master System que é de outro nível. Roda em velocidade cheia, 60fps, e ainda por cima com uma arte de sprite melhorada que aproveita a paleta superior do console. Ficou mais parecido com o remaster do Super Mario All-Stars do Super Nintendo do que com a versão original meio crua do NES. A comunidade retro ficou de queixo caído.

Isso provou, na prática, a minha tese: o Master System é capaz de rodar versões superiores dos jogos de NES. Sempre foi.

Agora, dois pontos honestos sobre esse port, porque eles importam pro resto da história.

Primeiro: o trabalho do lackoftrack27 é uma reimplementação feita à mão, a partir da disassembly do jogo, otimizada especificamente pro Super Mario. Não é uma tradução automática de propósito geral como a que eu tento fazer. Ele resolveu um jogo, lindamente, no braço. Curiosamente, isso reforça o que os fóruns já diziam: o caminho que funciona é reimplementar no braço, não traduzir a máquina.

Segundo: por mais impressionante que seja ver o Super Mario no Master System, é bom lembrar que ele ainda é um jogo de primeira geração, de uns 40kb. Ou seja, é um dos jogos mais simples do NES. Coisas de geração posterior, tipo Super Mario Bros 3 ou Kirby, ninguém tentou converter ainda, e por bons motivos que eu explico mais pra frente.

Mas o mais importante foi o efeito colateral: com o mapa que o port dele me deu, eu finalmente consegui fazer a minha conversão automática rodar direito. Voltei ao projeto no começo de setembro, carreguei o código do lackoftrack27 no Claude Fable e depois no novo GPT Astra, e coloquei os dois pra estudar o que ele fez que eu não estava fazendo.

A arquitetura da solução

Como esse artigo é pra programador, deixa eu abrir a caixa preta.

A primeira decisão importante é que o nes-to-sms não é um emulador, nem um tradutor texto-pra-texto de 6502 pra Z80. Ele é um recompilador estático. Ele lê a ROM do NES, levanta o código 6502 pra uma representação intermediária com semântica explícita, e daí gera código Z80 a partir dessa IR. A saída é um projeto em assembly WLA-DX que compila numa ROM .sms de verdade. O núcleo é um workspace Rust com treze crates, mais um runtime Z80 escrito à mão que é compartilhado entre os jogos.

O fluxo, de ponta a ponta, é mais ou menos assim:

1. Parsear o cabeçalho da ROM, separar os bancos de código (PRG) e de tiles (CHR) e ler os vetores de reset e interrupção.
2. Carregar um perfil por jogo (um TOML com rótulos, regiões de dados, tabelas de salto, tipo de mapper e substituições).
3. Descobrir as funções, montar o grafo de fluxo e classificar cada byte como código ou dado. Aqui entra um detalhe chave: cada acesso à memória é etiquetado com a região a que pertence (zero page, pilha, RAM, registradores do PPU, DMA de sprite, som, mapper).
4. Levantar cada rotina pra IR, com as flags do 6502 explícitas. Uma escrita no registrador $2006 do PPU não vira um mem[]= qualquer, vira uma primitiva de “escrita no PPU” de primeira classe.
5. Baixar a IR pra Z80. As flags do 6502 são mantidas num byte de status sombra na RAM, e todo acesso a hardware vira uma chamada pro runtime.
6. Emitir os bytes Z80 e também o assembly WLA-DX legível.
7. Converter os assets: os tiles 2bpp do NES viram tiles 4bpp do modo 4 do Master System, a paleta do NES vira a CRAM do SMS, e por aí vai.
8. Escrever o projeto SMS inteiro, com Makefile, runtime e dados, pronto pra compilar.

O mapeamento da CPU é conservador de propósito. O acumulador A do 6502 vira o A do Z80, os registradores X e Y ficam em RAM ou em registradores, a zero page vira um bloco fixo na RAM do SMS, e cada operação que mexe em flag chama um helper. É seguro e correto, mas é justamente aqui que mora o custo.

Onde NES e SMS divergem de verdade

O achado central do projeto é sobre velocidade, e ele é contraintuitivo.

O 6502 do NES roda a 1.79 MHz. O Z80 do Master System roda a 3.58 MHz, o dobro do clock. Você olha isso e pensa “então tem folga de sobra”. Só que não. O Z80 gasta em média uns 13 ciclos por instrução, enquanto o 6502 gasta uns 4. Na conta real, um Z80 de 3.5 MHz equivale mais ou menos a um 6502 de 1 MHz pra trabalho genérico. Ou seja, o Z80 do SMS é na verdade mais lento que o 6502 do NES pra fazer o mesmo trabalho. A folga é negativa.

Pior: o idioma mais barato do 6502, um LDA tabela,X, é um dos mais caros de emular no Z80. Então uma tradução fiel de um jogo que já espremia o NES no talo simplesmente não tem como bater 60fps sem overclock. A culpa é da física do problema, não do meu tradutor.

E o vídeo é outra história. O NES enxerga a memória de vídeo de forma mapeada, com nametables, scroll por hardware e uma tabela de sprites acessada por DMA. O Z80 do SMS não endereça a VRAM como memória: ele seta um latch de endereço e joga bytes por portas do VDP. Então toda escrita de PPU do NES precisa ser capturada, enfileirada num buffer e despejada no VDP durante o vblank. O NES vira sprite de graça, só setando um bit de atributo. O Master System não tem flip de sprite por hardware, então o programa precisa espelhar os dados do tile na VRAM na unha, gastando memória. O split de tela que os jogos de NES fazem no meio do frame, mexendo no scroll a cada scanline, também não tem equivalente direto, porque o VDP trava o scroll vertical no topo do frame.

E ainda tem o teto de VRAM. Os 8 KB de tiles do Super Mario viram 16 KB no formato 4bpp do SMS, que é a VRAM inteira do console. Fundo e sprites não cabem residentes ao mesmo tempo. E o código explode de 3 a 6 vezes de tamanho, por isso a saída SMS já é bancada desde o primeiro jogo, mesmo os mais simples.

Aproveitando o que o SMS tem de melhor

A sacada pra recuperar velocidade é parar de emular o comportamento do NES e passar a gastar as forças do Master System. O lema do projeto virou “gastar ROM pra comprar CPU”.

O SMS aceita cartuchos de vários megabytes. Então em vez de espelhar sprite na unha em tempo de execução, o build já gera variantes pré-espelhadas de cada tile de sprite, e o flip vira uma consulta de tabela. Em vez de emular a tabela de atributos do NES, o assembler já grava a palavra final de nametable do SMS, com os bits de flip, paleta e prioridade embutidos. A tabela de atributos do NES simplesmente deixa de existir no programa. As cópias pro VDP usam blocos de OUTI desenrolados, mais rápidos que o loop genérico. E o split da barra de status, que no NES depende do sprite-zero, vira uma interrupção de linha do SMS, que é o jeito nativo de fazer isso.

Nada disso é mágica. A folga negativa da CPU continua lá, então essas otimizações reduzem o custo mas não fazem milagre sozinhas. Mas é a diferença entre injogável e jogável.

O pulo do gato: fazer a IA rodar o emulador

Aqui está a parte que eu considero mais importante do projeto inteiro, e é o que separou a tentativa fracassada de maio da versão que finalmente anda.

Tradução cega não funciona. O modelo precisa de feedback real pra saber o que está quebrado e o que está lento. Então o coração do projeto está no oráculo diferencial, a infraestrutura que roda os emuladores e mede a realidade. O tradutor é só a parte fácil.

Funciona em duas camadas. A primeira compara instrução por instrução: pra cada rotina, o sistema gera estados iniciais aleatórios, roda o 6502 original num interpretador de referência e roda o Z80 gerado, e compara o resultado (acumulador, registradores, flags, RAM tocada). Qualquer divergência acende o alerta. A segunda camada compara frame a frame: ela roda a ROM do NES como verdade absoluta e a build do SMS lado a lado, com o mesmo roteiro de botões, e compara a RAM byte a byte em cada frame. Depois isso foi estendido com um oráculo que confere a VRAM e a paleta do SMS, e com um oráculo visual que compara a saída contra o frame real do NES.

Esse loop de medir é o que destravou os consertos recentes. Não foi chute. Dois exemplos concretos:

No Super Mario, cada passo de otimização foi medido em ciclos por frame, com o emulador rodando de verdade. O orçamento de um frame é 59.736 ciclos. A base parou em uns 370 mil ciclos por frame, algo como 6 vezes acima do orçamento, o que dava uns 10fps e explicava a necessidade daquele overclock brutal de 500%. Medindo passo a passo, cada mudança validada pelo oráculo, a coisa desceu até 118.296 ciclos por frame, ou 1.98 vezes o orçamento. Ou seja, saiu de 6 vezes pra menos de 2 vezes. Agora ele roda em velocidade cheia já no overclock padrão do emulador, e fica confortável ali na casa dos 200 a 300%, contra os 500 a 700% do começo.

No Castlevania, o maior ganho de velocidade veio de um perfil que só o emulador conseguiu revelar: um loop de espera de sprite-zero, no endereço $F8C7, estava fazendo 255 leituras de status e saindo por timeout toda vez, consumindo quase 23% de toda a CPU. Sem rodar o emulador e medir, ninguém acharia isso no olho. Com a medição, o conserto foi cirúrgico.

É esse o argumento maior que eu venho batendo faz tempo sobre agentes: um LLM que só gera código no escuro erra feio. Um LLM que consegue rodar o alvo de verdade, coletar dado real e reagir ao que mediu joga em outro nível.

O que aprendi estudando o port do lackoftrack27

Com esse oráculo no lugar, coloquei o Claude Fable e o GPT Astra pra dissecar o port do lackoftrack27, que é uma reimplementação do mesmo jogo a partir da mesma disassembly que eu traduzo. Isso respondeu de vez uma dúvida que estava me travando: o Super Mario cabe no Master System. O meu estouro de 6 vezes no orçamento era 100% overhead de tradução, não limitação do jogo nem do hardware.

Os ganhos dele, em ordem de impacto, foram mais ou menos esses:

• A maior de todas: a representação dos dados. Ele reorganizou os arrays de objetos do jogo em páginas de RAM, uma por slot, com os mesmos offsets de campo. Aí o X do 6502 vira o registrador H e o nome do campo vira o L, e um acesso que no meu tradutor custava umas 70 unidades de tempo passa a custar 14. O detalhe cruel é que isso só funciona porque o programador sabe, de cabeça, que aquele X ali é sempre um índice de objeto entre 0 e 6. Um tradutor estático não tem como descobrir esse invariante com segurança. Essa é a otimização mais poderosa, e é justamente a que a tradução automática não consegue provar sozinha. É o resíduo que segura as últimas 2 vezes de velocidade.
• Flags auditadas, não emuladas. Ele checou o código e achou só uns 10 lugares que dependem de verdade de alguma peculiaridade do carry do 6502. O resto usa flag nativa do Z80. Isso confirmou uma medição minha: gastar energia emulando flag rende quase nada.
• Chamadas nativas. JSR virando CALL de verdade, sem a contabilidade cara de pilha emulada. Esse foi o maior ganho genérico que eu portei pro meu pipeline.
• PPU deletado em tempo de build, não emulado em runtime, exatamente como descrevi na seção de aproveitar o SMS.
• Frame arquitetado pra estourar com elegância, transformando um estouro em um frame de lag limpo em vez de corromper a tela.

Adotei o que dava pra generalizar, e o Super Mario despencou de 6 vezes pra menos de 2 vezes o orçamento. Esse é o resultado rodando hoje:

A lição mais honesta desse estudo é dupla. Os ganhos de verdade estão na representação de dados e na convenção de chamada, não no que eu tinha atacado primeiro. E o ganho mais fundo de todos é exatamente o que o tradutor automático não consegue inferir. Isso desenha bem o teto do que dá pra automatizar.

Castlevania e o problema dos mappers

Com o Super Mario andando, voltei pro meu velho alvo: o primeiro Castlevania. E aqui a gente esbarra na limitação mais séria do NES.

O NES é um console simples, com um monte de limitação. Uma das principais é que ele não suporta jogo maior do que uns 40kb de ROM, porque o 6502 só enxerga uma janela de 32 KB de programa no espaço de endereço dele. A “solução” da época foi genial e meio maluca: partes do console foram sendo turbinadas pelo próprio cartucho.

Muita gente pensa que cartucho é só um chip de ROM com o código do jogo. No caso do NES, não. Os cartuchos vinham com uma variedade de chips extras que aumentavam a capacidade do console, seja um chip de som melhor ou, muito mais comum, os mappers. Existem vários mappers diferentes, da própria Nintendo e de third parties como Capcom e Konami. Eles usam uma técnica chamada bank switching: como o 6502 não enxerga endereço suficiente, o mapper vai trocando quais pedaços de ROM ficam visíveis naquela janela de 32 KB, conforme o jogo pede. É assim que jogos grandes cabem num console que, no papel, não aguentaria.

Eu já expliquei isso em detalhe num vídeo antigo do canal, o Akitando #81, sobre aprender computação com o Super Mario do jeito hardcore:

O Castlevania usa um dos mappers mais antigos, o UxROM. E aqui está o problema de escala do meu projeto: se eu quiser conseguir traduzir a maioria dos jogos de NES, eu tenho que mapear todos os mappers, um por um. Hoje o projeto implementa só dois: o NROM, que é o cartucho pelado do Super Mario, e o UxROM do Castlevania. Todos os outros, os MMC1, MMC3 e companhia, estão só planejados. Cada mapper é um trabalho e tanto de implementar, porque não basta entender o bank switching do NES, é preciso traduzir esse comportamento pro mapper próprio do Master System.

A boa notícia é que o Master System também é um sistema bancado, então o mapeamento é “a mesma forma um nível acima”. Um banco de PRG do NES vira um conjunto de bancos do SMS, uma escrita de troca de banco do NES vira uma escrita no mapper do SMS através de um shim, e uma chamada que cruza bancos usa a maquinaria de “portão” que já existe. A identidade de uma rotina passa a ser o par (banco, endereço), e uma tabela de despacho resolve isso em tempo de execução. Quando não acha, ele falha fechado, com um trap, em vez de rodar lixo.

É aqui que os jogos maiores vão bater na parede. O bank switching de tiles dos mappers mais avançados, o timing de interrupção por scanline do MMC3 e do MMC5, e o próprio teto de bancos do SMS pra um jogo de NES bem grande, tudo isso ainda está por resolver. Por isso eu ainda não sei dizer se um Super Mario Bros 3 é viável ou não. É bem possível que os jogos maiores morram exatamente nessa etapa.

De qualquer forma, mexi mais um bocado no Castlevania nessa retomada. Consertei uma pilha de coisas usando o oráculo: o loop de sprite-zero que comia CPU, a lógica de armas e projéteis que perdia retornos de chamada, um glitch de scroll na barra de status, a colisão de VRAM entre sprites 8x16 e 8x8, e a coerência entre fundo, paleta, HUD e sprites. Hoje o Castlevania sobe, aceita o start, desenha o primeiro estágio de forma reconhecível, responde ao controle e roda por um bom tempo sem travar. Mas é honesto dizer que ele ainda roda devagar, e o caminho que eu uso pra jogar é o Mednafen com overclock de 500%, e mesmo assim ainda está de 2 a 3 vezes abaixo da própria meta de velocidade. Está longe de ser pixel perfeito e em tempo real.

Conclusão

Depois de tantas semanas e tantas tentativas, eu ainda não sei quanto mais dá pra espremer de uma tradução automática. O teto pode estar perto, porque as otimizações mais fundas são justamente as que uma máquina não consegue inferir sozinha.

Mas tem um caminho que me anima. A tradução automática pode virar uma linha de base. Uma conversão SMS que já roda, correta, ainda que lenta, e que depois pode ser otimizada no braço, jogo a jogo, exatamente como o lackoftrack27 fez com o Super Mario e como tanta gente vem fazendo com decompilações e ports por aí. O oráculo garante que a base está correta, e a mão humana entra pra fazer o que a máquina não consegue.

Portar jogo pra um hardware muito superior, tipo um port pra PC, é relativamente fácil, porque sobra capacidade. O difícil de verdade é encaixar o jogo num console da mesma geração, onde não sobra nada. E é justamente essa dificuldade que torna a ideia de fazer versões melhores de jogos de NES pro Master System tão atraente. É o console que merecia ter tido esses jogos, e nunca teve.

Eu espero que mais gente se anime com essa possibilidade e contribua com o projeto. Está tudo aberto no nes-to-sms. Se você curte 6502, Z80, VDP e o desafio de espremer ciclo de um hardware de 40 anos atrás, apareça. Tem lugar de sobra.

Na semana passada publiquei sobre o meu setup distrobox-gaming, com mais de dez jogos de corrida retro rodando em Linux, do Gran Turismo 1 no DuckStation ao Forza Motorsport 4 no Xenia. No fim daquele artigo, falei do Driveclub no shadPS4 como o “final boss”: o jogo boota, o menu carrega, a corrida começa, o controle responde.

Só que tinha dois problemas que eu mencionei de passagem e tratei como “limitações aceitas”:

1. De dia, a imagem fica um pouco mais escura do que no PS4 de referência. Nada alarmante, mas perceptível.
2. De noite, race start no Canadá ou em Munnar ficava pitch black por 10 a 30 segundos antes de o jogo “se recuperar sozinho” perto de 1:30. Durante esses segundos, só o HUD aparecia. Pista, carro, faróis, tudo preto absoluto.

No artigo anterior eu empurrei a explicação pra “ainda não foi consertado no emulador, vou conviver com isso”. Mas por dentro eu não conseguia me aceitar jogando num estado visualmente injogável. Eu queria jogar o Driveclub no melhor que ele podia entregar, e não queria ficar esperando o projeto consertar por mim. Decidi pegar a coisa nas minhas próprias mãos. Um preto absoluto de 30 segundos não é “um pouco mais escuro”. É um bug grave, dos que tornam o jogo injogável na prática.

Esse artigo é o que aconteceu entre domingo de noite e quinta-feira de manhã.

O blackout, ao vivo

Esse vídeo é o comportamento que eu queria consertar. Race start na Índia (Munnar), corrida noturna. Você vê a pista, os faróis aparecem, os primeiros segundos rodam. Depois, escurece progressivamente. Em uns 15 segundos já tá tudo preto. Fica assim por mais uns 60-90 segundos. Aí o jogo “recalibra” sozinho, e a pista reaparece.

Se você for um jogador, você não quer saber do porquê. Você quer dirigir.

Por que shadPS4 é difícil de depurar

shadPS4 ainda não tem release estável. O projeto tá em desenvolvimento ativo. Main branch muda várias vezes por semana, configs migram de TOML pra JSON sem aviso, settings ficam atrás de “Advanced” pra não gerar issue de usuário com hardware incompatível, PRs em aberto disputam abordagens diferentes pra o mesmo problema.

Quem tenta configurar Driveclub hoje encontra:

• Guias de Reddit de setembro/2025 que usam readbacks = true (era bool na época) e dizem “pra DriveClub sempre ligar readbacks”.
• Guias de novembro/2025 que dizem “desliga readbacks, mata a performance” (porque em 2025-07 readbacks virou enum Disabled | Relaxed | Precise, com perfil de performance diferente, e Bloodborne começou a travar com ele ligado).
• Vídeos YouTube de janeiro/2026 com fork customizado que ninguém documentou qual é.
• Thread no shadps4.net com três explicações diferentes pro blackout, todas mutuamente exclusivas.
• Minhas próprias anotações da semana passada no distrobox-gaming/docs/driveclub-shadps4.md dizendo readbacks_mode: 0. Que é exatamente o oposto do que eu descobri essa semana.

Ou seja, a informação existe, mas tá espalhada, datada, contraditória, e a maior parte depende de detalhes de versão que mudaram entre a postagem original e hoje. Reproduzir setup via vídeo do YouTube é tentar resolver cubo mágico de olhos vendados.

Spoiler: a solução é um inteiro

Depois de 31 fases de investigação, 44 commits no meu fork do shadPS4, 15.668 linhas de código instrumental adicionadas e 3 dias de debug quase ininterrupto, a resposta é uma linha no config por jogo:

{
  "GPU": {
    "readbacks_mode": 2
  }
}

readbacks_mode: 2 é o modo Precise. Explicar o que isso faz exige entender como o Driveclub implementa auto-exposure, e é aqui que a jornada começa. Pra saber POR QUE esse toggle resolve, você precisa entender a cadeia toda.

O resumo do porquê: o Driveclub faz auto-exposure como um loop de feedback GPU→CPU.

1. A cena renderiza num HDR target.
2. Um compute shader calcula um histograma de luminância num SSBO.
3. A CPU lê esse SSBO no frame seguinte e deriva uma exposição alvo.
4. A CPU escreve essa exposição de volta num UBO de lighting de 1936 bytes (nos slots [38] [48] [50]).
5. Os fragment shaders leem esse UBO e multiplicam a luminância da cena por ele.

Sem readbacks_mode: Precise, o passo 3 lê zeros obsoletos. A página de memória que o GPU escreveu o histograma nunca é sincronizada pro lado da CPU. O integrator de exposição da CPU conclui “a cena tá escura, abrir diafragma ao máximo” e rampa o valor de saída monotonicamente: 2.59 → 7.84 → 24 → 90 → 179 → 255. Em 60-90 segundos, a escala satura tão alto que tudo clipa pra zero. É esse o pitch black.

Com readbacks_mode: Precise ligado, o emulador marca as páginas que o GPU acabou de escrever como protegidas no nível de kernel (via mprotect no Linux). Quando a CPU tenta ler uma dessas páginas pela primeira vez, dispara uma page fault. O emulador intercepta, emite um vkCmdCopyBuffer download do buffer do GPU pro staging de host, espera no scheduler, e a CPU enfim vê o dado fresco. O histograma verdadeiro entra no integrator, a exposição converge normalmente, e o race start abre brilhante como deveria.

Por que não é o default? Três motivos documentados. Primeiro, per-page mprotect + per-fault GPU stall + compute dispatch + scheduler wait tem custo real: em NVIDIA warm path é tolerável, em AMD derruba pra menos de 12 FPS, issue aberta a respeito. Segundo, Bloodborne trava em loading screens com Precise ligado. Terceiro, o maintainer escondeu a opção atrás de “Advanced” no UI justamente pra evitar que usuário de hardware sensível habilite sem saber. O modo existe desde v0.15.0 (setembro/2025), mas ninguém tinha publicamente conectado Precise + DriveClub + feedback loop de auto-exposure. O compat tracker já admite que DriveClub “requires readbacks enabled to function properly”, mas não especifica o modo.

No meu setup o custo de performance é irrelevante. Tenho uma RTX 5090 no desktop, hardware de sobra pra bancar o mprotect, o page fault, o copy e o stall por frame. A decisão é trivial: ligo Precise, pago o preço, o jogo roda. Num hardware mais modesto ou numa AMD a conversa é outra, e é exatamente por isso que o setting não é default e fica atrás do “Advanced”.

Importante deixar claro uma coisa: essa explicação toda acima, sobre Precise vs Relaxed vs Disabled, feedback loop GPU→CPU, mprotect syscall por página, não é conhecimento que eu tinha domingo à noite. Eu não sabia o que era um buffer readback, não sabia que Driveclub implementava auto-exposure como feedback loop GPU→CPU, não sabia que readbacks_mode virou um enum em 2025 com três valores. Pra chegar na resposta certa, precisei aprender cada peça do zero. Não dava pra chutar. Se eu tivesse tentado “ligar readbacks” semana passada sem entender a cadeia, teria pegado o valor errado (Relaxed não basta pra esse feedback loop, explico isso mais pra frente) e desistido achando que “não funciona”.

E mais duas coisas precisam estar no lugar pra isso funcionar, que já cobri no artigo anterior:

• v1.28 patch aplicado em cima da install base de v1.00 (sem isso, o conteúdo fica locked com “não lançado ainda”).
• Patch XML de 60fps desabilitado (render rate subiu mas logic tickrate é fixo; com ele ligado, o jogo roda em câmera lenta).

O resultado

Mesma corrida no Canadá, noturna, com readbacks_mode: 2 ligado. Race start abre brilhante, auto-exposure converge imediatamente, a transição pra noite acontece de forma natural conforme o TOD (time of day) do jogo avança. Sem blackout, sem “recalibração” aos 1:30, sem janela de 30 segundos de preto absoluto. Isso é Driveclub rodando como no PS4.

Agora a pergunta interessante não é “qual o setting”. É: como a gente chegou aqui?

Como um junior aprende hoje?

Tem uma pergunta que eu ouço com frequência: “com a IA fazendo tudo, como um junior aprende?”

A premissa dessa pergunta tá errada. A IA não faz tudo. A IA faz o que você pede. Ela não descobre por conta própria. Ela não tem iniciativa de domínio. Ela não é capaz de dizer “olha, isso aqui parece um feedback loop quebrado em GPU→CPU readback” se você não souber pelo menos que existe uma coisa chamada readback, e que feedback loops quebrados são uma classe de bug.

Pior ainda: se você for num agente de IA hoje e pedir “conserta essa tela preta no Driveclub no shadPS4”, ele vai te entregar uma lista de respostas possíveis baseada em fóruns antigos, com probabilidade alta de te mandar no caminho errado. Ele vai sugerir patch XML de 60fps (errado, causa slow-motion). Vai sugerir tonemap override (errado, o jogo já escreve SDR correto). Vai sugerir vblank_frequency tweak (inútil pro problema real). Vai sugerir gamma manual (trata o sintoma, não a causa).

O caminho pra descobrir é mergulhar na cadeia, fase por fase, descartando hipóteses erradas até o terreno ficar suficientemente conhecido pra você reconhecer a resposta certa quando ela aparece.

E é aí que muita gente se confunde comigo. “O Akita já é senior, ele tem 25+ anos de experiência, claro que ele sabe.” Falso. Profissional senior é alguém que já foi junior em cada tópico que domina. E continua virando junior toda vez que pega um domínio novo. Eu tenho 25 anos de programação web, sistemas distribuídos, Ruby, Erlang, Go. Mas eu nunca programei pra PS4. Nunca tinha olhado o codebase do shadPS4. Não conhecia a arquitetura gráfica do PS4. Domingo eu era um absoluto junior nesse domínio.

Junior não é o mesmo que totalmente cru. Em anos anteriores eu já tinha explorado no meu canal a arquitetura low-level de consoles antigos (do 6502 do NES pra cima) e como emuladores funcionam internamente em geral. Os dois vídeos abaixo ajudaram a construir o vocabulário básico de como videogame funciona por dentro, e garantiram que eu não ia tropeçar em conceitos tipo fetch-decode-execute, opcode, interrupt, ou HLE vs LLE.

Eu também já tinha feito outro vídeo, mais antigo, sobre a evolução de CPUs, GPUs, DirectX e Vulkan, então pelo menos o vocabulário de “pipeline gráfico moderno” e “shading language” não era estranho pra mim.

Saber que existe VkCommandBuffer é bem diferente de saber onde no shadPS4 um vkCmdCopyBuffer de readback dispara. Mas dá uma base. Esse tipo de curiosidade antiga rendeu juros agora.

O rodízio: Claude Code e Codex

A IA (no meu caso o Claude Code) não “sabia” mais que eu. Ela tem o mesmo texto de fórum datado que você achou no Reddit. O que ela fazia bem era agregar: ler o código do shadPS4 em paralelo comigo, indexar os comentários, cruzar referências entre phase docs, compilar, rodar probes, parsear logs de 61 MB, comparar binário decompilado com o diff de UBO, jogar luz em cantos do sistema mais rápido do que eu sozinho conseguiria.

Mas a decisão de “continuar investigando” era minha. A perseverança de “não aceita uma mitigação, quer a causa-raiz” era minha. E quando a IA sugeria “honestly, we should just accept the current result and document it” (e ela sugeriu várias vezes ao longo dos quatro dias), eu era o que tinha que dizer “não, continuamos”.

O ponto central do rodízio: nenhum LLM sozinho conseguiu fechar esse problema.

Ao longo dos quatro dias, várias vezes o Claude Code entrou em loop, repetindo as mesmas hipóteses sem rumo novo. Quando isso acontecia, eu trocava pro Codex por algumas horas pra trazer ideias de fora, probes diferentes, releitura do codebase por ângulo novo. Depois voltava pro Claude Code pra integrar o que o Codex tinha levantado. E assim por diante, alternando.

A resolução final aconteceu no Claude Code, mas a jornada trocou de modelo várias vezes. Cada LLM tinha seus viéses e seus pontos cegos. Deixado sozinho, cada um teria desistido antes.

O que rompeu o impasse foi eu continuar trazendo novas ideias pra tentar, forçando o modelo a reavaliar, trocando quando um deles começava a repetir.

Em dois momentos a coisa foi além de “só repetir hipóteses”. O Codex literalmente teve um glitch em loop agêntico: começou a repetir a mesma “solução” que tinha acabado de tentar, de novo e de novo, em sequência, sem perceber o que estava fazendo. Foi a primeira vez que eu vi isso acontecer em qualquer agente de IA. Tive que matar a sessão e começar uma nova do zero pra quebrar o ciclo.

Isso diz muito sobre o tamanho de contexto e a duração da sessão. A complexidade e o ritmo dessa investigação foi suficiente pra derrubar os dois LLMs, cada um do seu jeito.

Toda a jornada abaixo está documentada em 33 phase docs no branch gamma-debug do meu fork do shadPS4. Cada seção aqui linka pro doc original pra quem quiser o detalhe completo. Aqui eu resumo o essencial: a hipótese que tínhamos, o que tentamos, o que aprendemos de novo, e por que essa fase não fechou o caso.

Sessão zero: baseline e reprodutibilidade

Toda investigação séria começa antes da Fase 1. A primeira coisa, pra qualquer projeto, é garantir que o baseline funciona como esperado e que a situação que você quer pesquisar é reproduzível toda vez. Se você não consegue reproduzir o bug por comando, tá caçando fantasma. Cada probe depois vai ser inconclusivo porque o bug “apareceu e sumiu” sem controle. E se o baseline tá quebrado de algum jeito que você nem percebeu, cada experimento mede o problema errado. Sem essas duas garantias, não tem como progredir.

No meu caso, domingo à noite confirmei:

• O jogo boota até a tela de corrida sem crash, usando a config da distrobox-gaming.
• DriveClubFS extrai v1.28 limpo, 8018 arquivos, ~47 GB.
• MSAA depth resolve aplicado no fork, pistas noturnas renderizam forma em vez de uniforme preto absoluto (isso está coberto no artigo anterior).
• Controle 8BitDo detectado.
• Corrida noturna na Índia 19:30 reproduz o blackout em 100% das tentativas, no mesmo padrão temporal: fade progressivo nos primeiros ~15s, pitch black entre ~20s e ~90s, “recalibração” aos 1:30.

Esse baseline é a única base sólida que me permite comparar cada experimento de forma confiável. Sem ele, um probe que “funcionou” pode ser só um cache diferente, não o fix real. Com ele, cada mudança tem um antes e um depois que são mensuráveis.

Fora isso, zero conhecimento específico de:

• Formato de PKG do PS4 (PFS, param.sfo, disc_info, keystone).
• Codebase do shadPS4 (src/core, src/video_core, shader_recompiler, buffer_cache).
• Pipeline gráfico do PS4 (GCN ISA, forward+ lighting, MSAA depth resolve).
• Vulkan além do superficial (descriptor sets, UBO binding, push constants, pipeline cache).
• SPIR-V disassembly e patching.
• PS4 OELF loader, Itanium RTTI, SCE dynamic relocations.
• mprotect-based page-fault tracking pra CPU-GPU synchronization.

A jornada em fases

Vou organizar as 30+ fases em grupos que fazem sentido como narrativa. Cada fase linka pro doc completo pra quem quiser o detalhe técnico.

Nota pra quem não quiser ler todas as 30+ fases: depois da sequência de fases tem seções de reflexão e metodologia que dá pra ler direto. A técnica do shotgun explica a metodologia de depuração que usei ao longo da investigação. O que eu sabia domingo vs quinta resume o que aprendi de fato. A IA sugeria aceitar. A perseverança humana foi minha discute o papel real da IA nesse processo. Custo real dessa jornada cataloga o que foi gerado. Se quiser pular direto pro argumento, esses são os atalhos.

Fase 01: pipeline cache, o warm-up

phase-01-shader-compile-stalls.md

• Hipótese: menus rodam a 2-3 fps no primeiro launch, deve ser compilação de pipelines Vulkan acontecendo em tempo real.
• Ação: ligar pipeline_cache_enabled: true no config global.
• Conceito novo: cache de pipelines Vulkan. Quando o emulador traduz um shader GCN do PS4 pra SPIR-V e depois em binário Vulkan específico do driver, ele pode cachear esse binário. Sem cache, recompila cada cold launch (~864 shaders + ~590 pipelines).
• Resultado: resolvido. Primeira sessão paga o custo; sessões seguintes leem do disk e sobem imediatas. Fácil. Também foi minha primeira lição sobre o codebase do shadPS4.

Fase 02: gamma dim, começando pela direção errada

phase-02-gamma-dim-image.md

• Hipótese: imagem do Driveclub tá dim comparada com referência. Deve ser sRGB encode errado, ou HDR tonemap mal aplicado pelo emulador.
• Ação: instrumentei a swapchain pra logar formato; adicionei env var SHADPS4_PP_* pra experimentar; montei pipeline de pós-processamento com três knobs (exposure, ACES tonemap, gamma curve).
• Conceito novo: sRGB OETF, HDR tonemap (ACES vs Reinhard), Bayer dither como anti-banding.
• Resultado: descobri via bypass path (SHADPS4_PP_BYPASS=1, escreve raw game output sem nenhum pós-processamento) que o jogo escreve SDR já correto no framebuffer. O pipeline de pós-processamento do emulador é que estava estragando o sinal. Shader final virou simplesmente sRGB encode + Bayer dither. Dim persiste, mas não é culpa de gamma.

Três horas nessa fase. A lição mais importante é: quando “a imagem tá estranha”, o primeiro diagnóstico deveria ser um bypass path que mostra o raw game output. Se bypass tá certo, o emulador tá estragando o sinal. Pare de mexer no tonemap.

Fase 03: v1.28 content access

phase-03-v128-content-access.md

• Hipótese: v1.28 extrai, mas o jogo diz “content not released yet, download required”.
• Ação: merge v1.28 em cima de v1.00, restaurar param.sfo, disc_info.dat, keystone.
• Conceito novo: PS4 cumulative patches, metadata do package.
• Resultado: resolvido. Detalhado no artigo anterior.

Fase 04: MSAA depth + slow-motion

phase-04-slowness.md

• Hipótese: pistas à noite pitch black e o jogo “parece lento”.
• Ação: duas coisas separadas. Desabilitar patch XML de 60fps (que tava descolando render rate do logic tickrate). Implementar ReinterpretMsDepthAsColor no meu fork (pra permitir que o emulador resolva depth MSAA 4x pra color 1-sample, que o Driveclub precisa pro forward+ lighting nas pistas noturnas).
• Conceito novo: forward+ lighting (renderer que escreve cena em MSAA depth target e depois lê como color pra SSAO e volumetrics), MSAA depth resolve.
• Resultado: dois problemas resolvidos. Detalhado no artigo anterior.

Fase 05: second pass no brilho

phase-05-brightness-followup.md

• Hipótese: já que o game escreve SDR correto, talvez um boost estático no pós-processamento ajude sem mexer em UBO feedback.
• Ação: testei linear boost (1.5x, 2.0x), gamma pre-encode (pow curve), auto-exposure cena-aware com peak+mean sampling.
• Resultado: tudo rollback. Linear boost clipa luz. Gamma introduz banding. Auto-exposure da minha camada cancela o slider manual do usuário. Não tem almoço grátis no pós-processamento. Imagem dim fica dim sem HDR real ou patch de shader.

Narrowing the blackout: o gate compartilhado

race-start-blackout-040420.md

• Hipótese: o blackout tem uma assinatura curiosa: main view vai pra dim/preto, retrovisor vai pra preto absoluto, HUD permanece brilhante. Três camadas com comportamentos diferentes sugerem um “gate” compartilhado, não um fade comum.
• Ação: instrumentei texture-cache aliasing, probes com live fragment shader substitution nos inputs suspeitos.
• Conceito novo: texture-cache aliasing (várias imagens com mesmo endereço de memória, cache do emulador reusa), render-target lifetime.
• Resultado: aponta pra “permissão de apresentação” compartilhada entre main scene e retrovisor, não um fade narrativo.

Fases 07-09: tortura de texturas, cirurgia de UI, plano de binary patch

phase-07-aggressive-torture-probe.md · phase-08-ui-asset-surgery.md · phase-09-eboot-binary-patch-plan.md

• Hipótese: o overlay dim do race start é um asset. Textura pequena, panel da UI, ou método do controller FreeplayGetInCar no eboot.
• Ação: null-substituir materiais BC comprimidos, textures pequenas candidatas, four-vector weight masks durante draws críticos. Desabilitar painéis da UI (loading_freeplay.txt, get_in_car_animation.txt, vehicle_select_background). Extrair o OELF, localizar strings ASCII FreeplayGetInCar, identificar construtor em VA 0xf89b00 e vtable em 0x15dc3e0.
• Conceito novo: PS4 OELF loader (variant do ELF da Sony), Itanium C++ RTTI (como C++ encoda type info em vtables), SCE dynamic relocations (placeholders que só o loader dinâmico resolve em runtime).
• Resultado: nulls funcionam mas o fade persiste. O overlay renderiza direto nos HDR scene targets, não via panel system. Binary patch tem placeholder de relocation que não é resolvível estaticamente sem um Ghidra com PS4 plugin. Asset-side surface exhausted. Seis horas depurando, final conclusion: o bug vive em state, não em asset.

Fase 10: rethink + animlib

phase-10a-rethink-040422.md · phase-10b-video-diagnostic-animlib.md

Terça-feira de manhã. Sentei, reiniciei mentalmente. Modelo novo: o blackout é um state-machine gate. Não é “cena não pronta”, é “permission transition”. O gate fecha depois da grid de largada aparecer. Próximo probe: runtime dispatch trace, chega de blind asset surgery.

Em paralelo: extração de frame da gravação de vídeo a 10 Hz, cruzamento com keyframes de animation library (animlib) em india_posteffects.lvl. Encontramos smoking gun. Track MasterBrightness com keyframe 0.003 e 0.0007 (0.63% brightness), quando o default seria 1.0. Animlib vence inline defaults todo frame.

• Conceito novo: animation library, keyframe encoding, float-scanning de binário.

Vídeo acima: o processo de probar pelo fade em real time.

Fase 11: multi-scalar patch

phase-11-multi-scalar-patch.md

• Hipótese: patchar MasterBrightness + AutoTargetLuminance + ManualAutoMix simultaneamente vai lift o blackout.
• Ação: estendi PatchAnimlibFloatValues pra reescrever três scalars. Instrumentei com SHADPS4_DC_DRAWLOG + SHADPS4_DC_UBOLOG.
• Resultado: patch produz um lift numérico real (1.2 → 6.5 em 255, um 5×), mas ainda é sub-perceptual black. E descobri o achado crucial: o mirror funciona normalmente após o patch. Não está gated, apenas refletindo uma cena escura. Pelo menos 285× de atenuação adicional vive downstream dos scalars que a gente pode patchar.

Fase 12: bisect fechando o asset-side

phase-12-bisect-closes-asset-side.md

• Hipótese: um dos 60 patches acumulados quebrou o mirror independente do blackout. Bisect.
• Ação: binary bisect em 60 overlay files ao longo de 5 rounds.
• Resultado: x_live_lobby_pre_race.txt (reroute de loading-spinner transition de ZoomInAndFade pra NoFade) era o mirror killer. Rollback. Asset-side completamente fechado. O driver vive em código compilado ou em post-process state, não em asset de jogo.

Asset sweeps 01-09 (consolidado)

asset-sweep-09-conclusions.md

Em paralelo com as fases acima, varri 12 RPK substitutions: page swaps de FreeplayGetInCar, mexidas no postfx de india_landscape_gui.rpk, edits em globaldata RTT-only, rewrites de prerace state strings. Todos clean misses. Nenhuma família de asset toca o blackout. Lição: pare de chasing by names; chase por state transitions.

Fase 13: UBO dump breakthrough

phase-13-ubo-dump-breakthrough.md

• Hipótese: loop de feedback de eye-adaptation com input stale é o culpado. Um scalar de luminância crescendo sem convergir.
• Ação: dump de 128 bytes de UBO em hex durante a race window, em seis pipelines hand-picked. Procurar valores monotonicamente em mudança.
• Conceito novo: UBO (Uniform Buffer Object), região de memória compartilhada que o CPU escreve e shaders leem. Auto-exposure integrator, componente clássico de eye adaptation que tira tempo pra convergir em direção a um target.
• Resultado: encontrei. Offset 3 do UBO sobe monotonicamente de 2.59 → 7.84 → 24 → 90 → 179 → 255 em 2 segundos. Textbook feedback loop com input quebrado. Primeiro hit real em 12 fases.

Fase 14: scene-pipeline UBOs são o read-side

phase-14-scene-pipeline-ubos-wrong.md

• Hipótese: clampar o scalar que tá subindo vai parar o blackout.
• Ação: SHADPS4_DC_LUM_CLAMP=2.0 força offset 3 a um valor fixo durante race window.
• Resultado: clamp dispara 1093 vezes, blackout inalterado. Scene-pipeline UBOs consomem o dim, não produzem. Dim tá upstream, em um tonemap ou post-fx compute fullscreen.

Fases 15-16: runtime texture dump + mutation

phase-15-runtime-texture-dump.md · phase-16-runtime-texture-mutation.md

• Hipótese: o blackout é uma textura fullscreen composta sobre a cena.
• Ação: SHADPS4_DC_TEX_DUMP=1 dumpa todas as texturas bound durante race window (1079 texturas capturadas). Converter tiled-format pra PNG pra triagem visual. Depois, mutar deterministicamente cada textura via hash-based tint + InvalidateMemory pra forçar re-upload.
• Conceito novo: GCN tile format (Sony interleava bytes de forma específica pra cache locality), texture de-swizzle, buffer cache invalidation.
• Resultado: 14 rounds de mutação (BC textures, float data, render targets, UI atlases, post-fx buffers, LUTs). Blackout inalterado em todos. Texture content 100% descartado como source.

Fases 17-19: UBO smashing, push-constant smashing, compute dispatch probe

phase-17-ubo-batch-smashing.md · phase-18-push-constant-smashing.md · phase-19-compute-dispatch-probe.md

• Hipótese: random-fill em UBOs, push constants e compute input buffers pode bracket and isolate o field do dim sem crashar.
• Ação: SHADPS4_DC_UBO_SMASH=1, SHADPS4_DC_PC_SMASH=1, SHADPS4_DC_DISPATCH_SMASH=1 com filtros de cb-index e size.
• Conceito novo: push constants (128 bytes de param rápido que o driver empurra direto pro pipeline, sem descriptor), compute dispatches (dispara compute shaders com uma grid de threads), ud_regs (user data registers do GCN, como shadPS4 mapeia user-data pra push-constants).
• Resultado: brackets seguros geram overlay bokeh + blinks, mas dim inalterado. Brackets wide o suficiente pra pegar o dim também pegam matrices/transforms e crasham. Random-fill é instrumento errado. Precisa de diff methodology.

Fase 19b-c: dim-vs-lift dispatch diff

phase-19b-dim-vs-lift-diff.md · phase-19c-dispatch-draw-skip-null.md

• Hipótese: compute dispatches que firam só durante dim (e param depois do lift) fazem parte do chain.
• Ação: dividir log limpo em pre / dim / bright windows (via user wall-clock), contar dispatch frequency por pipeline.
• Resultado: identificamos 8 compute pipelines (histogram 256→downsamples, tile-grid reductions, auto-exposure 1x1 scalars) que param exatamente quando dim lifts. Shapes fortemente sugerem eye-adaptation chain. First genuine diagnostic hit. Skip test dessas 8 + 101 draws correlacionados: blackout inalterado. Elas são downstream effects, não drivers.

Fase 20-21: tonemap inline, fragment → flip buffer

phase-20-shader-dump-tonemap-inline.md · phase-21-fragment-to-flip-buffer.md

• Hipótese: o auto-exposure compute shader tá quebrado, ou o tonemap compute tá com a matemática errada.
• Ação: recompilar todos os shaders, dumpar SPIR-V, desmontar o histogram auto-exposure. Patchar a saída dele pra constante 1.0 e testar.
• Conceito novo: SPIR-V disassembly (formato intermediário do Khronos, tem assembly legível). Verificação de shader compute. Depois, pipeline-to-shader mapping.
• Resultado: patch sem efeito. Descoberta: Driveclub não tem tonemap pass separada. Scene geometry escreve direto no flip buffer, com exposure inline nos material shaders. Cada material shader bake o scalar de dim de um UBO compartilhado. Pipeline cache wipe + SHADPS4_DC_PIPEMAP=1 dumpa todos os pipeline→shader mappings. Filtrar drawlog por pipelines que escrevem em 0x5000900000 / 0x5000108000 (os swapchain buffers de verdade) resulta em 14 pipelines únicos. Zero com Exp2/Log2 tonemap ops. Exposure é aplicada upstream.

Fase 22: tonemap compute identified

phase-22-tonemap-compute-identified.md

• Hipótese: entre os 510 compute shaders do jogo, um deles tem assinatura de tonemap (muitos Exp2/Log2).
• Ação: scan automatizado, cross-reference com dispatchlog.
• Resultado: cs_0x2c918c06 é o candidato forte, com 8 Exp2 + 8 Log2, 5 SSBOs (scene params, TAA, bloom, camera, exposure), 11 images. Skip test pra esse pipeline específico: para o blackout cycle, remove color grading, introduz temporal ghosting. Esse é o caminho final scene→swapchain pra tonemap.

Fase 22+: tonemap patches → playable

phase-22plus-tonemap-compute-patches.md

• Hipótese: dois SPIR-V surgical edits (histogram no-op + tonemap exposure clamp/boost) deixam o jogo jogável.
• Ação: patch de histogram pra nunca atualizar; patch de tonemap pra clampar exposure floor em 0.5 e boost blend por ×10. Ambos via SPIR-V patching + shader/patch/ drop-in.
• Resultado: playable! Dim reduz de pitch black pra mild. É uma mitigação real, não fix de causa-raiz. A fade curve ainda arrasta a exposição, e cada pista precisa de tuning per-threshold.

Aqui a IA sugeriu parar pela primeira vez. “O jogo tá playable, isso é uma mitigação decente, deveríamos documentar e aceitar.” Eu pressionei: “tá playable mas tá errado. Não aceita. Continuamos.”

Fase 23: CPU-side exposure intercept

phase-23-cpu-exposure-intercept.md

• Hipótese: clampar o exposure scalar no momento do BindBuffers da tonemap compute previne o over-dimming.
• Ação: SHADPS4_DC_EXPOSURE_PIN=1 intercepta BindBuffers, sobrescreve exposure offsets com clamp-min threshold, invalidate buffer_cache.
• Conceito novo: CPU-GPU buffer binding (momento em que o CPU entrega descriptor pro GPU). Buffer cache invalidation (como o emulator mantém consistency entre o estado CPU-side e GPU-side de um buffer).
• Resultado: scalar oscila no race start, depois sobe monotonicamente. Per-track tuning necessário. A Índia quer 3.0, o Canadá blows out no mesmo threshold. Solução de scalar único não converge cross-track.

Fase 24: dim upstream of tonemap

phase-24-dim-upstream-of-tonemap.md

• Conclusão: depois de toda a cadeia de probes (identity tonemap, exposure pin, compute skip), o dim está no HDR target antes do tonemap ler. Três upstream suspects: (1) atmospheric scattering / volumetric fog, (2) reflection-probe / envmap update, (3) pre-tonemap exposure apply.
• Conceito novo: atmospheric scattering (simulação de como luz viaja pela atmosfera, tipo Rayleigh/Mie), volumetric fog (neblina renderizada como froxel volume).
• Resultado: plano definido. Frame-order dump, andar pra trás da tonemap pela cadeia toda.

Fase 25: frame-order trace

phase-25-frameorder-trace.md

• Ação: SHADPS4_DC_FRAMEORDER=<N> loga strict per-submit pipeline/shader chain sobre N submits durante race window.
• Conceito novo: frame-order reconstruction (listar toda submission ao GPU em ordem exata), froxel volumetrics (volume frustum voxels, malha 3D alinhada ao frustum da câmera pra armazenar info de luz).
• Resultado: três suspeitos: (A) half-res compute (60,34,1), provavelmente SSAO; (B) dispatches progressive (256,1,1)→(2560,1,1)→(10240,1,1), froxel volumetric; (C) draw fullscreen apply-fog-to-HDR. Suspeito B é o mais forte (sunset best-fit, per-pixel non-uniform dim).

Fase 26: O UBO fade pin, o “aha moment”

phase-26-ubo-fade-pin.md

Aqui mudou tudo.

• Hipótese: memory diff direto (bright vs dim vs recovered) identifica os bytes exatos que o jogo escreve pra controlar o blackout.
• Ação: capturar snapshots periódicos de UBO através das transições visuais. Diffar três snapshots byte por byte. Procurar fade signatures.
• Conceito novo: state diff methodology. Ao invés de “qual passagem parece suspeita?”, perguntar “quais bytes realmente mudam com o estado visual?”
• Resultado: breakthrough. Dois UBOs controlam o fade: um de 1936 bytes com slots [38/48/50] (light intensity) sendo multiplicados por 0.094 (fade factor), e um sun UBO de 224 bytes com slot [50] caindo 97%. Pinar os dois: race start abre brilhante. TOD animation intacta. Content-aware three-state lifecycle (idle → engaged → expired).

Quarta-feira à noite. Claude sugere parar de novo. “Temos pin funcionando, three-state lifecycle robusto, Canadá + Munnar rodando. Isso é upstream-quality, deveríamos PR-ar e fechar.” Eu insisto: “ainda tem dim residual em outras pistas, não tá fechado. Continuamos.”

Fase 28: pivot pra emulator code

phase-28-pivot-to-emulator-code.md

• Realização: o dim residual no Canadá ao anoitecer não é um valor errado de UBO. É uma translation gap do emulador. O jogo roda correto no PS4 real, então shadPS4 tem algum caminho que traduz ou sincroniza errado.
• Ação: 5 candidatos de bug emulator ranqueados — HLE shader misidentification, image storage classification, layout transitions, IMAGE_STORE_MIP fallback, OpImageFetch LOD restriction.
• Conceito novo: HLE (High-Level Emulation). Substituir funções complexas do sistema operacional do PS4 por implementações host-side. Diferente de LLE (low-level) que emula bit a bit. HLE é mais rápido mas pode divergir do comportamento real quando a implementação host não cobre todos os casos.

Fase 29: calibrated state + recording harness

phase-29-calibrated-state.md

• Ação: SHADPS4_DC_RECORD=1. Recording harness que dumpa lighting UBOs periodicamente + cross-correlation com screenshots wall-clock.
• Resultado: descoberta importante. Slots [144..295] do UBO de 1936 bytes (30+ fields) ficam denormal/uninitialized pelos primeiros ~90 segundos de corrida. Na “auto-recalibração” dos 1:30, o jogo escreve os valores reais. Não é recovery mágico, é a CPU finalmente escrevendo os valores que já deveriam estar lá desde o frame 1. No PS4 estão prontos antes do primeiro frame; no shadPS4 atrasam 90s. Root cause vive num init gap do emulador.

Fase 30: UBO writer audit

phase-30-ubo-writer-audit.md

• Ação: auditoria exaustiva de todos os caminhos que escrevem no slot [38] do UBO de 1936 bytes. 7 suspeitos ranqueados: (1) ObtainBuffer stream-copy race, (2) lazy RegionManager em memory_tracker, (3) histogram compute skip, (4) page-fault delayed invalidation, (5) readback gating, (6) buffer-coherency race, (7) push-constant.
• Status: auditoria incompleta. Antes de conseguir verificar cada suspeito, a Fase 31 curto-circuitou tudo.

Fase 31: readbacks_mode = Precise, a virada

phase-31-readbacks-mode-fix.md

Quinta-feira de manhã. Cansado, pensando na suspeita #5, readback gating. Essa me coçava porque era a única dos 7 writers que tocava timing do read e não correctness do write.

• Hipótese: ligar readbacks_mode: 2 (Precise) no config per-game faz o feedback loop funcionar sincronizando read do CPU a fresh GPU output.
• Ação: uma edit no custom_configs/CUSA00003.json. Boot. Corrida no Canadá à noite.
• Resultado: race start abre brilhante. Auto-exposure converge normalmente. Zero blackout. Zero recalibração aos 1:30. Night TOD natural.

Testes em Munnar. Mesmo resultado. Um inteiro. 31 fases. 44 commits. 15.668 linhas. Resposta: um inteiro no config.

Por que isso passou batido por 30 fases? O doc da Fase 31 tem a análise honesta:

1. Disfarce de sintoma. Progressive darkening parece exatamente com tonemap quebrado, shader ruim, ou scalar de exposure compilado errado. Toda probe dump-driven achou valores errados no UBO, que é verdade, mas descreve o downstream read, não o upstream gap.
2. Red herring do readback_linear_images. Testei essa flag na Fase 29 e deu zero efeito, então concluí que “a superfície de readback tá auditada”. Esqueci que essa flag é pra image readbacks (linear images via TextureCache::DownloadImageMemory). O histogram SSBO é um buffer, caminho separado.
3. Pinning piorando em vez de melhorar. Sobrescrever os slots [38/48/50] parecia prometer, mas nunca convergia. O jogo reescrevia em cima do pin a cada frame. Interpretei como “o mecanismo de pin chega tarde demais no pipeline”. Gastei as fases 27-29 movendo o pin pra mais cedo. O fix real era parar de clobber o GPU-side input que o integrator lê.
4. Nunca auditei o caminho do readback de buffer. A auditoria da Fase 30 listou 7 candidatos de writer, mas todos eram sobre a correctness do write. Nenhum perguntou “o que a CPU está lendo, esperando que o GPU tenha preenchido?”

A técnica do shotgun

Tem uma coisa que eu quero registrar: os probes de tortura não são desperdício, são infraestrutura de aprendizado. E a metodologia por trás deles tem nome: shotgun.

Se você tem uma suspeita, tipo “o dim vem de alguma textura”, a pior coisa que você pode fazer é começar investigando uma textura por vez, em profundidade. Driveclub tem 1079 texturas bound durante a race window. Se cada triagem detalhada leva 20 minutos, você gasta três dias num galho só dessa árvore, e ainda não sabe se o dim vem de textura. Pode até ser que a resposta não esteja na árvore inteira.

Shotgun resolve isso. Em vez de investigar uma por vez, você dispara em todas ao mesmo tempo. Muta cada textura bound com um tint hash-based, força re-upload, roda o jogo. Em 30 segundos você sabe se alguma delas afeta o dim. Se afeta, então o dim é texture-side e aí sim vale a pena começar a narrow down. Se não afeta, parabéns: você acabou de descartar a categoria “textura” inteira em 30 segundos. Muda de categoria, shotgun em UBOs. Nenhum hit? Shotgun em push constants. Nenhum hit? Shotgun em compute dispatches. Continua até algo reagir.

Não comece tentando estreitar uma árvore que pode ser enorme. Você vai gastar semanas em folhas irrelevantes. Dê um tiro de shotgun no tronco primeiro. Veja qual galho reage. Aí sim, desce em detalhe dentro desse galho.

Foi isso que eu fiz, sem saber que estava fazendo, pelas 30 primeiras fases. 32 variáveis de ambiente de probe (SHADPS4_DC_UBO_SMASH, SHADPS4_DC_PC_SMASH, SHADPS4_DC_DISPATCH_SMASH, SHADPS4_DC_TEX_NUKE_*, SHADPS4_DC_UBO_NUKE, e mais). Batches randômicos, tints hash-based, substituições null. A maioria nunca apontou pro fix real. Mas cada rodada de shotgun descartou uma categoria inteira de modelo mental. “Não é textura.” “Não é push-constant.” “Não são esses 8 compute pipelines.” “Não é UBO write-side em qualquer lugar dessa região.” Cada descarte estreita o problema.

E enquanto eu fazia isso, eu aprendia o sistema. Cada smash que crashava me dizia “aqui vive um descriptor pointer crítico”. Cada color tint que aparecia me dizia “esse UBO alimenta essa passagem de composição”. Cada dispatch que fira diferente entre dim/bright me mostrava onde está a fronteira interessante.

Quando você não conhece o sistema, shotgun probes são um mapa. Você não usa eles pra encontrar a resposta. Você usa pra descobrir o terreno.

O que eu sabia domingo vs quinta

Domingo: zero em tudo. Todas as áreas abaixo eram caixas pretas pra mim.

Quinta:

• PS4 package format end-to-end (PKG → PFS → param.sfo → disc_info → keystone → npbind). Como v1.28 cumulative patches funcionam em cima de v1.00 base install.
• Arquitetura do shadPS4 em resumo: src/common, src/core (OS emulation, libraries HLE), src/shader_recompiler (GCN→SPIR-V), src/video_core (Vulkan renderer, buffer cache, texture cache, page manager).
• Pipeline gráfico completo: G-buffer → forward+ lighting (escreve MSAA depth) → read depth como color pra SSAO / volumetric froxel → post-fx compute → tonemap → composite → swapchain.
• UBO vs push constant vs descriptor set. Quando usar cada um.
• SPIR-V disassembly e re-assembly pra patching cirúrgico. Como identificar tonemap compute por assinatura de Exp2/Log2.
• Forward+ lighting + MSAA depth resolve + como implementar ReinterpretMsDepthAsColor.
• Buffer cache do shadPS4: MemoryTracker, RegionManager, FaultManager. Como page-fault vira GPU→CPU sync.
• readbacks_mode: Disabled / Relaxed / Precise. Qual tradeoff de cada. Por que Relaxed não basta pra feedback loops (ele só write-protect, não read-protect).
• PS4 OELF → Itanium RTTI → SCE relocation → dynamic linker reasoning, mesmo sem ter feito o binary patch (o plano ficou documentado).

Não virei expert em nada disso. Mas virei de total outsider pra operador razoavelmente orientado. E esse salto, como eu comento depois, foi a coisa mais valiosa dos 4 dias.

A IA sugeria aceitar. A perseverança humana foi minha

Eu disse algumas vezes ao longo do artigo que “Claude sugeriu parar”. Quero ser justo e específico aqui: não foi uma falha da IA. Foi exatamente o comportamento correto de uma ferramenta inteligente: quando você tem algo que funciona razoavelmente bem, parar e documentar é frequentemente a escolha certa. O patch de tonemap na Fase 22+ fez o jogo playable. O pin de UBO na Fase 26 fez a imagem ficar bonita. O recording harness da Fase 29 cobriu a janela crítica. Todos eram pontos legítimos de parada.

Se você ler o codex-conclusion.md, documento que a IA produziu após a Fase 26 (ainda sem saber sobre a Fase 31), ela descreve a solução de então como “a mitigation, not a root-cause fix”. Admite honestamente o que sabíamos: o pin de UBO era um contra-ataque, não explicação. Esse é bom comportamento.

A diferença é que eu tinha um teimoso palpite de que algo ainda tava errado. Ela funcionava no sentido playable. Mas o custo (pin Driveclub-specific + patch SPIR-V de tonemap + per-track threshold tuning + não generalizar) era alto demais pra um fix supostamente de engineering-quality. Profissional senior reconhece quando a assimetria entre custo e entendimento aponta pra algo mais fundo. Não sempre acerta. Mas esse palpite merece ser escutado.

Quatro dias sem interrupção, das 8h à meia-noite, domingo, segunda, terça, quarta, e resolvido quinta de manhã. Quantas vezes a IA sugeriu “honestly, we should just accept the current result and document”? Umas 4 ou 5 vezes. Cada uma tecnicamente defensável. A perseverança humana é a diferença entre “o jogo funciona bem o bastante” e “o jogo funciona, e eu sei por quê”.

Custo real dessa jornada

O investigation-effort-accounting.md catalogue tudo antes da limpeza. Uns highlights:

• 3 dias de trabalho ativo (Apr 21-23, 2026).
• 33 phases numeradas + sweeps + side threads = 54 docs, 412 KB, 6.867 linhas de prosa.
• 44 commits no fork gamma-debug. 15.668 linhas adicionadas, 1.204 removidas.
• src/video_core/renderer_vulkan/vk_rasterizer.cpp cresceu de 1.364 pra 4.680 linhas (3.4×) com instrumentação, pin lifecycles, recording harness.
• 32 env vars de probe definidas. 1 efetivamente usada pra encontrar o bug (SHADPS4_DC_LOG_STREAMCOPY, na Fase 30).
• 61 MB de log shadPS4 acumulado. 57 MB de shader dumps (5.803 arquivos). ~470 MB totais de artifacts reclaimáveis depois de fechar.

Resolution: 1 inteiro no config.

A proporção 6.867 linhas de prosa : 1 inteiro me diverte. Mas ela não é uma piada de ineficiência. É o custo real de aprender um sistema que você não conhecia. Cada linha de prosa descartou uma hipótese. Cada commit ensinou uma camada do stack. O inteiro foi o fim; o caminho foi o produto.

Uma nota honesta: apesar das 15.668 linhas adicionadas no fork gamma-debug, quase nada disso presta pra contribuir upstream no shadPS4. O que está lá é instrumentação — torture probes, recording harness, pin lifecycles, calibrate-at-arm, snapshots de UBO, dezenas de env vars de debug. Código de diagnóstico, não código de produção. Diagnóstico que só faz sentido pro Driveclub naquelas condições específicas.

O fork vai ficar público, mas não como branch de contribuição pro projeto shadPS4. Infelizmente. Fica como documento de estudo: 54 arquivos md cobrindo o processo completo, 44 commits mostrando a sequência de hipóteses, descartes e falhas. É material pra quem quiser entender como foi o processo de depuração, ou pra reaproveitar algumas das técnicas em outras investigações similares. PR upstream-ready dali não sai.

Fechamento

Sim, a solução final era um toggle de config que já existia. Está no código do shadPS4 há sete meses. Mas domingo à noite, zero conhecimento de PS4, zero conhecimento do emulator, zero noção de que auto-exposure era um GPU→CPU feedback loop, eu não tinha autoridade técnica pra dizer “liga readbacks Precise, resolve”.

Eu tive que ver a cadeia toda pra entender por que funciona. Por que Relaxed não basta (só write-protects, e o DriveClub lê, não escreve no SSBO do histograma). Por que Precise é caro (per-page mprotect + per-fault GPU stall). Por que o maintainer escondeu atrás de “Advanced” (Bloodborne trava, AMD cai pra 12 FPS). Por que ninguém na comunidade tinha conectado Precise com DriveClub antes: o compat tracker admite “readbacks enabled”, mas não cita o modo, e ninguém tinha visto a assinatura de drift monotônico pelo ângulo do loop GPU→CPU.

Essa é a diferença entre conhecer a resposta e conhecer o terreno o suficiente pra reconhecer a resposta. Pra junior que me pergunta “como eu aprendo hoje na era da IA”: essa é a minha resposta. Não pergunte. Mergulhe. Use a IA pra acelerar a busca, pra ler código em paralelo, pra indexar fóruns antigos, pra compilar, pra parsear logs. Mas insista em entender o porquê. Quando a IA sugerir “vamos aceitar e documentar” (e ela vai sugerir, porque esse comportamento é frequentemente correto), pergunte a si mesmo se você realmente entendeu a cadeia. Se ainda tiver a coceira de “isso tá errado mas eu não sei por quê”, continue.

Provavelmente você vai gastar 4 dias numa coisa que tem solução de um inteiro. Provavelmente você vai descobrir 5 caminhos errados antes do certo. Provavelmente a metade dos seus probes vão ser torture shotguns que nunca apontaram pro fix.

E provavelmente, quando terminar, você vai saber um domínio que você não conhecia.

• Fork gamma-debug: github.com/akitaonrails/shadPS4/tree/gamma-debug
• 54 docs da investigação: docs/driveclub-investigation/
• Operational runbook (recipe): distrobox-gaming/docs/driveclub-shadps4.md
• Resolução da Fase 31: readbacks_mode: 2

Agora eu vou jogar Driveclub. Corrida noturna no Canadá, brilho natural, sem blackout. Boa quinta-feira.

No topo dessa lista estão dois monstros. Primeiro, Driveclub no shadPS4. É exclusivo de PS4, nunca foi portado, a Evolution Studios foi fechada, não tem remaster. Pra jogar fora do PS4 original, só via emulação, e emulação de PS4 ainda é a parte mais imatura da ecossistema hoje. Esse é de longe o mais difícil da lista.

Segundo, Forza Motorsport 4 com Project Forza Plus no Xenia Canary. FM4 é o GOAT da era Xbox 360, Project Forza Plus é a mod comunitária que consolida patches e conteúdo, e fazer os dois rodarem juntos no Xenia com gráfico decente, sem crash de áudio e sem shadow bug, levou horas sérias de trial and error.

Em torno desses dois eu organizei o resto do que eu já sabia que funcionava em algum nível, só faltava consolidar num setup repetível: Gran Turismo 4 com Retexture 3.0 e HD HUD, Gran Turismo 3 com HD textures e widescreen, Gran Turismo 2 na mod Spec II, os Gran Turismos de PS3 (GT5 e GT6), os Forza Horizon 1 e 2, os PGRs, Ridge Racer, Enthusia, Colin McRae. Esses eu tinha ideia de como fazer, só precisava consolidar num setup que não volta a quebrar na próxima vez que eu reinstalar o sistema.

Antes de entrar no detalhe, preciso esclarecer duas coisas.

Primeiro, sobre a infra: não vou repetir aqui o como o setup foi montado. Já escrevi isso em detalhe no artigo Distrobox de Emulação com Claude Code. Arch Linux num distrobox com --nvidia, 17 roles Ansible, todos os emuladores no AUR, ES-DE como frontend, configs per-game automatizadas, scripts Python pra PS3 update check e Xbox 360 title updates, Xenia via Wine. Lê lá. O repo tá em akitaonrails/distrobox-gaming pra quem quiser reproduzir. Aqui eu vou falar dos jogos.

Segundo, sobre o gosto: eu gosto de simcade de corrida. Gran Turismo é meu vício declarado desde o PS1, e escrevi sobre o resto no artigo do meu cockpit Formula FX1. Volante direct drive, pedal com load cell, triple monitor quando tô afim de sofrer. Esse é o tipo de corrida que eu gosto.

O aviso pra quem já tá de dedo no teclado

Sim, eu conheço iRacing e os outros sims e simcades atuais. Eu tenho 12 TB de ISO e ROM no NAS, provavelmente tenho algum que você ia lembrar de citar. Não é por falta de opção que eu tô focando em emulação hoje.

Aliás, dos jogos novos que eu realmente tô esperando: Forza Horizon 6 em Tóquio, Assetto Corsa EVO e Assetto Corsa Rally. Tô jogando as demos dos dois Assetto Corsa e gostando muito das campanhas single-player. Quando eles saírem em versão final, vão virar meus jogos principais de sim na rotina. Esse artigo aqui cobre um lado diferente da coleção, que é tirar do esquecimento os clássicos que ainda não têm remaster.

Hoje, aqui, eu estou interessado nesses jogos específicos que listei acima. Ponto. Você faz o que você quer, eu faço o que eu quero. Se você quer iRacing, abra um Steam e vá em paz. Esse artigo é sobre mexer com emulador, preservar jogo velho, e tirar essas pérolas do esquecimento num setup Linux. Quem tá procurando review de sim atual não vai encontrar aqui.

Agora vamos ao que interessa.

Observação sobre os vídeos: a maioria tá sem áudio porque eu esqueci de ligar a captura de som no OBS antes de gravar e fiquei com preguiça de re-gravar. O áudio funciona perfeito em todos os emuladores aqui, é falha minha no OBS, não do setup.

Settings globais por emulador

Antes dos jogos, vale consolidar as configs globais que valem pra tudo em cada emulador. Isso tá automatizado no repo, mas se você tá configurando na mão, aqui tá o resumo.

DuckStation (PS1)

• Renderer: Vulkan
• Internal Resolution Scale: 8x (8K render, downscalado pro monitor)
• Texture Filtering: JINC2 (preserva pixel art mas suaviza)
• PGXP: ligado (corrige wobble de vértice típico do PS1)
• Widescreen Hack: ligado como fallback, mas preferência por cheat widescreen per-game
• Aspect Ratio: 16:9 com widescreen cheat, 4:3 sem

PS1 hoje em dia sobe liso no DuckStation. É o emulador mais maduro da lista. A atenção vai pras escolhas per-game (alguns jogos precisam de cheat específico de widescreen).

PCSX2 (PS2)

• Renderer: Vulkan
• Upscale: 4x SSAA (1440p nativo → 4K interno)
• Anisotropic Filtering: 16x
• Post Processing: FXAA ligado, PCRTC antiblur ligado
• Deinterlacing: Automatic (alguns jogos precisam override)
• Controller: bindings Xbox-style (eu uso controle 8BitDo)

PCSX2 2.7.x é muito superior ao 2.6.3 que ainda tá no repo oficial do Arch. O AUR pcsx2-latest-bin tracka o 2.7.x e é onde mora o texture replacement, FXAA moderno e PCRTC antiblur. Se você tá em distro diferente e tá no 2.6.3, procure o AppImage oficial.

RPCS3 (PS3)

• Renderer: Vulkan
• Resolution Scale: 300% (geralmente) ou nativo (jogos com issue de upscale)
• Shader Precision: Ultra
• Force High Precision Z: ligado
• SPU XFloat: Accurate
• Multithreaded RSX: ligado
• Write Color Buffers (WCB) / Read Color Buffers (RCB): desligados por padrão (GT-series safety)

RPCS3 é onde mais tem armadilha. Cada jogo tem preset recomendado na DB de compatibilidade oficial. E atenção: configs per-game ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. Prefixo config_ obrigatório. Perdi tempo até descobrir isso, o RPCS3 aceita o YAML silenciosamente e depois ignora se o nome tá errado.

Xenia Canary (Xbox 360)

• Build: Canary (o master tá parado há meses, Canary é o que anda)
• Renderer: Vulkan
• Render Target Path: rtv por default, fsi pra jogos específicos (PGR4)
• User Profile: criado uma vez, persiste
• Wine Prefix: dedicado, gerenciado pelo Xenia Manager

Xenia no Linux roda via Wine, gerenciado pelo Xenia Manager. Não tem build nativo decente. Funciona bem, mas cada jogo pede ajuste específico, e Title Updates tem que ser puxado manualmente do archive.org (escrevi um script pra isso, detalhes no artigo anterior).

shadPS4 (PS4)

Esse merece a seção dedicada no final. Resumindo: funciona pra alguns jogos simples, pra Driveclub ainda não é confiável. Continua sendo um tiro no escuro.

PS1 no DuckStation

Gran Turismo (o primeiro, de 1997)

Esse aqui é puro sentimento. GT1 foi um dos primeiros jogos que eu comprei pro PS1, e joguei até rachar o CD. Na época, era outro patamar. Simulação real numa máquina de 128K de RAM de vídeo, física decente, 140 carros quando todo mundo tinha 15, trilha sonora memorável.

Mas sejamos honestos: não dá pra voltar hoje. A física do GT1 tem drift exagerado, o carro desliza mais do que deveria em qualquer curva acima de 80 km/h. É parte do charme de 1997 mas irrita em 2026. O modelo de controle foi muito refinado a partir do GT2, e tudo que veio depois só melhorou. Entre GT1 e GT2, GT2 vence em conteúdo (650+ carros vs 140) e principalmente em dirigibilidade.

Eu deixo o GT1 no ES-DE pra abrir em momentos de nostalgia, jogar uns 10 minutos em Trial Mountain e fechar. Pra gameplay sério da era PS1, vai de GT2.

Gran Turismo 2 (Spec II Mod)

O Gran Turismo original do PS1 é um marco histórico. Eu joguei muito na época. Hoje, pra jogar de novo? Não. GT2 existe, e GT2 é superior em tudo. Mais carros (650+), mais pistas, mais modos, e principalmente, um modelo de controle muito melhor. O GT1 tem aquele drift exagerado onde o carro desliza mais do que deveria, o GT2 ajustou isso pra algo mais próximo do que a série seria a partir do PS2. Entre jogar GT1 ou GT2, sempre GT2.

E o GT2 que eu rodo hoje é o GT2 Spec II Mod do Project A-Spec, um projeto comunitário que consolida as duas variantes regionais (Arcade + Simulation) num único jogo, traz de volta eventos que foram cortados no release final, corrige bugs de física, adiciona suporte a widescreen nativo e dá quality-of-life updates em menus. É o jeito definitivo de jogar GT2 em 2026. O projeto não mantém mais site próprio, as atualizações vêm pelo Twitter do autor.

Pra rodar:

O cheat de 8 MB RAM é importante pra pistas cheias (tipo Seattle em corridas populated) onde o áudio começa a estourar. Ele simula a expansão de memória da versão japonesa que nunca veio pro Ocidente.

Colin McRae Rally 1 e 2

Jogos icônicos do PS1. CMR1 tem aquela sensação áspera de rally primeiro-gen que tem seu charme. CMR2 é tecnicamente superior, física melhor, mais rallys, melhor grafia. Mas eu vou ser honesto: pra jogar CMR2 hoje, vale procurar a versão PC original. Resolução maior, 60fps nativo (a versão PS1 trava em 30), controle direto de teclado/volante. Existem repacks do Codemasters na internet, tem umas 40 segundos num search decente. Não vou linkar, você sabe onde procurar.

No PS1 via DuckStation eles rodam liso, nostalgia garantida, mas não é onde eu passo o tempo.

PS2 no PCSX2

Gran Turismo 3 A-Spec

GT3 foi um salto geracional. Saiu do mundo quadradinho do PS1 pra um mundo de shaders, environment mapping decente, modelos de carro com polígono sério, física que finalmente começou a parecer com física de verdade. A trilha sonora com Feeder de “Just a Day” abrindo o jogo ainda me dá arrepio.

O problema é que GT3 tem MENOS conteúdo que GT2. Polyphony foi mais cautelosa, cortou modos pra focar em qualidade. Licença A/B/S é menor, carros são menos, pistas são fewer. Mas o que tem é polido.

Em 2026 no PCSX2 2.7.x, GT3 fica muito bom. HD textures de comunidade, widescreen pnach, anti-aliasing via SSAA, 16x AF. Parece jogo relançado.

Caveat sobre o pack de retextura: quando ligado, tem cenas de mostruário de carro no garage onde o NFS stream causa um flicker momentâneo. Não incomoda em corrida. Se te irrita no menu, desliga.

Lembrete: pro widescreen pnach fazer efeito você ainda precisa entrar nas opções dentro do jogo e mudar o aspect ratio pra 16:9. O pnach libera a opção no menu, não aplica automaticamente.

Gran Turismo 4 (Spec II Mod)

GT4 é o meu GOAT da série. 700+ carros, 50+ circuitos, física ainda respeitável pra padrão 2026, e aquela trilha sonora que mistura rock alternativo, lounge japonês, e o infame “Sail Away” do Moby no menu principal. Foi o jogo que mais mexi em 2004, e é o que eu mais mexo hoje.

Igual o GT2, o GT4 que eu rodo hoje não é o disco original. É o Gran Turismo 4: Spec II mantido pelo TheAdmiester — uma mod comunitária massiva que é objetivamente o melhor jeito de jogar GT4 em 2026. Ela combina o disco final USA, a Beta prototype de 2003 e o release japonês original num único jogo, restaurando carros cortados (incluindo vários que nunca saíram fora do Japão), eventos cancelados, dezenas de faixas de trilha sonora faltantes, suporte a widescreen 16:9, mais de 30 cheats integrados como opções de menu (pro tuning, velocidade máxima, economia de combustível), opção de trocar entre idiomas Inglês/Japonês, e correções de bugs originais. O projeto é ativo, ainda recebe patches e tem instalador próprio que aplica sobre uma ISO USA limpa.

Na prática, Spec II é o que o GT4 deveria ter sido se a Polyphony tivesse tido mais seis meses pra polir. Quando você joga hoje, é GT4 com todo o conteúdo que ficou de fora + quality-of-life moderno. Pra qualquer um que gostou do original, é obrigatório.

Por cima disso vai o Retexture 3.0 da comunidade (pack de textura HD) e o HD HUD do Silentwarior112. Com essas três peças juntas (Spec II Mod + Retexture + HD HUD), GT4 roda a 1440p SSAA no PCSX2 2.7.x com 16x AF, FXAA, e uma cara que honestamente é indistinguível de um jogo novo em low-poly style. É o meu atual favorito pra sentar e jogar longo.

Quem tá usando o Spec II Mod precisa atentar pro CRC: os HD packs do GT4 vanilla foram feitos pro 77E61C8A (USA), então no Spec II com CRC 4CE521F2 eu linko os assets via symlink na pasta CRC-suffixed que o PCSX2 procura. O pnach de widescreen também foi renomeado pra bater com o CRC do Spec II. Sem esse cuidado, o jogo roda mas os mods não carregam.

Lembretes in-game: igual ao GT3, o widescreen pnach só libera a opção, você ainda precisa entrar em Options dentro do jogo e trocar pra 16:9. E importante: mude o modo de vídeo pra progressive 480p (também em Options). O default é interlaced 480i, que fica péssimo em tela moderna. O Spec II Mod tem suporte nativo a progressive, é só ligar.

Se eu pudesse recomendar um único GT da série pra alguém começar hoje, seria esse. Se você gosta de corrida e nunca jogou GT4 full, tá perdendo.

Enthusia Professional Racing

Enthusia é o jogo esquecido da Konami de 2005. Saiu na sombra do GT4 e morreu no balcão. É uma pena, porque a física do Enthusia era mais realista que a do GT4. Peso do carro, transferência de massa, comportamento em limite, tudo mais próximo do comportamento real. A comunidade sim-racing dos anos 2000 sabia disso e o jogo tem culto hoje.

O problema do Enthusia era o sistema de Enthusia Points: você ganhava pontos por andar limpo, perdia por bater, e a progressão do jogo dependia desses pontos. Muita gente achou punitivo. Eu achei perfeito. Forçava você a dirigir com cabeça.

Em PCSX2 com retexture e widescreen, o jogo fica muito bom. Recomendação forte pra quem quer algo diferente dos Gran Turismo.

Ridge Racer V

Ridge Racer é sua própria coisa. Não é simcade, é arcade puro. Drift tudo, colinha dinâmica, trilha sonora eletrônica, cores saturadas. Ridge Racer V foi o jogo de lançamento do PS2 no Japão e por isso tem aquele cheiro de “mostra o que o console pode fazer”, com cenários colossais e sensação de velocidade que GT nunca tentou.

No PCSX2 ele roda bem, com uma caveira: textura de carro às vezes flicka em hardware renderer (issues #3639 e #13729 do PCSX2). Software renderer resolve mas mata performance. Eu fico no hardware e aceito o flicker ocasional.

Colin McRae Rally 3, 4, 5 (PS2)

Versões de PS2 dos Colin McRae rodam bem no PCSX2 com configs default. CMR3 e CMR04 são bons. CMR05 (o último antes do rebrand pra Dirt) é o melhor dos três tecnicamente. Mas de novo: se você tá em PC, procura a versão nativa. Os ports de PS2 eram relativamente inferiores aos PC da época, rodavam em resolução menor, e o PC moderno com repack vai dar 144Hz fácil.

Fica o registro no PCSX2 pra completude da coleção.

PS3 no RPCS3

Gran Turismo 5

GT5 é controverso. Polyphony prometeu mundos e entregou um jogo meio fragmentado: modelos Premium lindos ao lado de Standard que eram basicamente carros do GT4 em HD, sistema de níveis que alguns amaram e outros detestaram, online que foi pra lama quando o serviço PSN desligou, modo Top Gear que era estranho. A crítica na época foi mista, e eu lembro de comunidades inteiras brigando sobre se o jogo era decepção ou genial.

Pra mim, é genial. GT5 tem o Course Maker (edita tua própria pista baseada em seções reais), o Nurburgring 24h real com chuva dinâmica, o Moon Rover (sim, modo de dirigir na Lua), Red Bull X-Challenge com Vettel, e a experiência de endurance single-player é ridiculamente grande. Quem entrou no jogo a fundo sabe que tem conteúdo pra ano inteiro.

No RPCS3 em 2026, GT5 roda muito bem. Estável, sem os bugs graves de anos passados. É o GT mais estável que eu tenho emulado hoje.

A combinação Shader Precision Ultra + Force High Precision Z mata o dithering típico do RSX que fazia GT5 parecer granulado em RPCS3 antigamente. Sem esses dois, o asfalto parece ter ruído constante. Com eles, o jogo fica limpo.

Gran Turismo 6

GT6 é um dos meus preferidos da série. Saiu em 2013 pra um PS3 no final de vida, enquanto a concorrência já olhava pra PS4. Vendeu mal. Muita gente não jogou. E é uma pena, porque GT6 pegou a base do GT5, cortou a gordura (Standards foram reduzidos), adicionou mais Premiums, sessões em circuito no Moon melhores, meteorologia dinâmica em mais pistas, refinamento de física. É basicamente o GT5 polido.

Em conteúdo, GT6 é comparável ao GT4. Muitos jogadores da velha guarda botam o GT4 acima por causa do charme da era PS2. Eu fico entre os dois e vou mais pro GT6 em dia normal, GT4 em dia nostálgico.

Em RPCS3, GT6 tem uma pegadinha grave: patches 1.06 em diante regridem visualmente. Superfícies pretas em carros no menu garagem, flicker em cockpit view, tela inteira piscando em certas pistas. A versão que funciona bem em 2026 é travada em v1.05. O script extract_ps3_dlc.py do repo tem um ceiling por título específico pra pinar GT6 em 1.05 mesmo quando o PSN cuspa 1.22 como “mais recente”.

Além disso, Force CPU Blit é mandatório. Sem ele, tem flicker de tela inteira em menu. O trade-off é que o retrovisor fica permanentemente preto. Eu prefiro perder o retrovisor a ter o flicker. Quem quer retrovisor pode ligar Write Color Buffers, mas aí a resolução cai pra 720p nativo.

Em 2026, com essas configs, GT6 tá no meu rodízio. Não é perfeito, mas é jogável o suficiente pra eu passar uma tarde fazendo endurance.

Ridge Racer 7

Ridge Racer 7 foi lançamento do PS3 em 2006 e é o último mainline da franquia. Arcade igual Ridge Racer V, drift-first, trilha sonora eletrônica, câmera cinemática. Pra PS3 da época era uma demo tecnológica bonita.

No RPCS3 ele roda, mas com caveats: requer Write Color Buffers ligado pra não ter problemas de iluminação, e o preset recomendado na compat DB é diferente do meu preset GT. Eu uso config per-game dedicada pra ele. Não é meu favorito, mas tá lá pra completude.

Sem vídeo pra esse, gravo depois.

Xbox 360 no Xenia Canary

Aqui tá a parte que mais me deu dor de cabeça nesse domingo. Xbox 360 no Linux é território hostil. Xenia roda via Wine, cada jogo tem tweaks específicos, title updates tem que vir do archive.org, e Forza Motorsport 4 especificamente tinha problemas sérios até pouco tempo atrás.

Forza Motorsport 4 (o GOAT)

FM4 é, pra muita gente, o melhor Forza Motorsport já lançado. Polyphony fez Gran Turismo, Turn 10 fez Forza, e FM4 é o pico da era 360. Modelos de carro belíssimos pra época, pistas bem construídas, física sólida sem ser simulador puro, Autovista mode com narração do Jeremy Clarkson, trilha sonora épica, e aquela sensação de Xbox 360 sendo usado no limite.

FM4 no Xenia era um pesadelo até recentemente. Shadow com artefato severo, texture pop-in constante no carro, textura de pista chiada e pixelada, céu com brilho completamente errado (ficava branco-estourado em vez do azul profundo original), e o pior: crash de áudio frequente, onde o XMA (codec proprietário do Xbox 360) travava e o som virava ruído agudo até congelar o jogo. Eu passei horas nesse domingo mexendo em config, testando builds, procurando issue no xenia-canary, testando diferentes title updates.

O que destravou:

• Build Xenia Canary mais recente (o master tá parado, Canary acompanha desenvolvimento ativo)
• Render Target Path: rtv (o default funciona bem pra FM4)
• Title Update 1.0.17.0 instalado via Xenia Manager (versão importa, mais velha dá regressão em sombras)
• GPU Vulkan com ICD NVIDIA forçado (no meu setup híbrido com AMD iGPU, tinha que forçar a 5090)

Depois disso, FM4 rodou. Não é perfeito. Ainda tem algum crash esporádico de áudio (xenia-canary issue #161 aberta). Mas é jogável, e eu passei umas duas horas do domingo no Top Gear Test Track só apreciando o Koenigsegg CCX. Valeu cada hora de debug.

Forza Motorsport 3

FM3 é uma das entradas boas da série, entre o charme áspero do FM2 e o pico técnico do FM4. Tentar emular foi surpreendentemente chato, porque eu tava usando a ISO errada.

Existem dois releases do FM3: o retail (disco original vendido em loja) e o Ultimate Edition (com todas as DLCs empacotadas num segundo disco). Eu tava tentando rodar o Ultimate, que combina dois discos numa ISO híbrida que o Xenia não parseia direito. Troquei pro retail padrão + DLCs instaladas separadamente via Title Update, e bingo, o jogo rodou na primeira.

Moral: se teu FM3 não tá rodando no Xenia, verifica se é retail. Ultimate dá problema.

Forza Motorsport 2

FM2 é da era 2007, primeira-gen do 360. Sistemas menos refinados, modelagem mais básica, mas aquele charme de Forza original que alguns preferem à sofisticação do FM4. No Xenia rodou praticamente out-of-the-box. Nenhum tweak especial.

Forza Horizon 2

FH2 foi o Forza Horizon mais polido da geração 360 (existe também a versão Xbox One, que é melhor tecnicamente, mas o 360 tem seu charme por causa do mapa menor e da progressão mais focada). Mundo aberto no sul da Europa, trilha sonora icônica, festival Horizon no seu pico.

No Xenia rodou sem pedir nada extra. Como o FM2.

Forza Horizon 1 (com XE Mod)

FH1 original roda OK no Xenia, mas tem uma comunidade que mantém o Forza Horizon 1 XE Mod, que melhora IA do tráfego, rebalanceia progressão, adiciona carros que ficaram de fora, corrige bugs conhecidos, e traz uns quality-of-life tweaks na UI. Eu testei o XE Mod nesse domingo e vale a pena. O jogo parece mais vivo e progressão mais justa.

Detalhes da instalação do XE Mod estão no site do projeto. Basicamente é patch sobre a ISO original + alguns title updates customizados.

Pra comparação, aqui é o FH1 sem o mod, rodando puro:

A diferença mais visível é no tráfego e na variedade de situações que aparecem, mas o XE Mod tem muita coisa que você só percebe depois de algumas horas.

Project Gotham Racing 3 e 4

PGR3 foi lançamento do 360 em 2005 e continua lindo hoje. Pistas urbanas (Nova York, Tokyo, Nurburgring, Las Vegas), kudos system, câmera cinemática. PGR4 adicionou clima dinâmico (chuva e neve) e motos (algumas pessoas adoram, eu prefiro fingir que não existe).

PGR3 no Xenia Canary roda razoavelmente bem com configs default. PGR4 precisa de tweak específico: render_target_path_vulkan = "fsi" no config. Sem isso, algumas pistas quebram com artefato visual severo (barras verdes atravessando a tela em corridas de neve).

E PGR4 no NVIDIA tem um bug conhecido de áudio: decoding XMA gera garbage intermitente (issue aberta no xenia-canary, sem resolução). Não é game-breaking, mas incomoda.

Ridge Racer 6

Ridge Racer 6 foi o Ridge Racer do 360, pula o 7 que ficou em PS3. Arcade puro, igual Ridge Racer V do PS2. No Xenia Canary roda com config default, sem tweak especial. É divertido pra sessão curta. Sem vídeo dele no artigo, mas tá no catálogo rodando.

PS4 no shadPS4: o estado do emulador

shadPS4 ainda não tem release estável. O projeto tá em desenvolvimento ativo, main branch muda várias vezes por semana, e “o que funciona hoje” pode regredir num rebase amanhã. Dito isso, muitos jogos já bootam e rodam bem o suficiente. Lista da comunidade tá no compatibility tracker e cresce toda semana.

A diferença entre shadPS4 e os outros emuladores desse artigo é o tipo de esforço. PCSX2, RPCS3, Xenia são projetos maduros onde cada jogo tem uma página de wiki razoavelmente atualizada. shadPS4 é o oposto: você lê um guia do Reddit, tenta reproduzir, descobre que o guia usa um fork específico (não o main oficial), ou um commit de dois meses atrás, ou um firmware com sys_modules linkados de jeito particular, ou patches XML aplicados numa ordem específica que o autor não documentou. Reproduzir setup de shadPS4 a partir de vídeo YouTube é tentar resolver Rubik’s Cube com venda.

Mas isso não significa que você não deve tentar. Significa que você precisa tratar shadPS4 como brincadeira, não como workflow. E se você tiver paciência, dá pra colher resultados impressionantes.

Driveclub: o impossível, finalmente possível

Driveclub é meu Moby Dick da emulação. É o único jogo de PS4 que eu quero muito rodar. Saiu em 2014 pela Evolution Studios, teve lançamento catastrófico (servers online colapsaram no dia 1), foi patchado durante dois anos até virar um dos melhores jogos de corrida da geração, e foi descontinuado pela Sony quando a Evolution foi fechada em 2016. Não tem port pra PC. Não tem remaster. Não tem sequel. Só existe no PS4.

E hoje, depois de muitas horas de debug, está rodando aqui. Menu principal carrega, intro roda, corridas começam, controle responde, áudio funciona, pistas de dia visíveis, pistas de noite com faróis iluminando pista. O vídeo acima é gameplay real, a 30 FPS estáveis, v1.28 com conteúdo DLC acessível.

Chegar até aqui exigiu desarmar várias armadilhas. Vale documentar, porque a maioria dos guias online não menciona nenhuma.

Armadilha 1: o FMOD loop error que não era FMOD

Quando você tenta bootar Driveclub no shadPS4 direto da PKG retail, o log estoura um loop infinito de:

/app0/audio/fmodstudio/masterbank.bank failed, file does not exist

A primeira reação é investigar FMOD. Tem gente na internet que passou horas mexendo em sceFont, libtbb, sceNgs2, convencidos que era problema de áudio ou lib HLE. Nada disso é a causa. O arquivo masterbank.bank literalmente não existe no disco, porque ele tá empacotado dentro dos arquivos gameNNN.dat num formato de archive customizado da Evolution Studios que o VFS do shadPS4 não sabe ler. A mesma história vale pra fontes, modelos, shaders. O conteúdo todo do jogo mora dentro dos .dat.

A única ferramenta pública que parse esse formato é o DriveClubFS do Nenkai. É uma app .NET que lê o game.ndx (o índice) e decomprime os .dat em arquivos soltos. Sem esse unpack, o shadPS4 não consegue abrir nada.

Detalhe de build: o projeto DriveClubFS tá em net9.0, e o Arch tem net8 e net10. Precisa retargetar o csproj pra net10.0 antes de buildar. O comando exato tá documentado no docs/driveclub-shadps4.md do repo.

Armadilha 2: v1.28 é patch, não instalador base

Como em qualquer PS4, update é patch que vai em cima de uma install base. A PKG do v1.28 traz o eboot atualizado, .dat com conteúdo novo e patch content (sce_sys/about/right.sprx), mas não traz param.sfo, disc_info.dat nem keystone. Esses metadata ficam na base de v1.00 — num PS4 real já estariam gravados do install original.

E tem mais: o game.ndx do v1.28 referencia tanto os .dat da base quanto os novos. Rodar o DriveClubFS contra só o v1.28 faz o índice apontar pra arquivos que não tão ali.

O sintoma mais cruel vem depois: o jogo boota, a Qt Launcher mostra o tile, você clica, a tela carrega. Aí o jogo decide que nenhum conteúdo “foi lançado ainda” e pede pra fazer download. Download obviamente não vai acontecer porque PSN pra PS4 não tá acessível. Você fica travado achando que é bug de rede, quando na verdade é metadata faltando.

O fluxo correto é tratar v1.28 como overlay sobre a base. Primeiro, extrai a PKG de v1.00 pra um dir dedicado (CUSA00003.v100-working-backup/ funciona bem, e dobra como snapshot de rollback se algum experimento quebrar a instalação viva). Depois extrai o v1.28 pra staging e linka os .dat de índice baixo da base dentro do staging pra o DriveClubFS enxergar o set completo. Roda o unpack. Sai com 8018 arquivos soltos, ~47 GB.

Move pra CUSA00003/ final, copia o eboot e conteúdo novo do v1.28 por cima, e puxa param.sfo, disc_info.dat e keystone da base de v1.00. O param.sfo da base já vem com APP_VER = 01.28 gravado (porque ela recebeu o patch original), então não tem conflito de versão. O eboot v1.28 lê esses arquivos e libera o conteúdo.

Armadilha 3: o patch XML de 60fps gera slow-motion

Tem um Driveclub.xml patch comunitário que faz o jogo renderizar a 60fps. Intuitivamente, parece ganho puro. Na prática, o patch reescreve o render rate mas não mexe no logic tickrate interno do jogo, que é fixo em 30fps. Num PS4 Pro real, o hardware reconcilia a diferença. No shadPS4, não.

Resultado: o jogo renderiza liso a 60fps, mas toda a física, AI, áudio, timing de corrida roda em câmera lenta. Você aperta acelerador e o carro leva dois segundos perceptíveis pra sair. Parece bug aleatório até você entender o mismatch.

Desabilitar o patch XML resolve (basta renomear o arquivo pra algo como .disabled). Sem o patch, o jogo fica a 30 FPS nativos, mesma velocidade do PS4 base stock. Que é o que a gente quer. Se alguém conseguir no futuro fazer um patch que mexa nos dois rates (render + logic), a gente religa.

Armadilha 4: pipeline cache precisa estar ligado

Default do shadPS4 vem com pipeline_cache_enabled = false. Num jogo grande como Driveclub, que tem centenas de shaders e pipelines Vulkan, isso significa que cada cold launch recompila tudo. Nos meus testes o primeiro launch contou ~864 shaders e ~590 pipelines sendo compilados em tempo real. O menu animava a 2-3 fps. Um minuto depois, com tudo compilado, saltava pra fluidez normal. Próximo launch, mesmo ciclo de compilação do zero.

Basta ligar "pipeline_cache_enabled": true no config.json global. Primeira sessão paga o custo único de compilação, sessões seguintes leem do cache e sobem direto.

Armadilha 5: TOML silenciosamente ignorado

O shadPS4 migrou de TOML pra JSON em config per-game em late 2025. Se você tem um CUSA00003.toml antigo na pasta custom_configs/, ele é silenciosamente ignorado, sem warning no log. Você pensa que sua config tá ativa, na prática tá rodando tudo default.

Deleta qualquer TOML e usa CUSA00003.json. As configs per-game que funcionam pra Driveclub são específicas e detalhadas, documentei todas no docs/driveclub-shadps4.md do repo.

Armadilha 6: controle não detectado sem hidapi hints

Qt Launcher do shadPS4 chama um Shadps4-sdl.AppImage interno. Sem env vars específicas do SDL hidapi, o controle (no meu caso 8BitDo Ultimate 2) não é detectado, mesmo funcionando em outros emuladores. O fix é wrapar o AppImage num shell que exporta SDL_JOYSTICK_HIDAPI=1 e variantes específicas por plataforma (PS4, PS5, Xbox), antes de executar o original.

Plugar o controle antes de abrir o Qt Launcher também ajuda. Hot-plug funciona durante o jogo, não antes.

Armadilha 7: pistas de noite ficam pretas no upstream

Esse aqui é o único que precisou de patch de código, não só config. No upstream do shadPS4, pistas de Driveclub à noite ficavam pretas. HUD aparecia em cima, mas pista, carro, tudo escondido num preto absoluto. Faróis do próprio carro não iluminavam nada.

Investigação apontou pro log repetindo 1325 vezes a mensagem ResolveDepthOverlap: Unimplemented depth overlap copy. A causa: o Driveclub usa renderer forward+, que escreve a profundidade da cena num buffer MSAA 4x D32Sfloat, depois lê esse mesmo buffer como R32G32B32A32Sfloat 1x pra efeitos tipo SSAO, volumetrics e iluminação dinâmica (faróis). O shadPS4 upstream tem caminho pra MSAA → MSAA e pra cor → cor como MSAA depth, mas não tinha caminho pra “MSAA depth de 4x vira color de 1x” nesse formato específico. Cai no else final, libera o buffer, e o shader lê lixo não inicializado — ou seja, preto.

Implementei no meu fork local do shadPS4 um ReinterpretMsDepthAsColor simétrico aos ReinterpretColorAsMsDepth que já existiam. É um fragment shader minúsculo (ms_depth_to_color.frag) que faz texelFetch da profundidade sample 0 e escreve como vec4(depth, 0, 0, 1) no attachment de cor. Plus um helper no BlitHelper e um novo else if no TextureCache::ResolveDepthOverlap. Com isso, pistas de noite iluminam corretamente, faróis dos oponentes aparecem, AO e volumetrics no dia também ficam mais precisos.

O fix tá num branch gamma-debug do meu fork, pronto pra virar PR upstream. Enquanto não mergeia, quem quer rodar Driveclub à noite no shadPS4 precisa buildar desse branch. Quem fica só em corridas de dia pode usar o upstream nightly direto.

O que finalmente funcionou

Tudo isso tá encapsulado no docs/driveclub-shadps4.md do repo, com o passo a passo exato de extração, config e wrapper. A investigação técnica completa (5 fases, engineering log detalhado) tá no driveclub-v128-investigation.md do fork.

Quão jogável tá hoje

Bom. O vídeo acima é gameplay real, a 30 FPS estáveis, com física respondendo, áudio sincronizado, HUD correto, v1.28 com DLC acessível. Corridas de dia e de noite funcionam (com o fork do MSAA depth pra noite). O que sobra de limitação:

• Brilho de dia um pouco abaixo do que o PS4 entregava. Não é bug do emulador. Passei horas testando tonemap, auto-exposure, gamma curves, ACES, vários shaders de post-processing, e no fim descobri que o jogo escreve SDR já correto no framebuffer. O que estava faltando era o pipeline de calibração de display que o firmware 4.0+ do PS4 aplicava por fora, e que o Linux não tem. O slider de brilho in-game (que no shadPS4 mapeia pra sceVideoOutAdjustColor) funciona, mas só vai até o ponto que o jogo pensou que seria complementado pelo firmware. A cena de 5 segundos escuros no início da corrida também é fade-in cinematográfico do jogo, não falha de emulador. Aceitei.
• 30 FPS nativos. Sem patch de 60fps viável (pelo motivo do logic tickrate fixo). Stock PS4 speed.
• MSAA depth fix ainda no fork. Tem PR candidate pronto, aguardando upstream mergear.

“Achievement Unlocked”. O jogo roda, com som, controle, jogabilidade, dia e noite, e eu completo corrida inteira sem crash. Isso é um marco pessoal. Eu passei anos tentando fazer esse jogo rodar no Linux e chegava num ponto onde simplesmente desistia. Agora é parte do meu ES-DE, atalho no desktop, tá lá esperando eu sentar pra jogar.

Se você quer replicar, o repo tá público. Boa sorte. Vai precisar de paciência.

“Achievement Unlocked”

Eu venho tentando fazer esses jogos funcionarem, em algum nível, desde que cada respectivo emulador saiu de alpha. GT2 eu tô rodando desde ePSXe. GT4 eu mexo desde PCSX2 0.9.6. FM4 eu tentei fazer rodar em Xenia duas vezes em anos anteriores e desisti nas duas. E Driveclub eu olhei pra cara do shadPS4 três vezes antes desse domingo e engoli em seco.

Hoje fechou. Os dois monstros que abriram esse artigo (Driveclub no shadPS4 e FM4 com Project Forza Plus no Xenia) estão rodando, junto com todo o resto da coleção de Gran Turismo, Forza, Ridge Racer, Colin McRae e Enthusia. Tudo num setup único, reproduzível, automatizado. Agora eu faço parte do grupo bem pequeno de pessoas que conseguiu brute force emular Driveclub no Linux, e isso sozinho já tornou o domingo inesquecível.

A frustração de anos não era falta de informação. Era o OPOSTO. Informação demais, mal indexada, espalhada em fóruns apagados, vídeos YouTube que ficaram datados, threads Reddit com soluções pra versão do emulador de dois anos atrás que não valem hoje, wiki de projeto desatualizada em metade das páginas, e mods com requisitos MUITO específicos de CRC, versão, patch, path, setting. Cada vez que eu sentava pra fazer um desses jogos rodar direito, eu ficava três horas lendo material conflitante antes de escrever a primeira linha de config. Pior ainda quando o material bom estava enterrado entre diagnósticos errados, tipo o FMOD loop do Driveclub que todo mundo investigava como se fosse problema de áudio quando na real era formato de archive proprietário da Evolution Studios.

O que mudou nesse último ano é que Claude Code consegue ser meu agregador. Eu peço pro Claude ir na issue tracker do Xenia, na wiki do PCSX2, no subreddit do RPCS3, nos PRs do shadPS4, comparar todas as informações com a versão atual do emulador instalada, cruzar com os logs que eu tô vendo, e me devolver a combinação que funciona hoje. Ele lê source code quando precisa, entende por que Force CPU Blit muda comportamento no GT6, acha qual title update do FM4 foi o que consertou o shadow bug, descobre que o DriveClubFS precisa de retarget pra .NET 10 antes de compilar. O que antes levava três fins de semana pesquisando agora leva uma tarde de execução assistida.

Esse domingo é o resultado consolidado de todo esse trabalho. distrobox-gaming é a versão desse conhecimento virada código, reprodutível, automatizada. Rodando numa máquina fresca, um ansible-playbook site.yml me põe de volta nesse estado em menos de duas horas. Menos de 10 comandos separam “Arch Linux vanilla” de “Driveclub rodando”.

Se alguém quiser contribuir, testar em outro hardware, reportar bug ou mandar config que ficou faltando, o repo tá aberto. Quanto mais gente testar em setups diferentes, mais resiliente o projeto fica. Se você melhorar a situação do Driveclub (mergear o MSAA depth fix upstream, patch de 60fps que também corrija o logic tickrate, dump de fontes que não precise hardware jailbroken), manda PR que eu abraço.

Por enquanto, eu vou fazer uma corrida na Islândia no Driveclub. Boa noite de domingo.

No meu canal eu inclusive usei jogos antigos pra ensinar fundamentos de computação. No Akitando sobre Super Mario e computadores antigos eu explico 6502, mapa de memória, PPU, limitações de hardware e por que aqueles jogos eram programados daquele jeito. Se você nunca viu, recomendo assistir:

O problema é o de sempre: a cada poucos anos eu resolvo montar uma máquina nova de emulação, baixo de novo os emuladores principais da vez, e lá vou eu repetir o mesmo ritual masoquista. PCSX2, RPCS3, Eden, Azahar, Dolphin, RetroArch, Flycast, shadPS4 e por aí vai. Cada um com suas manias. Cada um com sua forma particular de te fazer perder horas.

Em teoria, montar tudo isso deveria ser divertido. Na prática, leva dias. E não é exagero. Dolphin ainda consegue ser um dos piores porque controle de GameCube e Wii não tem nada de padrão. RPCS3 exige tuning por jogo. Eden precisa de DLC, update e cheats no lugar certo. shadPS4 é um festival de tentativa e erro. Quando eu finalmente terminava de configurar tudo, eu já não queria mais jogar porcaria nenhuma. Eu só queria fechar os menus e ir fazer outra coisa.

Eu já cheguei a dizer que talvez a graça estivesse justamente no tuning. Não acho mais isso. Depois de repetir esse processo vezes demais, eu cansei. Eu quero jogar os jogos, não preencher formulário escondido em GUI de emulador.

O problema não era Linux

Eu já resolvi esse tipo de coisa de várias formas no passado. Anos atrás eu rodava Linux no host e um Windows virtualizado com GPU passthrough pra jogar dentro da VM. Na época era o que fazia sentido. Eu fiz um vídeo inteiro sobre isso:

Mas isso foi antes do trabalho monumental da Valve, do Proton, do Wine moderno e de toda a comunidade open source que empurrou o desktop Linux pra um lugar muito melhor. Hoje dá pra evitar Windows na maior parte dos casos. No outro vídeo abaixo eu explico a evolução de CPU, GPU, OpenGL, Vulkan e por que chegamos nesse ponto:

Meu mini-PC dedicado a games com RTX 4090 continua sendo minha principal máquina de Steam, especialmente agora que montei um cockpit decente de sim racing. Nele eu uso EmuDeck, que nasceu justamente pra automatizar instalação e configuração de emuladores no Steam Deck, depois passou a suportar Windows também, e ajuda bastante a reduzir a complicação de montar esse tipo de ambiente. Mas meu desktop principal também é forte demais pra ficar subutilizado. Ele tem uma RTX 5090, e hoje eu uso essa GPU principalmente pra testar LLMs e benchmarking, como contei em Testando LLMs Open Source e Comerciais. Seria um desperdício não usar isso pra gaming também.

Só que no Linux eu queria outra coisa. Eu não queria uma caixa-preta fazendo tudo por mim sem eu saber exatamente o que estava sendo alterado, principalmente no meu PC principal, que é minha máquina de trabalho. Eu queria um setup meu, feito “na mão” no sentido certo da expressão: não clicar GUI por GUI, mas entender o que está sendo configurado, manter os arquivos sob meu controle, e conseguir reconstruir tudo do jeito que eu gosto. Eu sei que o pessoal do NixOS vai pular aqui pra dizer “é só usar Nix” — explico mais abaixo por que descartei essa rota. Também não queria transformar a minha máquina de trabalho num carnaval de pacote de emulador, tema GTK, wrapper, launcher, runtime esquisito e config enterrada em ~/.config. Nem queria dual boot ou VM. Em 2026, a melhor resposta pra isso, na minha opinião, é Distrobox.

Pelo que o próprio projeto explica, Distrobox é um wrapper em cima de podman, docker ou lilipod pra criar containers fortemente integrados ao host, com acesso a HOME, Wayland/X11, áudio, dispositivos USB, storage externo e GPU. Ou seja: exatamente o tipo de isolamento pragmático que eu queria. Não é uma fronteira de segurança, e o próprio site deixa isso claro. Não use pensando em sandbox de alta segurança. Use pensando em separar ambientes sem ficar pagando o preço de uma VM.

E antes que alguém repita a confusão de sempre: container não é máquina virtual. Eu explico isso com calma neste outro episódio:

O setup

A ideia é simples: um Arch Linux vanilla dentro de um Distrobox chamado gaming, com os caminhos do NAS montados em read-only, a biblioteca Steam acessível onde faz sentido, e todos os emuladores instalados lá dentro. Como o container tem acesso a GPU NVIDIA, áudio, USB e demais periféricos, eu separo trabalho de jogo na mesma máquina sem penalidade prática de performance.

O bootstrap inicial é mais ou menos isso:

distrobox create --name gaming --image archlinux:latest --nvidia \
  --home /mnt/data/distrobox/gaming \
  --volume /mnt/data/steam:/mnt/data/steam \
  --volume /mnt/terachad/Emulators:/mnt/terachad/Emulators:ro

Só esse começo já tem pegadinha. O archlinux:latest dentro de Distrobox vem sem [multilib] no pacman.conf, com um sudoers mal configurado, e com o velho problema do --nvidia: as libs do driver do host entram bind-mounted read-only, então qualquer instalação que dependa de nvidia-utils quebra com conflito de arquivo. Só isso já é o tipo de dor de cabeça que, alguns anos atrás, me faria abrir meia dúzia de abas, mais uma penca de terminais, e gastar uma noite inteira em tentativa e erro.

Desta vez eu fiz diferente.

Claude Code como assistente de infraestrutura

Eu venho ficando cada vez mais confortável em usar Claude Code como meu assistente de infraestrutura nas minhas máquinas pessoais. Eu não faria isso cegamente em servidor de cliente. Mas em máquina minha, em ambiente que eu posso destruir e reconstruir quantas vezes eu quiser, faz todo sentido. Escrevi sobre isso no artigo Migrando meu Home Server com Claude Code, quando usei Claude pra instalar e configurar openSUSE MicroOS, Docker, NFS, firewall, hardening e o resto todo sem eu precisar ficar lembrando comando chato de shell.

Então pensei: por que não fazer a mesma coisa aqui?

Foi exatamente o que eu fiz. Comecei com prompts bem objetivos, sempre pedindo duas coisas ao mesmo tempo: fazer o trabalho e documentar o suficiente pra eu poder reconstruir tudo depois. O histórico mais importante ficou em docs/distrobox-gaming-prompts.md.

Vale um esclarecimento: aqueles prompts no GitHub não são as minhas mensagens cruas, do jeito que saíram na hora. Depois que tudo funcionou, eu pedi pro próprio Claude reescrever os prompts de forma organizada e detalhada, só pra fins de documentação. Os prompts originais eram bem mais simples e bem menos específicos. Eu descrevia o objetivo e deixava o Claude descobrir sozinho paths, arquivos de configuração, formatos e comandos necessários.

O primeiro prompt criou a box com --nvidia, --home separado e os mounts corretos. O segundo resolveu os três problemas clássicos do Arch dentro de Distrobox: sudo, multilib e o dummy package de nvidia-utils. O terceiro instalou a base de gaming, inclusive um detalhe que eu teria esquecido fácil se estivesse fazendo na mão: pipewire-pulse, necessário pra vários emuladores não ficarem mudos nem perderem sincronia.

O ponto não é o texto em si. O ponto é o método. Eu não preciso lembrar a ordem exata, nem as opções precisas, nem onde está a documentação de cada detalhe. Eu descrevo o objetivo e deixo o agente carregar o piano. Fico no papel de tech lead: observando, revisando, corrigindo direção quando precisa, e mandando continuar.

O projeto no GitHub

O setup vive em akitaonrails/distrobox-gaming, estruturado como um projeto Ansible. 17 roles cobrem desde criação da box, bootstrap de pacotes, seed de configs, instalação de DLC, configuração de controle, até verificação pós-setup. Os playbooks principais são:

• site.yml: setup completo do zero
• reset-configs.yml: reset só das configs (útil quando você quer zerar tuning e redeployar)
• backup.yml / restore.yml: snapshot e restauração do container inteiro via podman commit
• refresh-shadps4.yml: atualização standalone do shadPS4
• install-xenia.yml: instalação opcional do Xenia Manager (Wine prefix)

O passo a passo completo está em docs/rebuild-runbook.md. As decisões de pacote (por que AUR em vez de Flatpak, por exemplo) estão em docs/distrobox-gaming-packages.md.

Por que não Nix?

Alguém vai perguntar. “Você tá recriando ambiente reproduzível. Por que não usar NixOS, ou pelo menos nix-shell/flakes?”

Eu considerei e descartei. O ecossistema de emuladores que eu preciso vive no AUR. Pacotes -bin do AUR são wrappers de AppImage que empacotam o binário oficial do upstream sem compilar nada. rpcs3-bin, pcsx2-latest-bin, eden-bin, duckstation-qt-bin, shadps4-bin — esses binários acompanham o upstream praticamente no dia do lançamento. No Nixpkgs, muitos desses emuladores ficam semanas ou meses atrás do release, e alguns nem existem. Criar um overlay Nix pra cada emulador que eu preciso, manter, e lidar com os patches de compatibilidade quando upstream muda, é trabalho que eu não quero ter.

Tem também o modelo mental. Eu não quero aprender a linguagem Nix, o sistema de derivações e o modelo de avaliação pra montar um ambiente de games pessoal. Ansible eu já conheço, as roles são pastas com tasks em YAML, e o debug é ansible-playbook -vvv. Quando dá errado, eu leio a mensagem de erro, abro o task que falhou, e sei exatamente onde mexer. Se eu precisasse do mesmo nível de reprodutibilidade em escala, num cluster, com rollback atômico, aí sim Nix teria argumento. Pra um distrobox com emuladores na minha máquina pessoal, Ansible resolve com muito menos atrito.

Flatpak também foi testado e descartado. O bwrap (bubblewrap) do Flatpak não aninha direito dentro das mount namespaces do Docker, então apps Flatpak simplesmente não rodam dentro de distrobox. A alternativa seria instalar Flatpak no host, mas aí você volta ao problema de poluir a máquina de trabalho com pacotes de gaming. Além disso, as versões Flatpak de emuladores ficam bem atrás do AUR — o pcsx2-latest-bin do AUR tracka o AppImage 2.7.x, enquanto o Flathub ainda distribui a v2.6.3.

Plataformas cobertas

O setup cobre 12 plataformas hoje:

RetroArch entra por cima pra cobrir o resto (NES, SNES, Genesis, N64, arcade, etc.), com 21 cores do buildbot e 8 asset packs (databases, shaders, cheats, overlays, autoconfig).

Frontend é ES-DE. As definições dos sistemas customizados ficam em ansible/group_vars/all/esde.yml e cada emulador entra com um wrapper que já sobe com as variáveis certas de GPU (voltarei nisso).

GPU hardforce pra NVIDIA

Num sistema híbrido com NVIDIA dGPU + AMD iGPU (meu caso no desktop), Vulkan às vezes escolhe o iGPU sozinho e o resultado é emulador rodando a 15 fps enquanto a 5090 fica parada. A solução é forçar o ICD Vulkan da NVIDIA em todos os launchers.

Cada entrada de desktop rendereizada pelo Ansible exporta VK_ICD_FILENAMES apontando pro ICD da NVIDIA, e o wrapper do ES-DE faz a mesma coisa antes de lançar qualquer core. Em combinação com a flag --nvidia na criação da box, que bind-monta os drivers do host em read-only, o resultado é previsível: Vulkan sempre na dGPU NVIDIA, independente do estado do sistema na hora.

Isso vale principalmente pra quem tem setup híbrido. Num desktop com só uma GPU, o ICD filtering é placebo, mas também não atrapalha.

PS2: PCSX2 com tuning por jogo

A linha Gran Turismo é meu vício declarado. Cada versão precisa de tweak específico. O setup do PCSX2 hoje tem configs globais razoáveis (Vulkan, 4x SSAA, widescreen 16:9, Xbox-style bindings, FXAA + PCRTC antiblur, 16x anisotropic, deinterlace Automatic) e per-game INIs pros títulos que eu realmente jogo:

• Gran Turismo 3 A-spec (SCUS-97102 + bundle PBPX-95503): widescreen pnach, pack de retextura opcional (desabilitado por default porque NFS causa flicker em cutscenes de showcase de carro)
• Gran Turismo 4 USA (SCUS-97328): HD HUD do Silentwarior112, pack completo de retextura, patches do Silent pra gatilho e câmera, widescreen pnach
• Gran Turismo 4 Spec II (SCUS-97436, CRC 4CE521F2): caso especial — os HD packs de GT4 vanilla são linkados via symlink porque o Spec II tem mesma estrutura mas CRC diferente. Widescreen pnach renomeado pra bater com o CRC. Deinterlace mode 8 (Adaptive TFF), ShadeBoost tuning (+10 saturação, +3 brilho, +2 contraste) pra corrigir ghosting de pause-interlace e saturação anêmica do upscale
• Enthusia Professional Racing (SLUS-20967): HD textures + widescreen
• Ridge Racer V (SLUS-20002): widescreen + no-interlace pnach

Os pnach files do Silent e da comunidade são baixados automaticamente pelo role pcsx2_textures, que também faz o deploy do pack de cheats do NAS e instala os HD packs do Spec II via symlink. Widescreen é ligado via gamesettings por CRC (PCSX2 identifica jogo por CRC antes de aplicar o pnach).

Sobre versão do PCSX2: o pcsx2-latest-bin do AUR tracka a linha 2.7.x, que é onde todas as features modernas estão (texture replacement, FXAA, PCRTC antiblur). O pcsx2 padrão dos repos oficiais do Arch ainda está na 2.6.3. A diferença é mais de 250 commits de correção e feature novo.

PS3: RPCS3 com per-game configs curados

RPCS3 tem um detalhe chato: configs por jogo ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. O formato do arquivo tem versão, e se você gerar um YAML manualmente com versão errada, o RPCS3 rejeita silenciosamente e volta pro default. Isso custou tempo pra descobrir.

A role rpcs3_per_game_configs resolve isso assim:

1. Query o compatibility DB da comunidade RPCS3 pra pegar os presets recomendados por título
2. Aplica overrides curados por cima pra títulos que eu sei que precisam de ajuste específico (tipicamente GT5 e GT6)
3. Salva o YAML com a filename convention exata (config_<SERIAL>.yml, prefixo config_ obrigatório)

Na linha Gran Turismo:

• GT5 (BCUS98114, BCES00569): Resolution Scale 300%, Shader Precision Ultra, Force High Precision Z, SPU XFloat Accurate, Multithreaded RSX. Combinação que mata o dithering típico do RSX sem quebrar a GT series safety config (WCB/RCB off).
• GT6 (BCES01893 + variantes regionais): caso especial, versão travada em v1.05. Patches 1.06+ regridem com superfícies pretas em carros no menu garagem. O script extract_ps3_dlc.py tem per-title PATCH ceiling justamente pra pinar o GT6 no 1.05 mesmo quando o PSN cuspe patches mais novos. Além disso, Force CPU Blit ligado é mandatório (sem ele, flicker de tela inteira). O trade-off é que o retrovisor fica permanentemente preto — ligar WCB restauraria o retrovisor mas downgradaria pra 720p nativo. Prefiro perder o retrovisor.

Mais detalhes desses dois em docs/gt5-rpcs3.md e docs/gt6-rpcs3.md.

Update checker de PS3

Pra não ter que abrir a GUI do RPCS3 e ficar clicando em Download Game Updates jogo por jogo, criei um script em Python: check_ps3_updates.py. Ele percorre os jogos instalados em dev_hdd0/game, parseia o PARAM.SFO pra pegar a versão atual de cada título, consulta o servidor de updates da PSN (a0.ww.np.dl.playstation.net) e compara com o cache local de patches. --list mostra o diff; --download baixa o que falta. --max-version respeita os teto por título (ex: 1.05 pro GT6).

O primeiro scan na minha biblioteca achou 51 de 72 jogos com update disponível, 69 patches faltando localmente, uns 24 GB no total. Só o GT6 sozinho tinha 16 patches faltando, da 1.07 até 1.22, que eu descartei pelos motivos acima.

Os patches chegam como pacotes PSN tipo 0x0001 sem criptografia, então o próprio extract_ps3_dlc.py consegue instalar depois. A chamada padrão:

distrobox enter gaming -- python3 scripts/extract_ps3_dlc.py \
  "/mnt/terachad/Emulators/EmuDeck/roms_heavy/ps3-DLC" \
  --dest "/mnt/data/distrobox/gaming/.config/rpcs3/dev_hdd0/game"

Acompanhar versão de DLC de PS3 manualmente, jogo por jogo no RPCS3, é inviável. Vira lista de tarefas eterna e você só descobre que tinha patch 1.22 quando o jogo crasha.

PS1: DuckStation com per-game

A trilogia Gran Turismo começa no PS1, e a qualidade ali só sobe se você ligar as coisas certas:

• Gran Turismo (SCUS-94949): built-in WidescreenHack do DuckStation (não existe cheat pra esse jogo), PGXP ligado
• Gran Turismo 2 Simulation (SCUS-94455): widescreen cheat + 8 MB RAM cheat (fix de áudio em track crowded), filter JINC2
• Gran Turismo 2 Arcade (SCUS-94488): mesmo tratamento do Simulation

Global defaults: Vulkan, 8x upscale, JINC2 como filter default.

Os cheats pro GT2 saem de um repositório de widescreen fixes e são ligados automaticamente na pasta de cheats do DuckStation.

Switch: Eden com DLC, update e cheats

No Switch, eden-bin é o emulador. A integração automatiza três coisas que antes eu fazia na mão:

1. Install de DLC e update: o role install_dlcs aponta pro diretório de dumps no NAS, identifica os arquivos .nsp/.nsz/.xci/.xcz, e instala tudo em ~/.local/share/eden/nand/user/Contents/registered/. Se o dump está bagunçado (patches e DLC misturados em flat folder), o script reorganize_switch_nsps.py sorteia tudo por Title ID antes.

2. Cheats Atmosphere: os cheats em formato Atmosphere vão symlinkados pro load path do Eden (~/.local/share/eden/load/<TITLE_ID>/cheats/). O role switch_cheats faz isso por todos os títulos cobertos pelo pack do NAS.

3. Update checker: check_switch_updates.py lista títulos com update disponível vs o que tá instalado localmente. Útil pra não perder patch importante de jogo que sai atualização ainda.

Atenção ao detalhe que me queimou: QT_STYLE_OVERRIDE precisa ser desarmado antes de lançar o eden-bin, senão ele conflita com Kvantum e quebra a UI. O wrapper já faz o unset antes do exec.

Xbox 360: Xenia Manager via Wine

Xbox 360 ainda é território áspero no Linux. Não tem emulador nativo decente. A melhor rota hoje é Xenia rodando via Wine, gerenciado pelo Xenia Manager.

Isso é opt-in no meu setup. O playbook install-xenia.yml cria um Wine prefix dedicado, baixa o Xenia Manager, e registra os launchers. Não faz parte do site.yml principal porque nem todo mundo quer Wine no meio do caminho.

Project Forza Plus (Forza Motorsport 2/3/4)

Forza antigo ainda é o rei do simcade de geração passada. Rodar FM2/3/4 no Xenia requer mods da comunidade Project Forza Plus: patches de compatibilidade, mods de performance, instalação de title updates específicos. Documentei o processo em docs/project-forza.md.

Project Gotham Racing 3 e 4

PGR3 roda razoavelmente bem no Xenia Canary. PGR4 precisa de ajuste específico: render_target_path_vulkan = "fsi" no config, senão algumas races quebram com artefato visual. Documentei o setup em docs/xbox360-pgr.md. Áudio do PGR4 no NVIDIA ainda tem problema de XMA decoding que gera garbage intermitente. Tem issue aberta no xenia-canary, sem resolução up até agora.

Title Updates em batch

Title Update pra jogo de Xbox 360 era distribuído pela Xbox Live, que já foi desligada. A alternativa é o archive.org, que tem o catálogo completo preservado. Escrevi scripts/download-xbox360-tus.py pra automatizar:

distrobox enter gaming -- python3 scripts/download-xbox360-tus.py \
  --src /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360 \
  --dest /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360-updates \
  --dry-run

O script precisa do CLI internetarchive autenticado (ia configure uma vez, guarda o token). Ele scaneia a pasta de jogos, faz match contra o manifest do archive.org (cacheado localmente), prioriza por região (USA > World > Europe > Japan), e baixa via ia download --checksum com retry automático. Os .zip resultantes vão pro Xenia Manager via Manage → Install Content, que extrai pro diretório correto (000B0000/).

O setup completo tá em docs/xbox360-title-updates.md.

Steam no distrobox

Desde que o Proton virou cidadão de primeira no Linux, faz sentido ter Steam também no gaming box. Adicionei o pacote steam no Ansible (que puxa multilib e dependências 32-bit), montei /mnt/data/steam em read-write pra a biblioteca persistir fora do container, e criei launcher no host.

Na prática, isso me permite rodar jogos Steam via Proton lado a lado com emulação, sem precisar alternar ambiente. O mini-PC com RTX 4090 continua sendo a máquina principal de Steam no cockpit de sim racing. O desktop é fallback e ambiente de teste.

Shell e controle por controle

Shell mínimo dentro da box

Quando eu entro no gaming box via distrobox enter gaming, eu quero prompt decente mesmo pra troubleshooting rápido. Instalei zsh + starship com config mínima, zero plugins exóticos. Não é meu setup de dev full, é só “prompt que mostra path e git branch sem me dar vergonha”.

Dolphin e o inferno do controle moderno

Dolphin sempre foi o rei do atrito manual. Se você usa um controle mais moderno, como meu 8BitDo Ultimate 2, precisa lembrar como eu gosto do mapeamento de GameCube, como adapto o Wii Remote, quando usar perfil de Nunchuk, quando trocar pro Classic Controller. Eu não tenho a menor paciência pra reconstruir isso na mão toda vez. Os perfis ficam prontos em config/emulator-overrides/dolphin/Profiles/ e são copiados pelo role seed_configs. Detalhes em docs/controller-hotkeys.md.

Alguns tropeços que sobraram

Nem tudo virou magia. Emulação sempre tem casca de banana.

Flycast, por exemplo, tem uma armadilha irritante. O arquivo emu.cfg usa chaves rend.* dentro da seção [config]. Se você cria uma seção [rend] separada, parece certo, mas o emulador simplesmente ignora e depois reescreve tudo com default medíocre. A correção virou wrapper dedicado em $DG_BOX_HOME/bin/flycast-hires:

$DG_BOX_HOME/bin/flycast-hires \
  -config config:pvr.rend=4 \
  -config config:rend.Resolution=2880 \
  -config config:rend.EmulateFramebuffer=no \
  -config config:rend.WideScreen=yes

Detalhes em docs/flycast-resolution.md.

shadPS4 ainda está longe de ser um caso encerrado. O setup atual é focado em Driveclub, com config espelhada, patch XML e links dos sys_modules do firmware 11.00. E isso não foi por acaso: eu gosto muito de Driveclub. Aliás, é praticamente o único jogo ainda preso no PS4 que eu realmente queria conseguir rodar direito. Eu já vi vários vídeos no YouTube mostrando o jogo funcionando, mas até agora eu mesmo não consegui fazer isso rodar de forma satisfatória no Linux. Documentado em docs/driveclub-shadps4.md. A parte boa é que agora eu não dependo mais de memória muscular pra lembrar como lançar, com qual patch, em que pasta, com quais módulos. A parte ruim é que emulação de PS4 ainda é emulação de PS4. Não existe script que faça upstream amadurecer mais rápido. Se alguém souber como fechar essa configuração no Linux, olhe o projeto no GitHub e mande um PR.

Ridge Racer V tem um flickering de textura de carro documentado nas issues do PCSX2 (#3639, #13729). O renderer Hardware é aceitável pra jogo de corrida onde você não fica admirando parado o modelo. Software renderer resolve mas mata performance. Escolhi aceitar o flicker.

O ganho real não é só automação

Seria fácil resumir isso como “olha que legal, usei IA pra automatizar shell script”. Não é isso.

O ganho real é mais chato e mais importante: eu parei de gastar energia mental com trabalho braçal. Não precisei mais lembrar comando raro. Não precisei manter dezenas de abas com wiki, issue, fórum e README. Não precisei deixar meia dúzia de terminais espalhados dando tail em log enquanto tento lembrar que opção escondida de GUI o emulador insiste em regravar no primeiro boot. Eu passei a trabalhar em conversa.

Eu digo pro agente o objetivo. Ele procura os arquivos, lê os logs, encontra o formato certo do config, compara defaults, propõe correções, escreve script, valida paths, verifica UID/GID, confere symlink quebrado, gera wrapper, exporta launcher. Eu continuo responsável pelas decisões, claro. Mas parei de ser digitador de comando raro.

Esse é o ponto que mais me interessa no uso de coding agents em Linux. Eles reduzem dramaticamente a fricção de entrada. Muita gente desiste do desktop Linux não porque o sistema seja incapaz, mas porque a curva de tuning historicamente foi irritante demais. Ter um assistente capaz de ler docs, cruzar config, propor automação e executar com supervisão muda esse jogo.

Se você quiser reproduzir

O repo foi publicado pra isso:

git clone https://github.com/akitaonrails/distrobox-gaming.git
cd distrobox-gaming/ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml  # ajuste paths da sua máquina
ansible-playbook site.yml

Xenia é opt-in:

ansible-playbook install-xenia.yml

Leia o README.md e o docs/rebuild-runbook.md antes. Eu não distribuo ROM, BIOS, firmware nem chaves. O repo só detecta, linka e configura o que você já tem na sua própria máquina.

Se você preferir a rota com Claude Code

Minha recomendação é simples:

1. Comece pelo objetivo, não pelo comando. “Quero um distrobox Arch com GPU NVIDIA, home separado, ROMs read-only e Steam rw” é melhor do que despejar meia linha de shell sem contexto.
2. Peça sempre pra documentar o que está fazendo. Se der certo, promova o resultado a script ou role. Se não documentar, você acabou de fabricar uma gambiarra descartável.
3. Trabalhe em fases. Criação da box. Bootstrap. Config de emuladores. Export de launchers. Verificação. Foi exatamente assim que eu quebrei o problema.
4. Peça verificações objetivas. command -v, existência de arquivos, symlinks quebrados, UID/GID, path de ROM, áudio, GPU. A melhor automação é a que falha cedo.
5. Não use agente como papagaio de comando. Use como assistente técnico. Você continua revisando as decisões e mandando ajustar o rumo.

Pra mim, esse foi o ganho. Eu saí do zero pra uma máquina de emulação muito mais completa sem precisar customizar tudo na unha, em GUI, uma janela por vez. E, dessa vez, terminei com energia pra fazer o que eu queria desde o começo.

Jogar.

Como podem ver, eu tenho praticamente todos os handhelds possíveis e imagináveis. Então acho que tenho alguma propriedade pra falar sobre as vantagens e desvantagens da maioria dos mais populares. E eu tinha mais, mas fui doando pra amigos com o tempo. Esses são os meus favoritos.

Vou falar dos hardwares primeiro e na segunda parte do artigo vou falar um pouco dos softwares também. Use os links de seção na direita (na versão desktop), pra navegar onde quer ler primeiro.

Já aviso que vou ser preguiçoso e nas tabelas de especificações, sim, é ChatGPT pra ajudar. Senão é muito detalhe kkkk 🤣

Ambernic RG400M

Especificações

Este é um dos mais antigos que eu ainda tenho. Ambernic é a marca que eu mais gosto e um dos mais confiáveis. De vez em quando lançam modelos esquisitos, mas no geral são bem consistentes na qualidade.

Esse modelo 400M acho que não existe mais, mas o sucessor dele é RG477M e recomendo assistir o review do canal Retro Game Corps:

Durante todo o artigo vou sempre linkar pros reviews desse canal porque considero que o Russ faz os reviews mais completos. Ele realmente vai fundo em cada detalhe, tamanho dos botões, peso, compatibilidade, tudo. É o único canal que você precisa assistir.

Pra 2025 o 400M/477M é antiquado, inclusive é caro, a USD 280, sem considerar frete e taxa bostil (que vai dobrar esse preço). Isso porque ele tem corpo de alumínio, o que dá uma sensação bem mais premium do que os baratos de plástico. Porém, eu acho que a maior desvantagem dele é que a resolução da tela é só 1280x960. Vou falar de resolução em outra seção, mas acho isso baixa resolução.

Quer dizer, pra jogar coisas como Gameboy, funciona super bem, mas se for pra Mega Drive, Super Nintendo, já começa a ficar apertado. Acima disso já sinto pixelizado mesmo numa tela pequena de 4.0".

O 477M tem tela maior, inclusive é isso que os nomes querem dizer: 400M tem tela de 4.0" e 477M tem tela de 4.7". O 400M tem SoC (System on a Chip) Unisoc T618 2.0Ghz e o 477M tem o MediaTek Dimensity 8300 3.35Ghz. Triplo de RAM (4G LDDDR4X vs 12GB LPDDR5), bateria um pouco maior (4.500 mAh vs 5.300 mAh).

Parece potente mas é porque esse handheld roda Android. Eu particularmente não curto handhelds Android. Depois falo porque.

No geral é um excelente handheld, pequeno, premium, roda bem até PS1 e dá pra arriscar um PSP, mas a tela não foi feita pra isso (PSP é widescreen, este é 4:3). Só que eu não recomendo ele é muito caro e a performance não condiz com o preço, só é caro porque é de alumínio. Pelo mesmo preço se compra outros muito melhores, como vou mostrar a seguir.

TRIUMUI BRICK - MIYOO MINI

Os próximos da lista são os verticais “miniatura”.

O mais clássico de todos é sem dúvida o Miyoo Mini Plus:

Falei que 4.0" e 1280x960 acho pequeno? O Miyoo Mini Plus tem tela de só 2.8" e resolução de 750x560. O SoC é muito bom com ARM Cortex-A7, 1.2Ghz que consegue rodar bem até PS1. Nessa tela pequena é mais indicado pra coisas como Gameboy, GameGear e outros portáteis antigos. Dá pra jogar NES, MasterSystem, MegaDrive. Mas PS1 já começa a ficar muito pequeno pra conseguir ler.

É difícil de descrever quão pequeno é essa tela. Compare acima a tela com meu dedão pra ter uma noção. É extremamente pequeno. Não recomendo pra nada muito maior que jogos de Gameboy mesmo. Se você for jovem, com boa vista, vai conseguir jogar melhor. E vai ficar com a vista ruim como a minha mais rápido também kkkk 🤣 fica pelo seu risco.

Eu uso óculos de muito grau, então essa tela é muito pequena pra mim. Mas a construção da Miyoo é muito boa. Ela tem aquela sensação de Gameboy clássico mesmo, só que em miniatura. O fator nostálgico é muito forte.

O melhor OS pra ela é o Onion OS, que torna o Miyoo ainda muito melhor. Uma coisa comum é que todo handheld vamos acabar substituindo o OS que vem por um open source melhor. É muito satisfatório a UI pra salvar estado do game, depois recarregar de onde parou.

De longe uma das melhores UIs pra handhelds. Todo OS deveria copiar o OnionOS. De novo, o review do Russ sobre ele é bem detalhado:

Depois do Miyoo Mini Plus, que considero “miniatura com tamanho suficiente” é o TrimUI Brick. Ele é parecido em formato e funcionalidades com o Ambernic RG35xx Plus então qualquer um dos dois vai atender quem quer esse tamanho.

A tela do TrimUI é consideravelmente melhor em qualidade, cores saturadas, mais nítido, mais brilhante. É uma das melhores telas nesse formato que existem. Não tem como errar. Comparado com o Miyoo Mini, veja a diferença de qualidade de tela e, principalmente o tamanho!

E veja como a área útil não é muito menor que a tela de um Gameboy Advance SP de verdade, por isso é bem jogável.

Pra melhorar, existem outros OS que dá pra instalar no TrimUI, como o lendário Knulli, mas você pode optar por pedir um microSD card já configurado e com vários jogos bons (não aquela lista genérica gigante de jogos repetidos que vem nos outros). Ele vem com o SurwishOS, que não é um OnionOS mas não está longe.

Ou seja, “out-of-the-box”, sem precisar configurar nada, o TrimUI Brick é um dos mais simples. Só ligar e já jogar, sem precisar mexer em OS ou fazer qualquer tuning. Plug and play. É fácil, um dos melhores que posso recomendar.

Novamente, roda bem até PS1, arrisca um PSP mas PSP é muito pesado mesmo. Não é o indicado. O ideal é até Gameboy Advance. Assista o review do Russ:

Numa classe um pouco superior, mais parecida com Ambernic RG35XX vertical, tem os Retroid Pocket Classic. Eu nunca tive, mas ouço falar muito bem também. Em particular a versão com 6 botões igual controle de luta do Mega Drive/Sega Saturn:

Também é uma boa recomendação e tem o review do Russ.

Ambernic RG35XX SP

Se eu tivesse que escolher só um, ficaria bem dividido com o TrimUI Brick, mas acho que acabaria sempre voltando pra este: Ambernic RG35XX SP

Como expliquei antes, RG400M significa tela de 4", então RG35XX significa tela de 3.5". É um pouco maior que os 3.2" do TrimUI Brick, um pouco menor que o RG477M. Na minha opinião acho que este é o “sweet-spot” entre portabilidade e visibilidade.

O “SP” significa que ele copiou o formato do lendário Gameboy Advance SP", a segunda revisão da Nintendo que introduziu o formato “clamshell”, que se dobra ao meio. A grande vantagem é que esse formato protege a tela quando fechada e não precisamos de uma bolsa pra quando queremos jogar na mochila, preocupados em riscar a tela.

Em termos de specs, todos os que falei até agora tem performance parecida. Os RG477M são mais poderosos porque rodam Android (que é bem mais pesado), os demais rodam Linux então é bem mais leve.

Novamente, depende muito de quem é você. Por exemplo, eu tenho mãos pequenas, e mesmo pra mim um Miyoo Mini e até mesmo o TrimUI Brick eu sinto desconfortável pra jogar por muito tempo. Tenho que ficar segurando o console só com os dedos. Já o RG35XX SP se apoia na palma das minhas mãos, então eu sinto muito mais confortável e ergonômico pra jogar.

Por causa disso também eu não recomendo a nova versão RG34XX SP:

Também não recomendo o Miyoo Flip v2:

O diferencial deles são os dois controles analógicos no final, que seria bom pra jogar coisas como Nintendo 64, os jogos mais novos de PS1, PSP, Dreamcast. Mas tem um porém: nenhum deles tem potência suficiente pra jogar acima de PS1. Sim, dá pra jogar mais ou menos bem Nintendo 64 e Dreamcast, mas não roda tudo.

Daí o que eu elogiei que dá pra apoiar na palma da mão se perde com os analógicos, porque pra usar os dedões nele, precisa segurar o handheld muito pra cima pra alcançar. Daí tem outro problema: os botões de ombro, que ficam atrás, os L1 e R1, ficam longe de apertar com os indicadores. Pra jogar FPS (jogos de tiro em primeira pessoa), é horrível. Então um Golden Eye 007 do Nintendo 64 fica ruim de jogar, mesmo com os analógicos.

Além disso note o nome: RG34XX, significa que a tela cai de 3.5" pra 3.4". Falei antes que eu acho 3.5" ideal e nessa nova versão é um downgrade. O erro é tentar achar que dá pra ter um único handheld que vai ser bom pra tudo. Não tem isso.

Outro canal que eu gosto muito é o Wulff Den e ele faz essa consideração nesse review:

Minha recomendação sempre é o RG35XX SP. Não precisa de botões analógicos e vai rodar tudo até PS1 sem problemas. Mais que isso, você quer um handheld MAIOR e mais potente.

Na categoria “clamshells” um que vale a pena olhar é o Retroid Pocket Flip 2, que é maior, mais potente e mais caro. Mas ouço falar bem também:

Novamente, assista o review do Russ

Ayn Odin 2

Vamos falar dos mais potentes. Pra mim, o melhor de todos, que roda basicamente tudo até Nintendo Switch, é o Odin 2 - e está pra sair o Odin 3, que vai ser melhor.

O preço não é muito maior que o RG477M, mas ele é infinitamente melhor. Na faixa de USD 300 (sem frete, sem impostos), é o melhor custo-benefício.

Veja as especificações, é um Qualcomm Snapdragon 8 Gen 2. É o mesmo chip que se tem em smartphones Android midrange pra high-end. Com GPU Adreno 740 e de 8GB até 16 GB LPDDR5X. Bateria de 8.000 mAh (maioria dos smartphones nessa categoria tem bateria de 5.000 mAh ou menos).

O principal: é uma tela IPS 6" de 1080p de resolução (Full-HD). Nesse tamanho, até eu que sou cegueta, consigo enxergar qualquer jogo sem problemas. Um Nintendo Switch original tem tela de 6.2", então é levemente menor. É basicamente a potência de um Switch 2, na realidade.

O review do Wulff Den diz tudo:

Na prática, veja na foto os controles: se quiser ter sticks analógicos, eles precisam estar no formato de Xbox ou Switch, na horizontal, esse é o formato mais ergonômico pra jogar por bastante tempo. Por isso falei que os Miyoo Flip ou RG34XX SP não vale a pena. No Odin 2 sim, dá pra jogar Halo, Golden Eye, Doom, etc sem problemas. E como é um Android também dá pra instalar Call of Duty da Play Store sem problemas.

Agora, minha reclamação pessoal: Android é BEM mais chato pra configurar emuladores do que Linux. De longe mesmo. Precisa de MUITO tempo, MUITA paciência e MUITA tentativa e erro até deixar do jeito perfeito. É tanta coisa que recomendo assistir o guia do Russ sobre isso:

Sério, assista o video, leia o blog post do site dele pra mais detalhes. Você não vai acertar de primeira.

Pelo menos, uma vez configurado, vai rodar tudo liso. PSP com 3x resolução, Dreamcast com 3x resolução, PS2 com 3x resolução, GameCube com 2x resolução, até Switch Full-HD Docker mode. É meu modelo preferido pra jogar PSP mesmo: Ridge Racer 2 fica perfeito.

Nessa categoria de Android horizontal, outra boa recomendação é o Retroid Pocket 5, na mesma faixa de preço e também ouço falar bem. Em particular todo mundo fala muito bem da qualidade da tela.

Novamente, assista o review do Russ.

Ayaneo Pocket DMG

Se tiver dinheiro pra jogar fora mesmo, também recomendo o Ayaneo Pocket DMG. Esse monstro começa na bagatela de USD 420 (sem impostos, sem frete, na config básica). Se escolher tudo, sobe até USD 690. Mais caro que um Playstation 5!!! Realmente não dá pra recomendar, é o pior custo-benefício de todos.

Ele é mais potente que o Odin 2 com um Snapdragon G3x Gen 2 e Adreno A32. É comparável a um bom Samsung Galaxy da vida.

A construção dele é super-premium, case, botões, tudo. A tela é um pouco pequena, de 3.92" (acima do que eu falei que considero ideal no 35XX SP), mas é OLED, super nítido, super brilhante, cores super saturadas, uma das melhores telas em qualquer handheld, comparável mesmo à tela de um Samsung Galaxy. Não tem como errar com essa tela. Todo jogo fica ainda mais bonito nela. Por isso custa caro!

Pra não dizer que é perfeito, os botões são um pouco “mushy” enquanto eu prefiro botões mais “clicky” com os Ambernic. Mas não significa que são ruins.

Por ser potente, também rodaria até Nintendo Switch sem problemas, mas aí a limitação é o tamanho da tela. Não acho que vale a pena rodar jogos feitos pra TVs grandes numa tela tão pequena assim. Ela é melhor mesmo pra retro-games, mas vai rodar PS2 e Gamecube de boas mesmo, com todos os filtros e upscaling que quiser pra deixar mais bonito que o original.

O review do Wulff Den diz tudo:

Sendo Snapdragon, esse handheld também é Android, então também é um saco de configurar. Mas no final roda tudo direitinho mesmo. Só seguir o guia do Russ.

Ele tem esse stick analógico no canto inferior esquerdo e tem um touchpad na direita que simula stick analógico direito. Não é confortável pra FPS, é usável pra algumas coisas como reposicionar câmera em jogos de plataforma 3D. Mas não espere usar o tempo todo. Tem o mesmo problema do Miyoo Flip que falei acima: fica MUITO pra baixo. Não é confortável num handheld vertical.

Se quiser jogos que requerem sticks analógicos, é melhor ficar num handheld horizontal, como o Odin 2, SteamDeck, Rog Ally, etc. O nome DMG é de Dot-Matrix Gameboy, que é o Gameboy Clássico. E o Pocket DMG de fato tem todos os fatores nostálgicos do DMG.

Eu, que tive o clássico, gosto muito desse formato. Mas eu acho que se você não tem nostalgia desse período, não vai fazer muita diferença. Esse formato limita jogos feitos pra telas wide-screen. Nesse caso o formato horizontal similar a Nintendo Switch é mil vezes mais ergonômico.

Como falei antes, é pra quem tem nostalgia e dinheiro pra jogar fora. Nada justifica comprar esse aparelho, por melhor que ele seja. É pra colecionador como eu. Odin 2 ou Retroid Pocket 5 tem custo-benefício melhores pra essa categoria.

Analog Pocket

Falando em caros, chegamos na categoria super-premium. E o mais super-premium de todos com certeza é o Analog Pocket.

Essa desgraça nunca está em estoque. Eu mesmo encomendei na época da campanha de lançamento na Indiegogo e levou acho que 1 ano pra chegar na minha casa. Custou os olhos da cara e mais alguns rims com os impostos do Brasil.

Ele é caro, mas o Pocket DMG é mais caro. Felizmente o preço hoje - se estiver em estoque - é “só” USD 220 (sem frete, sem impostos). É razoavelmente acessível. Mas ele é feito pra um público muito específico: quem gosta de FPGAs.

A Analog é famosa por não usar emuladores via software, como RetroArch. Todos os handhelds que comentei até agora usam emuladores: Citra, RPCS3, PCSX2, DuckStation, Sudachi, Yuzu, etc.

O Analog Pocket vem com o Altera Cyclone V FPGA. Ele foi feito pra rodar consoles antigos como se fosse o hardware original. Não é 100% perfeito (porque os cores de cada console são codificados via engenharia reversa dos chips, mas não é garantia que foram clonados 100%, depende de quem codificou os cores).

No caso do Pocket, ele tem slot pra encaixar cartuchos de verdade de Gameboy e Gameboy Advance. Dinamicamente ele copia a ROM pra memória RAM, carrega o core do Gameboy, e dali é como se estivesse rodando um Gameboy de verdade, no hardware original. Então coisas como frame lag, input lag, e qualquer tipo de latência são minimizados ou zerados. E se jogar lado a lado com um Gameboy de verdade, ele tende a ser idêntico, frame a frame.

Pra maioria das pessoas, na prática, isso não importa - ninguém vai ficar comparando quadro a quadro e a maioria dos emuladores via software hoje fazem um excelente trabalho de emular os consoles antigos de uma forma que um jogador médio não vai perceber a diferença. É realmente só pra quem entende os detalhes, como speed runners. Eu mesmo não noto a diferença.

Mas a grande vantagem desse console, pra mim, é a tela. O tamanho dela é só 3.5" e é IPS, não OLED. Mas é um dos melhores IPS do mercado. Brilhante, boas cores. Mais importante, é a mais densa do mercado com resolução absurda de 1600x1440 pixels (absurdos 615 ppi).

Isso é exatamente 10x a resolução do Gameboy original. Significa que ele consegue fazer upscaling de 10x pixel-perfect. Cada 1 pixel do Gameboy original vira 10 pixels no Analog Pocket. Com isso é possível também colocar filtros que simulam a tela dot-matrix verde antiga, no nível do sub-pixel, simulando todos os efeitos colaterais daquela tela obsoleta, trazendo uma sensação ainda mais perfeita de estar jogando um Gameboy de verdade.

Não é exagero. Olhem nessa foto, a simulação dos pixels do LCD antigo. Você enxerga exatamente o mesmo comportamento dos pixels com latência do LCD verde.

Acho que ninguém fez um review mais detalhado do que a Digital Foundry:

Essa tela, sozinha, é razão suficiente pra ter um Analog Pocket se você for um aficcionado por retro-games como eu. É item de colecionador que aprecia qualidade de verdade.

Além disso, eles abriram suporte a openFPGA e isso dá possibilidade de instalar dezenas de outras cores de FPGA feitas pela comunidade open source.

Existem várias ferramentas pra instalar e organizar esses cores, como o PocketSync

Tem FPGAs de arcades antigos, CPS1, NeoGeo, Lynx, PC Engine e muito mais. É como ter o hardware original desses consoles no seu bolso. Não tem experiência igual.

Sim, dá pra rodar tudo isso num emulador no seu PC. Mas vai por mim, essa tela é impressionante. Igualmente tão impressionante quanto o OLED do Pocket DMG. Eles ficam pau a pau em nível de qualidade, mas o Analog tem mais densidade de resolução ainda.

Menção Honrosa: Razer Kishi

Notem como metade dos handhelds que eu falei acima são todos Android. Basicamente chips de smartphone mesmo. Daí você já deve ter pensado, “ué, porque não jogar direto no meu smartphone então?”

E você está correto. Pra isso existem controles especiais pra smartphones, como o meu favorito, o Razer Kishi

Pra você que não pode sair de casa sem seu Genshin Impact, essa é a melhor opção mesmo:

Eu sei que existem outras alternativas, algumas genéricas do AliExpress, e eu não conheço elas. Procure o review específico no YouTube. Cada uma tem suas características. E por causa de tamanho, posição da porta USB-C e coisas assim, nem todo modelo encaixa, por isso é bom ver o site do fabricante pra ver se seu modelo vai encaixar nele. Não é garantido.

Mas ele basicamente funciona como um controle de Xbox conectado via Bluetooth ou USB-C no seu smartphone. Só isso.

O guia de Android do Russ vale pro seu smartphone também então dá pra instalar emuladores e jogar retro-games igual um Odin 2 ou Pocket DMG. A tela de smartphone normalmente é maior e você já carrega ele no seu bolso todos os dias, daí não precisa carregar um segundo dispositivo.

O controle em si não é pequeno, mas é leve. Tem num case que é fácil de jogar na mochila e não ter problema:

Então sim, não precisa gastar a mais com um novo handheld, use seu smartphone ou aquele mais velho que você encostou e não tinha uso pra ele. Pra retro-games vai funcionar muito bem.

Rog Ally X

No outro lado espectro, se quiser o mais poderoso e o mais versátil de todos, tamanho não for problema, dinheiro não for problema, vá pra um Handheld PC mesmo. Na minha opinião, o melhor ainda é o ASUS Rog Ally X

Esse é caro nível notebook, porque é basicamente isso que ele é: um notebook num formato mais compacto. Tem as mesmas tecnologias de um notebook.

A primeira versão (que ainda é boa e superior ao Steam Deck), num Mercado Livre, vai ser faixa de BRL 5.000. A segunda geração que é o “X”, com chip Z1 Extreme vai ser nada menos que uns BRL 15.000. Como falei é nível de notebook e iPhones.

Mas também, se conectar em qualquer Dock USB-C, dá pra conectar num monitor externo, teclado, mouse e ele vira um PC mesmo, rodando Windows 11 normalmente. Dá pra usar pra navegar a web, ver seus e-mails, até programar.

São 24GB de LPDDR5X-7500 (compartilhada com a iGPU Radeon) é bem rápida, tem 2TB de NVME 2280 (full-size), tela de 7" IPS (1" maior que o Switch Original, 1" menor que o Switch 2, Full-HD, 1920x1080 pixels, 120hz, 500 nits de brilho).

O SOC Z1 Extreme é Zen 4, com 8 cores, 16 threads, boost até 5.10 Ghz, com Radeon 780M (12 CUs), TDP de 15 a 30W (essa é a parte que ele é mais fraco que um notebook, lógico, não tem espaço pra dissipar mais calor).

Em comparação a outros chips, ele é mais rápido que um antigo Ryzen 9 5980HS, mais rápido que um Ryzen 5 7535HS. Ou seja é classe de um Ryzen 9 HS. Não chega a ser classe desktop como um Ryzen 9 7945HX ou 8945HX, mas pra um handhed, é muita potência.

E sim, tem outros similares no mercado hoje, como o Lenovo Legion Go que tem tela maior ainda de 8" 120hz, mesmo Z1 Extreme. Ou o Legion Go 2 já com Z2 Extreme, que é arquitetura Zen 5.

Tem o MSI Claw A8 também com Z2 Extreme, tela de 8" 120hz.

Qual o melhor? Não sei. Eu só experimentei o Rog Ally X. Recomendo assistir os reviews do ETA PRiME. Ele faz as melhores comparações de performance e benchmarks desses chips.

A ASUS também firmou parceria com a Microsoft pra lançar o novo ROG Xbox Ally, com Z2 Extreme e um OS de Xbox adaptado pra handheld, que tira a principal desvantagem desses handhelds todos: o fato que Windows 11 é um dos piores OS de todos os tempos pra handhelds. Dá pra usar, mas é bem gambiarra. Já com esse OS oficial, é como se tivesse um Xbox Series no bolso de verdade, com capacidade pra rodar jogos de Steam e outra lojas também.

Eu não tenho, mas fiquei com vontade de experimentar.

Todos esses são mais potentes que o SteamDeck, mas este ainda continua sendo o melhor custo-benefício no segmento e com o melhor ecossistema de mods, acessórios, e tudo mais. E a Valve tem dado bom suporte de atualizações.

Graças a tecnologias como FSR, hoje em dia dá pra fazer upscaling de resolução e frame generation via IA pra ter mais FPS. Então, jogando em medium settings ou low settings, não fica tão ruim. Com chips Z1 Extreme, Z2 Extreme e Ryzen AI Max+, já dá pra subir pra medium ou até high settings e ficar com bom FPS em Full-HD (1080p).

Todos eles tem saída HDMI, então dá pra ligar numa TV ou monitor. Todos eles aceitam controles externos Bluetooth, então dá pra ligar seu controle de Xbox ou 8BitDo da vida. E ele vira tanto um console quanto um handheld.

Mas são caros, faixa que vai de USD 600 a USD 900 dependendo da marca e modelo. São mais caros que um Playstation 5 e quase faixa de um bom notebook mesmo. Dependendo vale mais a pena comprar um notebook com Ryzen AI Max, que vai ter a mesma Radeon integrada e suportar bons jogos.

Portáteis Originais

Vamos a outra constatação importante: qual a melhor forma de jogar handhelds antigos com duas telas, como Nintendo DS e Nintendo 3DS?

Simples: nos handhelds originais.

A forma mais fácil de jogar jogos piratas neles é com os cartuchos R4, acho que não é difícil achar eles em Mercado Livre ou AliExpress. Eles aceitam microSD card e você joga suas ROMs nela, coloca no 3DS e já era.

Nintendo 3DS teve “end-of-life” recentemente e desde então todos os jogos estão facilmente disponíveis online. Leia o Guia de Hacks do 3DS pra saber como desbloquear o seu. Os jogos estão todos no hShop e quando desbloquear seu 3DS vai instalar o App pra abrir esse site e de lá pode baixar direto as ROMS pra memória interna do aparelho também. Existem várias opções.

Também é possível instalar emuladores no 3DS: vai rodar Gameboy, até Genesis e Master System. Não espere rodar um PS1 ou PSP nele, obviamente, é um hardware fraco.

Só tem uma coisa que me desagrada: as telas são velhas e antiquadas. Tem baixa resolução, baixo brilho, baixo contraste. Comparado com a tela do seu smartphone, nem chega aos pés. Mas pra jogar em dual screen, não tem jeito mais fácil.

Sim, vários fabricantes vieram tentando fazer handhelds com duas telas, como o Ayaneo Flip DS mas é extremamente chato de usar ele. Veja este review do Wulff Den:

São extremamente caros (Android ou Windows) e a experiência de software ainda é extremamente ruim. Não compensa pelo que se paga. Melhor ficar com os originais.

No caso de Gameboy Advance, já existem dezenas de bons handhelds com emuladores, então é melhor ficar com os RG35XX SP que eu já recomendei antes.

Mas, caso queira explorar a comunidade de mods, recomendo muito o site Boxy Pixels que fazem cases em alumínio e diversos acessórios pra dispositivos antigos, seja Gameboy, DS, até iPods. Veja este video do canal Macho Nacho que demonstra como fazer esse mesmo Gameboy Advance SP em alumínio:

Foi por causa desse canal que eu comprei o kit e montei o meu. É caro, é um hobby pra entusiastas mesmo. Isso não é pra amadores! Mas se tiver essa vontade, tá aí o site e o canal pra guiar.

Além disso, dá pra jogar ROMs piratas no Advance também. Similar aos cartuchos R4 pra 3DS tem os cartuchos EZ-Flash tanto pra Gameboy DMG/Color quanto Advance. Também são adaptadores de microSD card, onde você joga suas ROMS, pluga no hardware original e ele vai bootar um menu pra escolher as roms.

Eis um exemplo do EZ-Flash no meu Advance SP modificado. A tela está com white balance errado não sei porque, talvez eu tenha cometido algum erro ao montar, mas não parei pra consertar ainda. O importante era só mostrar o menu que aparece no boot pra escolher o jogo.

O cartucho funciona até no Analog Pocket, mas é redundante porque no Pocket posso jogar os ROMs direto nele.

Os Softwares

Agora deixa eu resumir o que você precisa saber de emuladores. O primeiro e mais importante de todos é o RetroArch.

Ele não é um emulador, ele é um front-end pra emuladores. É uma forma mais fácil de instalar os diversos emuladores individuais, cheats, save states, configurar controles que funcionam em todos, filtros, e muito mais.

Os emuladores mesmo ele chama de “Cores” que são “wrappers”/“adaptadores” pros emuladores de verdade. Cada sistema tem diversos emuladores feitos por diferentes pessoas ou grupos, que focam em coisas específicas (rodar maior quantidade de jogos, rodar menos jogos mas com precisão, conseguir rodar com menos recursos - bons pra handhelds fracos, etc).

Vamos ver uma lista básica (isso muda o tempo todo):

Nintendo

• NES: Mesen, Nestopia UE. Ouma
• SNES: bsnes, Snes9x. Ouma+1
• N64: Mupen64Plus-Next (+ParaLLEl-RDP/Angrylion), Project64. Libretro Docs+2Libretro+2
• GameCube/Wii: Dolphin. Dolphin Emulator
• Wii U: Cemu. Cemu
• Switch: Yuzu, Ryujinx
• GB/GBC: SameBoy, Gambatte. sameboy.github.io
• GBA: mGBA. BSNES
• NDS: melonDS, DeSmuME. GitHub
• 3DS: Lime3DS → now Azahar (successor fork). redream.io
• Virtual Boy: Mednafen VB (Beetle VB). Emulicious

Sega

• SG-1000/Master System/Game Gear: Emulicious, Genesis Plus GX.
• Mega Drive/Genesis: BlastEm, Genesis Plus GX. AirDroid
• Sega CD: Genesis Plus GX. AirDroid
• 32X: PicoDrive. GameTechWiki
• Saturn: Beetle/Mednafen Saturn, Kronos/Yaba Sanshiro (faster). GitHub
• Dreamcast/Naomi: Flycast, Redream. mamedev.org+1

Sony

• PlayStation (PS1): DuckStation (accuracy/perf), Beetle PSX HW/SW. Emulicious
• PlayStation 2: PCSX2. pcsx2.net
• PlayStation 3: RPCS3. RPCS3+1
• PSP: PPSSPP. RPCS3
• PS Vita: Vita3K. GitHub
• PS4: shadPS4 (rapid progress; still early). ShadPS4+2ShadPS4+2

Microsoft

• Xbox (OG): xemu, Cxbx-Reloaded. sameboy.github.io+1
• Xbox 360: Xenia. GameTechWiki

NEC / Hudson

• PC Engine/TurboGrafx-16(+CD): Mednafen (Beetle PCE Fast), Ootake (Windows). GameTechWiki+1
• PC-FX: Mednafen (Beetle PC-FX). Emulicious

SNK / Arcade & Handhelds

• Neo Geo AES/MVS (arcade): FBNeo, MAME. ppsspp.org+1
• Neo Geo CD: NeoCD (libretro), MAME. melonds.kuribo64.net+1
• Neo Geo Pocket/Color: Mednafen (Beetle NeoPop), RACE. GitHub

Bandai / Others (handheld)

• WonderSwan/Color: Mednafen (Beetle WSWAN). [sameboy.github.io](https://sameboy.github.io/?utm_source=chatgpt.com
• Atari Lynx: Mednafen (Beetle Handy). Emulicious

Atari (consoles)

• 2600: Stella. GameTechWiki
• 5200/8-bit: Altirra / Atari800. GameTechWiki
• 7800: A7800 (or MAME). GameTechWiki
• Jaguar: BigPEmu. mednafen.github.io

3DO / CD-i / Misc. classic

• 3DO: Opera (libretro). Libretro Docs
• Philips CD-i: MAME (best public option). Vita3K
• Vectrex: ParaJVE. vectrex-emu.blogspot.com
• Intellivision: jzIntv. intellivision.us
• ColecoVision: blueMSX (core) / MAME. Libretro Docs
• Magnavox Odyssey²/Videopac+: O2EM. o2em.sourceforge.net
• Fairchild Channel F, Bally Astrocade: MAME. Vita3K

Arcade (general)

• MAME (breadth/accuracy), FinalBurn Neo (speed/curation). Vita3K+1

Home computers (popular)

• Commodore 64/128/VIC-20/PET: VICE. vice-emu.sourceforge.io
• Amiga: WinUAE (Windows), FS-UAE (cross-platform). [winuae.net+1](https://www.winuae.net/?utm_source=chatgpt.com
• Atari ST/STE/TT/Falcon: Hatari, Steem SSE. hatari-emu.org+1
• ZX Spectrum: FUSE, Retro Virtual Machine. fuse-emulator.sourceforge.net+1
• MSX: openMSX, blueMSX (stale but usable; libretro core still common). openmsx.org+2msx.org+2
• PC-98: Neko Project II kai (NP2kai) (or DOSBox-X for DOS/V/PC-98 modes). Libretro Docs+1
• DOS / Win9x era: DOSBox Staging (games), DOSBox-X (games + Win3.x/9x).

Alguns emuladores são chatinhos, porque estão incompletos ou em desenvolvimento ou bugados ou sem suporte mais. Alguns exemplos:

• Xemu pra Xbox original funciona bem, mas é bem mal otimizado, portanto é bem pesado. Não vai rodar em nada que não seja pelo menos um handheld PC moderno como o Rog Ally ou um PC de verdade.
• Xenia Canary pra Xbox 360 ainda é bem bugado, só funciona em linha de comando (tem uma GUI de terceiros mais ou menos), tem que configurar arquivos pra tunar cada jogo. Meus jogos favoritos como Forza Motorsport 4 rodam com vários bugs visuais e crashes aleatórios que inviabiliza jogar (por isso comprei um Xbox 360 de verdade e desbloqueei).
• RPCS3 avançou bastante, mas não chega aos pés do PCSX2 ainda. Muitos jogos exigem configurações especiais - que não são intuitivos pra um amador, tem que ler o Wiki com muito cuidado, pra cada jogo. Jogos favoritos meus como Gran Turismo 6 ainda não rodam direito.
• shadPS4, esquece por enquanto, ele começou desenvolvimento recentemente, ainda é mais alpha que beta, quase nada roda nele sem muito trabalho. Não é pra amadores.
• Dolphin, até que é bem estável e quase plug and play, mas é mais pesado que um PCSX2. Não vai rodar em hardwares fracos.
• Mupen64 roda bem também, até em Android, mas nem todo jogo ainda roda nele e alguns rodam com pequenos glitches. No geral dá pra jogar, mas não espere perfeição.
• Emuladores de 8-bits, 16-bits, estão bem completos, estáveis, rodam liso qualquer um deles, pode confiar, incluindo arcades via Mame ou FBNEO. Mas no caso desses últimos, eles exisgem romsets (conjuntos de ROMS compatíveis com o emulador), não dá pra pegar qualquer ROM aleatória por aí e esperar que vai rodar. Fuce o Internet Archive pra achar alguns desses romsets.
• Home Computers como openMSX ou DOSBox, lembre que muitos jogos só funcionam com teclado ou mouse ou os dois e talvez não funcione muito bem mesmo mapeando pra controle. Tem que ler o Wiki de cada jogo pra saber.
• Por causa dos processos da Nintendo, emuladores de Switch aparecem e somem, alguém faz um novo fork e reaparece. Yuzu já foi fechado mas forks apareceram. Surgiu Suyu, mas fechou. Ryujinx continua funcionando e é o meu favorito. Android acho que tem Sudachi e outros. Tem que dar uma pesquisada.

RetroArch tem suporte pra quase todos esses emuladores. Portanto só instalando ele, já vai te dar acesso à maioria. Alguns é melhor instalar separado como apps individuais, em particular isso é verdade em Android, por isso falo tanto do guia do Russ e como Android é mais chato.

Em Linux, distros como OnionOS, GammaOS, Surwish, Knulli, MinUI, já vem com RetroArch instado e pré-configurado, por isso são mais fáceis de instalar e usar.

Dá pra usar só o RetroArch, seja em handheld, seja em Android, seja no Windows. Mas a interface dele é bem feia, velha, chata de navegar. Talvez você não se importe, mas depois que tem a experiência de console, como Playstation, Xbox, é chato usar uma interface velha. Pra consertar isso existem diversos front-ends pra colocar por cima do RetroArch, o mais famoso e popular de todos acho que é o EmulationStation

Ele é bonito, dá pra escolher vários temas e fica assim:

Novamente, o Russ do canal Retro Game Corps tem guias pra isso:

• Emulation Station em Android
• Emulation Station no SteamDeck
• Emulation Station no Windows

Tem mais videos, só pesquisar por “emulation station” direto no canal dele e também no blog dele. Tem dezenas de guias por aí, por isso não vou perder tempo detalhando ele. Pára de ter preguiça e pesquisa. O que não falta é material.

No mundo de handhelds Linux, também existe Emulation Station em distros como Knulli, que é um fork do antigo Batocera. E adivinhe: tem guia do Russ:

Já entendeu a única coisa que você precisa tirar deste artigo né: se tiver alguma dúvida sobre esse assunto, pergunte ao Russ, não a mim!

No mundo de SteamDeck e outros handhelds PC, existe outra distro Linux, o Bazzite que é um fork modificado do SteamOS pra rodar fora do SteamDeck.

Assim seu Rog Ally vai funcionar igual um SteamDeck mais potente! Rodando jogos de Steam em Linux via Proton. Eu pessoalmente não fui por essa opção porque já me acostumei com a chatice do Windows 11 e eu gosto de rodar WeMod pra rodar jogos com cheats. Além disso eu instalei outros emuladores que só funcionam em Windows, com os de Sega Model 2 e Model 3. Sim, tem como rodar em Linux com Wine e tudo mais, mas já tá funcionando, deixa assim. Faz no seu.

Pra Emulation Station e outros front-end como Daijisho no Android vão pedir pra você ter uma conta no site ScreenScrapper. Com essa conta dá pra ler as ROMs no seu microSD card e ir no site buscar coisas como imagem da caixa, video de demonstração e tudo mais pra ficar tudo mais bonito.

Última coisa: se eu tenho tantos handhelds, como faço pra compartilhar os saves entre todos eles pra continuar jogando de outro handheld?

Tem dois jeitos: o mais fácil é só tirar o microSD de um e colocar no outro e vai ter os mesmos saves. A outra forma - bem mais complicada (que é o que eu faço) - é subir um container de SyncThing, que é um serviço que syncroniza diretórios entre diferentes computadores (pense um mini-Dropbox). Pra variar, o Russ tem um tutorial:

Conclusão

Entendeu a mensagem do post? Não pergunte “Akita, qual retro-handheld é melhor pra eu comprar?” O coitado do Akita não é tech-reviewer pago, patrocinado, nem monetizado, portanto todos os handhelds que eu tenho, comprei só pra mim. Por isso não tenho nenhum Retroid. Não adianta perguntar se Ambernic ou Ayaneo são melhores que Retroid. Akita não vai saber.

Em vez disso perguntem a tech reviewers que são pagos a patrocinados pra falar disso. Eis minhas recomendações:

• Retro Game Corps
• Wulff Den
• Tech Dweeb
• Taki Udon
• ETA PRIME

Pra quem se interessa por mods:

• Macho Nacho Productions
• The Retro Future

E pra quem se interessa por consertos:

• TronicsFix

Todos eles vão dar respostas melhores sobre todas as suas perguntas sobre todos os modelos de handhelds, consoles, consertos, modificações, softwares, OS, customizações, ROMs e muito mais.

Eu fiz esta página só pra poder dar copy e paste do link pra todo mundo que repetir essas mesmas perguntas daqui pra frente. Acho que cobri tudo que eu sei do assunto!

Finalmente resolvi compilar uma lista com os canais que eu mais assisto e uma lista das principais playlists e exemplos de videos de cada canal que recomendo assistir.

Provavelmente vou ficar voltando nesta página pra atualizar de tempos em tempos. Se alguém se lembrar de algum que eu esqueci, mandem nos comentários. Tem canais como GameSack ou Sega Lord X ou Retro Game Corp ou Wullfden ou Macho Nacho Productions e vários outros assim que não listei, porque são mais de “reviews” e não cruzam tanto com “dev”. Tentei focar em coisas que eu acho que um “dev” deveria saber.

Lista (2025-05-19)

• Usagi Electric
  • Playlists:
    • Bendix G15 Vacuum Tube
    • Data General Nova
    • DEC/PDP-11
    • 1-Bit Computer
• Tech Tangents:
  • Playlists:
    • Data Generals
  • Videos:
    • Tandy 1000 RL HD
    • CP/M on Model 100
    • KayPro IV
    • HP Series 200 - CAD Monster
    • 8088 PC Networking
    • FreeDOS on IBM 5150
• The 8-Bit Guy
  • Playlists:
    • Commander X16
    • Game Development - Making of Planet X2
    • Texas Tech History
    • Commodore History
• Adrien’s Digital Basement
  • Playlists:
    • TRS-80 Model II Repair Series
    • Amiga 4000 Repair Series
    • ZX Spectrum
    • IBM 16-bit machines
    • Apple Computers - 8-bit
    • Macintosh Machines - 68000
    • Commodore - 8 bit
    • Commodore 64 Repairs
    • Tandy 1000 Series
• clabretro
  • Playlists:
    • Home Lab
    • Sun Microsystem Stuff
  • Videos:
    • Ressurrecting an IBM PS/2 Model 50Z
    • Windows NT 4.0 on a Compaq Proliant Gen 1
    • Token Ring Networking
    • Early 2000s Linksys Wi-Fi Gear
    • Compaq Proliant Gen 1
• LowSpecGamer
  • Playlists:
    • All Lore - Chronological
    • Chip WarsNintendo Lore
    • The Yokoi Saga
  • Videos:
    • How Amateurs created the world’s most popular processor - History of ARM Part 1
    • ARM’s Secret Weapon - History of ARM Part 2
    • How IBM Invented the PC, then everyone stole it
    • The Great Calculator Wars of the 70s
• Ben Eater
  • Playlists:
    • Build a 65c02-based computer from scratch
    • Building an 8-bit breadboard computer
    • Networking Tutorial
    • Error detection
• javidx9
  • Playlists:
    • NES Emulator from Scratch
    • Code-it-Yourself - TETRIS from scratch
• Gaming Historian
  • Playlists:
    • Video Game Hardware
    • The Story of Super Mario - Documentary Series
    • History of Wolfenstein
    • History of Sonic the Hedgehog
    • History of Super Smash Bros
    • Games
    • Gaming Historian
• Modern Vintage Gamer
  • Playlists:
    • Mistakes Were Made - Game Console Security
    • The Sony Playstation
    • The Original XBox
    • Doom Switch Port
    • Retro Reviews
  • Videos:
    • N64: Decomp vs Recomp vs Ports explained
    • XenonRecomp
    • Game Genie Explained
    • Super NES Graphics
    • N64 Emulation is a Mess
    • The First Amiga Virus
    • 35 Years of Game Boy
    • Video game piracy in the 80s
    • Doom SNES Sourcecode
    • How Graphics worked on the Game Boy
    • How UltraHLE changed N64 emulation forever
    • How Diablo was completely Reverse Engineered without source code
    • Duke3D on the Amiga 600
• Strafefox
  • Videos:
    • Video Game Development Through the 80s
    • The 3D Revolution in 90s game development
    • The Making of Sonic the Hedgehog
    • The Making of Mortal Kombat
    • The Making of Castlevania Symphony of the Night
    • The Making of Donkey Kong Country & Killer Instinct
    • The Making of Aladdin
    • The Making of Streets of Rage
    • The Making of Street Fighter II
    • The Making of Super Mario World
    • The Making of Star Fox
    • How Video Games were Made - Part 3
    • How Video Games were Made - Part 2
    • MSX Konami Games
• GTV Japan
  • Playlists:
    • The GTV Binge Watch
    • GTV’s Greatest Hits
  • Videos:
    • The Story of Chrono Trigger
    • The Final 16-bit Fantasy
    • Sonic Mania Day
    • The History of Sonic - 30th Anniversary
    • The Super Story of Mario World
• Displaced Gamers
  • Playlists:
    • Game Genie: Uncorked
    • Talkin’ Code
    • Behind the Code
    • Gaming Tech Talk
• Retro Game Mechanics Explained
  • Playlists:
    • Super Mario 2
    • Super Mario Bros.
    • Super Mario World
    • Super Mario Bros 3
    • Super Mario Land 2
• The Cherno
  • Playlists:
    • Ray Tracing Series
    • OpenGL
    • Code Review
• Kosmic
  • Playlists:
    • World Record SpeedRuns
    • Super Mario Bros
• Kaze Emanuar
  • Playlists:
    • SM64: Last Impact - Developer Commentary
  • Videos:
    • Mario 64 breaks after 7 days
    • Perfecting Random Number Generation on N64
    • Planetary Gravity is Cheap
    • The Genius of N64 Cache Instruction
    • The N64 has more RAM than you think
    • Why Devs need to know about Render Matrices
    • Better engine, Better graphics
    • The Folded Polynomial
    • Fastest Sine on N64
    • Fixing the Entire SM64 source code
• James Lambert
  • Videos:
    • Can Portal64 be saved?
    • Portal 64: First Slice, is out of beta
    • How I optimized Portal to run on the N64
    • How I implemented MegaTextures on real N64 hardware
    • I rewrote Portal from scratch and solved the Portal Paradox
    • How are toon shading and dynamic shadows possible on the N64?
    • How can Nintendo 64 run Portal?
• Veritasium
  • Playlists:
    • Computing
  • Videos:
    • I build a QR code with my bare hands to see how it workds
    • Exposing the flaw in out phone system
    • The Trillion Dollar equation
    • The Most Important Algorithm of All Time
    • Math’s Fundamental Flaw
    • The Bayesian Trap
    • How Does a Transistor Work
    • How to Make a Quantum Bit
• 3Blue1Brown
  • Playlists:
    • Convolutions
    • Probabilities of Probabilities
    • Differential equations
    • Essence of Calculus
    • Essence of Linear Algebra
    • Neural Networks
  • Videos:
    • But what is a quantum computing - Grover’s Algorithm
    • Where my explanation of Grover’s algorithm failed
    • Large Language Models explained briefly

DESCRIÇÃO

Finalmente vou contar sobre um dos assuntos que eu mais gosto: videogames e emuladores. E aproveitar os episódios que eu vim fazendo sobre Introdução a Computadores pra adicionar mais alguns conhecimentos interessantes pra quem é programador entender como essas coisas funcionam.

ERRATA: eu falo que PPSSPP emula PS Vita mas na verdade é o PSP.

Links:

• Understanding the ELF File Format (https://linuxhint.com/understanding_elf_file_format/)
• Super Nintendo Architecture (https://www.copetti.org/projects/consoles/super-nintendo/)
• Mega Drive Architecture (https://www.copetti.org/projects/consoles/mega-drive-genesis/)
• CPU comparison: SNES vs. Genesis vs. TG16 (https://atariage.com/forums/topic/197977-cpu-comparison-snes-vs-genesis-vs-tg16/)
• Neat story about the 6502 CPU (NES.. sorta SNES..) (https://forum.nhl94.com/index.php?/topic/12514-neat-story-about-the-6502-cpu-nes-sorta-snes/)
• History of Console Emulators (http://www.emulationnation.com/console-emulation/history-of-console-emulators/)
• History of emulation (https://emulation.fandom.com/wiki/History_of_emulation)
• Emugen: History of emulation (https://emulation.gametechwiki.com/index.php/History_of_emulation)
• How UltraHLE changed Nintendo 64 emulation forever | MVG (https://www.youtube.com/watch?v=2NF5sU_n0uk)
• Introduction to N64 Programming (http://n64.icequake.net/doc/n64intro/kantan/step2/index1.html)
• After Burner II NEC PC Engine / TurboGrafx-16 (https://www.youtube.com/watch?v=TORgYPAXk18&t=0s)
• Mac OS on a Sega Genesis? Yes! (Mac OS on a Sega Genesis? Yes! (sega-16.com))
• Making a SEGA Mega Drive / Genesis game in 2019 (https://www.gamasutra.com/blogs/DoctorLudos/20191019/352537/Making_a_SEGA_Mega_Drive__Genesis_game_in_2019.php)

SCRIPT

Olá pessoal, Fabio Akita

Feliz 2021! Muita gente tava esperando o novo ano pra deixar 2020 pra trás, mas infelizmente não sei se esse ano vai ser muito diferente não. Vamos cruzar os dedos.

Depois que fiz o episódio onde falei do chip Apple M1 eu ia fazer este, mas acabei falando de segurança. Mas agora vou voltar ao assunto continuando a falar de emuladores e videogames. Isso porque uma das coisas que mais gosto nessa vida é videogames. Desde que comecei a trabalhar sempre dizia que eu trabalho pra ganhar dinheiro pra sustentar meus videogames, e é quase verdade mesmo.

Outra coisa que vocês já sabem que eu gosto é a história das coisas de tech. No episódio de hoje vou juntar a fome e a vontade de comer e contar um pouco da história dos videogames com uma visão mais de programador, levando em conta o que vimos nos episódios anteriores e focar em assuntos que eu pessoalmente gosto. Claro que o tema é gigantesco e não cabe tudo num video só, mas vamos ver o que eu consigo fazer hoje!

Antes de começar, eu vi nos comentários que muitos ficaram com uma dúvida com a explicação que eu dei sobre máquinas de Turing, ou o que hoje chamamos de programas, serem representados por um numerozão, lembram? Um binário é nada mais que um número gigante. Então como falei de emuladores, muitos perguntaram se o lance era fazer outro programa com o mesmo numerozão.

Mas não é assim que você tem que pensar. Pensar num numerozão como sendo um texto em inglês e a versão emulada sendo o texto em português. Ambos os textos falam, digamos, sobre Harry Potter, mas em línguas diferentes e, portanto, resultam em numerozões diferentes. Quando você sai de Intel e vai pra ARM, por exemplo, necessariamente o mesmo programa recompilado, vai gerar um binário totalmente diferente e, de novo, um numerozão diferente. Espero que tenha esclarecido.

(…)

Pra começar já vou recomendar logo de cara o canal do Dimitris, mais conhecido como Modern Vintage Gamer. Assisto faz anos e ele sempre trás histórias dos bastidores, coisa que eu gosto. O canal dele tem várias histórias de como conseguiram quebrar a segurança dos mais diversos consoles, coisa que é essencial pra conseguir fazer um emulador. Ao longo dos anos empresas como a Sony, Sega, Nintendo, Microsoft, vem colocando mais e mais mecanismos de criptografia e segurança e, mesmo assim, dado tempo suficiente, a comunidade de emulação encontra maneiras de burlar e é fascinante entender como fazem isso.

Por exemplo, lembro da controvérsia quando a Sony retirou o suporte a Linux no Playstation 3 e o povo ficou pistola demais e isso acelerou alguém conseguir quebrar o PS3. Hoje em dia até a Microsoft já aprendeu e qualquer Xbox One você consegue colocar em modo de desenvolvimento, pra facilitar a vida de quem faz jogo independente, e ao mesmo tempo desincentiva gente que quer hackear pra instalar software homebrew, porque o próprio sistema já permite isso. Todo mundo fica feliz. O Dimitris faz uma série muito boa que conta essas histórias em mais detalhes, é o Mistakes were made, ou em bom português, “Erros foram cometidos”.

Pra quem não sabe, a gente costuma dividir consoles de videogames em gerações. Acabamos de entrar na nona geração com o PS5 e Xbox Series X. Infelizmente eu não reservei na pré-venda então me fodi. Se alguém souber de alguém querendo vender a um bom preço, mandem direct no meu Instagram. Enfim, acabamos de deixar pra trás a oitava geração, com PS4, XBox One, Switch e até o Wii U entra nessa.

A anterior foi do PS3, XBox 360 e o Wii original e foi a maior lavada em favor do Xbox 360 com o Wii original também deixando sua marca com a febre por causa dos controles de movimento. A sexta foi do Dreamcast, PS2, Xbox original e Gamecube, que marcou a virada do milênio em direção ao mundo de alta fidelidade, HD, telas de Plasma e LCD de alta resolução. Mas no fim do século passado, a quinta geração foi o salto de 16 pra 32-bits e a primeira onda de jogos 3D com consoles como Nintendo 64, o Playstation original, o Sega Saturn, Atari Jaguar, Panasonic 3DO e vários outros, foi uma das gerações mais movimentadas que eu já vi, e o salto pra 32-bits foi uma das mais importantes e conturbadas da história recente.

A quarta geração foi dos 16-bits, a virada da década de 80 pra 90, com o Sega Genesis liderando no começo mas com o Super Nintendo lado a lado, a era de tentar ter qualidade gráfica de arcade em casa, e tinha outras opções excelentes como o Turbografx 16 que no Japão era chamado de PC Engine e também tinha o monstruoso Neo Geo. Aliás, Genesis é nos Estados Unidos, aqui no Brasil ou no Japão a gente conheceu como Mega Drive.

A campanha de marketing da Sega nos Estados Unidos foi super agressiva, com o famoso slogan do “Sega does what Nintendon’t” e com o lançamento de jogos como o lendário Sonic, veio o slogan bullshit de “Blast processing”. Tecnicamente o Genesis era mesmo mais performático, mas fizeram o erro de configurar uma paleta de cores horrível e limitada. O Super Nintendo usava um chip de 16-bits mais fraco, mas eles tinham aceleração de background como o Mode 7 e uma paleta de cores muito mais rica.

Em seguida, a terceira geração foi dos 8-bits que representaram a renascença do videogame com o Nintendinho liderando, mas com outros como o Sega Master System tentando conseguir espaço. Em termos de hardware, essa geração foi o oposto da de 16-bits, o Master System é quem tinha uma paleta de cores mais rica e por isso jogos de Nintendinho tem cores meio bleh e no Master System eram cores bem mais saturadas e diversificadas. Mas obviamente o sistema de licenciamento e exclusividade da Nintendo garantia muito mais jogos pro console deles, deixando a Sega com poucas opções.

A terceira e quarta geração foram marcadas pelo que hoje conhecemos como a “Guerra dos Consoles”, a briga entre a Sega e a Nintendo. E, de novo, mais nos Estados Unidos, porque no Japão a Sega dominava nos arcades mas nos consoles sempre foi a Nintendo na frente. Até eles fazerem uma merda com a Sony. Fizeram parceria pra lançar o Nintendo Playstation com tecnologia de CD da Sony. Mas num grande evento, a CES, a Nintendo anunciou que ia fazer parceria com a Philips e a Sony só descobriu isso com todo mundo nesse evento. Foi uma cagada homérica da Nintendo, procurem essa história. Mas o importante é que isso deixou a diretoria da Sony full pistola e por isso eles aprovaram lançar o próprio console, o Playstation original, daí o resto - como diriam - foi história.

Voltando, a segunda geração foi a que terminou nos Estados Unidos com o crash dos videogames no começo dos anos 80, a geração do nostálgico Atari 2600, Magnavox Odyssey 2, Intellivision, ColecoVision, Vectrex e dezenas de outros. O crash aconteceu justamente pelo excesso de consoles e principalmente excesso de jogos extremamente ruins, o que arruinou a reputação de games, afastou todo o público e inspirou a Nintendo a criar o modelo de licenciamento e controle de qualidade pra lançar jogos pro console deles.

Eu joguei alguma coisa nessa época, e apesar da nostalgia, não acho mais divertido jogos de Atari hoje em dia. Esses jogos não envelheceram nada bem, e quem gosta realmente é pelas memórias da infância. Eu tenho essas memórias, mas viraram só isso mesmo, memórias. Nem Enduro, nem River Raid, nem Space Invaders, ou Pitfall, todos jogos que eu adorava, não consigo mais jogar hoje. A tecnologia nessa época ainda era bem experimental, bem pouco madura, com pouquíssimos recursos, então realmente programar pra esses consoles era um exercício em frustração e era impossível fazer jogos mais sofisticados do que um Pacman.

Agora, segundo a Wikipedia, a primeira geração de consoles tem pelo menos uns 900, não é a toa que na próxima geração ia ter um crash. Começou como uma bolha. Tudo foi derivado da do avô dos videogames, o Pong. E nessa época ainda não havia sido inventado e nem difundido o conceito de cartuchos. A grande maioria desses consoles eram meros clones baratos de Pong e vinham com um único jogo, ou até mais de um, mas eram pré-instalados dentro e você podia trocar de jogo usando um interruptor, mas não podia instalar jogos novos. Ainda era a geração que entendia que uma máquina só precisava executar uma única tarefa. E nessa geração trocentos fabricantes diferentes faziam seus próprios clones de Pong, Pacman e coisas assim. Imagina a dificuldade pro consumidor.

Já vimos nos episódios anteriores que cartuchos são uma placa com chips de ROM que o console tem acesso direto, sem precisar “carregar” nada pra RAM, é como se fosse um pente de RAM pré-carregado. E se você assistiu a série do Netflix, High Score viu que o primeiro console que introduziu o conceito de cartuchos foi o Fairchild Channel F em 1976 mas quem de fato popularizou a idéia foi o Atari VCS que saiu um ano depois. Vários fabricantes já estavam testando idéias pra baratear custos e facilitar vendas, e eventualmente alguém chegaria no cartucho, era inevitável. Todo mundo tava procurando formas de baratear os custos e tornar coisas como games mais acessíveis, sem usar mecanismos lentos como as fitas cassette, ou caros como disquetes.

Obviamente, a cada nova geração a complexidade dos consoles ia aumentando uma ordem de grandeza. Por exemplo, os consoles de 8-bits não são tão complicados assim e eu dei um pequeno exemplo no episódio do Super Mario com o Nintendinho e canais como o Coding Secrets e Retro Gaming Mechanics Explained tem muitos vídeos explicando técnicas de programação e como os jogos eram estruturados nessas plataformas, incluindo coisas como o lendário Mode 7 do Super Nintendo. Nessa época, cada clock contava e nenhum compilador ainda conseguir cuspir binários otimizados. Todo jogo precisava ser escrito em assembly, na mão mesmo. Recomendo assinar os canais deles.

Emular esses consoles significa encontrar as especificações dos chips e programar as instruções equivalentes em software, garantir que o clock funcione igual, que as instruções executem nos mesmos tempos. Isso não é tão trivial porque pensa que nossas CPUs hoje são absurdamente mais rápidas que antigamente, então a gente precisa propositalmente fazer as instruções rodar mais devagar. No caso de um Nintendinho você tem que criar o emulador pra CPU Ricoh 2A03 que é baseado no MOS 6502. Tem que escrever o emulador pro PPU ou Picture Processing Unit que é o chip responsável por renderizar backgrounds e sprites. Mesma coisa pro APU que é o Audio Processing Unit que tem cinco canais de áudio e é um PSG ou Programmable Sound Generator. Enfim, criar software pra emular cada um dos chips.

Daí precisa emular os 2 kilobytes de RAM que é bem fácil porque temos RAM de sobra hoje. Tem que emular os controles e finalmente os MMU ou memory management controllers que são chips que vinham nos cartuchos e permitiam bancos de ROM. O sistema permite um máximo de 40 kilobytes de ROM mas com os MMUs você podia ter cartuchos com até 2 megabytes ou mais e também memória com bateria pra gravar saves. E sim, é bastante coisa pra emular. Eu expliquei como isso funciona no episódio do Super Mario, dêem uma olhada. Aliás, tudo isso é só pro Nintendinho de 8-bits. Agora repita isso pra todos os consoles, em todas as suas variações ao longo dos anos, de cada uma das oito gerações que eu descrevi. É coisa pra cacete.

Falando só de especificações técnicas, sem olhar os jogos, tecnicamente o Turbografx 16 deveria ser o mais fraco, porque ele usa o processador 65C02 que é o mais rápido CPU 8-bits da família 6502, e tava competindo na geração de 16-bits do Genesis e Super Nintendo. A NEC escolheu usar chips de RAM e ROM dos cartuchos com o clock máximo que o CPU conseguia rodar, e isso foi muito inteligente. Se você pegar jogos de Turbografx como Bonks Adventure ou Dracula X que é o Castlevania, vai provavelmente dizer que é comparável ou até superior ao Super Castlevania IV do Super Nintendo.

O Super Nintendo muita gente pensa que é o mais poderoso por conta do chip gráfico que tem capacidade de rotacionar e escalar o layer de background pra fazer os famosos efeitos pseudo-3D como em Mario Kart ou Pilotwings. Mas a Nintendo foi pelo caminho mais conservador e escolheu usar o processador 65816 que é o sucessor de 16-bits do 65C02 usado no Turbografx 16. Só que o chip de 8-bits do Turbografx ia até 7.6 Mhz e o chip de 16-bits do Super Nintendo foi capado em míseros 3.58 Mhz, metade, em parte porque a RAM não era mais rápida que isso.

Muita gente pensa em performance só como clock da CPU, mas até hoje, você precisa parear a CPU com RAM porque o a CPU precisa ficar constantemente puxando dados e gravando nessa RAM, por isso coisas como clock da RAM e dual channel fazem muita diferença em PC de hoje. E por isso também uma Apple preferiu soldar a RAM direto do lado do seu novo CPU M1 pra garantir a melhor combinação de performance. Smartphones fazem a mesma coisa. Se você comprar um AMD Ryzen mais moderno mas colocar pentes de RAM velhas de menos de 2Ghz e sem colocar em dual channel, você criou um gargalo enorme, e está desperdiçando o CPU.

Sendo o Super Nintendo e o Turbografx derivados da família 6502, eu não posso dizer por experiência própria mas pelo que já li a respeito o assembly dele não era muito amigável pra programar, exigindo muita burocracia, como a constante troca de modes no Super Nintendo entre instruções de 8 bits e 16 bits. Se tentasse escrever em C, o código gerado ficava muito lento pelo overhead do C, faltava registradores pra conseguir otimizar. Enfim, não era uma CPU amigável pra um programador de assembly, e eu já disse que nessa época era obrigatório programar em assembly pra tirar o máximo dos poucos recursos que tinha nesses consoles.

Por outro lado, o Sega Genesis ou Mega Drive de fato tinha o CPU superior, eles escolheram o Motorola 68000 que era híbrido 32 e 16-bits, com clock também de 7.6 Mhz, o dobro do Super Nintendo e ainda vinha com um segundo processador Zilog Z80 de 8-bits que era o mesmo do Master System, usado como processador dedicado de áudio. Além disso, diferente do 65C02 e 65816, você conseguia escrever pelo menos parte do jogo em C, que gerava assembly suficientemente rápido pro 68000. E mesmo não tendo um chip gráfico dedicado pra conseguir os efeitos de rotação e escalonamento de background, ele conseguia alguns desses efeitos via software por causa do CPU mais rápido. Veja jogos como Castlevania Bloodlines por exemplo. Pois é, era possível fazer Mode 7 no Mega Drive, isso não era uma exclusividade do Super Nintendo.

Mas como eu disse antes, uma coisa que o Mega Drive falhou foi na escolha de paletas de cor. Ele tinha conjuntos de cores horríveis e menos cores no total que o Super Nintendo ou Turbografx. Por isso, visualmente, os jogos de Megadrive parecem sempre mais feios em termos de cor se comparar jogos que foram lançados pras outras plataformas. Pegue jogos que saíram ao mesmo tempo em todas como Street Fighter II e no Mega Drive vai ser mais feinho. Olha aqui do lado. Esse é o do Super Nintendo, esse outro do Turbografx e por último, esse é do Mega Drive.

No final do dia, tudo depende do que os programadores conseguiam extrair dessas máquinas. E em termos de jogos não se pode comparar os que saíram no lançamento dos consoles com os que saíram no final da geração. No começo é quando os programadores ainda não conhecem todo o potencial do hardware. E quando a geração tá acabando, é quando os programadores já descobriram todos os truques possíveis. É interessante ver como jogos como Afterburner II é definitivamente melhor no Turbografx com um processador teoricamente pior de 8-bits contra a versão do Mega Drive de 16-bits.

Mais do que isso, o processador do Mega Drive, o 68000 é super famoso e equipou microcomputadores como os Amiga e Macintosh por exemplo. Existiu até uma tentativa de emular o Mac OS 7 pra rodar em cima de um Mega Drive. Infelizmente, tirando uma thread de fórum de 2006, não achei imagens boas ou vídeos mostrando ele rodando. Se alguém tiver não deixe de compartilhar nos comentários.

Obviamente não seria prático rodar o Mac OS num Mega Drive, é só mais uma evidência do que falei no vídeo anterior sobre máquinas universais de Turing: mesmo lento é possível emular outro sistema. E tecnicamente faz sentido, ele usa o Sega CD como um CD SCSI que o Mac consegue acessar e o video sai pela extensão 32X que foi uma expansão pro Mega Drive conseguir rodar polígonos e outros efeitos especiais, incluindo mais resolução e mais cores também.

De qualquer forma, até a terceira geração, dos 16-bits, muito da programação de jogos se fazia em Assembly, particularmente porque a família de CPUs da MOS não conseguia ter C que gerasse binários eficientes, então só codando assemblão na munheca mesmo. Mas a próxima geração teve um salto enorme. Na quarta geração começamos a usar processadores de 32-bits com arquitetura RISC, semelhante aos processadores ARM de celulares de hoje em dia e ao novo Apple M1.

Era possível ter clocks maiores e acesso a exponencialmente mais endereços de RAM. E daí passou a se utilizar mais C, porque nessa arquitetura os compiladores evoluíram mais e já era possível ter código compilado tão eficiente ou mais do que escrever assembly na mão. E se alguém tinha alguma dúvida, não, em 99.99% dos casos você não vai conseguir escrever mais assembly melhor do que um compilador consegue gerar.

Num resumo bem resumido, pense que a arquitetura x86 ou CISC é feita de instruções complexas, ou seja, que fazem bastante coisa e por isso demoram vários clocks pra executar e arquitetura RISC como nos chips ARM é feita de instruções simples que, que executam poucas tarefas e por isso terminam rápido, tipo num único clock. Só pra ilustrar pra quem não tá acostumado com assembly, num processador x86 talvez eu tivesse uma função chamada “desenhar um botão” que numa instrução só já mostra um botão desenhado na tela. Num ARM hipotético teria só a função “desenhar linha” e eu precisaria chamar quatro vezes pra desenhar o mesmo botão.

Na prática não faria tanta diferença porque desenhar botão digamos que leva 4 clocks pra executar e o desenhar linha leve 1 clock. No fim ambos levariam 4 clocks. Mas pra quem escreve direto em assembly faz diferença porque ele precisaria escrever muitas linhas a mais de código pra fazer a mesma coisa. Hoje em dia não faz diferença, porque do C o compilador que vai ter o trabalho de gerar o assembly, mas antigamente programar em C não era eficiente então fazia diferença essa história de arquiteturas CISC ou RISC porque influenciava diretamente na produtividade dos programadores.

Mas a partir da geração 32-bits passamos a programar quase que exclusivamente em C, deixando o trabalho de gerar assembly pros compiladores, como o compilador do Visual Studio da Microsoft ou o GCC que tem em todo Linux ou o LLVM, mais especificamente o Clang, que tem em todo Mac. Agora, imagine que descobrimos uma forma mais eficiente de fazer a função hipotética de desenhar botão e em vez de levar 4 clocks poderia levar 2.

Num Intel fodeu, não tem como mexer nessa função porque ela é impressa no hardware, no chip da CPU. Num RISC, que tem instruções mais simples, podemos atualizar o compilador e ele vai cuspir um assembly mais otimizado que vai usar menos instruções e executar em 2 clocks. Ou seja, sempre temos possibilidades de, sem mexer no código em C, ganhar performance de graça por avanços nas otimizações dos compiladores. E nesse quesito o ARM tem mais vantagens do que x86 da Intel.

Pra nós, que dificilmente vamos programar assembly na mão, a arquitetura do chip por baixo não importa porque o compilador vai fazer o trabalho bruto de escrever assembly otimizado, mas basta saber que sim, a arquitetura RISC é definitivamente mais flexível do que os x86. A Intel é obrigada a carregar esse legado que vem da época em que era importante um assembly mais simples e, portanto, mais complexo. Hoje isso não é mais importante. Em última instância a arquitetura RISC era mais chata naquela época se você precisasse escrever assembly na mão, mas agora ela tem vantagens. Ela estava à frente do seu tempo.

De qualquer forma, a arquitetura dos dois tipos foi ficando mais complexa com o tempo, porque agora esses CPUs também eram capazes de realizar tarefas concorrentemente com multithreading além de ter chips gráficos capazes de calcular polígonos. Você tinha que ser um sadomasoquista hardcore pra querer fazer multithreading e polígonos em assembly num jogo inteiro. E antes os jogos tinham acesso direto ao hardware, sem um sistema operacional intermediando, mas no Saturn, Playstation ou Nintendo 64, agora eles tinham um firmware que funciona como um sistema operacional super leve. Agora meio que ficou necessário, porque senão ninguém ia conseguir fazer jogos nesses hardwares que eram exponencialmente mais complexos do que a geração anterior. É quando começamos a trocar um pouco de performance por mais qualidade de vida de programação.

Isso aumentou dramaticamente a dificuldade de emular esses sistemas. Porque se você fizer a engenharia reversa de chips de processamento de polígonos e tentar emular só via software, os CPUs de PCs da época simplesmente não conseguiam rodar. Ao mesmo tempo começamos a ter placas gráficas 3D em PC também com os venerados 3DFX. Pra programar em C pra placas 3DFX se usava a biblioteca Glide. Então algumas das primeiras tentativas de emular Playstation ou Nintendo 64 envolvia criar um software Adaptador entre as funções do console e os equivalentes na Glide. Por isso se você instalou emuladores dos anos 90 como o famoso UltraHLE tinha a chatice de achar a DLL certa de Glide por exemplo.

Existem vários vídeos e blogs onde você consegue encontrar a diferença de uma GPU pra uma CPU mas sendo bem simplista pra você ter uma idéia na cabeça. Numa CPU teríamos funções como adição, onde você coloca dois números em dois registradores e ele calcula a soma e grava em outro registrador, e vai fazendo assim uma instrução de cada vez. Se precisássemos processar todos os pixels de uma tela, digamos deixar a cor mais escura, seria um puta trampo pro CPU. Por que? Antigamente a resolução de videogame era tipo trezentos e vinte por duzentos e quarenta pixels, ou seja, setenta e seis mil e oitocentos pixels.

Só pra simplificar a conta digamos que cada adição da CPU custasse um clock, então ia levar mais de setenta e seis mil clocks pra processar todos os pixels. E ele teria que dar um jeito de fazer isso sessenta vezes por segundo. Ou seja, não dava porque num processador da era 16-bits, de 7 megahertz significa 7 mil clocks por segundo. Então ia levar mais de dez segundos pra processar essa imagem do exemplo.

Agora uma GPU é feita pra executar múltiplas adições em paralelo. Desde sempre ela foi organizada no que hoje você conhece como multi-core. Mas em vez de quatro ou oito cores que você tem num Intel i5 da vida, uma GPU tem dezenas, ou centenas de pequenos cores que fazem bem pouca coisa muito rápido. Em vez de passar só um número como parâmetro, passamos um vetor. Pense em um vetor como um array de números.

Então é a adição de um vetor com outro vetor. Digamos que a GPU aguente um vetor de 320 números, então ele precisaria processar a adição só duzentas e quarenta vezes, um por clock, ou melhor ela poderia rodar em duzentas e quarenta dos seus micro-cores e executar tudo em paralelo num clock só. Olha como só nesse exemplo, saltamos do custo de mais de setenta mil clocks pra um único clock.

Uma GPU executa tarefas muito simples em uma quantidade grande de dados de uma só vez, essa é a especialização dela. Porém, ela só é rápida pra esse tipo de cálculo mais massivo e não pra cálculos simples e lineares onde a próxima instrução depende do resultado da anterior. E gráficos é o melhor caso de uso, porque são trinta ou quarenta quadros por segundo com uma quantidade massiva de pixels que precisam ser processados e cujo processamento de uma linha de pixels independe da outra linha de pixels.

E pixels podem ser organizados em vetores e matrizes, que são os elementos que uma GPU adora processar. E em tempos mais recentes inventaram uma forma de mandarmos pequenos programinhas pra GPU, isso é o que você já deve ter ouvido falar como shaders. Enfim, já foi uma longa tangente, por hoje vamos só entender isso. GPU é um troço simples que se tornar complexo porque roda com vetores longos e massivamente em paralelo. CPU é um troço complexo que roda com argumentos simples e linear.

Ah sim, e nessa época a Microsoft tava lançando coisas com Direct3D que era uma tentativa de padronizar a programação 3D pra placas gráficas de diferentes fabricantes. Então talvez você não tivesse a 3DFX Voodoo mas tinha a Nvidia TNT2. Então precisava do nGlide que era uma camada que respondia as APIs da Glide mas mapeava pra chamadas de Direct3D. Sim, se hoje em dia você tem dores de cabeça com drivers da Nvidia ou AMD, com Direct3D ou Vulkan ou OpenGL, imagina a zona no fim dos anos 90. Era a mesma coisa só que pior e mais instável, a gente ainda tava aprendendo como lidar com placas 3D. Um dia vou fazer um episódio falando mais de GPUs, mas pra agora, só estas noções que expliquei pra diferenciar um CPU de uma GPU deve bastar pra maioria dos casos.

Ver coisas como o emulador UltraHLE, rodando Super Mario 64, em um Pentium II ou III, mesmo que parcialmente e meio bugado, em 1999, sendo que o Nintendo 64 tinha sido lançado só 3 anos, antes era absurdamente impressionante. Pra você ter uma idéia, mesmo hoje em dia usando emuladores como o Mugen 64, você não consegue emulação perfeita de Nintendo 64. Temos dificuldade em manter 60 frames por segundo em hardware considerado fraco hoje mas que pra época era um supercomputador, como um Raspberry Pi 3 ou processadores de celular Androids. Isso depois de 20 anos. De qualquer forma o UltraHLE era tão bom que deixou a Nintendo full pistola e você pode conferir essa história no video do canal Modern Vintage Game que vou deixar nas descrições abaixo.

A estratégia de emulação começou a mudar com o UltraHLE. Com consoles de 8 e 16 bits a estratégia era emular os chips como a CPU, PPU e tudo mais. Com o aumento da complexidade nas plataformas de 32-bits isso era um trabalho brutal e bem mais difícil. Porém, como o processo de desenvolvimento dos jogos passou pra C, linkando com as bibliotecas no firmware dos consoles, outra estratégia passou a ser interceptar as chamadas de função em C e traduzir pro equivalente no Windows por exemplo. Se você assistiu meu episódio sobre WSL, o Windows Subsystem for Linux, vai lembrar que a versão 1.0 fazia a mesma coisa com programas pra Linux, interceptava as chamadas de sistema pra kernel do Linux e traduzia em tempo real pra chamadas pra kernel do Windows.

O Playstation, pela popularidade, teve muito mais gente tentando emular e hoje em dia você consegue rodar praticamente todos os jogos, inclusive com hacks pra aumentar a resolução interna e aplicando filtros nas texturas pros jogos ficarem um pouco mais bonitos. Mas em paralelo ao UltraHLE a gente tinha alguns emuladores de Playstation também como o PSEmu ou o Virtual Game Station que era comercial e só rodava em Macintosh. Nenhum dos dois era perfeito na época, mas foram referência pra próxima geração de emuladores.

O primeiro emulador que eu lembro que me deixou realmente impressionado foi o Bleem. Ele era diferente primeiro porque era comercial e fechado e segundo porque em vez de tentar emular tudo do sistema e todos os jogos, eles preferiram focar em otimizar bem só alguns poucos jogos, como Gran Turismo ou Final Fantasy 7. Ou seja, eles deixavam hardcoded no emulador algo como “if gran turismo mude pra fazer X”, até o Gran Turismo rodar liso mesmo que outros jogos falhem. E eles vendiam pacotes de otimizações pra cada jogo. Na época, quando vi os anúncios, eu achava que era enganação, mas de fato a desgraça funcionava.

E eles ainda faziam isso de aumentar a resolução de renderização então jogos de playstation que nativamente só tinham 320 por 240 pixels dobrava pra 640 por 480. Lembrando que a gente usava monitores de 800 por 600 ou 1024 por 768. Então 640 por 480 era nosso HD. O emulador começou a mudar os jogos pra fazer coisas que originalmente eles não foram projetados pra fazer, e isso era fascinante. Pra ver como foi essa história eu recomendo o documentário sobre o Bleem do canal The Gaming Historian, que é outro canal bem produzido, e vou deixar o link nas descrições abaixo.

O Bleem acabou não vingando, tomaram um processo da Sony nas costas e eles tentaram voltar repetindo a estratégia com o Bleemcast na geração seguinte, pra emular Dreamcast. Mas apesar de não terem perdido o processo da Sony, os custos de advogados foram absurdos, e eles fecharam em 2001, no mesmo ano que a Sega decidiu descontinuar o Dreamcast também.

O desenvolvimento de emuladores de Playstation andou bem mais rápido do que Nintendo 64 mas o mais atrasado de todos sempre foi o Sega Saturn. Ele saiu antes do Playstation e esse lançamento foi um dos maiores desastres da história do videogame. Pra quem não sabe, a Sega dos Estados Unidos sempre se ferrava por causa das decisões da Sega do Japão. A falta que fazia mandar e-mails naquela época. Eles desenvolveram o 32X nos Estados Unidos pro Genesis sem saber que no Japão estava sendo desenvolvido o Saturn. Pensa a zona.

O Saturn ainda recebeu uma arquitetura super difícil de trabalhar com dois processadores paralelos. A maioria não sabe programar paralelo hoje, imagina naquela época. Daí acabavam só usando um dos processadores. Foi mais ou menos o mesmo problema que a Sony repetiu com o Playstation 3 e o famigerado CPU Cell com seus co-processadores paralelos, os SPUs. Até hoje o chip é considerado excepcional, mas era notoriamente difícil de programar. Tanto que só no final da sexta geração começaram a sair jogos que tiravam vantagem do processamento paralelo como o lendário The Last of Us original. E foi um dos motivos de porque a Sony perdeu essa geração pro XBox 360 da Microsoft, que era uma arquitetura muito mais simples de programar. Um canal que mostra vários jogos de Saturn é o canal do Sega Lord X, recomendo assistir pra ver se você nunca jogou Saturn.

Em termos de emuladores, o RPCS3 já consegue rodar muitos jogos de PS3 mas é bem pesado. Simular os SPUs sempre foi o desafio. E essas foram algumas das curiosidades que eu mais gosto sobre alguns dos meus videogames favoritos, mas tem toneladas de histórias a mais, tanto que existem canais de YouTube dedicados só nisso, como o The Gaming Historian ou Modern Vintage Games que já mencionei, recomendo que assistam o canal deles pra mais curiosidades assim. Mas o objetivo de hoje era dar uma pequeno overview, uma pincelada geral pra ver se vocês ficam interessados no assunto também. Eu acho que gosto mais de entender os mecanismos de como esses consoles e games funcionam, como eram construídos, que truques usavam, mais do que realmente jogar os jogos propriamente ditos.

Pra finalizar, deixa eu listar os emuladores que mais gosto pra vocês pesquisarem no Google e brincar. A maioria existe pra todas as plataformas e sistemas operacionais, incluindo Windows, Linux e rodam em Raspberry Pi que é fraquinho pros padrões hoje mas suficiente pra maioria dos emuladores. Mas se puder rodar num hardware pra Android melhor, eu recomendo. A maioria dos apps você encontra direto no Google Play Store. E o principal de todos é o RetroArch. Ele em si não é um emulador, mas uma interface pra vários emuladores, que são chamados de Cores. Nem todos funcionam bem ou de primeira, mas pelo RetroArch você consegue instalar os Cores online além de coisas como temas diferentes, artes das capas das caixas dos jogos, códigos de cheats, e diversas outras coisas. É um mundo em si só.

Quem gosta de Sony no próprio RetroArch tem cores de Playstation original. Tem o PCSX2 pra Playstation 2 que roda até que bem mas é pesado. Tem o RPCS3 que ainda não é muito estável e nem muito compatível mas se seu computador for potente deve rodar razoavelmente bem. E tem o PPSPP pro Vita, um dos meus favoritos, que roda muito bem. Jogos como Crisis Core rodam muito bem, mas God of War vai precisar de mais hardware pra rodar direito. E nem tentem rodar em Raspberry Pi, o hardware não é suficiente. Num smartphone mais novo deve rodar razoável, mas acima de PS2, recomendo um PC.

Pra quem gosta de Nintendo, o Nintendinho e Super Nintendo tem vários emuladores como o Mesen que já mencionei ou o Bsnes. E pelo RetroArch você baixa a maioria e é plug-and-play. Mas os mais interessantes são o Dolphin que consegue rodar bem jogos de Gamecube e Wii original, embora seja pesado. Tem o Citra que roda jogos de Nintendo 3DS muito bem. Mesmo no meu PC com Intel i7 alguns dão umas travadas e perde frame, então não é perfeito, mas tá evoluindo rápido. O mesmo vale pro Cemu que consegue rodar jogos de Wii U muito bem mas dá um puta trampo configurar. Se tiver paciência, vai poder jogar Zelda Breath of the Wild em Full HD com vários filtros que deixam o jogo mais bonito do que no Nintendo Switch. E falando em Switch tem o Yuzu que já roda vários jogos de Switch, mas eu mesmo não testei porque tenho um Switch.

Pra Sega, emuladores de mastersystem e genesis tem bastante no RetroArch, mas o mais difícil é o Saturn por causa da arquitetura complicada que expliquei antes. Mesmo assim, o emulador Yaba Sanshiro é bem competente e todo jogo que testei como Panzer Dragoon ou Sega Rally rodaram muito de boa mesmo num Android, então é o que recomendo. E quem gosta de Dreamcast tem o Redream que é pago, mas eu digo que vale a pena pagar porque é de longe o melhor emulador, que roda mais estável e mais compatível.

Finalmente, eu gosto muito de jogos de arcade então NEO GEO é essencial, mas eu mesmo odeio procurar emuladores, bios e configurações que funcionam direito então nem vou recomendar muito que se tente do zero. Eu me enchi tanto que preferi comprar no Mercado Livre o emulador que vem com as ROMS e tudo mais já pré-configurado pra MAME. MAME é de longe o emulador mais chato do mundo de configurar, eu não recomendo. É melhor achar pré-configurado. E a razão de ser tão chato é que arcades eram como um console específico feito só pra um ou um conjunto pequeno de jogos.

A Capcom tinha as famosas placas CPS1, os mais modernos usavam hardware derivado do Dreamcast, o Naomi. E se contar todas as placas criadas desde os anos 80, estamos falando de dezenas. E cada um tem uma configuração diferente. Configurar um a um na mão é um trabalho que não vale a pena. Se alguém tiver boas dicas de como facilmente configurar um bom emulador de Neo Geo pra Android, fiquem à vontade pra colocar nos comentários abaixo.

E sim, vou só listar os emuladores e não pretendo fazer vídeos de como configurar porque isso você vai achar toneladas de tutoriais em video e em blogs, bem detalhados. O próprio Wiki do RetroArch tem bastante documentação. Se você quer jogar jogos pirata, tem que fazer algum esforço ou gastar alguma grana pra comprar já configurado. Minha parte eu já fiz. Espero que tenham gostado dessa curta história dos videogames. Quem tem dúvidas ou histórias pra compartilhar, deixem nos comentários abaixo. Se curtiram o video mandem um joinha e compartilhe com seus amigos, assine o canal e não deixe de clicar no sininho pra não perder os próximos. A gente se vê, até mais!

DESCRIÇÃO

Continuando o assunto sobre máquinas de Turing hoje resolvi pegar parte do material que eu cortei do episódio anterior e aproveitar o lançamento do chip Apple M1 pra dar uma introdução ao assunto de emuladores usando aspectos das diferenças de arquitetura RISC/CISC e como ARM e x86 se comparam.

Índice:

• 00:00 - Introdução
• 01:10 - Turing Complete
• 09:37 - Doom roda em QUALQUER lugar :-)
• 11:58 - Apple M1 / ARM x x86
• 21:40 - Pirataria

ERRATA:

No teste de gravidez, eu não prestei atenção e deixei passar que na verdade o @foone teve que trocar alguns componentes então o teste de gravidez não foi usado 100% como veio de fábrica e portanto NÃO, ele não é um computador universal também 🤷‍♂️ de qualquer forma fica o conceito, de que poderia ser, se rodasse Doom ;-) https://twitter.com/renatomefi/status/1332694946575486978?s=20

Links:

• Tom Scott: Are There Problems That Computers Can’t Solve? (https://www.youtube.com/watch?v=eqvBaj8UYz4)
• Foone: Doom Pregnancy Test (https://twitter.com/Foone/status/1302820468819288066?s=20)
• Matthew Monis: MacBook Pro 13 Review - This M1 is Insane! (https://www.youtube.com/watch?v=BUBYO591Fo8)
• The Untold Story Of The Invention Of The Game Cartridge (https://www.fastcompany.com/3040889/the-untold-story-of-the-invention-of-the-game-cartridge)

TRANSCRIPT

Olá pessoal, Fabio Akita

Fiquei contente que vocês gostaram do episódio que contei um pouco mais sobre a máquina de Turing e a arquitetura de Von Neumann. Aquele episódio tinha ficado grande e eu tive que cortar um trecho enorme pra não perder a linha de raciocínio do que eu queria contar. O trecho era tão grande na real, que era praticamente outro episódio.

Pois é, no processo de escrever os textos e um dos motivos de porque eu não gosto de fazer live, é que eu faço muita tangente e aí o assunto fica mais complicado do que devia. Mesmo cortando eu ainda faço tangente. Ainda estou praticando cortar coisas, mas vira e mexe acontece de eu escrever 30 páginas e cortar 10 fora, como é o caso do material de hoje.

Então a primeira metade do video de hoje vai ser tipo a edição estendida director’s cut continuando o video anterior, mas a segunda metade vou começar a falar sobre emuladores e até dar uma palhinha do que eu acho dos novos chips Apple M1 no contexto de emulação e arquitetura. Mas isso vai ser introdução também pro próximo episódio onde vou cair mais no meu lado geek e falar de videogames.

(…)

Eu nasci no fim dos anos 70. A revolução dos micro-computadores nasceu praticamente junto comigo. Por exemplo, a Atari foi fundada em 1972, a Microsoft em 75, a Apple em 76. No mesmo ano que eu nasci também nascia o computador PET, o antecessor da linha Commodore que sairia em 82. O padrão MSX nasceu em 83. O Sinclair ZX Spectrum nasceu em 82 e no Brasil ele foi clonado pela Microdigital e virou o venerado TK 90X, que eu queria ter quando criança mas não pude.

No caso do TK 90X ele usava processador Zilog Z80, o mesmo também usado no Sega Mastersystem que fez muito sucesso no Brasil, fabricado pela Tectoy e que existe até hoje. Outros modelos de micros como o Apple II ou Commodore 64 ou mesmo o Atari 2600 usavam o MOS 6502 ou sua evolução, o 65C02, que eu introduzi no episódio do Guia mais Hardcore de Introdução à Computação.

Esse mesmo processador equipava o Nintendinho original de 8-bits. E mesmo o Super Nintendo usa o processador da família do 65816 que é baseado na arquitetura e instruções do 6502, meio como um Intel Core i5 de hoje é uma evolução dos Pentium de antigamente e ainda são compatíveis. Recomendo que assistam meu episódio também de Aprendendo sobre Computadores com Super Mario pra entender um pouco de como as instruções do 6502 funcionam na prática.

Essa conversa toda foi só pra voltar no conceito de máquinas Turing Universais ou UTMs. Pra recapitular, uma máquina de Turing, a abstração, é basicamente uma máquina com um leitor que consegue ler um bit de cada vez de uma fita infinita, consegue mover essa fita pra esquerda ou pra direita, e além de ler consegue mudar o valor de um bit de cada vez. Mesma coisa o console de um Nintendinho, onde é possível representar tudo que compõe o console com um número descritivo, porque ele é uma máquina de Turing.

Um cartucho é um conjunto de chips de ROM. Dentro dessa ROM tá gravado o programa do jogo e os dados como os sprites, imagens e áudio que compõem o jogo. Mas é basicamente tudo uma sequência de bits. Poderíamos escrever os bits todos numa fita. E de fato, antigamente a gente gravava programas e jogos em fitas cassete. Quem é dos anos 80 deve se lembrar. Era lento pra cacete, mas disk drives ainda eram muito mais caros. Mesmo um disco que tem num HD mecânico ou um CD-ROM é uma fita de discos em círculo na mídia.

O cartucho é como se fosse a tal fita na máquina de Turing. Mais do que isso, sem pensar que existem todos esses elementos separados, do ponto de vista da fita ou sequência de bits, são zeros e uns um atrás do outro. Se não ficou claro, vamos pegar um trecho de assembly que eu mostrei no episódio do guia de introdução à computação, instruções do 6502. Lá pelo minuto 49 do vídeo eu mostro uma sequência de instruções, lda ff, sta 60 02. Vamos considerar que o programa são só essas duas linhas. Em hexadecimal isso viraria a9 ff 8d 02 60. Em binário isso viraria esse numerozão aqui do lado. Se eu jogar na calculadora, e convertermos pra decimal, essas duas linhas de código podem ser representados pelo número trezentos e sessenta e cinco mil e tra la la que você pode ver aqui do lado. Entendeu? O programa É esse número.

1010 1001 11111111 1000 1101 0000 0010 1100000 365068452192

Zeros e uns um atrás do outro é basicamente um numerozão, em binário. No caso do cartucho do Super Mario é um numerozão de mais de trezentos e vinte mil dígitos binários ou bits, pra ser mais exato, porque são 40 kilobytes vezes um mil e vinte e quatro pra termos em bytes e vezes oito pra termos quantos bits, já que 8 bits é 1 byte. Todo programa, não importa o comprimento, é um numerozão. Todo programa que você já escreveu ou vai escrever pode ser representado por um único número gigante.

Não só o cartucho por ser representado por um número, mas o funcionamento do nintendinho inteiro também pode ser representado por um numerozão. Uma máquina universal de Turing pode pegar o tal número descritivo de uma máquina de Turing, como o tal numerozão que representa o Nintendinho inteiro e simular. E o resultado dessa simulação vai ser exatamente a mesma da máquina de Turing correspondente, o console de verdade. Então, uma característica importante de uma UTM é sua capacidade de “simular” qualquer outra máquina de Turing.

Resumindo. Uma máquina de Turing ou máquina de computar é um modelo abstrato capaz de ter um número finito de configurações ou estados. Ele é alimentado com uma fita infinita de bits. A cada momento a máquina tá escaneando somente um símbolo dessa fita de cada vez, e é automática porque a cada momento o estado da máquina é determinado pelo símbolo, ou bit que ele tá lendo naquele instante. A grosso modo, pense numa máquina de Turing como uma função ou método de qualquer linguagem de programação moderna.

O tal número descritivo representa o corpo dessa função, o binário do programa. Esse número descritivo ou programa manipula números computáveis, que na prática é quase todo número que você consegue pensar. E usa o que Turing chamou de funções computáveis. De curiosidade, ao contrário dos números, nem toda função é computável e existe muito mais funções não-computáveis do que computáveis na real. Portanto uma máquina de Turing Não consegue computar qualquer coisa. Existem funções que ela não tem capacidade de resolver.

Isso é um conceito importante porque a intuição popular é que dado tempo suficiente pra evolução de chips e processadores, qualquer problema deveria ser possível de resolver com um computador. Porém vale saber que existem problemas que um computador de Turing nunca vai resolver. Um exemplo disso é o Halt Problem. E como é muita tangente pra hoje, recomendo assistir a explicação do Tom Scott, que é outro canal que eu sigo faz anos. Apenas lembre disso: existem problemas que são impossíveis de resolver com um computador. E não, um computador quântico ainda é uma máquina universal de Turing. Daqui algumas décadas tem a possibilidade de ser ridiculamente mais rápido que hoje, sem dúvida, mas não vai ter mais capacidades nem vai ser capaz de resolver problemas que já não se resolve hoje.

De qualquer forma, uma Universal Turing Machine é uma máquina que pode pegar o número descritivo de alguma máquina de Turing e simular ela perfeitamente. Então, pra resolver problemas de computação, você pode escolher uma máquina de Turing adequada pra um problema específico, já que cada máquina só consegue executar uma tarefa. Lembrem-se que antes disso uma máquina mecânica era construída pra resolver só um tipo de problema. Agora você pode pegar uma máquina Universal, carregar o número descritivo ou programa, que é o tal numerozão que expliquei antes, e simular diversas máquinas de Turing. Esse é o conceito moderno de programação e computadores derivado dos papers de Alan Turing.

Na prática, computadores reais não são máquinas de Turing nem máquinas Universais, pelo simples fato que elas tem limites e a definição matemática tem o ideal de memória infinita. Mas, pra todos os efeitos e propósitos, a revolução de Alan Turing foi conseguir definir a idéia e conceitos de uma máquina de uso geral, em vez de uma máquina especializada como calculadoras por exemplo. Uma máquina de Turing seria o que chamamos de “programa”, o tal número descritivo seria a implementação desse programa, uma máquina Universal é o computador propriamente dito que consegue rodar diversos programas diferentes.

Alguém me perguntou uma vez se uma calculadora ou um ábaco não poderiam ser computadores já que “computam” números. E é uma pergunta válida. Tecnicamente uma calculadora “e” um computador, intuitivamente, são máquinas de calcular. E quando eu falo calculadora não estou falando de coisas como a TI-83 que todo engenheiro que se preze conhece e usa. Uma TI-83 é definitivamente um computador inteiro, que carrega programas de calcular e plotar gráficos e por isso consegue até rodar Doom nele. Estou falando daquelas calculadoras velhas que se tinha nas mesas antigamente.

Na minha definição informal e não-rigorosa, eu costumo pensar num computador como uma máquina que consegue simular qualquer outro computador, mesmo que bem mais lento. Performance não define um computador, suas capacidades sim. E uma linguagem Turing Complete, pra mim, é uma linguagem que consegue programar a simulação de outro computador. Se uma determinada máquina consegue rodar um emulador, pra mim é uma máquina universal. E se a linguagem de programação é capaz de escrever um emulador, pra mim ela é Turing Complete. É uma definição parcial, mas eu gosto dela porque é bem prática. Não consegue escrever um emulador, essa linguagem não é Turing Complete. Não consegue rodar um emulador, então não é um computador.

Recentemente um usuário que eu sigo no Twitter faz tempo, o @foone, ganhou o noticiário porque ele fez Doom rodar num teste de gravidez! Pois é, a miniaturização chegou num tal ponto que dentro de um mísero teste de farmácia, daqueles que tem uma telinha LCD bem podrona, tem um CPU turing complete, capaz de minimamente executar um jogo ao ponto dele aparecer na tela e rodar. Lento, feio, mas roda. Pára pra pensar numa coisa, todo teste de gravidez mais moderno é um computador inteiro, com um programa feito pra rodar só uma vez e depois você jogar no lixo! Isso tudo dito, não, ábaco não é um computador, a calculadora antiga de mesa não é um computador, mas um teste de gravidez como esse definitivamente é um computador.

Toda vez que alguém fala coisas como “nossa, conseguiram rodar Doom numa TI-83 ou numa câmera fotográfica” lógico, eu acho impressionante que alguém se deu a esse trabalho, mas eu não acho surpreendente porque mesmo um computador fraco é capaz de simular outro computador, só vai ser super lento. Mesma coisa quando alguém se impressiona quando vê uma distribuição Linux ou mesmo Windows 95 rodando no Chrome ou Firefox, emulado via Javascript. Não me surpreende, mas certamente impressiona, especialmente se você for iniciante.

Eu entendo a sensação. Eu me sentia da mesma forma nos anos 90, quando eu tinha um PC no nível de um 486 ou Pentium, que sequer tinha 32 MEGAbytes de RAM, e de repente eu tava conseguindo emular um nintendinho, que não fazia 10 anos só era possível jogar com um console de verdade. Ou a primeira vez que eu instalei o sistema operacional OS/2 que vinha com um emulador de MS-DOS e era possível até iniciar Windows 3.1 e rodar lado a lado dentro do OS/2. De qualquer forma, esses conceitos explodiam minha mente nos anos 90 e eu entendo que todo iniciante que vê isso pela primeira vez, mesmo hoje, deve ficar impressionado.

Agora, falando especificamente de emuladores. Um emulador simula um chip de outro computador via software. Quando um emulador carrega o jogo de um cartucho, o jogo em si não tem idéia que tá rodando num emulador. Pra todos os efeitos e propósitos, se o jogo tivesse consciência, ele não teria dúvidas que tá rodando no console de verdade. No máximo ia estranhar, “nossa, tá mais rápido esse hardware hoje”. Esse é o Matrix de verdade e eu falei um pouco disso no meu episódio sobre virtualização, dêem uma olhada.

Em particular sobre as discussões de ARM versus x86 que tá na moda agora, isso é um daqueles eventos que só acontece um a cada vinte anos. Eu usava Macs em 2006 quando aconteceu a transição de PowerPC pra Intel. Não vou entrar em detalhes dessas histórias porque nesse momento todo canal de tech no YouTube já tem vídeos a respeito e seria só ser redundante. Mas é relevante notar que em 2006 a Apple saiu de uma arquitetura RISC, de instruções reduzidas, pra Intel que tem instruções complexas. Agora ela tá fazendo o oposto, saindo de instruções complexas e indo pra arquitetura ARM, que é um RISC, de instruções reduzidas.

Pra nós programadores, uma coisa interessante é a camada Rosetta 2 que tem nos Mac OS a partir do Big Sur. Ele é um emulador pra conseguir executar binários legados de x86, convertendo as instruções pra ARM. Assim ele consegue rodar programas que não foram recompilados e atualizados pro novo chip M1. Todo reviewer tá com a cabeça explodindo porque o M1 já é mais rápido que modelos de notebooks PC comparáveis em preço aos novos Macbook Air ou Macbook Pro 13 polegadas.

Mais do que isso, todo mundo achava que rodar um Photoshop ou Premiere sendo emulado pelo Rosetta seria provavelmente lento. E eles tão abismados como a performance não só tá aceitável, mas tá realmente rápido, sem engasgos nem nada. Bem diferente de quando pulamos de PowerPC pra Intel em 2006. Sério, eu lembro de usar o primeiro Rosetta nos Macbook brancos Intel e rodar qualquer coisa pelo Rosetta era super lento. Dava desgosto de usar. Mas nos M1 de agora, ao que tudo indica, vai rodar quase que igual à velocidade de quando rodava no Macbook Intel.

Eu fiquei pensando sobre isso e vale lembrar um dos motivos possíveis. Todo mundo tá cansado de ouvir que a diferença de chips x86 e ARM é que um tem instruções mais complexas e o outro tem instruções mais simples. Pense por um segundo no que isso significa. A cada clock o processador executa uma ou mais instruções. Quanto mais instruções for possível executar por clock, maior a velocidade e menor o consumo de energia. O problema de instruções de complexidade variada é que é difícil de adivinhar quantas instruções dá pra rodar a cada clock. Pra ser mais exato, uma instrução x86 pode ser de um até 15 bytes de comprimento.

Por causa disso um processador Intel costuma executar algo em torno de quatro instruções por clock. Isso é horrível, porque faz de conta que chegamos numa parte do programa que tem 10 instruções simples de um ou 2 bytes um atrás do outro. Talvez o processador pudesse rodar oito, dez ou mais instruções dessas no mesmo clock. Mas como nem sempre dá pra saber se cabe ou não, ele roda só quatro. E fazendo isso ele tá desperdiçando clock, desperdiçando energia. E sem mudar a arquitetura de instruções, o pipeline sempre vai ser curto e isso é inerente a ser um x86.

Agora, processadores ARM tem instruções ou de 16 ou de 32 bits, ou seja, de 2 ou 4 bytes. E só. E eles não se misturam. Ou você tá executando instruções de 32-bits ou de 16-bits. Pra mudar entre um ou outro você manda uma instrução pra mudar o mode. Isso significa que você sempre sabe exatamente o tamanho das instruções e com isso pode configurar um pipeline mais longo por clock. Em particular, o chip M1 da Apple consegue executar oito instruções por clock. Só em profundidade desse pipeline, um chip M1 de 2Ghz tem potencial de ser duas vezes mais veloz e eficiente do que um chip Intel equivalente de 2Ghz. Mais do que isso, um chip M1 de 2Ghz pode ser competitivo com um chip Intel de 3 ou até 4Ghz, por isso você tanto ganho de bateria e menos calor sendo dissipado.

Mas não é só isso. Considere o aspecto de emulação. Pra um chip ARM emular Intel é relativamente mais fácil do que Intel emular ARM. Por que? Porque como ARM tem instruções simples, ou seja, mais básicas, ela consegue emular facilmente qualquer instrução mais complexa de Intel. Por exemplo. Pra facilitar a explicação imagina se fossem processadores gráficos. Digamos que em ARM existam funções como desenhar uma linha, desenhar um círculo, desenhar um triângulo.

Porém, em Intel existem funções mais complexas como, desenhar um botão, desenhar uma janela. Entenderam o que significa quando se fala em diferença de complexidade? Um só desenha linhas o outro numa única instrução já desenha um botão inteiro. Com instruções nesse ARM hipotético, como desenhar linha, eu consigo desenhar os botões ou janelas. Só vai dar mais trabalho porque eu preciso desenhar linha a linha. Se eu fosse um programador de assembly que precisa usar só essas instruções, seria um parto fazer isso. Mas como hoje escrevemos tudo em C ou outras linguagens, não faz diferença. Quem vai ter mais trabalho vai ser o compilador e não o programador. Agora, se eu só tenho instruções complexas, como desenhar o botão inteiro, como que eu desenho só uma linha? Fácil, eu faço um botão com 1 pixel de comprimento. Só que agora eu tô gastando o tempo de processamento de desenhar um botão inteiro pra fazer uma simples linha, portanto vai ser mais lento.

Pra piorar a situação, pra rodar instruções de x86, você precisa fazer o equivalente a passar argumentos pra uma função, como num javascript por exemplo. No caso, os argumentos você preenche em registradores e depois chama a instrução, que seria o equivalente de uma função. Ou seja, existe um número limitado de argumentos que uma instrução pode receber, porque existem poucos registradores, que funcionam como variáveis globais numa linguagem como Javascript ou PHP. Pois bem, processadores x86 como Intel de 32-bits possui só 8 registradores de uso geral. Os processadores x86 de 64-bits que a maioria de nós usa hoje tem 16 registradores de uso geral.

Adivinha quantos registradores tem um processador ARM de 32-bits? Dezesseis! E quantos tem o ARMv8 de 64-bits? Trinta e dois registradores. O dobro dos equivalentes x86. Ou seja, fodeu, pra um Intel emular uma instrução ARM que tem o dobro de registradores, ele vai ser obrigado a fazer vários truques pra lidar com argumentos que não cabem em todos os registradores que ele tem, e, de novo, a performance vai ser necessariamente mais baixa. No lado oposto, um chip Apple M1 que é um ARM de 64-bits, ele consegue facilmente emular qualquer instrução de x86 64 bits, porque tem registradores sobrando. Então a programação não precisa de truques, é super direto.

No frigir dos ovos? É uma ordem de grandeza mais simples e mais performático pra um processador ARM emular binários de x86 do que o oposto. O Rosetta de de 2006 era lento, porque ele tava justamente na situação oposta: precisava fazer os antigos processadores Intel dos novos Mac emular binários legados de PowerPC que é uma arquitetura RISC como ARM, era o caso de ter que usar uma função complexa que desenha um botão e desperdiçar o processamento pra emular uma linha.

É um dos motivos de porque é mais difícil ter emuladores de processadores RISC rodando bem em cima de um processador Intel. Por exemplo, até hoje não é performático emular os antigos PowerPC pra rodar Mac antigo. Da mesma forma é lento emular chips de smartphone, como os da Qualcomm que tem na maioria dos celulares Android que usamos. Já o inverso é mais rápido. Por isso eu fiquei um pouco decepcionado com o processador SQ1 que a Microsoft criou em parceria com a Qualcomm pra equipar os Surface Pro X.

O SQ1 é um Apple M1 piorzinho. Também é um chip ARM e tá rodando Windows 10 compilado pra ARM, como o Big Sur no caso do Mac. E pra rodar programas legados de x86, ele também roda um emulador. Até hoje tá limitado a rodar binários de 32-bits e mesmo assim roda muito lento. Tá pra sair o suporte a emular binários de 64-bits, e a expectativa é que seja um pouco melhor, mas mesmo assim ainda atrás da Apple. Talvez você nem tenha ouvido falar do Surface Pro X, mas não é de hoje que a Microsoft vem tentando usar chips ARM também. A Apple não foi a primeira, mas pra variar, foi a que entregou mais bem feito.

O fato de emular x86 em cima de ARM não ser tão difícil e não representar uma perda tão significativa de performance é importante, porque com Windows, MacOS e Linux ganhando cada vez mais otimizações pra ARM, significa que a hegemonia da Intel tá com os dias contados. Por causa dos smartphones a tecnologia ARM evoluiu bastante e em ambiente móvel, a Intel simplesmente não tem como competir. E agora esses processadores tão pulando pra notebooks e desktop, e já tão bons. E com emuladores ninguém vai ficar preso em Intel por causa de aplicativos legados. E se esse caminho der certo, em breve esses chips ARM vão invadir em massa o ambiente de servidores. Aliás, o maior supercomputador do mundo já usa ARM. E isso poderia representar o último prego no caixão da Intel. Ela vai precisar se mexer rápido pra evitar isso.

Eu vou falar um pouco mais sobre ARM no próximo episódio, mas de qualquer forma a comunidade de desenvolvimento de emuladores é grande. Eu sempre fico impressionado porque na maior parte são voluntários trabalhando só pelo prazer de ver as coisas funcionando mesmo, já que não se pode ganhar muito dinheiro em cima de jogos que ainda tem licenças e copyrights, especialmente se mexer em consoles da Nintendo. Nunca mexa com a Nintendo, é processo garantido e muita diversão pra se livrar. A única exceção é se você vive na China, daí você tá seguro.

Não dá pra falar de emuladores e não tocar no assunto de pirataria. É um assunto controverso, ser a favor ou contra direitos autorais e eu vou dizer que sou neutro nessa discussão. Não tenho uma solução completa nem pra um lado, nem pro outro. Então não vou tentar argumentar hoje. Mas sim, como todo mundo, eu já pirateei muito quando era moleque. Eu teria tido muito mais dificuldade pra começar a ganhar dinheiro se não fosse pela pirataria naquela época, então tem esse ponto mesmo. Hoje em dia não tenho esse problema, então não tenho motivos pra piratear e pago tudo que eu uso, acho justo.

Mesmo assim, existem software antigos especialmente de lugares como Japão por exemplo, que mesmo eu querendo comprar, não existe pra vender, e nesse caso a pirataria tem a função de preservar software do passado. E isso é outro fator importante. Então, se você é a favor ou contra, não sou eu que vou te julgar. Isso tudo dito, assim como todo YouTuber que fala do assunto, eu não vou dizer onde você encontra jogos pirata, mas qualquer um que saiba usar Google e sabe diferenciar de um malware, vai achar o que procura sem muito trabalho.

E por hoje é isso aí! Já divaguei bastante e vai ter mais nerdice no próximo episódio. Eu sei que o assunto do Apple M1 tá na cabeça do povo, mas não pretendo fazer um video só sobre isso porque já tem bastante, mas de vez em quando vou salpicando algumas curiosidades como fiz hoje e vou fazer no próximo. Se ficaram com dúvidas não deixem de mandar nos comentários, se curtiram o video mandei um joinha e compartilhem o video com seus amigos, assinem o canal e não deixem de clicar no sininho pra não perder os próximos videos. A gente se vê, até mais!

DESCRIÇÃO

Errata: em 17:12 eu disse certo mas na equação faltou mostrar dividindo tudo por 2. Em 13:00 eu claramente faltei na aula porque 278 x 7 é 1946 😅

Você não precisa ter assistido o video anterior pra entender este, mas certamente ajuda.

Hoje vou acelerar na missão de fazer vocês entenderem como computadores em geral funcionam por baixo dos panos usando um Nintendinho e o Super Mario como guias nesta jornada.

Não tentem entender tudo na primeira assistida. Eu mesmo não conseguiria. Assista até o fim pra ter a visão completa depois retorne pra partes específicas pra pegar em mais detalhes.

Já aviso que os primeiros Vinte Minutos podem parecer um pouco devagar, porque vou complementar o que comecei no video anterior, mas garanto que depois disso vem o filé mignon do filé mignon. Vamos ver como se constrói um emulador, como cartuchos funcionam, como começar a editar jogos e a entender como se começa a pensar em fazer jogos retrô, e vamos até falar de speedrun e hackear bugs de jogos. Tudo isso num único episódio!

Links:

• Super Mario Bros. 3 - Wrong Warp (https://www.youtube.com/watch?v=fxZuzos7Auk)

• A Comprehensive Super Mario Bros. Disassembly (https://gist.github.com/1wErt3r/4048722)

• Lembra deles? Confira jogos brasileiros do Master System lançados pela Tectoy! (https://blogtectoy.com.br/lembra-deles-todos-jogos-brasileiros-do-master-system-lancados-pela-tectoy/)

• Free NES assembler (https://bisqwit.iki.fi/source/nescom.html)

• Micro Mages (https://morphcatgames.itch.io/micromages)

• Nes Dev Wiki (https://wiki.nesdev.com/w/index.php/Nesdev_Wiki)

• Computer Archeology - The Legend of Zelda (https://www.computerarcheology.com/NES/Zelda/)

• 6502 Instruction Set (https://www.masswerk.at/6502/6502_instruction_set.html)

• An introduction to 6502 math: addiction, subtraction and more (http://retro64.altervista.org/blog/an-introduction-to-6502-math-addiction-subtraction-and-more/)

• Explain Half Adder and Full Adder with Truth Table (https://www.elprocus.com/half-adder-and-full-adder/)

• Build a multiplying machine using NAND logic gates (https://codegolf.stackexchange.com/questions/12261/build-a-multiplying-machine-using-nand-logic-gates)

• Tool Assisted Game Movies (http://tasvideos.org/)

• RETRO INSECTIVORES: FINDING AND ELIMINATING BUGS IN NES DEVELOPMENT (https://megacatstudios.com/blogs/press/retro-insectivores-finding-and-eliminating-bugs-in-nes-development)

• FCEUX (https://sourceforge.net/projects/fceultra/)

• Zelda Screen Transitions are Undefined Behaviour (https://gridbugs.org/zelda-screen-transitions-are-undefined-behaviour/)

• NES Emulator Debugging (https://gridbugs.org/nes-emulator-debugging/)

• Two’s Complement Multiplication (http://pages.cs.wisc.edu/~david/courses/cs354/beyond354/int.mult.html)

• NES Hello World (https://www.embed.com/nes/hello-world.html)

• DF Direct: CRT Displays - Was LCD A Big Mistake For Gaming? (https://www.youtube.com/watch?v=tvRyVZWuvQ4)

• DF Direct! Modern Games Look Amazing On CRT Monitors… Yes, Better than LCD! (https://www.youtube.com/watch?v=V8BVTHxc4LM)

• Mod pra Wonderboy II Turma da Monica (https://www.youtube.com/watch?v=zQCm_y31SC0)

• Meu fork do emulador de NES em Go (https://github.com/akitaonrails/nes)

• Meu código do decodificador de código de Game Genie (https://github.com/akitaonrails/gamegenie)

Assinem estes canais:

• Retro Game Mechanics Explained (https://www.youtube.com/channel/UCwRqWnW5ZkVaP_lZF7caZ-g)
• One Lone Coder (https://www.youtube.com/channel/UC-yuWVUplUJZvieEligKBkA)

SCRIPT

Olá pessoal, Fabio Akita

O tema do video da semana passada é um buraco de coelho de Alice no País das maravilhas. Estou demorando pra soltar videos porque cada assunto que eu esbarro vou pesquisar e abro mais uma dúzia de abas. Daqui a pouco vou encher meus 32GB de RAM só de abas. Computação retro é uma área gigantesca. Vocês não imaginam quantas comunidades existem não só colecionando itens antigos mas ainda desenvolvendo em assembly de MOS 6502 e outros processadores antigos como Z80, Intel 8088 e isso só no mundo dos 8-bits. Se entrar em 16-bits vai cair em processadores como o 65C816 do Super NES.

Eu reescrevi o script de hoje várias vezes, numa das versões eu estava gastando páginas e páginas só pra tentar explicar o problema da multiplicação em processadores antigos. Mas ficou muito fora do escopo do canal. Só pra dar um gostinho, no último video comecei a mostrar um pouco do Assembly do 6502 e algumas instruções básicas como LDA ou STA pra dar load no acumulador ou store do acumulador pra algum outro lugar.

Avançando pra operações aritméticas temos instruções como ADC ou SBC pra adição e subtração. Você já começaria coçando a cabeça quando precisasse somar números maiores do que 255, que é o limite que cabe em 1 byte, ou 8-bits. Lembra que o 6502 é uma CPU de 8-bits? Então todas as instruções só conseguem trabalhar com 8-bits de uma só vez. Pra trabalhar com números maiores a gente particiona o número e calcula 1 pedaço de 1 byte de cada vez. Vamos entender um pouco mais disso.

Como todo mundo pelo menos já deve ter ouvido falar, chips como o 6502 são feitos de componentes menores, como um transistor. Um transistor, em sua essência é um componente que funciona como um switch, ou interruptor. Acho que essa é a imagem mais simples de ter na cabeça. Você pode comprar transistors individualmente empacotados como um componente mais fácil de manipular num protoboard como esse aqui (video).

Aliás, no video anterior eu chamei isso de breadboard que é como falam nos Estados Unidos, mas aqui se chama protoboard. Enfim, usando transistores é possível criar alguns dos circuitos mais simples de todos, as portas lógicas, que são peças fundamentais sobre as quais todo o resto é montado. Por exemplo, você pode montar uma porta lógica NOT num protoboard com um transistor, um resistor, um led pra ver a resposta, uma bateria e fios pra conectar. Uma porta NOT quando você manda 0 ele responde 1, ou quando manda 1 ele responde 0. Uma porta NOT pode ser feito com dois transistors, por exemplo.

Além de NOT podemos montar outras portas fundamentais como OR, AND, NAND, XOR que é exclusive OR e assim por diante. E com essas portas podemos montar coisas mais complicadas como uma CPU inteira. Com outras construções como flip flops, podemos montar memória, e por aí vai. À primeira vista é difícil de entender como operações simples como inverter bits pode ser útil. Vamos pensar numa operação um pouco mais complicada que queremos ter numa CPU, por exemplo somar dois números.

Assumindo que todo mundo sabe somar. Pense uma conta besta, somar 28 mais 22. Você começa somando 8 com 2, vai dar 10, coloca zero embaixo e sobe 1. A mecânica interessante aqui é esse “sobe um”. Agora soma esse 1 que subiu com 2 do 28 e 2 do 22 e vai ter 50. Pra somar em binário é exatamente a mesma coisa. Pra converter um número decimal em binário, você vai dividindo por dois. 28 dividido por 2 é 14, resto 0. 14 por 2 é 7, resto 0, 7 por 2 é 3, resto 1, 3 divido por 2 é 1, resto 1. Então fica 11100. Pra ser 8 bits só completar os 3 zeros à esquerda.

Fazendo mesma coisa com 22 fica 0001 0110. Números pequenos uma hora você lembra de cabeça, mas pra números maiores qualquer calculadora do Windows mesmo converte pra você. Ou em qualquer linguagem de programação tem uma função de formatar strings onde você passa um inteiro e diz que quer formatar com base 2. Num javascript basta chamar o método .toString com argumento 2 num número.

Pra somar esses dois binários, você começa da direita pra esquerda também, zero mais zero é zero. Depois zero e um é um. 1 e 1 é 2 que em binário é 1 0, então coloca zero e sobe 1. 1 mais 1 mais zero, mesma coisa, coloca zero e sobe mais um. 1 + 1 + 1 é 3, coloca 1 e sobe 1. 1 mais zero mais zero é 1. E o resto é zero. Então o resultado final é 0011 0010. Só parece difícil porque você ainda não tá acostumado a enxergar zeros e uns, mas a regra é a mesma e usa a mesma mecânica do “sobe um”.

A máquina de adição mais simples que soma 2 bits é chamado de half adder ou meio somador. Você liga uma porta AND com uma porta XOR e vai ter a soma e o carry bit. Carry é o bit onde grava o “sobe 1”. O meio somador vai fazer exatamente o que eu fui descrevendo agora. Se passar 0 e 0 a soma é 0. Se passar 1 e 0 ou 0 e 1 a soma é 1. Se passar 1 e 1 a soma é 2, então baixa 0 e sobe 1 pro Carry bit. A versão completa se chama full adder ou somador completo.

Um dos jeitos de montar um somador completo pode ser ligando duas portas XOR, duas portas AND e uma porta OR. Ou melhor ainda, ligando dois meio somadores. A diferença é que além dos 2 números pra somar ele também recebe o carry bit de entrada e com isso podemos cascatear múltiplos circuitos de somador completo um embaixo do outro, ligando o carry bit de saída de um somador na entrada do outro. Se quisermos somar com números de 4-bits adicionamos 4 somadores completos em cascata. Pra 8-bits precisamos de 8 somadores. E com isso adquirimos um somador completo de 8-bits! (som de zelda)

Um circuito de somador completo pode ser montado de maneiras diferentes e com isso varia o número de transistors, mas pense que na média vai ser alguma coisa na faixa de 10 transistors pra cada somador. Pra somar números de 8 bits vamos precisar de no mínimo uns 80 transistors. Pra hoje em dia isso não parece grande coisa já que um processador A13 Bionic dos iPhone 11 Pro tem 10 bilhões de transistors. Um AMD Ryzen 7 3700X tem quase 6 bilhões de transistors e um AMD Epyc Rome, que é pra servidores, tem mais de 39 bilhões de transistors. Lembrando que são todos chips de 64-bits.

Nosso pobrezinho MOS 6502 de 8-bits tem na faixa de 3500 transistors, lembrem-se que estamos falando do meio dos anos 70. O que viemos fazendo depois, além de aumentar mais e mais a densidade de transistors por centímetro quadrado, foi adicionando novas funcionalidades como SIMD que são instruções de single instruction multiple data pra computação paralela, instruções de virtualização como VT-X ou AMD-V, instruções pra criptografia como AES, sem contar que os chips hoje são multi-core então é como se fossem múltiplas CPUs apertadas no mesmo chip. Mas as instruções fundamentais como somar bytes, carregar acumulador, incrementar contador de programas, atualizar apontador de pilha, e coisas assim que vimos no hello world da semana passada ainda é similar.

Um primeiro insight é que os chips hoje são na ordem de 10 milhões de vezes mais densos de transistors que os chips dos anos 80 pra trás. Porém isso não se traduz necessariamente em programas 10 milhões de vezes melhor. Pegue o melhor da geração 8-bits que foi Super Mario 3 e compare com New Super Mario Bros rodando no Switch cujo SoC Tegra X1 tem na faixa de 7 bilhões de transistors com 4 cores ARM Cortex A57 ativos.

Vamos descer um pouco mais hardcore pra dar mais contexto com o tipo de CPU que estamos trabalhando. Adição eu disse que fazemos mais ou menos do mesmo jeito que você faria no papel somando digito a digito e subindo 1 quando precisa. Se hoje em dia temos transistors de sobra nas CPUs, nos 3500 que tinha num 6502, cada transistor contava. Então só era implementado o estritamente necessário. Somadores completos numa cadeia de 8 bits está implementado na instrução ADC.

Se recapitularmos sobre o pouco que aprendemos sobre assembly do 6502, pra realizar uma adição de números de 8 bits, faz de conta, o número 1 mais 2 poderíamos fazer assim.

	LDA #$01
	ADC #$02
	STA $6000

Começa com LOAD do número 1 no acumulador, ADC que é adição com carry onde passamos 2 e ele vai somar com o número 1 que já tava no acumulador, daí armazena ou Store do resultado que fica no A pra algum endereço na memória, como o endereço $6000 que, no video anterior, ia mandar pro chip de trava e de lá pro LCD. Isso é uma coisa que hoje em dia você não se preocupa porque as linguagens de programação já cuidam disso, mas o 6502 faz cálculos com números de 8-bits. O valor máximo que cabe em 8 bits sem sinal é FF ou 255. O que acontece se eu tentar somar 255 + 255? Precisamos de mais bits.

Só porque uma CPU é de 8-bits não quer dizer que não podemos calcular números maiores, mas pra fazer isso precisamos particionar o número e lidar com pedaços dele. Por exemplo, digamos que tivéssemos uma CPU decimal mas que só faz conta com números de 2 dígitos de cada vez, então de 0 até 99. Se somarmos 99 + 5 teríamos 104. Precisaríamos gravar o 1 separado do zero quatro. No caso da soma, eu disse que todo somador completo lida com 1 bit do número. A instrução ADC é como se fossem 8 somadores completos em cadeia pra 8-bits.

Uma nomenclatura que às vezes você vai esbarrar é high order e low order. Quando lidamos com 16-bits, temos 2 bytes. O primeiro byte à esquerda chamamos de high byte e o último à direita de low byte. Dentro de cada byte tem 8-bits o bit mais à esquerda é o MSB ou Most Significant Bit e o último bit é o LSB ou Least Significant Bit, literalmente bit mais significativo e menos significativo. Lembra quando expliquei sobre little endian no episódio anterior? É pegar os 2 bytes e inverter, assim o low byte é lido antes do high byte.

Voltando pra soma, toda vez que tiver um “sobe 1” ele vai ser gravado no registrador C. Antes de toda soma o certo é usar a instrução CLC, literalmente Clear C, pra limpar esse registrador. Mas podemos não limpar também. Lembra que falei que registradores funcionam como varíaveis globais? Várias instruções deixam efeitos colaterais pra trás, deixando registradores com a sobra do que foi processado. E podemos usar isso a nosso favor, começar somando a primeira metade do número até 8-bits, e depois somar a segunda metade que vai usar o carry no C e continuar a soma com o resto dos bits. Por exemplo, digamos que temos um número grande, de 24-bits tipo o número 2 milhões. Seriam 3 pedaços de 8 bits cada que podemos chamar de high, medium e low byte.

Declaramos então os 3 pedaços do primeiro número A como A hi, A mid e A lo, depois B hi, B mid e B lo. Começamos limpando o registrador C, fazemos a soma dos bytes low, que é dar load no A low, adicionar com B low e guardar esse resultado parcial em B low; depois mesma coisa com os bytes medium e high. A soma final é a junção dos três pedaços de B.

; ex: 8 milhões = $7A 12 00, A_hi = $7A, A_mid = $12, A_low = $00 A_hi, A_mid, A_lo B_hi, B_mid, B_lo

START: CLC ; Clear C only to start. LDA A_lo ADC B_lo STA B_lo

    LDA  A_mid  ; Note that here we don't re-clear C, but just
    ADC  B_mid  ; let it do its job of adding the 9th bit that
    STA  B_mid  ; didn't fit in the result of the previous byte's
                ; addition.
    LDA  A_hi
    ADC  B_hi
    STA  B_hi

Pense na sua linguagem favorita, você nunca se preocupa com isso, simplesmente escreveria A + B. Como você tem processamento e memória de sobra e seus programas nunca são particularmente complicados, mesmo que tenha desperdícios, não chega a ser um problema. Mas quando seus recursos são extremamente limitados, desperdiçar bits é um problema real. Desperdiçar ciclos também, porque cada instrução gasta alguns ciclos de clock. Nada sai de graça. Um processador moderno roda na faixa de 2Ghz a 5Ghz hoje em dia, mas um 6502 roda entre 1 a 3 Mhz.

Portanto em máquinas pequenas como o 6520 queremos tanto economizar a quantidade de memória usada quanto o número de instruções pra não desperdiçar clocks. Literalmente podemos fazer dezenas de milhões de instruções a menos por segundo num 6502 do que num processador moderno de qualquer smartphone hoje. Fazer programas simples num computador excessivamente poderoso é muito fácil, qualquer um faz. Eu sempre digo que você sabe quando um programador é bom quando ele consegue programar num sistema com restrições, porque a arte de programar é conseguir tirar o máximo que o hardware oferece.

Vamos dar outro exemplo besta. Já sabemos como CPUs fazem adição. Subtração e multiplicação é a mesma coisa. Podemos desenhar circuitos como no caso do somador completo e implementar com transistors. Como falei antes, no 6502 temos a instrução ADC pra adição e também temos SBC pra subtração, mas não tem multiplicação.

Digamos que você, que nunca estudou nada de engenharia ou ciências da computação pense numa forma de implementar multiplicação só usando operações básicas que falamos até agora como adição, o que você faria? Eu aposto como a solução mais imediata que a maioria pensaria seria via adições sucessivas. Por exemplo se quisermos multiplicar 278 vezes 7, você iria somando 278 sete vezes até dar 1148. Seriam só 7 adições e não parece tão ruim assim. Aquele famoso caso de “testei aqui e no meu computador funciona”.

Mas e se quisermos multiplicar 10 mil vezes 10 mil? Agora precisa fazer 10 mil somas pra chegar no resultado. Isso é consideravelmente mais devagar e com números maiores só vai piorando. Vamos usar tempos hipotéticos só pra ilustrar. Pra somar cada bloco de 8 bits digamos que precisariamos gastar uma instrução de LOAD, uma de ADC e outra de STORE, cada um custando uns 5 ciclos de clock. 10 mil é um número que podemos representar em 2 bytes ou 16 bits. Então são pelo menos 2 loads, 2 adc e 2 stores pra cada rodada.

Então temos 6 instruções custando uma média de 5 ciclos de clock, ou seja 30 ciclos. Em 1 Mhz podemos ter no máximo umas 33 mil sequências dessa por segundo. Mas se precisamos executar 10 mil sequências de soma dessas gastaríamos 1/3 de segundo ou pelo menos 300 milissegundos. Lembrando que estou considerando condições ideais de temperatura e pressão, como a gente falava no colégio, mas provavelmente gastaria mais ciclos que isso. Parece pouca coisa mas 300 milissegundos é mais tempo que leva pra você pedir uma página num site, ele processar, retornar o HTML e seu navegador renderizar. Aliás, se sua aplicação web demora 300 milissegundos pra responder, isso é considerado lento quase parando.

Pra variar, não existe uma fórmula universal de multiplicação que tem 100% de melhor performance pra todos os casos. O bom senso é o contrário: fórmulas universais costumam ser lentas. Isso é uma coisa que, como programador, você precisa entender: existem fórmulas que funcionam melhor pra casos diferentes. Por exemplo, no episódio anterior eu já disse como faz multiplicação por 2: basta fazer um shift left, que é o equivalente a adicionar um zero no final do binário e pronto, tá multiplicado numa única instrução.

Você não conhece formas diferentes de multiplicar? Deixa eu contar um diferente. Existe um método ensinado no primário de escolas Russas que ficou famoso porque a gente associa tudo que é russo com excelência em matemática. Na real é um método bom pra números pequenos e não é particularmente bom pra computadores. É chamado de método do camponês russo. Vou explicar de curiosidade.

O método é assim: dobre o primeiro fator, divida o segundo fator pela metade. Se o segundo fator for par ignore e repita. Se o segundo número for ímpar, some o primeiro fator com o anterior. Por exemplo, digamos que eu quero multiplicar 278 por 7 como falamos antes. Primeiro dobramos o primeiro fator. Multiplicar por 2 todo mundo consegue fazer de cabeça e vai dar 556. Daí 7 divido por 2 é 3. 3 é impar então somamos 556 com 278 e temos 834. Agora dobramos 556 de novo e vamos ter 1112. No segundo fator temos 3 dividido por 2 que é 1, que é impar, então somamos com 834 com 1112 e vamos ter 1.946. Como o segundo fator chegou a 1 acabamos e a resposta é 1.946. Pode abrir uma calculadora aí e checar.

Não é difícil implementar isso em Assembly. Existe um site excepcional que é a fonte de referência de qualquer um que quer implementar um emulador de NES que é o Wiki Nesdev e quando fala de multiplicação ele implementa justamente esse algoritmo do camponês russo que fica assim:

https://wiki.nesdev.com/w/index.php/8-bit_Multiply

;;
; Multiplies two 8-bit factors to produce a 16-bit product
; in about 153 cycles.
; @param A one factor
; @param Y another factor
; @return high 8 bits in A; low 8 bits in $0000
;         Y and $0001 are trashed; X is untouched
.proc mul8
prodlo  = $0000
factor2 = $0001

  ; Factor 1 is stored in the lower bits of prodlo; the low byte of
  ; the product is stored in the upper bits.
  lsr a  ; prime the carry bit for the loop
  sta prodlo
  sty factor2
  lda #0
  ldy #8
loop:
  ; At the start of the loop, one bit of prodlo has already been
  ; shifted out into the carry.
  bcc noadd
  clc
  adc factor2
noadd:
  ror a
  ror prodlo  ; pull another bit out for the next iteration
  dey         ; inc/dec don't modify carry; only shifts and adds do
  bne loop
  rts
.endproc

Você dá load do multiplicador no acumulador, load do multiplicando no registrador Y e roda essa rotina e ele vai gravar o low byte do resultado no endereço $0000 e o high byte em A. Lembra que números maiores que 8-bits fica particionado em múltiplos bytes? O resultado de uma multiplicação costuma ser um número com o dobro de bytes dos fatores, então multiplicar 2 números de 8 bits dá um resultado de 16 bits.

Esse algoritmo gasta em torno de 150 ciclos. Se seu programa for ter poucas multiplicações pode ser suficiente. Mas qualquer operação que gasta mais que 100 ciclos num 6502 não é exatamente rápido. Existem maneiras mais rápidas que isso. E aqui vem outro insight que como programador você precisa ter na cabeça. Algoritmos costumam ser um balanço de dois fatores: se você quiser economizar memória vai acabar gastando mais ciclos de processamento. Se quiser velocidade economizando ciclos provavelmente vai gastar mais memória. Por exemplo, vamos pensar um pouco mais: como você faria multiplicações rápido no primário, sem calculadora?

Pra números pequenos você provavelmente teria que ter decorado a tabuada, lembram disso? Tenho certeza que a maioria odiava ter que decorar a tabuada. Mas lembrem de uma coisa, a tabuada é uma tabela pré-calculada. Você procura o multiplicando e o multiplicador e instantaneamente tem a resposta. Imagine uma tabela pré-calculada pra todos os números que cabem em 8-bits. Daí basta achar a posição na matriz com o resultado direto. Você vai gastar ciclos pra pré-calcular a tabela da primeira vez ou pode ler direto a tabela de uma ROM. O problema dessa solução é que fácil fácil ela vai ocupar 16 kilobytes de espaço ou mais. Considerando que um Super Mario Bros inteiro cabe em 40 kilobytes estamos falando em gastar 1 terço disso só numa tabela de números, o que seria um enorme desperdício.

Uma tabela pré-calculada é o que chamamos de lookup table e isso é uma técnica usada em todos os lugares da computação. Você que faz desenvolvimento web provavelmente já usou ou vai usar isso. Por exemplo quando faz cache com um Redis ou Memcache, é um lookup table. Quando cria índices numa tabela de banco de dados, isso é um tipo de lookup table. O problema é que se essa tabela for grande demais, o tempo pra procurar na tabela também pode começar a ser um problema, fora desperdício de espaço caso você não planeje direito.

Mas como seria uma maneira melhor então? E aqui a matemática nos ajuda. Se você estudou Álgebra e trigonometria não vai achar estranho o que vou dizer a seguir. Uma multiplicação de dois fatores a e b pode ser descrita de maneiras diferentes. Por exemplo, ela pode ser a exponencial da soma dos logaritmos de a e b. Se quiser ser mais complicado pode ser a soma do cosseno de x mais y com o cosseno de x menos y, tudo dividido por 2. Sendo que x é o arco cosseno de a que também é chamado do cosseno inverso. Arco cosseno é usado pra determinar o ângulo do cosseno em radianos. Y da mesma forma é o arco cosseno de b.

Continuando, a vezes b pode ser também o quadrado de a mais b, menos o quadrado de a, menos o quadrado de b, tudo dividido por 2 ou, finalmente, pode ser o quadrado de a mais b menos o quadrado de a menos b tudo dividido por 4. E essa opção final é que nos interessa, pois podemos reduzir a fórmula pra ser a subtração de a mais b aplicado numa função F, com a menos b na mesma função F, sendo essa função F o quadrado do número que passarmos dividido por 4.

A parte importante é que decompomos o problema da multiplicação numa adição dos fatores, subtração dos fatores e subtração do resultado da tal função F. E a essa função reduz o tamanho do lookup table pra em vez de ser todos os possíveis resultados da multiplicação de todos os números de 8-bits, pra simplesmente ter uma tabela só com o resultado da multiplicação do quadrado dos números. Ou seja, de 1 vezes 1, de 2 vezes 2, de 3 vezes 3 e assim por diante, que é uma quantidade pré-calculada ordens de grandeza menor, caindo dos 16 kbytes que eu falei pra talvez meio kbyte.

E pra calcular o quadrado de todos os números também vai ser rápido porque existe a propriedade que o quadrado do número é o quadrado do número anterior mais um número impar. Quadrado de 1 é zero mais 1. Quadrado de 2 é o 1 anterior mais o próximo impar que é 3, resultado 4. Quadrado de 3 é 4 mais o próximo impar 5 que dá 9. Quadrado de 4 é 9 mais o impar 7 que dá 16. Quadrado de 5 é 16 mais o próximo impar 9 que dá 25 e assim por diante.

E como eu disse no começo, dá pra ir longe estudando sobre assembly. Outros assuntos que tava pensando em cobrir neste episódio incluíam o conceito de complementar de dois, números inteiros com sinal pra lidar com negativos, algoritmo de Booth pra multiplicação e muito mais. Mas é teoria demais pra um único video, por hoje vou parar por aqui. Mas eu queria gastar pelo menos um pouco de tempo mostrando essa linha de raciocínio pra vocês entenderem que não, hoje em dia você dificilmente vai gastar tempo implementando uma multiplicação na mão. Toda CPU já implementa as melhores fórmulas em hardware e pra quem precisa de casos específicos existem bibliotecas voltadas pro campo científico que otimizam os piores casos.

Mas é importante você entender que tudo que uma linguagem te oferece, cada pequena coisinha insignificamente como aquele mero asterisco de multiplicação teve milhares de horas homens de pesquisa, experimentação, otimizações. Literalmente muito suor e lágrimas até chegar no estado da arte que você usa hoje sem nem pensar. É isso que significa subir nos ombros de gigantes, porque é com o conhecimento testado e acumulado de centenas de anos de matemática que esse asterisco de multiplicação se tornou possível e você consegue multiplicar dois números de praticamente qualquer tamanho em microssegundos.

E também é pra entender que muita coisa hoje ainda não tem uma fórmula perfeita. Eu disse que temos CPUs com dezenas de milhões de vezes mais transistors que um 6502 mas ainda assim não temos programas dezenas de milhões de vezes melhores. Isso porque muitas partes do software que usamos ainda não tá rodando da melhor forma possível. Grande parte do que é o trabalho de um programador é não ignorar os problemas e parar pra tentar encontrar formas mais inteligentes de fazer o computador processar.

Muito bem, vamos voltar ao nosso nintendinho. Assim como no exemplo do protoboard do Ben Eater, o PCB que é sigla pra Printed Circuit Board ou placa de circuito impresso, contém o cérebro que é o 6502 e diversos outros chips como chip de RAM, chip de VRAM que é memória de vídeo, e outros componentes como pra ligar seus controles. Tem a PPU que é o Picture Processing Unit ou unidade de processamento de imagens que é a versão primitiva do que hoje você chamaria de GPU. E tem o APU ou audio processing unit pra gerar som.

O nintendinho já foi tão dissecado nas últimas décadas que temos documentação super completa de cada componente em detalhes suficiente pra ter muita gente fabricando chips e PCB novos. Você consegue literalmente comprar um hardware moderno de nintendinho hoje se quiser, e ele vai ser 100% compatível com qualquer cartucho que você tenha guardado.

Mas pro que me interessa, a documentação é tão boa que é possível criar emuladores em software que se comportam exatamente como o hardware. Eu não sei se vocês conseguem entender a beleza disso. Todo hardware tem a capacidade de simular o comportamento de outro hardware via software. E praticamente toda linguagem de programação consegue representar qualquer hardware.

Tendo documentação tão completa como o Wiki Nesdev que eu mencionei antes, poderíamos escrever nosso próprio emulador. E como alguém faria isso? É um processo mais trabalhoso do que difícil porque você precisa ter o trabalho meticuloso de implementar cada detalhe que tá nas documentações, mas por exemplo, podemos começar criando um projeto vazio, digamos usando a linguagem Go. Aliás, como o nintendinho é bem antigo, qualquer linguagem hoje consegue simular um 6502 e os outros componentes.

Não existe “O” jeito correto de se escrever um software. Se você pegar diferentes emuladores de nintendinho vai ver que eles são organizados e escritos de maneiras diferentes. Só com experiência e muitos testes você vai chegar no que é o melhor balanço entre legibilidade e eficiência. Mas pra ser simples podemos pensar nos componentes principais que eu listei. O primeiro elemento que queremos emular é o console, então começamos criando um arquivo chamado console.go e dentro definimos o tipo Console como uma estrutura. E não se preocupe se você nunca viu Go, não é relevante entender cada linha do código hoje, só o raciocínio. Estude depois com calma.

Essa estrutura vai declarar ponteiros pra CPU, pro APU, pro PPU, pro cartucho, pros dois controles, pra um troço que vou explicar depois chamado Mapper, e delimitamos a RAM que é só um array. Lembram todos aqueles hexadecimais que eu falei no video anterior? Pense nesses números como posições no array. Memória é isso: uma listona de bytes. Agora precisamos criar arquivos pra cada um desses componentes e definir as estruturas de cada um. O próximo é o arquivo cpu.go.

A estrutura CPU vai ter muitos dos elementos que eu expliquei no vídeo anterior. Começamos definindo uma referência pra uma estrutura de Memory que vou explicar depois. Daí definimos PC que é o contador de programa como um inteiro gigante de 64-bits, e nem precisava ser tão grande porque ele só aponta pro endereço da próxima instrução, então 16-bits bastava. Vamos definir o SP que é o apontador de pilha como um inteiro de 16-bits. Daí os registradores todos de 8 bits, ou seja 1 byte. Temos o acumulador A, o X, o Y, o C, Z, I, D, B, U, V, N. E por fim temos uma última estrutura importante, um array de instruções.

Lembra que cada instrução como LDA tem um hexadecimal associado, que é basicamente o endereço da localização dessa instrução? Pois é, precisamos colocar cada opcode na posição correta nessa lista. Quando quisermos achar a instrução 0xa9 que é o LDA vamos pra posição 0xa9 que é a posição 169 nessa lista. Daí vamos encontrar a referência pra uma função de Go. Agora precisamos implementar cada uma dessas funções.

Por exemplo, o nosso LDA sabemos que vai escrever o valor no registrador A que é o acumulador. Então em Go é simplesmente associar o valor do argumento na variável A da CPU.

Sabemos também que JSR é o Jump pra uma subrotina, o que ele faz é empurrar o endereço no contador de programas pra pilha e sobrescrever o contador de programa com o endereço da subrotina pra onde tem que pular.

E assim vai, tem que escrever uma função pra cada instrução que existe de acordo com a especificação na documentação do 6502. Uma vez feito tudo isso podemos criar o inicializador NewCPU que vai alocar a estrutura que definimos. Esse inicializador recebe uma referência pra estrutura de console que criamos antes pra passar pra essa nova estrutura chamada Memory. Deixa esse Memory de lado que ainda não é hora pra ele. Em seguida criamos e populamos a tal tabela com referências pras instruções que criamos. Finalmente criamos uma rotina de reset.

Reset é o que você pensou mesmo: o equivalente a você apertar o botão reset que todo console e computador tem. A idéia é limpar o contador de programas pra apontar pro endereço 0xFFFC, lembra no episódio anterior que quando o 6502 inicializa a primeira coisa que ele faz é ir no endereço 0xFFFC procurar a primeira instrução do programa? Pois é. E em seguida limpamos o apontador de pilha pra iniciar em 0xFD. Isso é pra relembrar a importância desses dois registradores, porque é com eles que conseguimos executar um programa.

Tem mais coisas que precisam ser feitas pra CPU ficar completa mas por agora vamos pular pra essa tal de Memory criando um arquivo memory.go. A estrutura em si é muito simples. Ela só vai apontar pra uma referência à estrutura de Console que já definimos antes. A parte importante começa com a função de leitura Read. Ele recebe um endereço e vai devolver algum valor que teoricamente está em alguma lugar na tal memória.

Aqui começa a diferença de um nintendinho e outros computadores que usam o processador 6502 como um Atari ou Apple II, o mapa de memória. No episódio anterior eu expliquei que temos endereços de 16-bits então podemos mapear do endereço 0x0000 até 0xFFFF, daí dividimos esse espaço e por exemplo a CPU ia procurar no EEPROM se passássemos endereços acima de 0x8000. Ou seja, arbitrariamente definimos que certos chips respondem a certos endereços.

A grosso modo, do endereço 0x0000 até 0x07FF temos 2 kilobytes de RAM. Nos endereços de 0x2000 a 0x2007, que é bem curto, temos registradores pra PPU. De 0x4000 a 0x4017 acessamos a APU e registradores de I/O como os controles e só de 0x8000 a 0xFFFF temos o equivalente a uns 32 kilobytes reservados pra endereços que mapeiam pra algum lugar do cartucho. Em particular se acessarmos acima do endereço 0x6000 temos esse negócio que colocamos no código chamado Mapper. Agora vocês precisam entender os truques que eram usados em consoles com cartuchos.

Se sua história com games começa só depois do Playstation 1, você tá acostumado a ter os games em CDs, DVDs, Blu-Ray ou instalados no HD do seu computador. É de praxe que toda vez tem que esperar o famoso “Loading”, que é o tempo do computador começar a carregar os primeiros bytes do jogo na RAM pra só depois conseguir começar a jogar. Daí a cada fase tem que carregar novos bytes pra RAM e jogar fora os bytes da fase anterior que não vai precisar mais. Isso é necessário porque não cabe todo o jogo na memória. Um computador muito bom hoje tem 16 GB, mas qualquer jogo moderno tem 30 GB, 40GB, alguns jogos podem ter absurdos 100GB. Obviamente não cabe tudo na RAM então precisa ir carregando e descarregando de pedaço em pedaço.

Com cartuchos é diferente. O que tem num cartucho são chips de ROM, como expliquei no episódio anterior. Então quando você pluga o cartucho no console, não existe loading, não tem que carregar nada e ele pode iniciar imediatamente porque a CPU acessa os endereços diretamente da ROM, sem precisar carregar o jogo em memória. O cartucho “É” a memória. Entenderam? Diferente de CD ou HD, a ROM do cartucho já tem velocidade máxima de acesso, igual da RAM. Da mesma forma que a CPU consultaria um endereço na RAM, no caso pedindo endereços de 0x0000 a 0x07FF, quando ele precisa de dados do jogo ele pede nos endereços acima de 0x8000 até 0xFFFF.

Por isso jogos de consoles antigos carregam instantaneamente e não tem loading entre fases e tudo é rápido. Um dos maiores gargalos ainda não resolvidos em games modernos de fato é a lentidão do I/O, não só do HD mas de toda a cadeia que carrega dados, incluindo barramento, controlador e tudo mais. Inclusive é isso que a nova geração de consoles PS5 e Xbox Series X estão tentando combater colocando os SSDs e controladores mais rápidos do mercado pra minimizar ao máximo o tempo de carregar coisas do disco. Mesmo assim o tempo nunca vai ser zero como era nos cartuchos.

Vou repetir o que eu disse antes: programação é sempre um trade off, uma troca. Cartuchos tem tempo quase zero de acesso porque ele é direto um chip de memória. O problema é que chips de ROM são muito mais caros de produzir comparado a discos de HD ou Blu-Rays. É bem mais caro. A comparação mais óbvia foi na transição dos cartuchos pro CD quando saiu o Playstation 1 e o concorrente na época era o Nintendo 64 que preferiu usar cartuchos pelas razões que eu acabei de falar.

Jogos de Playstation podiam ter videos e muito mais conteúdo porque num CD daquela época era possível colocar até 650 megabytes de dados. Em comparação um dos maiores cartuchos de Nintendo 64 era Conker’s Bad Fur Day que tinha enormes 60 megabytes, ou seja mais de 10 vezes menos espaço e o cartucho ainda custava mais caro. Os lendários Zelda Ocarina of Time e Majora’s Mask eram cartuchos de menos de 30 megabytes. Por isso jogos de Nintendo 64 raramente tinham algum video e também por isso preferiam usar o mínimo de texturas nos modelos em 3D, porque texturas são imagens bitmap que consomem muito espaço.

Voltando pra era dos 8-bits. Um cartucho como do Super Mario original tem 40 kilobytes, portanto male male encaixa no nosso espaço de endereços reservados pra ROM. Mas um Super Mario 3 tem 385 kilobytes, quase 10 vezes mais bytes que o original. Um dos jogos mais pesados do nintendinho é Kirby’s Adventure e se você rodar vai ver um dos games mais bem elaborados pro nintendinho, chega perto do que seria um jogo de Super Nintendo. Também pudera, o cartucho dele tem quase 800 kilobytes, perto de 1 megabyte.

Mas como é possível endereçar isso tudo de bytes só com endereços de 16-bits? Agora vem o segundo grande fato sobre cartuchos: eles não tem só chips de ROM. Na realidade um cartucho é uma placa de expansão, um PCB completo. Quando falo em placa, pense mesmo como quando você compra uma placa gráfica como um novo NVIDIA RTX e espeta no slot PCI Express na placa mãe do seu computador. Encaixar um cartucho no console é a mesma coisa.

Num PCB você pode plugar não só ROM como qualquer outro componente. Por exemplo, você pode colocar um chip de SRAM e uma bateria de lítio e boom, você acabou de ganhar a capacidade de salvar o jogo. Só que isso torna o cartucho ainda mais caro, por isso nem todo jogo podia salvar. Um dos chips mais famosos se você jogou Super Nintendo foi o chip Super FX, que literalmente era uma placa primitiva 3D que permitiu jogos como Star Fox. O processo é o mesmo, o chip vem no PCB do cartucho.

Você literalmente poderia enfiar um nintendinho inteiro dentro de um cartucho. Mas só isso não responde a pergunta de como fazia pra um Kirby ter quase 1 mega de dados. Não basta só enfiar mais chips de ROM se não temos endereços suficientes pra passar de 32 kilobytes. Endereços funcionam como o nome diz, é como se tivéssemos uma rua de casas e só tivesse 32 números, da casa 33 em diante ficaria sem números. Se o carteiro precisasse entregar alguma coisa nessas casas como ele encontra?

E se nessa rua colocássemos um síndico? Que separasse a rua em blocos? Daí teria casa de 1 a 32 no bloco A, casas de 1 a 32 no bloco B e assim por diante. Continua só tendo 32 números mas dependendo do bloco sempre encontraríamos uma casa diferente. E é exatamente isso que o nintendinho faz. No cartucho, além de vir mais ROM ele vem com um síndico, um controlador que chamamos de Mapper.

Como o nome diz, Mapper é um mapeador. Em vez de blocos na rua do nosso exemplo a memória ROM é dividida em Banks ou bancos. E a técnica pra enxergar mais memória se chama Bank switching. A CPU continua só conseguindo enxergar dos endereços 0x8000 a 0xFFFF mas ele pode pedir pro Mapper trocar os banks, assim como no exemplo dos blocos da rua. Os banks costumam ter 16 kilobytes de tamanho e podemos ter vários banks, então se montarmos o cartucho com ROM suficiente pra 50 banks de 16 kilobytes, vamos ter os quase 800 kilobytes do jogo Kirby.

Agora vem a parte cabeluda pra fazer emulador de NES: não basta só escrever código que representa o console, precisa também emular os chips que vem nos cartuchos, em particular esses mappers. Você poderia imaginar que deve ter alguns poucos modelos de mappers. Mas que nada, se olhar a biblioteca toda de games de nintendinho existem 407 mappers que foram encontrados e documentados. Por sorte, se você cobrir os mappers da própria nintendo e alguns de marcas famosas como Konami, já cobre a maior parte dos jogos. Muitos mappers só existem em jogos muito obscuros, feitos na China ou lugares assim.

Se você olhar de novo no wiki da nesdev vai encontrar o código que vem no cartucho que identifica qual mapper ele tem. No arquivo de Memory ele vai selecionar um Mapper baseado nesse código identificador que ler da ROM. Daí precisamos de cada um dos Mappers, que precisam responder às mesmas funções. Por isso no nosso arquivo de mapper vamos definir uma interface que todos os mappers vão ter que implementar. Basicamente definimos o que um Mapper precisa obrigatoriamente fazer, que é ler da ROM, gravar na RAM e coisas assim.

No inicializador pegamos o cartucho associado no console. Depois que carregarmos uma ROM ele vai preencher esse campo Mapper com seu código identificador, e com isso podemos checar qual mapper vamos ter que carregar. Neste pequeno emulador em Go vai ter só alguns dos principais. De curiosidade esse último mapper código 225 é que permite aqueles cartuchos de 52 jogos em 1 que você já deve ter visto por aí. Um cartucho desses tinha 6 chips de ROM com meio megabyte cada.

Não vou entrar no detalhe de cada um, senão a gente fica aqui até o ano que vem, mas só pra mostrar um, podemos criar um arquivo pro mapper 2. Lembrando que no nosso caso, usando máquinas modernas, não temos esses limites pequenos de 16-bits. Podemos carregar a ROM de um cartucho como um arrayzão contínuo de bytes, seja lá quantos bytes tiver porque temos espaço pra mapear tudo. Então recebemos o endereço que o CPU manda e mapeamos com esse arrayzão.

No caso, o que nos interessa é que quando carregamos a ROM os bytes são identificados como regiões distintas, sendo as duas principais o PRG e CHR. PRG são bytes de programa. CHR são os bytes de caracteres, que é a área onde normalmente estão os tiles. Eu sempre chamo de tiles mas se for traduzir é como se fossem azulejos. Tiles, azulejos, caracteres, são termos que significam a mesma coisa.

O princípio de tiles é simples. Um CPU como o 6502 não fica dando instruções pra escrever pixel a pixel na tela. Ele pede pra escrever tiles. Pense num nintendinho como um editor de textos. Um editor não escreve pixel a pixel na tela, ele escolhe uma letra de alguma família de fontes, digamos Arial, e passa o código que representa ela. E o Windows ou MacOS da vida que vai se encarregar de realmente desenhar os pixels.

No nintendinho quem se encarrega de desenhar os pixels é o chip chamado de PPU que eu falei que é a unidade de processamento de pixels. O CPU não entende pixels, ele entende tiles. Significa que o PPU tem que trabalhar bastante pra desenhar pixel a pixel. Inclusive o clock do PPU é maior que do CPU. Mas a CPU só precisa mandar um byte pra identificar blocos de 8 por 8 pixels de uma vez só, em vez de mandar 64 comandos independentes pra cada um desses pixels.

Se você é de web front-end já lidou com algo assim, é como os sprites de CSS. Aliás a técnica de sprites de CSS não é novidade, isso é uma técnica antiga. Outra técnica antiga são fontes com imagens, como a Font Awesome que todo site hoje usa pra desenhar icones. A memória CHR da ROM que eu falei é como se fosse uma Font Awesome, literalmente caracteres. Cada caracter, ou fonte, é um tile. Acho que assim vocês conseguem visualizar na cabeça. Consoles antigos assim sequer tem fontes ou tabela de letras. Cada jogo define suas fontes e o código das letras, não tem um padrão como ASCII ou Unicode.

A PPU enxerga a resolução máxima de 256 por 240 pixels, e a CPU só enxerga uma grade de 16 por 15 espaços onde cabem os tiles. É parecido com um computador DOS antigo que tem resolução de 640 x 480 mas em modo DOS só enxerga 80 colunas por 25 linhas de texto. O PPU também só consegue enxergar 8 kilobytes de tiles de cada vez, então toda vez que precisamos de tiles diferentes, o CPU pede pro Mapper trocar o banco por outro. Existem dois excelentes emuladores pra quem quer aprender a programar jogos de verdade de nintendinho. Um deles é o FCEUX que acho que é o mais conhecido e o outro é o Mesen que eu acho que tem ferramentas mais modernas.

Vocês entenderam o que fizemos até agora? Eu fui estruturando o nintendinho como código de Go. Cada aspecto dele são estruturas de dados normais como arrays e bytes. Bytes na memória que sabemos exatamente onde estão e com isso podemos consultar a qualquer momento. Seja o emulador feito em Go, em C ou C++ vai ser a mesma coisa. O emulador Mesen implementa de forma parecida mas além de só emular ele expõe essas estruturas de forma visual em tempo real. Por exemplo, podemos abrir um visualizador da memória da PPU e organizar pra vermos os bitmaps.

E olha só o que tem na memória da PPU, esses são os tiles. Cada tile é um quadrado de 8 por 8 pixels. Se eu não estou enganado, podemos associar até 4 cores pra cada um, dentre 12 cores de uma paleta, num total de 4 paletas que posso escolher. Em outra aba podemos ver as 12 cores da paleta de background e outras 12 cores da paleta pros sprites. Se você já brincou de front-end, HTML e CSS certamente já viu código de cores em hexadecimal, é a mesma coisa.

Como a localização dessa área CHR na ROM é conhecida, podemos editar o que tem lá. Os tiles são bitmaps não comprimidos. Hoje em dia você tá acostumado a lidar com imagens comprimidas como JPEG que usa um algoritmo lossy, ou seja, que perde detalhes da imagem pra reduzir o tamanho. Um bitmap é exatamente o que o nome diz, um mapa de bits, nas posições exatas pra formar a imagem e sem compressão.

Só pra mostrar como podemos afetar o jogo, com o Mesen rodando podemos editar as cores da paleta de background e trocar a cor do céu de azul pra outra cor. Ou podemos mexer na paleta de sprites e trocar a cor do Mario. Você pode mudar completamente a aparência do jogo só de ajustar as cores dessa forma.

Repetindo, pense na tabela de tiles como se fosse uma tabela de fontes de letras. Aliás, o nintendinho sequer tem fontes. Ele não tem um sistema operacional, o jogo começa rodando direto no hardware, sem nenhuma camada intermediária pra ajudar. Então se um jogo quer escrever textos na tela, ele próprio precisa embutir tiles de fontes. E de fato você vai ver que normalmente começando no endereço zero dessa área CHR costuma ter letras, números e símbolos. Aqui o número zero é a posição zero mesmo, o número um é posição um e assim por diante. E começando do zero até a letra F fica bonitinho de 0 a F em hexadecimal.

Lembra quando usamos no Linux a ferramenta hexdump ou xxd e na terceira coluna ele tenta interpretar bytes que mapeiam pra tabela ASCII como letras e às vezes aparecem textos mesmo? Numa ROM de videogame isso não funciona porque os códigos das letras não seguem a tabela ASCII. Mesmo entre jogos diferentes a posição das letras na ROM não é a mesma. Por isso em emuladores com debug como o Mesen e FCEUX podemos carregar nossa própria tabela que mapeia código das posições dos tiles pra letras, como essa na tela que é um arquivo texto com extensão TBL. Assim podemos tentar reconhecer algum texto no meio do binário.

Vejam no espaço PRG da ROM que não dá pra identificar nada. Mas carregando a tabela começamos a reconhecer quais bytes são textos. E com isso posso editar o texto, por exemplo trocando de MARIO pra FABIO. Resetamos o jogo e olha só como aparece meu nome. Podemos trocar todos os textos num cartucho e salvar o binário por cima, contanto que o texto novo caiba no mesmo espaço usado pelo texto antigo. Esse é o hacking mais simples de todos e que todo mundo que já brincou com binários já fez na vida. É assim que muita gente traduziu cartuchos japoneses pra inglês, por exemplo. Se tiver filhos pequenos imagino que eles vão gostar de ver os nomes deles nos jogos.

E podemos editar o binário não só do texto como dos tiles. Por exemplo, existem programas como o Tile Layer Pro. Se abrirmos a ROM do Super Mario, no começo vamos ver um monte de sujeira que são bytes de programa, mas se descermos vamos encontrar os tiles do jogo. Pra enxergar melhor podemos mudar a paleta e rapidamente vamos começar a reconhecer alguns, como os tiles que formam o personagem. Pra ver melhor, podemos arrastar os tiles pra esta outra janela e montar como um quebra cabeça. O Mario grande é formado por seis tiles. Na ROM tem a sequência pra cada posição da animação, seja correndo ou pulando.

Podemos fazer mais, podemos editar cada tile e mudar o jogo completamente. É um puta trampo editar tile a tile mas se tiver paciência fazendo isso eu poderia pegar os bits de tiles de um Zelda ou Megaman e mudar o Mario pra ser o Link, ou qualquer outro personagem que caiba em seis tiles ou menos. E só com as técnicas eu mostrei aqui você poderia fazer um novo jogo usando um que já existe como base.

Sabe quem já fez isso? A Tectoy aqui no Brasil. Por causa deles nós somos o único país no mundo que ainda produz Master System novo até hoje. O Master System foi o concorrente do nintendinho nos anos 80. Também é um console de 8 bits mas no papel ele era tecnicamente superior. Em vez do MOS 6502 de 1.8 Mhz o Master System vinha com o Zilog Z80 que ia até 3.5 Mhz, quase o dobro de clock. Em vez de 2k de RAM e 2k de VRAM ele vinha com 8k de RAM e 16k de VRAM. Em vez de ser limitado a ter só 16 cores na tela, ele podia ter 32 cores, por isso jogos de Master System sempre parecem mais coloridos e vivos

Essa discussão de especificações e jogos sempre foi uma constante nas rodas de gamers. Um Xbox One X é tecnicamente mais poderoso que um PS4 Pro, mas o Playstation continua tendo alguns dos melhores jogos exclusivos como God of War ou Spiderman. Nos anos 80 não era diferente. O Master System era mais poderoso mas as marcas que chamavam mais atenção estavam no Nintendinho.

De qualquer forma o Master System conseguiu um público cativo aqui no Brasil e a Tectoy começou não só a licenciar e distribuir jogos estrangeiros como começou a lançar jogos brasileiros. Um grande exemplo que eu lembro que me impressionou na época foi o jogo da Turma da Mônica.

Esse jogo na realidade é o Wonder Boy II com textos e sprites editados pra encaixar numa história da Turma da Mônica. Se nunca viram olhem lado a lado.

A Tectoy produziu vários jogos usando essas técnicas como Geraldinho, Sapo Xulé, TV Colosso. Mas fazendo isso eles foram aprendendo como de fato programar no Master System e começaram a produzir jogos mais elaborados. Por exemplo, um dos melhores jogos de Master System sem dúvida é Castle of Illusion. Daí a Tectoy pegou emprestado elementos desse jogo e fez um terceiro jogo na sequência do também excelente Land of Illusion, com fases novas e inimigos novos e chamou de Legend of Illusion. É bem claro onde são sprites dos jogos anteriores e quais são sprites desenhados do zero. A parte artística ainda tava bem primitiva, mas já é uma evolução.

Mas quando você treina e vai aprimorando as coisas melhoram. Por exemplo, eles começaram a experimentar com a idéia de pegar jogos de Mega Drive, que é um console bem mais poderoso que o Master System, pegar os sprites e elementos visuais e diminuir detalhes, diminuir cores, diminuir frames de animação pra tentar fazer caber no Master System. E fazendo isso eles de fato conseguiram alguns jogos interessantes. Mesmo a jogabilidade não sendo nada boa, eu acho interessante pela tentativa. Só no Brasil existem jogos como Street Fighter, Mortal Kombat, Ecco the Dolphin e A Pequena Sereia pra Master System.

Tem vários videos no YouTube contando a história da Tectoy. Tem até vários canais gringos descobrindo a Tectoy só agora e ficando impressionado de ver o Master System e Mega Drive sendo fabricados por aqui até hoje, recomendo darem uma olhada, é uma parte da história da nossa indústria brasileira que infelizmente ficou parado nos anos 90 e não conseguiu evoluir. Aliás, recentemente lançaram um remake HD do Wonderboy II que ficou bem bacana e tá em lojas como Steam. E claro, alguém fez um mod pra ele relembrando o jogo da Turma da Mônica. Então você tem uma versão HD disso também! Vale conferir só pela nostalgia se você jogou o original no começo dos anos 90.

Bom, vamos voltar pro nintendinho. O que eu mostrei do código do emulador é só o começo do esqueleto. Na verdade eu não escrevi um emulador não, esse foi um projeto que achei aleatoriamente no Github. Vocês podem baixar a versão completa no link que vou deixar nas descrições abaixo. E pra mostrar que ele funciona vamos compilar e executar.

(nes)

Um último insight que eu queria aproveitar pra falar é sobre o PPU. Como expliquei ele era o equivalente aos nossos GPUs de hoje só que muito mais primitivo. Se havia um chip que trabalha incessantemente no nintendinho era o PPU, desenhando 60 quadros por segundo sem parar. Na verdade são dois insights. Vamos lá. Pra começar eu disse que o MOS 6502 roda a meros 1.8 Mhz que é milhares de vezes mais lento que qualquer CPU de hoje.

Antigamente jogos tentavam usar o máximo que a CPU podia oferecer e o timing de tudo era atrelado ao clock do sistema. Hoje em dia não fazemos isso, em vez de atrelar ao clock atrelamos a outras coisas como framerate que é a taxa de quadros por segundo ou vsync que sincroniza com a frequência de atualização do monitor. Ou seja, se temos como alvo rodar o jogo a 60 quadros por segundo, vamos calcular tudo pra caber na faixa de 60 quadros por segundo. Mesmo se o clock aumentar ou diminuir, a referência vai ser os quadros por segundo. Se a CPU for lenta demais vamos ser obrigados a cortar quadros. Se a CPU for rápida demais vamos dar pausas pra esperar. Estou simplificando, claro.

Mas jogos antigos não tinham o luxo de esperar, cada clock contava. Por isso se programava em assembly pra ter controle absoluto do hardware. Daí quando os CPUs evoluiram na geração seguinte e pularam de 1Mhz pra digamos 40Mhz os jogos ficaram rápidos demais. Até por isso nos 386 de antigamente tinha um botão Turbo. A idéia desse botão era diminuir o clock do sistema pros programas não rodarem rápidos demais. Se você tentar rodar um jogo dos anos 80 num PC moderno vai ver que ele roda rápido demais ao ponto de ser injogável.

Um dos desafios mais difíceis nos emuladores de consoles antigos é literalmente adicionar pausas em cada passo pro jogo rodar exatamente como seria antigamente, se não tiver esse controle de pausas o jogo rodaria rápido demais. E nosso emulador precisa levar isso em conta. Por isso temos que editar o arquivo do CPU e adicionar outra informação importante: uma lista dizendo quantos ciclos cada instrução consome. Lembra que falei que um Load, Adição e Store consomem em média uns 5 ciclos? Não pode ser aproximado assim, tem que ser a quantidade exata de ciclos. Então vamos adicionar a lista, onde cada posição é o endereço da instrução como declaramos na estrutura table.

O segundo insight que falei tem a ver com timing de velocidade. O PPU é ocupado demais, ele não pode parar de desenhar na tela. Ele roda com clock 3 vezes mais rápido que a CPU e precisa de uma rotina pra sincronizar. A coordenação entre CPU e PPU é um assunto fascinante em si só mas a parte importante é que a CPU não pode interromper a PPU a qualquer momento. Ela vai estar escrevendo pixels na tela numa frequência precisa e se você interromper, vai quebrar toda a renderização.

Significa que do lado da CPU digamos que você detecte que um botão foi pressionado no controle. Digamos que foi um botão de salto. Você iria querer imediatamente mostrar isso na tela acionando a animação de salto do Mario por exemplo. Então você processa esse estado e envia o comando pro PPU atualizar o sprite do Mario. Mas isso vai quebrar a renderização, então como faz?

A característica importante do PPU é que ele escreve na tela uma linha horizontal de cada vez. Isso se chama ScanLine e é derivado de como monitores de tubo funcionam. Se você nunca viu ele não escreve pixels em qualquer coordenada. No fundo do tubo existe um canhão, que vai atirando eléctrons na tela de fósforo na frente dele uma linha horizontal de cada vez e fazendo um zigue zague pra próxima linha. Diferente de LCDs modernos que tem uma quantidade fixa de linhas, monitores de tubo podem ter quantas linhas quiser, basta o canhão distanciar ou aproximar essas linhas. Por isso bons monitores de tubo tendem a ter imagens melhores do que LCDs. Recomendo ver esse video da Digital Foundry que explica sobre a qualidade esquecida dos CRTs e como eles ainda superam os LCDs.

De qualquer forma, o PPU do nintendinho vai desenhar 240 linhas visíveis e depois vai entrar num período entre as linhas 240 a 260 em que ele não desenha nenhuma linha visível. Isso se chama Vertical Blank ou Vblank. Isso acontece 60 vezes por segundo, uma vez depois de desenhar cada frame. É nessa pequena janela de 20 ScanLines que o PPU tem a oportunidade de ser interrompido e receber ordens da CPU, por exemplo, dizendo o que tem que desenhar no frame seguinte.

De novo, se você é de front-end, uma das boas práticas que deve ter aprendido, principalmente se usa frameworks como um React é nunca escrever direto no navegador. Você acumula todas as modificações e escreve tudo de uma vez depois. E como você faz isso? Em vez de mandar ordens de desenhar direto na árvore de elementos HTML do navegador, o famoso DOM, você manda escrever numa cópia desse DOM que só existe em memória, o famoso Virtual DOM. Então se você modificou 50 elementos nesse VDOM, você não precisou interromper o navegador 50 vezes. Você guarda essas modificações em memória e só interrompe o navegador uma vez pra desenhar só o que mudou, uma vez só.

E é quase isso que se faz no nintendinho também. A idéia de separar lógica da apresentação não é novidade. É assim que se programa desde pelo menos os anos 80. Então do lado da lógica do jogo na CPU ele faz as modificações em RAM e durante o Vblank o PPU puxa essas modificações e avança pro próximo frame, e com isso temos uma separação de responsabilidades.

Como cada jogo monta estruturas diferentes pra representar o que precisa mandar pra PPU. Mas um jogo que é visualmente fácil de acompanhar é o Super Mario Bros 3 porque ele mantém a estrutura completa da tela com cada elemento aberto na RAM. Se você procurar por memory map e o nome do jogo no Google facilmente vai achar a documentação que várias pessoas gastaram horas garimpando e com isso sabemos que a partir do endereço 0x6000 na RAM vai ter os dados de montagem de cada tela da fase.

Vamos abrir no Mesen e vou colocar lado a lado pra vocês verem. Se procurarmos na RAM depois do endereço 0x6000 rapidamente vamos encontrar padrões que se assemelham à tela que estamos, e na sequência vai tendo todas as outras telas dessa fase. Olhem os códigos internos de cada bloco dessa tela e veja como o código muda quando eu modifico um objeto, por exemplo batendo nele.

E se você é adepto de Mario Maker, esse é o Mario Maker raíz. Vamos olhar algumas telas pra frente. Por tentativa e erro sabemos que essas “arrobas” representam moedas. Vamos criar um monte …. e agora vamos até essa tela. … Olha que bonito. E de novo vejam como cada vez que vou pegando as moedas o código se modifica na RAM.

De novo usando a analogia com front-end, isso é o equivalente a você dar um inspect no navegador e sair editando os elementos. E aproveitando que estamos no Mesen, vamos abrir primeiro o Super Mario de novo. E esses são todos os tiles que tem no cartucho, somente um único bank de 16 kbytes. Pense que o jogo inteiro, que não é curto, é desenhado somente com esses tiles. É impressionante se considerar que antes dele você só tinha jogos nível pacman bem simples e eles conseguiram esticar pra múltiplas fases que parecem diferente mas que são basicamente os mesmos tiles com paletas diferentes de cores.

Mas se abrirmos o Super Mario 3 de novo, que vem com o Mapper conhecido como MMC5, ele vai ter bem mais banks como eu expliquei. E olha só no visualizador de novo. Podemos ir explorando os diferentes banks que são os conjuntos de tiles. E por isso o Super Mario 3 tem visuais bem mais elaborados e diferenciados de mundo pra mundo. Não é só uma mudança de paleta de cores mas de diversidade de tiles. E no último olha como só a tela de entrada com título grande ocupa um bank quase inteiro. Por isso quando tem imagens bitmap grande que ocupam a tela inteira a gente sabe que é um jogo caro porque literalmente ele tá usando uma parte considerável do chip só pra guardar essa uma imagem que só aparece uma vez.

Recentemente teve uma ressurgência de games independentes publicando nos Steam da vida que tentam emular o visual pixel art pra ter aquela vibe de jogo retro. Um bom exemplo disso é o excelente jogo Celeste, considerado um dos melhores jogos de plataforma pra speedrun pela nuance nos controles e como ela recompensa quem consegue combinar timing com movimentos avançados do jogo pra percorrer as fases. Outros exemplos são os já classicos Meat Boy ou Shovel Knight também. Mas o que esses jogos tem em comum é que eles são modernos mas só escolheram um estilo artístico de pixel art pela estética e não porque foram obrigados a isso.

Entendam, jogos antigos não são pixel art porque o povo gostava do estilo mas sim porque a resolução da tela era de meros 256 pixels na horizontal por 240 pixels na vertical. Isso é um quarto da resolução de um monitor full HD que tem 1080 pixels na vertical. Cabe literalmente 16 telas de nintendinho numa tela full HD. Mas agora você entende também que não é só a resolução, todo o design do jogo, das fases, inimigos e outros elementos dependem muito do espaço na ROM. Quanto mais ROM se adicionava no cartucho mais caro ele ficava. Por isso a maioria dos jogos se mantinha nos limites de 40 kilobytes que o Super Mario original usava. Em comparação, a instalação do jogo Celeste tem mais de 700 megabytes.

Existem vários programadores hoje explorando programar no hardware limitado do nintendinho. Um grande exemplo é o jogo Micro Mages da Morphcat Games. Dois anos atrás eles soltaram um mini documentário mostrando como as limitações do console e do cartucho influenciaram as decisões de design do jogo. Eles se colocaram no desafio de fazer um jogo de verdade, bem feito, escrevendo em Assembly de 6502 e ainda suportando 4 jogadores simultâneos.

O jogo é excepcional, eu paguei pra ter a ROM e recomendo que comprem também, são 10 dólares bem gastos. A mecânica é muito simples, lembra um pouco a idéia do Celeste. É um jogo vertical onde a tela vai subindo lentamente e você precisa alcançar o fim da fase antes que a tela te alcance. E falando em fases, vale um parêntese pra explicar mais uma estrutura de dados que o nintendinho usava, os nametables. Em resumo hiper resumido, é um espaço na memória do PPU que organiza o equivalente a 4 telas, duas em cada linha.

Se você está num Mario que é plataforma horizontal, ele vai mantendo a próxima tela no espaço à direita. Olha como a memória vai atualizando conforme vamos avançando pelas telas.

Se for plataforma vertical como Kid Icarus ele mantém a próxima tela no espaço pra cima e você pode trabalhar os modos desse namespace se precisar de algo mais complexo como num Mario 3 que é horizontal mas quando você pega a folha pode voar vertical.

No caso do Micro Mages ele vai usar um modo semelhante ao do Kid Icarus. Jogando um pouco, veja lado a lado como o próximo nivel vai se montando nesse espaço de memória de nametables.

No video da Morphcat ele começa explicando o que eu já falei, que gráficos são divididos em duas tabelas CHR. Ele chama tiles de sprites mas é a mesma coisa, eu chamo sprites os tiles que estão na tela neste momento. Ele continua repetindo que cada tile é um quadrado de 8 por 8 pixels e que pode escolher até 3 cores da paleta. E que juntamos tiles pra formar o que ele chama de meta-sprites que é o objeto completo. Continuando, ele explica que só dá pra ter até 4 paletas de cores e que as cores são reusadas pra outros objetos como inimigos porque não dá pra ter cores diferentes pra cada coisa, é tudo as mesmas paletas.

Outra limitação do PPU que eu não mencionei ainda é que ele só consegue desenhar 8 sprites por scanline. Como cada personagem é formado por duas linhas de dois tiles cada, nesse exemplo vai ter 10 tiles por linha em vez do máximo de 8. Se tiver mais que 8 os sprites seguintes simplesmente não são desenhados. Por isso um truque muito usado é escolher 8 tiles dos 10 e desenhar num frame, daí no próximo frame você esconde 2 que foram desenhados no anterior e troca por 2 que ainda não tinham sido desenhados, e vai permutando de frame a frame. Por isso muitos jogos de nintendinho parece que os personagens ficam piscando na tela. Isso acontece quando eles se movimentam e na mesma linha acaba ficando mais de 8 sprites.

Por causa dessas limitações, a primeira decisão da Morphcat foi criar personagens que precisam só de um tile pra formar o sprite em vez de 4 ou mais. Além de economizar em espaço, isso também evita o flicker, aquelas piscadas, porque vai ser mais difícil ter mais de 8 sprites por scanline. Falando só em espaço, de volta à tabela de tiles CHR na ROM, esse é o espaço ocupado por todos os tiles que formam as animações do Mario, que nós já vimos antes. E agora o espaço ocupado por todas as animações dos magos nesse novo jogo. Veja como economiza espaço escolhendo fazer personagens menores que cabem num único tile. E não só isso, também conseguimos adicionar mais quadros na animação, tornando a movimentação mais fluida.

Outro desafio são os chefões, que costumam ser sprites grandões. Por exemplo, esses são todos os frames de animação de um dos chefões. O problema é que se você tentar encaixar todas essas imagens no que restou do espaço CHR, simplesmente não vai caber. E isso é só um chefão. Agora vem a parte onde a programação e o design precisam andar juntos, porque o designer tem que fazer um chefão cujos quadros podem ser divididos em partes, no caso três, que podem ser animados independentemente.

Olhando só os quadros que fazem a animação da cabeça, dividimos em tiles, e vemos se tem repetições. E de cara você pode ver que a primeira metade em todos os três quadros é igual, então só precisa armazenar uma versão, que pode ser reusada em todos.

Não só isso, se um tile é o espelho de outro tile, você guarda só uma versão e pede pro nintendinho inverter horizontalmente, e assim pode economizar mais um pouco. E fazendo isso, só na cabeça otimizamos de 16 tiles pra 4 que realmente precisam existir na ROM.

Pra parte do meio, fazemos a mesma coisa: procuramos todos os tiles repetidos, todos que podem ser invertidos e diminuímos mais ainda.

E a última parte tem 5 animações mas de cara as duas últimas são inversões das duas primeiras. E fazendo todas as mesmas reduções, removendo tudo que é repetido, compare os tiles que sobraram com os que originalmente eram necessários sem otimizar.

O video deles continua mostrando como aplicaram outras técnicas pra reduzir ainda mais a quantidade de memória necessária pra montar as fases. Mas eu vou pular pra não ficar extenso demais, por isso recomendo que assistam e também comprem o jogo.

Falando em programar seus próprios jogos, como você faz isso? Simples, se pesquisar no Wiki da Nesdev vai encontrar sobre ferramentas, tem vários fóruns ainda ativos onde o povo troca dicas e informações sobre as melhores técnicas e ferramentas, mas o mais básico é o cc65 que vem com o montador ca65 e o disassembler da65. E se procurar num Github vai encontrar vários exemplos, de hello world a joguinhos completos feitos do zero como o Micro Mages. Se você já pensou em programar games e não quer ser só mais um mero clonador de Flappy Bird, programar em hardware restrito como um nintendinho é um excelente exercício pra aprender todos os fundamentos de um bom design de games.

Por exemplo, baixei este projetinho que faz todo o setup do ambiente, carrega o mínimo de tiles e tudo mais pra ter fontes e com isso consigo fazer um hello world da vida rapidamente em C. E sim, é possível programar em C e compilar com o cc65 pra binário de 6502 específico de nintendo. A desvantagem de programar em C é que ele vai gerar um binário menos otimizado do que um bom programador faria na unha direto em assembly. Por outro lado, como estamos em ambiente emulado você sempre pode mexer no emulador pra ter uma CPU mais rápido do que o nintendinho original e quantos banks de ROM quiser.

Aliás, sobre o hello world, considere o seguinte: o nintendinho não tem um sistema operacional, sequer vem com fontes numa ROM, o jogo tem que fazer tudo, então pra fazer um hello world, você precisa primeiro armazenar suas próprias fontes no espaço CHR da ROM. Só depois pode escrever alguma coisa.

Falando nisso vale a pena mostrar como subir um pouquinho o nível da linguagem pra não ficar tão tedioso fazer só assembly puro. Não é um compilador ainda, tá longe disso, mas muitos assemblers tem capacidade pra macros. Pra quem não sabe, macro é como um template. Um procesador de Markdown é tipo um macro de HTML. Quando eu digito asterisco o processador vai pegar o texto seguinte e colocar entre as tags de bold por exemplo. Macro é uma forma de reduzir copy e paste de trechos de código.

O ca65 que é o assembler mais recomendado pra programar pro nintendinho já vem com vários macros que adicionam algumas construções mais modernas como ifs, whiles e outras coisas, assim você consegue ter mais dicas visuais do que cada trecho faz em vez de ver só um linguição de instruções. Some isso a subrotinas com JSR que mostrei no video anterior e é possível programar sem ficar completamente doido no processo. Mas pense assim: é assim que se programava games de verdade. O grande lance de programar em consoles é tirar o máximo que o hardware consegue oferecer.

Outra coisa interessante. Hoje em dia não existe mais o código fonte da maioria esmagadora dos games. Muitas empresas da época até faliram e muito material se perdeu. Mas isso não tem problema. Você sempre consegue reabrir o código a partir do binário. Pra isso serve a ferramenta da65 que vem no mesmo pacote. Você pode fazer o desassembly e voltar aos mnemônicos. Obviamente não vai ter o nome correto das subrotinas, labels, constantes e variáveis. Mas se você tiver experiência com o hardware vai saber por exemplo que se tiver alguma coisa mexendo com o endereço a partir de 0x8000 está acessando a ROM, se mexer com o endereço 0x4016 ou 0x4017 está falando com os controles.

Daí você pode fazer a engenharia reversa que é adicionando as etiquetas e nomes das coisas mais óbvias primeiro e fazer o caminho inverso. Ah, se esse trecho mexe com o endereço 0x4016 deve ser o trecho que decide o que fazer quando aperta um botão. Além disso você pode fazer tracing, visualizar o que acontece em cada registrador e na memória a cada instrução pra determinar do que se trata cada subrotina. É super trabalhoso mas fazendo isso você consegue encontrar praticamente tudo. Diversos jogos já foram mapeados assim.

E de fato, se procurar no Github você vai achar um disassembly do Super Mario praticamente completo com todos os nomes de subrotinas, etiquetas e constantes. É o mais próximo que se chegou do código fonte original. E em cima disso você pode modificar o jogo como quiser no nível do código em vez de se limitar a só modificar os bytes no nível da ROM como fizemos com textos e tiles. Podemos adicionar tiles novos ou fazer textos mais longos e reprogramar a lógica porque o assembler vai conseguir recalcular todos os endereços corretamente e gerar um novo binário que funciona.

Finalmente, vou completar a maior tangente que fiz até hoje. Vocês vão se lembrar que o episódio anterior começou só porque eu vi um video falando sobre o Game Genie. Como expliquei antes, Game Genie é um hardware que fica entre o cartucho e o console. E agora sabemos que o cartucho responde a uma faixa de endereços bem específico entre $8000 e $FFFF. Também sabemos que endereços que a CPU pede não correspondem à localização exata nos cartuchos por causa do sistema de mappers e bank switching.

Existem duas formas de adicionar cheats, ou trapaças nos jogos. Uma delas é alterando o valor carregado na memória RAM e a outra é alterando direto o binário na ROM. Com bastante paciência você consegue visualizar o conteúdo da RAM usando emuladores como o FCEUX e o Mesen, gravar dumps da memória entre uma parte do jogo e outro e comparar os bits pra ver o que mudou. Por exemplo, gravar a RAM antes de morrer e depois de morrer pra ver qual byte diminuiu e ele é um candidato pra ser o local na memória que representa quantas vidas você tem, daí você pode testar esse valor.

Com tantas décadas de gente escovando bits, existem bancos de dados inteiros com diversos cheats pra cada jogo. Você facilmente consegue encontrar código pra tudo. Num emulador como o RetroArch tem até funcionalidades pra sincronizar com esses bancos de dados daí você nem precisa digitar os códigos manualmente. Só escolher o jogo, selecionar em cheats, carregar e já era.

Resumindo o video do canal Retro Game Mechanics Explained o que o hardware do Game Genie faz é receber um endereço de 16-bits e um ou dois valores de 8 bits cada. Isso forma códigos de 6 ou de 8 letras. Quando o código tem 6 letras é fácil porque os primeiros 4 dígitos representam o endereço na RAM e os dois últimos digitos representam o valor que o Game Genie vai devolver e pronto. Quando estamos falando de jogos usando o Mapper mais simples, como num Super Mario original que só suporta ROMs com 40 kilobytes, isso é tudo que precisamos.

Agora que você entende bank switching, sabe que no mesmo endereço da RAM pode estar apontando dados em banks diferentes da ROM. Depende de qual bank tá apontando no momento. Então o Game Genie não pode responder com um valor fixo toda hora, só quando um determinado bank tá selecionado. Pra isso serve o código de 8 digitos. De novo, os primeiros 4 formam o endereço na RAM. Agora os dois dígitos seguintes representam qual é o valor que esperamos encontrar na RAM, ou seja, o valor que ele carregou do bank. Se for diferente do que passamos é porque o console tá olhando um bank diferente do que queremos. Mas quando o valor voltar igual, é porque ele mudou pro bank que queremos, e aí devolvemos o valor fixo que tá no ultimos dois dígitos do código.

A forma como o Game Genie monta os códigos é só um embaralhamento arbitrário que ele faz sei lá porque, talvez só pra deixar o código um pouco mais legível. É só uma obfuscação simples. Pra isso primeiro você pega os bits do endereço e dos dois valores, daí embaralha os bits pra outras posições, e no fim substitui cada bloco de 4 bits por uma letra de acordo com uma tabela arbitrária. Pra cada console tem uma regra de embaralhamento e tabela de mapeamento de letras diferentes.

Eu fiz um programinha bem besta na linguagem Crystal que pega o código do Game Genie, traduz de volta em bits, desembaralha os bits e devolve o endereço e os valores. Eu fiz em Crystal só porque eu quis, nenhuma razão especial, podia ser em qualquer linguagem. Vou deixar o link pra esse código nas descrições abaixo. Talvez eu termine de fazer o desembaralhamento das versões de game genie pros outros videogames mas eu queria um executável simples pro meu teste.

Eu fiz algumas coisas do jeito menos otimizado, estilo “o que funciona primeiro”, então não xinguem. Pelo menos tem testes unitários direitinho. Veja esse por exemplo, eu garanto que eu passo um código de Game Genie e ele vai gerar o binário que eu quero. Daí no outro spec eu garanto que dado esse linguição de bits vai gerar a representação em hexadecimal direitinho também.

O código em si é muito simples. Ele começa pegando o código de 6 ou 8 letras do game genie, processa letra a letra e troca pela representação binária. Eu não estou lidando com o número binário e sim com a representação em texto mesmo pra ficar mais fácil. Depois de montar esse binário, o próximo passo é desembaralhar, e isso é arbitrário do game genie, só trocar bits de posição. Finalmente, com os bits rearranjados, faço um outro loop besta pegando de 4 em 4 bits e transformando em hexadecimal.

Vocês vão notar que eu fiz de um jeito meio tosquinho aqui criando um array pra mapear cada conjunto de bits no hexadecimal em vez de converter a string num número e depois usar um formatador pra hexa, mas foi mais porque eu não achei fácil o jeito de fazer isso em Crystal ainda. Quando descobrir eu mudo. Mas pros meus propósitos esse código tá suficiente. Com isso eu posso compilar um binário e … pronto, posso chamar o binário, passar o código de game genie e ele devolve o hexadecimal certo.

O próximo passo foi mexer no emulador feito em Go. A grande maioria dos emuladores mais maduros e populares tem suporte a códigos de game genie. Mas esse emulador mais simples não tinha, por isso achei que seria um exercício interessante. Pra começar eu resolvi modificar o arquivo do console adicionando uma estrutura chamada Cheat que vai ter só dois elementos, o valor de condição pra comparar com o que tá no bank da ROM selecionado nesse instante, e o valor trapaceado que eu quero devolver. Daí eu adiciono na estrutura do console uma nova estrutura, um Map de Cheats. Map é o que algumas linguagens chamam de dicionário ou de hash. É uma lista que vai mapear um número inteiro, que no caso, é o endereço com uma instância da estrutura de Cheat.

Agora precisamos ler os cheats de algum lugar. No caso escolhi ler de um arquivo. Eu não estou mostrando, mas estou seguindo o padrão que esse emulador já fazia pra fazer saves dos jogos, criando um hash md5 do binário. O nome do arquivo que eu vou buscar é o hash md5 do Super Mario numa pasta .nes/cheats. Essa função readCheats recebe o caminho pra esse arquivo e só vai lendo linha a linha e gravando numa lista. Assim podemos ter múltiplos arquivos pra com códigos específicos de cada jogo que queremos.

A função seguinte vai interpretar essa lista. A função LoadCheats vai usar a readCheats acima passando o caminho do arquivo e recebendo a lista que ele ler. Daí eu passo um caminho fixo mesmo por enquanto, pro executável daquele programinha que eu fiz em Crystal. Ele vai passar os códigos pra esse programinha pra decodificar o endereço e valores.

Com o que ele devolver, checo se é um código de 6 ou 8 digitos, e isso serve pra preencher ou não aquele campo de condição na estrutura de Cheat. Feito isso associamos o endereço devolvido com a estrutura de Cheat e jogamos no dicionário na estrutura do Console. Com isso o console tá ciente dos códigos.

Pra de fato aplicar o cheat o lugar mais óbvio pra procurar é a estrutura de Memory, lembram dele? É nesse arquivo que tem a lógica pra escolher qual mapper o cartucho carregado precisa. Mas ele abstrai os mappers e a gente não precisa se preocupar. Os Mappers vão se encarregar de ler da ROM nos banks corretos. Então o que vamos fazer é, em vez de devolver o valor lido, vamos gravar temporariamente numa variável e passar pra uma nova função chamada replaceWithCheat.

Essa função recebe o endereço consultado e o valor devolvido. Agora acessamos o dicionário de Cheats que tá na instância do Console e procuramos por esse endereço. Se não achar nada, devolve o valor real original. Caso encontre ele checa se precisa comparar com a condição do Cheat.

Se não tiver condição ou se a condição bate com o valor real, então ele devolve o valor falsificado. E pronto, é só isso que precisa pra implementar um game genie num emulador. Com isso o console vai receber o valor falsificado em vez do valor real e nosso Super Mario vai começar com mais vida. Podemos testar isso.

Veja o arquivo de cheats com o código. Agora executamos o emulador passando a ROM do jogo, esperamos carregar e olha só, 9 vidas!!

Mas digamos que a gente é ruim em Super Mario e o tempo sempre acaba, quero que comece com 900 segundos em vez de só 400 e se procurar no Google descubro que o código pra isso é VGYOKK, então vamos editar o arquivo de trapaças e adicionar o código. Reiniciamos o emulador e … veja só que bacana, 9 vidas e 900 segundos pra terminar a fase.

Mas digamos que a gente é tão ruim, mas tão ruim que morre toda hora. Malditos Goombas! Mas não se preocupem, existe um código pra isso. Vamos editar de novo o arquivo e adicionar SSASSA. Agora vamos reiniciar o emulador e corremos de cara pra um Goomba. E olha só, invencibilidade!!

Vocês vão notar no terminal que toda vez que eu encosto num inimigo o programa busca o endereço 0xD88D pra checar se é pra perder vida ou não, daí se devolver 0xD5 ele sabe que é invencível. E é assim que trapaceamos pra chegar até o final fácil! E com isso finalmente consegui fechar o assunto que comecei no video anterior, fazer meu próprio Game Genie de Nintendinho. Com tudo que expliquei desde o vídeo anterior agora vocês entendem exatamente como tudo funciona.

E pra finalizar o episódio de hoje quero mostrar como vocês vão ter uma noção melhor pra entender videos de outros canais também. No próprio canal do Retro Game Mechanics Explained, alguns dos videos mais divertidos é a explicação de diversos bugs que esses jogos tem, e como podemos tirar vantagem disso. Uma das categorias de gamers mais escovadores de bits são os speedrunners. São jogadores que competem pra bater o recorde de quem acaba o jogo no menor tempo. Tem várias sub-categorias. Uma das mais divertidas é quando eles encontram bugs que permitem, por exemplo, saltar todas as fases e ir direto pro final.

Antes de falar desse bug preciso falar de uma última ferramenta que emuladores mais avançados como o FCEUX tem, se chama TAS ou Tool Assisted Speedrun. Lembram no nosso código em Go que eu associo controles na estrutura de console? Obviamente nós conseguimos ler o que vem do controle pra poder codificar o que cada botão apertado vai fazer no jogo. E naturalmente eu posso fazer o que quiser com esses dados, inclusive salvar num arquivo. Mais do que isso, como eu controlo a PPU também consigo saber exatamente em que frame cada botão foi apertado.

Então eu também consigo ler esse tal arquivo que diz em que frame foi apertado qual botão e com isso podemos dar replay no jogo inteiro repetindo exatamente tudo que que foi apertado com precisão de 1 frame. E é exatamente assim que esses jogos são arquivados em sites como o tasvideos.org, que mantém registros de todos os recordes. E você pode baixar o arquivo formato .fm2 ou .fm3 que contém exatamente essa sequência, rodar no seu emulador e assistir o speedrun exatamente como a outra pessoa jogou.

Então eu vou abrir o FCEUX, carregar a ROM do Super Mario 3, abrir o TAS Editor e carregar o arquivo .fm2 que baixei do site tasvideos.

Pronto, agora é só despausar e assistir. Vou pular as primeiras fases porque ele usa outros truques conhecidos pra ir pulando de warp zone em warp zone até chegar no mundo 7. Nesse ponto a maioria dos speedrunners ia pro Dark World normalmente, mas nessa corrida eles vão pelo Pipe World porque é de lá que dá pra acionar o bug. Assistam primeiro.

(glitch run)

Foda né, vocês não entenderam nada eu imagino, mas deu pra ver que eles fazem uma sequência bem absurda de coisas no Pipe World, daí começa tudo a descer pra um monte de sujeira de tiles e de repente ele chega na princesa direto. Agora que vocês tem uma idéia de como as coisas funcionam, dá pra entender que o bug aciona alguma coisa que faz a tela descer por um pedaço de RAM com bytes aleatórios que ele manda pro PPU que mapeia os tiles correspondentes, montando uma fase toda bagunçada e com comportamento incerto. E em algum momento dá um JUMP. O truque é simples, vamos usar a posição dos sprites na RAM pra montar um assembly em tempo real e dar um jeito de executar.

O código em si que precisa ser escrito é JSR 0x8FE3. Se conseguir fazer o jump esse é o endereço pra subrotina que inicia a sequência final da princesa. Então precisamos de 3 bytes consecutivos num lugar especial na RAM, os bytes sao 0x20 que é o JSR, e depois 0xE3 e 0x8F que é o endereço com os bytes invertidos por causa de little endian, que vocês já sabem como funciona.

A posição X dos inimigos, especialmente dos koopa troopers ficam sempre no mesmo lugar e não apagam mesmo quando o sprite some da tela. Por isso esses bytes são bons candidatos pra usar. Mas não adianta sair matando qualquer koopa. Precisamos que eles estejam na posição correta nessa lista e também que estejam numa posição X específica. Pra isso precisamos tentar fazer com que eles apareçam numa determinada ordem primeiro. A lógica é que novos sprites sempre vão aparecer primeiro na posição mais alta livre da lista primeiro. Então usamos essa informação pra fazer eles aparecerem numa ordem em particular.

Ao matar essa tartaruga e ir pro cano enquanto ela ainda está na tela, podemos forçar as plantas piranha pra aparecer nos slots 2 até 4 e o próximo koopa no slot 5.

Matamos as plantas pra elas não reaparecerem mais tarde quando voltarmos pra essa parte.

Agora o koopa entre os blocos de interrogação vai estar no slot 4 e o parakoopa no slot 3. Pegamos a casca dessa tartaruga e matamos jogando ele no bloco. Isso fixa o byte na posição fixa 0xE3 que precisamos.

Daí ficamos exatamente nessa posição em cima do cano e damos uma rabada no parakoopa quando ele estiver exatamente alinhado com o topo do outro cano pra garantir que a casca aterrisse na posição X hexadecimal 0x20, e com isso temos o byte que representa o jump. Agora vamos pra baixo, agarramos a casca desse koopa e voltamos ao comeco do nível.

Nesse ponto precisamos realizar o bug do cano apertando pra baixo no controle ao mesmo tempo que faz um clip na parede no canto desse cano. Às vezes o Mario consegue fazer um clip numa parede, tipo passar por ela, se estiver rápido o suficiente e bater bem na beira do grid de 16 pixels, é um movimento bem preciso e às vezes precisa fazer várias vezes pra acertar. Nessa sequência não tem tanto problema se de vez em quando pisar na casca pra tartaruga não acordar.

Uma vez entrando no cano inicia uma sequência de bugs porque não tava programado pra ter como ele entrar no cano nesse ponto, dai vai descendo por todo esse lixo aleatório que tá na memória. O PPU vai simplesmente mapeando o lixo que vai recebendo com os tiles na tabela CHR e mostrando na tela. Por isso fica essa bagunça visual.

No final tem que pular com muito cuidado com a casca e alinhar com o fundo bem nessa posição. Tem um detalhezinho que se notar que esse bloco de música estiver parcialmente cortado, talvez precise mover o Mario um pixel pra direita pra compensar a posição da camera. Deixamos o koopa reaparecer nas nossas mãos e desaparecer no fundo da tela, e essa posição onde ele desaparece nos dá o último byte que precisávamos, valor 0x8F. Finalmente caímos aqui e pulamos pra ativar a instrução. E se tudo foi configurado exatamente como mostrado aqui, vamos pular direto pra princesa e terminar o jogo.

Pra entender o que aconteceu vamos usar tudo que aprendemos até agora. Essa fase vertical é mapeada entre os endereços 0x6000 e 0x6EFF, que é suficiente pra 16 telas. Mas aquele cano que entramos depois de clipar pela parede manda o Mario pra tela 19 que obviamente não existe. Então acontece um transbordamento, um overflow da memória e começamos a acessar áreas da RAM que não era pra acessar.

E pra piorar, além de visualmente aparecer essa zona, a rotina de desenho falha e o que estamos vendo pode não estar de fato lá, por isso o Mario consegue subir numa plataforma invisível. A coincidência é que o final desse cano deixa o Mario do lado de um bloco de nota invisível e é batendo nesse bloco que ativa os bytes de Jump que configuramos.

Quando batemos num bloco de musica o tile é temporariamente removido e outra versão do sprite aparece pra fazer a animação. E claro, o índice nos dados da tabela de fase tá todo zoado quando procura por esse tile e ele pega o endereço 0x9C70 pra atualizar, que não é nem de longe perto da tabela de dados. Pior esse endereço simplesmente não existe na RAM.

Recapitulando o que já vimos sobre os endereços que nintendinho entende, temos a RAM entre 0x0000 e 0x1FFF e temos Work RAM entre os endereços 0x6000 e 0x7FFF e já sabemos que de 0x8000 até 0xFFFF é a região reservada pra ROM, ou seja, pro cartucho. Então aquele índice errado do bloco de musica tenta escrever na ROM. Mais do que isso, esse endereço na verdade fala com o Mapper do cartucho. E você sabe o que é um Mapper.

Por acaso quando tentamos escrever nesse endereço 0x9C70, é o mesmo que dizer pro Mapper fazer uma troca de banco, pra apontar pra outros bancos da ROM. Recapitulando, já sabemos que entre os endereços 0x8000 e 0xFFFF só cabe 32 kilobytes de dados, mas a ROM de programa do Super Mario 3 tem 256 kilobytes. Obviamente não cabe e por isso durante o jogo ele vai pedindo pro Mapper ir trocando os bancos pra apontar pra outras regiões da ROM.

Então esse trecho tá fazendo seu trabalho feliz e contente, achando que tá atualizando um tile na tela pro bloco de musica, mas em vez disso quando executa a instrução no endereço 0xDD1A, a ROM de 0xA000 a 0xDFFF é trocado pelo mapper do nada. Ele literalmente atira no próprio pé e as próximas instruções foram trocadas pelo que tá no novo banco que o Mapper trocou.

O apontador de pilha nesse momento da execução é 0xFD, que sabemos que quer dizer que a pilha tá quase vazia, lembra do video passado e do código de Reset da CPU que fizemos antes? Lembra que a instrução RTS vai retornar pro último endereço que estiver na pilha? E por acaso na pilha tem só um endereço nesse momento. E de fato essas instruções novas que vieram na troca do bank pelo Mapper, ele continua executando e uma hora bate num RTS fazendo ele pular pro endereço 0x8F4D.

Agora caímos no meio de uma nova rotina com uma pilha vazia, coisa que ele não esperava. Daí ele continua executando e uma hora vai bater num RTS, vai olhar pra pilha pra saber pra onde retornar. Mas a pilha tá vazia então quando isso acontece o ponteiro faz um wrap, ele circula como se a pilha estivesse totalmente cheia, lembra de quando falei de stack overflow no video anterior?

Lembrando que a pilha fica entre os endereços 0x0100 e 0x01FF, mas praticamente nunca a pilha enche totalmente então alguns programas acabam usando o topo da pilha pra outra coisa e no caso o jogo mantém informação da fase em 0x0100. Lá vai ter o valor 0xC0 se forem fases horizontais e 0x80 em fases verticais. E como o ponteiro circulou pro topo da pilha ele pega o valor que tá lá, subtrai 1 e retorna o endereço 0x0081.

Beleza, então o RTS vai pular pra 0x0081 e isso é endereço da RAM que tem um monte de dados voláteis sobre as propriedades da fase. Por exemplo em 0x007E a 0x0086 tem propriedades sobre os sprites carregados nesse momento, tipo o timer de quando as plantas piranha tem que aparecer dos canos, ou como os parakoopas voam. Dos endereços 0x0087 a 0x008F tem o high byte da posição Y de cada sprite, que é o número da tela onde eles estão.

Agora chegamos onde queríamos porque dos endereços 0x0090 a 0x0098 estão os low bytes da posição X de cada sprite na tela, que são as posições que viemos manipulando no começo e configuramos o JUMP. Os bytes antes disse são dados, mas o processador não sabe disso e tenta executar como se fossem instruções. Por coincidência nenhuma das tentativas de executar esses dados termina num crash e ele consegue chegar até nosso jump. Como esses dados anteriores podem ser qualquer coisa que representa os tais elementos na tela que falei, poderiam ser bytes que representam instruções que crasheiam, então essa sequência toda que fizemos não é garantido que funciona sempre, mas funciona vezes o suficiente.

Chegando no nosso JSR 0x8FE3 ele pula pra um programa que fica num bank que nunca é trocado pelo mapper então garantidamente sempre vai estar lá e é a rotina pra carregar o quarto da princesa.

Pra fechar, a sequência pra montar a instrução de jump pode ser feita de várias formas contanto que a posição X dos inimigos certos entre na sequência correta nos slots da memória. Esse é o recorde mundial usando esse bug do MitchFlowerPower onde ele termina o jogo em 3 minutos e 9 segundos. Ele mesmo jogou manualmente e gravou seus comandos.

E com tudo isso dito, finalmente chegamos ao final do episódio! Tudo que eu queria era explicar como o Game Genie funciona, mas pra realmente entender era necessário entender cada componente de como um computador funciona. Com isso eu espero que se você é iniciante tenha conseguido ter uma visão um pouco mais abrangente do que significa fazer um hardware funcionar.

Pra mim isso é programação. Programação nunca foi sobre seguir receitas e procedimentos prontos e sim encontrar um cenário de restrição e com conhecimento de verdade usar as ferramentas disponíveis pra conseguir soluções criativas. Nenhum livro, nenhum curso, nenhum tutorial jamais vai ensinar essas coisas. Só quando você encara problemas difíceis é que conhecimento de verdade começa a aparecer. Eu tenho certeza que vocês nunca imaginaram que tinha tanta coisa que podia ser dito sobre um videogame obsoleto dos anos 80.

Se você ficou empolgado pra escrever seu próprio emulador recomendo que acompanhem outro canal, o do One Lone Coder que está desenvolvendo um emulador de NES em C++ e explicando passo a passo no seu canal. Vou deixar o link nas descrições abaixo. O próprio canal do Retro Game Mechanics Explained na realidade tem videos detalhados explicando o funcionamento do Super Nintendo. Como funcionam os gráficos e cores, como funciona a memória, como funciona o lendário Mode 7. Tem bastante coisa pra aprender.

Se vocês pensam que eu acabei todos os assuntos, tão enganados. Descer nesse buraco de coelho me levou a rever um monte de coisas do passado em relação a emuladores e estou pensando em fazer um episódio mais leve do que esses pra explicar o ecossistema atual de emuladores. Pra variar eu vou descer mais no detalhe em alguns deles então aguardem pelo próximo. Como vários assuntos eu tive que resumir ou mesmo pular pra não ficar confuso demais, se você também é entusiata desses assuntos, não deixem de complementar nos comentários abaixo. Se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho. E principalmente ajudem o canal compartilhando os videos com seus amigos. A gente se vê na próxima, até mais!

Links:

• Super Mario Bros. 3 - Wrong Warp (https://www.youtube.com/watch?v=fxZuzos7Auk)

• A Comprehensive Super Mario Bros. Disassembly (https://gist.github.com/1wErt3r/4048722)

• Lembra deles? Confira jogos brasileiros do Master System lançados pela Tectoy! (https://blogtectoy.com.br/lembra-deles-todos-jogos-brasileiros-do-master-system-lancados-pela-tectoy/)

• Free NES assembler (https://bisqwit.iki.fi/source/nescom.html)

• Micro Mages (https://morphcatgames.itch.io/micromages)

• Nes Dev Wiki (https://wiki.nesdev.com/w/index.php/Nesdev_Wiki)

• Computer Archeology - The Legend of Zelda (https://www.computerarcheology.com/NES/Zelda/)

• 6502 Instruction Set (https://www.masswerk.at/6502/6502_instruction_set.html)

• An introduction to 6502 math: addiction, subtraction and more (http://retro64.altervista.org/blog/an-introduction-to-6502-math-addiction-subtraction-and-more/)

• Explain Half Adder and Full Adder with Truth Table (https://www.elprocus.com/half-adder-and-full-adder/)

• Build a multiplying machine using NAND logic gates (https://codegolf.stackexchange.com/questions/12261/build-a-multiplying-machine-using-nand-logic-gates)

• Tool Assisted Game Movies (http://tasvideos.org/)

• RETRO INSECTIVORES: FINDING AND ELIMINATING BUGS IN NES DEVELOPMENT (https://megacatstudios.com/blogs/press/retro-insectivores-finding-and-eliminating-bugs-in-nes-development)

• FCEUX (https://sourceforge.net/projects/fceultra/)

• Zelda Screen Transitions are Undefined Behaviour (https://gridbugs.org/zelda-screen-transitions-are-undefined-behaviour/)

• NES Emulator Debugging (https://gridbugs.org/nes-emulator-debugging/)

• Two’s Complement Multiplication (http://pages.cs.wisc.edu/~david/courses/cs354/beyond354/int.mult.html)

• NES Hello World (https://www.embed.com/nes/hello-world.html)

• DF Direct: CRT Displays - Was LCD A Big Mistake For Gaming? (https://www.youtube.com/watch?v=tvRyVZWuvQ4)

• DF Direct! Modern Games Look Amazing On CRT Monitors… Yes, Better than LCD! (https://www.youtube.com/watch?v=V8BVTHxc4LM)

• Meu fork do emulador de NES em Go (https://github.com/akitaonrails/nes)

• Meu código do decodificador de código de Game Genie (https://github.com/akitaonrails/gamegenie)

Assinem estes canais:

• Retro Game Mechanics Explained (https://www.youtube.com/channel/UCwRqWnW5ZkVaP_lZF7caZ-g)
• One Lone Coder (https://www.youtube.com/channel/UC-yuWVUplUJZvieEligKBkA)