Essa foi a semana no X, e se você só lê manchete, é uma conclusão razoável. Este texto é pra quem quer saber o que cada uma dessas coisas faz de verdade.

Explodiu no dia 9, quando a conta abaixo resumiu o que um desenvolvedor de Atlanta, Brandon Thomas, vinha publicando desde o fim de setembro: sete clones de código aberto dos produtos principais da Adobe, escritos em Rust com ajuda do Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. Tudo de graça, tudo feito em “sala limpa”, sem uma linha de código da Adobe. A conta que viralizou foi esta:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

Na mesma semana, o REA, “Reverse Engineer Anything”, passou de 100 mil estrelas no GitHub, ganhando dezenas de milhares por dia. A promessa da página: “viu uma feature num app que você quer no seu produto? Peça pro seu agente investigar com o REA e construir uma versão pro seu projeto”.

E quem acompanha retrogaming sabe que 2026 é o ano que não para de dar. Tem uma planilha comunitária tentando listar os ports não oficiais pra PC, com uns 100 jogos de Ship of Harkinian a Skate 3, e ela está sempre atrasada. O canal Video Game Esoterica publica port novo quase todo dia: Time Crisis decompilado do arcade, Daytona USA, Bloodborne.

A versão de Xbox One do Forza Horizon 2, presa lá desde 2014, roda em Windows. O AnyPS5 promete converter executável de PS5 em binário nativo de PC, e emuladores de PS5 como o KytyPS5 e o SharpEmu já rodam Astro Bot com gameplay de verdade. Boa parte disso com IA no meio, alguns abertamente vibe-coded.

Daí o consenso: programar, em geral, acabou. Todo binário é reversível e reutilizável, basta apontar o agente. Minha posição é que ficou muito mais fácil mesmo, que ainda está longe da bala de prata que as pessoas imaginam, e que o motor por trás disso, o LLM, parou de crescer exponencialmente. O resto do texto são os motivos.

TL;DR: engenharia reversa é uma disciplina de 40 anos com ferramenta madura, e a IA acelerou o trabalho braçal dela, com destaque pro retrô, onde o binário está disponível, é minúsculo e o alvo não se move. Os clones da Adobe são alpha com centenas de bugs abertos e print bonito. O REA é uma caixa de ferramentas que exige o binário na mão, Ghidra ou IDA instalados, e muito token. O que vale dinheiro hoje nem binário tem: é SaaS, nuvem, parceria com fabricante e décadas de ciência de cor. Reescrever o Bun, com o autor do projeto e 64 agentes, custou US$ 165 mil. Pule pra linha do tempo, pro REA, pros clones da Adobe, pro caso Bun, por que o retrô anda rápido ou pras respostas no final.

Antes de tudo: eu não gosto da Adobe

Pra ficar claro de onde eu falo. Eu detesto as práticas comerciais da Adobe tanto quanto qualquer um. Fui cliente pagante por anos, usei Photoshop e Premiere extensivamente, mais Lightroom e After Effects, e saí pelos mesmos motivos que todo mundo sai: assinatura compulsória, cancelamento com multa, preço subindo sem contrapartida.

E é exatamente por ter usado a fundo que eu sei o tamanho do que está dentro daquelas caixas. Quem acha que Photoshop é camada, crop e texto nunca precisou de prova de cor pra gráfica, nunca abriu um RAW de câmera cujo perfil de cor a Adobe mantém há vinte anos, nunca fez a conformação de material de cinema, o trabalho de reunir o material bruto da câmera pra finalização. Vou chegar lá, depois do básico.

Engenharia reversa não nasceu semana passada

Todo emulador que você já usou existe porque alguém abriu hardware, desmontou binário, farejou protocolo e, em alguns casos, quebrou criptografia. A disciplina tem jurisprudência, ferramenta comercial e uma história de décadas. Uma linha do tempo resumida, com os marcos que mais importam:

• 1982 a 1984: a Compaq reescreve a BIOS do IBM PC por engenharia reversa, e em 1984 a Phoenix vende uma BIOS licenciável feita em sala limpa, com um time que só lia a especificação. Nasce a indústria de PC compatível. Fonte.
• 1992: Andrew Tridgell cria o Samba farejando pacotes SMB. No mesmo ano, Sega v. Accolade e Atari v. Nintendo firmam nos EUA que desmontar código pra chegar em elementos funcionais é fair use, uso justo (a Atari perdeu o caso dela por outro motivo: mentiu pro Copyright Office pra conseguir o fonte).
• 1993: começa o Wine, que vira a base do Proton e de todo jogo de Windows que roda no Steam Deck hoje.
• 1999: UltraHLE roda jogos comerciais de N64 em velocidade real; o bleem! emula PS1, a Sony processa e perde as liminares, e o bleem! ainda assim fecha em 2001; o DeCSS quebra a proteção do DVD.
• 2000: Sony v. Connectix decide que copiar a BIOS do PS1 pra construir um emulador é uso justo.
• 2002 e 2003: nascem PCSX2 e Dolphin, os dois emuladores que vinte anos depois ainda são referência.
• 2007: o iPhone é aberto onze dias depois do lançamento. A Comissão Europeia obriga a Microsoft a documentar seus protocolos de rede, e a equipe do Samba recebe a documentação por 10 mil euros.
• 2010: o grupo fail0verflow mostra no 27C3 que a Sony assinou o firmware do PS3 com um nonce fixo, expondo a chave privada (o nonce é o número que deveria ser aleatório em cada assinatura). Dias depois, já em 2011, o geohot publica a chave, a Sony processa e faz acordo em março.
• 2011 e 2013: nascem RPCS3 (PS3) e Xenia (Xbox 360), os dois emuladores mais difíceis já feitos, por motivos que vou explicar.
• 2019: a NSA libera o Ghidra como código aberto. A decompilação do Super Mario 64 vaza e vira pública, e no ano seguinte aparece o port pra PC.
• 2021 e 2022: Ocarina of Time 100% decompilado depois de quase dois anos de trabalho; o Ship of Harkinian vira o port de referência.
• 2024: Mr-Wiseguy lança o Zelda 64: Recompiled, a primeira vitrine da recompilação estática de N64.
• 2025: Sonic Unleashed Recompiled traz o mesmo truque pro Xbox 360, convertendo PowerPC pra C++ e shaders pra HLSL.

Repare que a fase atual, decomp e recomp em escala, começa em 2019, bem antes de qualquer agente de código. A IA entrou numa linha de montagem que já existia.

As ferramentas

O ferramental também é maduro, e boa parte é gratuita:

• IDA Pro (Hex-Rays), o disassembler e decompilador comercial de referência, de mil a quase nove mil euros por ano, com uma versão gratuita limitada a x86.
• Ghidra, a resposta aberta da NSA, com decompilador e scripting, Apache 2.0.
• Binary Ninja, com uma edição gratuita e licenças de 200 a 3.500 dólares.
• radare2 e o Cutter, interface do rizin, que é um fork do radare2: a linha de comando e a interface abertas.
• x64dbg e WinDbg no Windows, GDB no resto.
• Frida, pra injetar código em processo vivo e observar o que ele faz.
• JADX pra Android e ILSpy pra .NET.

Guarde essa lista. O REA, que a gente vai ver daqui a pouco, é um embrulho em volta dela.

Como se desmonta um binário, na prática

Em princípio, todo binário é reversível. O processador precisa conseguir executar aquilo, então as instruções estão lá. O caminho é sempre o mesmo:

1. Desmontar: o binário vira assembly, uma instrução de máquina por linha. Isso é mecânico.
2. Decompilar: o assembly vira algo parecido com C. Ghidra e IDA fazem isso razoavelmente bem, com muito ruído.
3. Recuperar o que o compilador jogou fora: nome de variável, nome de função, tipos, estruturas, comentários. Nada disso sobrevive à compilação. Esse é o trabalho de verdade, e é humano.
4. Refatorar até virar código que uma pessoa consegue ler, manter e portar.

Os projetos de decomp de N64 fazem o passo 4 até o fim: o código em C deles, recompilado, gera byte a byte a ROM original. É assim que o Super Mario 64 virou um projeto com 135 mil linhas de C de código de jogo (uns 100 mil de código efetivo, mais meio milhão de linhas de dados de fase e modelo gerados), e o Ocarina of Time passou de 430 mil linhas. A recompilação estática pula parte disso: traduz as instruções do processador original pra C genérico, sem tentar entender, e troca só as partes que falam com o hardware. É mais rápido e o resultado é menos legível.

“Mas a IA não pode ler o binário direto?”

Alguém sempre pergunta: se é IA, pra que passar por C? Deixa o modelo ler o binário e construir em cima. A resposta curta é que LLM só sabe o que estava no corpus de treino, e corpus de binário pareado com código fonte é escasso, porque nenhum humano escreve assembly de produção há décadas.

A resposta longa é que existe literatura, e ela é instrutiva justamente por ser modesta. A linhagem vai de redes neurais de 2018 a modelos como o SLaDe (200 milhões de parâmetros, um por arquitetura e nível de otimização), o LLM4Decompile (até 33 bilhões) e o Nova. A Meta publicou um LLM Compiler que traduz assembly pra IR do LLVM. Os melhores resultados, em funções isoladas de benchmark, giram em torno de 60 a 65% de código que roda de novo e dá o mesmo resultado, caindo forte quando o compilador otimizou com -O3.

Dois estudos recentes mostram o estado real. O DecompileBench, com 23 mil funções reais, achou que decompiladores baseados em LLM produzem código mais legível e com metade da correção funcional dos decompiladores comerciais. E um trabalho de setembro de 2026 mediu que o refinamento por LLM da saída do Ghidra sobe a taxa de compilação de 75% pra 90% e derruba a fidelidade de comportamento de 74% pra 62%, com até uns 10% das funções com vulnerabilidade conhecida deixando de reproduzir a falha, ou seja, o bug sumiu sem ninguém pedir.

Resumindo o que existe: modelos pequenos, função por função, quase só x86-64 Linux, e os melhores são camadas de refinamento em cima do Ghidra, o que mantém o decompilador clássico no loop. Nenhum emulador, nenhum jogo, nenhum programa inteiro foi recompilado neuralmente. Enquanto alguém não inventa isso, você trabalha com a realidade, e a realidade inclui a camada intermediária de linguagem de programação e compilador.

Os assistentes de IA que existem pra isso em produção confirmam o desenho: o aiDAPal, plugin de IDA da Atredis, o Sidekick do Binary Ninja, os servidores MCP pro Ghidra. Todos são um LLM dando nome a variável e explicando função em cima do que o decompilador tradicional produziu.

O que o REA faz de verdade

Eu clonei o REA e li o código. Ele é um servidor MCP e uma CLI em TypeScript que embrulha as ferramentas da lista acima e as expõe pro seu agente de código: Ghidra, Hopper, IDA, JADX, Frida, Wakaru pra JavaScript ofuscado, Playwright pra capturar o que um site faz. O agente pede, o REA roda a ferramenta e devolve pseudocódigo, grafo de chamadas, strings e traces de IPC, cada resultado com um registro de evidência e uma lista de limitações.

Esse fluxo eu já tinha feito na mão, meses antes de o REA viralizar. Em julho eu coloquei o Fable 5 pra analisar o código do TikTok, do Clash of Kings e do gov.br: baixei os APKs, descompactei (APK é um zip), rodei o JADX nos .dex e deixei o modelo ler o Java que saiu do outro lado. Deu pra ver os endpoints, as permissões, os SDKs embutidos e como cada app monta o fingerprint do aparelho, aquele identificador persistente que sobrevive a limpar dados e reinstalar. O TikTok saiu como coleta de grau industrial, blindada contra auditoria; o gov.br, como exemplo de como fazer direito.

As três lições daquele post valem pro REA inteiro. Android é fácil demais de descompilar, e mesmo assim o resultado serve só pra análise estática, porque recompilar o app fica fora de alcance: os nomes vêm embaralhados pela ofuscação, faltam recursos e chaves de assinatura. A parte mais sensível mora em código nativo, .so em C e C++, que descompila em nada legível, e no TikTok é justamente aí que fica o miolo. E o que saiu daquele trabalho foi um relatório sobre o que o app faz, com ressalvas, e nenhum clone do TikTok. O REA embala esse mesmo fluxo num servidor MCP; as paredes continuam no mesmo lugar.

Quem fornece o julgamento é o LLM que você já paga. O REA fornece o encanamento determinístico e a proveniência. A frase “automatiza as heurísticas de engenharia reversa”, que circula por aí, não aparece em lugar nenhum do repositório; a descrição que o próprio projeto usa é engenharia reversa dirigida por agente, com evidência rastreável.

O que ele exige: o artefato na sua máquina (binário nativo, app Electron, assembly .NET, APK, firmware, captura de rede), Node 22.19 ou superior, e as ferramentas pesadas instaladas por sua conta. Ghidra é grátis; IDA, Hopper e JEB o README manda você comprar. Não tem chave de API do REA porque ele roda local, e o custo de token cai inteiro na sua assinatura de agente.

E esse custo é o detalhe que ninguém cita. O catálogo de ferramentas MCP do REA tem 2,3 MB de JSON, que entra no contexto do agente. O próprio projeto publica um experimento em que analisar o SQLite compilado em WASM, no caminho padrão, levou 42 chamadas de ferramenta, cinco minutos e 300 mil tokens de entrada. Um inventário completo de um app Electron como o Obsidian devolve quase 1 MB de JSON.

Tem issue aberta reclamando que inspecionar um app de Mac comum devolve de 80 a 230 mil tokens de uma vez.

O projeto é sério e vai longe: seis meses, 2.600 commits, mil arquivos de teste, versão 6.4 lançada em 11 de outubro. Também é instável: 190 issues abertas, várias mudanças incompatíveis a cada versão menor, subsistemas marcados como experimentais.

Os limites estão escritos no próprio repositório. O CONTRIBUTING exclui quebra de DRM, anticheat, licença e proteção comercial. O DISCLAIMER avisa que decompilação, reconstrução e análise assistida por IA “podem ser incompletas ou incorretas”. E até as instruções internas pra gerar as figuras do site dizem, com todas as letras: “nunca implique que o REA clona um programa automaticamente” e “nunca diga reconstrução completa, clone exato ou recuperação automática de código fonte”.

O REA é uma boa caixa de ferramentas pra quem já sabe fazer engenharia reversa e quer um agente segurando o Ghidra. Ele não é o botão “copia esse app pra mim”. Quem escreveu o projeto é o primeiro a dizer isso.

PhotoCraft: print bonito, alpha por dentro

O repositório do PhotoCraft foi criado em 30 de setembro. Em duas semanas, 54 mil estrelas, 8 versões lançadas e, no momento em que escrevo, mais de 800 issues abertas. O selo no README diz “early alpha”, e o próprio Brandon Thomas, citado pela Gizmodo, disse que não está nem perto de pronto. A imprensa que testou chegou na mesma conclusão: a Gizmodo chamou de “Photoshop cheio de bug, mas real”, e o OMG Ubuntu de “fac-símile superficial com falhas pronunciadas”.

As issues contam a história técnica:

• Qualquer imagem acima de 8.192 pixels sai do compositor de GPU e cai pra CPU, com pico de 6 GB de memória, porque o limite de textura do egui-wgpu é esse (issue 49, já fechada, e as que vieram depois, 1015 e 4017).
• Uma foto de 12 megapixels precisa de quase 800 MB só pra abrir, ajustar e exportar pela linha de comando (issue 1637).
• O gerenciamento de cor é rudimentar: espaço de trabalho só global, em vez de por documento, e sem transformação de visualização (issue 321). Dezoito issues mencionam CMYK, quinze mencionam perfil ICC.
• Quase cem issues abertas mencionam PSD. Camadas de matiz e saturação compõem diferente do Photoshop, e salvar por cima sobrescreve a imagem mesclada correta do arquivo original (issue 4089).
• Cinquenta issues abertas mencionam “crash”.

A interface lembra o Photoshop, então o print é compartilhável, e quem vê o print assume que é cópia carbono. Isso é esperado numa alpha de duas semanas. Com interesse, tempo e contribuição, parte disso vai sendo resolvida. E aí os contribuidores vão descobrir uma coisa que os projetos de N64 nunca enfrentaram.

O PhotoCraft hoje é aquela réplica de Ferrari montada em cima de um Fusca: a carroceria tem a forma certa, você tira uma foto e a maioria das pessoas diz “uau, uma Ferrari”. Aí você liga e sai o motor de Fusca. Se você se empolgou com a foto, o problema foi seu.

O alvo se move

Decompilar o Zelda de 1998 é mirar num alvo parado. A Nintendo não vai lançar o Ocarina of Time 2026 com formato de arquivo novo. Copiar um produto vivo é outra conversa, e a gente já viu esse filme.

Nos anos 90 e 2000 o alvo era o Microsoft Office. O StarOffice virou OpenOffice em 2000 e LibreOffice em 2010, e todos eles passaram anos correndo atrás de um formato binário, o .doc, que mudava de versão pra versão e só ganhou especificação pública em 2008, quando o jogo já tinha acabado. A parte comprovada dessa história está nos processos: a Comissão Europeia multou a Microsoft em 497 milhões de euros em 2004 por recusar informação de interoperabilidade, e em 899 milhões em 2008 por descumprir a ordem. O .docx só virou padrão ISO em 2008, numa votação tão controversa que países protestaram formalmente.

Levou mais de dez anos. E quando o formato finalmente abriu, o Office já não importava do mesmo jeito. O valor mudou de lugar: hoje são 400 milhões de assentos pagos de Office 365, 3 bilhões de usuários de Google Workspace e uns 41 milhões de assinantes de Creative Cloud. Ninguém quer instalar aquilo no desktop, e por isso ninguém tem o binário.

Fazer engenharia reversa do Google Docs é reescrever o produto do zero olhando só pra interface, porque o código que importa nunca sai do servidor. Depois que o mundo migrou pra SaaS, a maior parte do software proprietário virou jardim murado sem binário. Sem binário, não tem o que desmontar.

Dá pra fazer versões disso, claro. O Immich substitui o Google Photos pra uma pessoa ou uma família: backup do celular, reconhecimento de rosto, busca semântica, tudo no seu servidor. O que ele não replica é a infraestrutura e o corpus de treino que fazem a busca do Google ser a busca do Google. E a Adobe fez a mesma migração, em pedaços.

Photoshop é muito mais que camada e crop

Aqui entra a parte que eu conheço por ter pagado. As features que vendem assinatura hoje nem rodam no seu computador.

O Generative Fill e o Generative Expand rodam no Firefly, na nuvem, e consomem créditos generativos. Vários Neural Filters, segundo a própria documentação, precisam de internet porque o processamento é no servidor da Adobe. A seleção de objeto por IA tem, desde 2020, uma opção de processar na nuvem pra refinar o resultado. Isso tudo é código que não existe na sua máquina pra ninguém desmontar.

Depois vem o que está no binário, mas levou décadas e parceria pra existir. O Camera Raw carrega perfis de correção de lente e perfis de cor por câmera pra centenas de modelos, construídos ao longo de vinte anos e atualizados a cada lançamento. Clone nenhum adivinha isso. Ou tem o dado, ou não tem.

E tem a ciência de cor. O exemplo que eu sempre lembro é o GIMP e o CMYK.

O GIMP nasceu em 1995. O primeiro suporte nativo a arquivo CMYK chegou em 2022, e só de importação e exportação, com o pixel sempre em RGB. O GIMP 3.0, de 2025, ainda sem modo de edição em CMYK. Está no roadmap como trabalho em andamento.

Trinta anos de projeto aberto, com gente boa e motivada, e a gráfica ainda pede o Photoshop. Isso é o tamanho do buraco da ciência de cor, e nenhum agente de código inventa ciência de cor: ele reproduz o que está no treino.

Por que demorou tanto, se era a feature mais pedida? Porque o núcleo do GIMP nasceu com RGB de 8 bits por canal embutido em cada camada, modo de mesclagem e filtro. Suportar outro modelo de cor exigiu reescrever o motor de pixel inteiro, a migração pro GEGL, que levou a maior parte de uma década e só ficou pronta no GIMP 2.10, em 2018. O CMYK só pôde começar depois disso.

E CMYK é uma família de perfis de dispositivo, com quatro tintas, perfil ICC por impressora, limite de tinta e regra de geração de preto, e editar nele significa que toda a cadeia precisa calcular num modelo subtrativo de quatro canais e ir e voltar pelos perfis sem desviar a cor. Um desenvolvedor sozinho, por melhor programador que seja, sem experiência nessa área específica, vai sofrer pra implementar isso, porque o conhecimento está na gráfica e no laboratório de cor, e quase nada dele está em corpus de treino. No GIMP, quem levou a coisa adiante foram contribuidores que entendem de impressão, e mesmo assim foram anos. Ferramenta nova nenhuma atalha esse tipo de conhecimento.

E tem a camada que nem é técnica: licença comercial. Cor de gráfica é Pantone, e Pantone é uma biblioteca proprietária. Projeto aberto nenhum pode embarcar as paletas; os desenvolvedores do Inkscape chegaram nessa conclusão em 2005, e a Linux.com explicou o risco jurídico na mesma época. A própria Adobe sentiu isso em 2022: quando a Pantone mudou o modelo de negócio, as bibliotecas saíram do Photoshop, do Illustrator e do InDesign, arquivos antigos passaram a abrir com as cores Pantone trocadas por preto, e quem precisa delas paga uma assinatura separada de plugin. Se nem a Adobe, pagando, escapou, imagine um clone que vive de boa vontade.

Vídeo é pior

No Premiere, no After Effects e no DaVinci Resolve, o problema multiplica. Câmera de cinema não entrega vídeo, entrega dado bruto numa curva logarítmica própria: LogC4 da ARRI, IPP2 da RED. Pra transformar aquilo em imagem, você precisa das transformadas do fabricante, e a RED entrega as dela num SDK que os editores integram e atualizam a cada versão. O ACES, o padrão neutro da indústria, depende de transformadas de entrada fornecidas por cada fabricante.

A Blackmagic dá o Resolve de graça e ele decodifica ARRIRAW e R3D. Faz isso porque paga o SDK e a parceria por você. Um clone feito por agente, “adivinhando” como a imagem da Alexa deve ficar, produz uma imagem que não bate com o monitor de referência, e no cinema isso significa que não serve. Esse conhecimento não está em corpus de treino nenhum: está em contrato.

O caso Bun: quanto custa reescrever software grande

Pra ter noção de ordem de grandeza, o melhor dado público que existe é o do Bun. Em maio de 2026, Jarred Sumner reescreveu o runtime inteiro de Zig pra Rust usando agentes, e em julho publicou os números:

• 535 mil linhas de Zig em 1.448 arquivos viraram um diff de um milhão de linhas de Rust, em 11 dias.
• Até 64 instâncias de Claude em paralelo, 24 horas por dia, cada linha revisada por dois agentes adversariais e um corretor.
• 5,9 bilhões de tokens de entrada não cacheados, 690 milhões de saída, 72 bilhões de leituras de cache: uns US$ 165 mil a preço de API.
• 16 mil erros de compilador corrigidos por 64 agentes antes do CI ficar verde em seis plataformas.
• A suíte de testes existente, com mais de um milhão de asserções, passou 100% antes do merge.

Lê de novo o que viabilizou isso:

• o autor original do projeto pilotando
• um código fonte completo e funcional como referência
• uma suíte de testes de um milhão de asserções servindo de oráculo
• orçamento ilimitado, porque o Bun pertence à Anthropic desde dezembro de 2025, e uma versão pré-lançamento do Claude Fable 5

O Sumner estima que três engenheiros com contexto total levariam um ano.

Agora tira cada uma dessas vantagens. O PhotoCraft não tem o fonte do Photoshop pra portar, tem que inventar. Não tem suíte de testes que diga “isso aqui bate com o Photoshop”. Não tem o autor do Photoshop.

E o Photoshop é um produto de 36 anos, cujos requisitos de disco a Adobe lista entre 10 e 100 GB, contra um runtime de JavaScript. Mesmo sem saber o tamanho do código da Adobe, estamos falando de um alvo maior, sem referência, sem oráculo e sem dono. Ordens de grandeza acima de US$ 165 mil, e ainda assim seria uma aproximação.

Por que o retrô anda tão rápido

Se é tão difícil, por que sai port de jogo antigo todo dia? Porque o retrô acumula todas as vantagens que o resto não tem.

O binário está disponível e é minúsculo. Super Mario Bros. do NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time e Majora’s Mask: 32 MB cada. Um CD inteiro de PS1: 650 MB.

Compare com Baldur’s Gate 3, 150 GB, ou com o Call of Duty mais recente, acima de 100 GB. São três ou quatro ordens de grandeza, e o escopo encolhe junto: um jogo de 1996 tem um punhado de sistemas, não um motor de física com rede, loja e anticheat.

A tecnologia é antiga e documentada. Vinte e cinco anos de comunidade já mapearam o hardware do N64, do PS1 e do SNES instrução por instrução. O agente não descobre nada; ele acelera um trabalho com mapa pronto. É o mesmo padrão que eu vi nos meus projetos de retrocomputação: onde tem referência e oráculo, a IA voa; onde não tem, ela gira em força bruta.

O alvo não se move. Ninguém vai atualizar o Zelda de 1998.

E o jurídico está resolvido há trinta anos. Sega v. Accolade e Sony v. Connectix deram o contorno. Os ports exigem que você forneça a sua ROM.

Console moderno é um PC

A segunda metade da explosão, os ports de PS4, PS5, Xbox One e Switch, tem outra explicação: esses consoles são PCs ou celulares com outro invólucro. O PS4 usa um AMD Jaguar x86-64, o PS5 um Zen 2, o Xbox Series outro Zen 2, o Switch um Tegra X1 ARM da NVIDIA. O processador do seu PC roda aquele código nativamente. Então ninguém precisa emular a CPU.

O trabalho que sobra é traduzir o sistema operacional e a GPU. O shadPS4 reimplementa as bibliotecas do sistema do PS4 e recompila os shaders: os jogos saem da fábrica com código de máquina da GPU AMD, que o emulador decodifica instrução a instrução e converte pra SPIR-V, o formato do Vulkan.

O Azimuth, que faz o Forza Horizon 2 rodar no Windows, traduz chamadas WinRT do Xbox pra Win32 e DirectX 11.X pra DirectX 12 desktop, com o código x86 do jogo rodando direto. O AnyPS5 religa o executável: pega o binário do PS5 e gera um binário nativo de Linux ou Windows, ligado a bibliotecas de sistema reimplementadas. Nos três casos, Proton, DXVK, VKD3D e MoltenVK já tinham resolvido a camada de tradução gráfica anos antes.

A prova inversa são os consoles que não eram PC. O PS3 usa o Cell, um PowerPC com sete coprocessadores ativos (os SPEs), cada um com memória local própria e sem cache, e o RPCS3 está nisso desde 2011, com a emulação dos SPUs sendo gargalo até hoje. O Xbox 360 é PowerPC também, e por isso o Sonic Unleashed precisou do XenonRecomp traduzir PowerPC pra C++. Engenharia reversa é caso a caso, e a arquitetura decide se o caso é fácil.

A IA está no meio, e já tem briga

Que os ports de 2026 usam IA, boa parte deles diz na cara. O decomp do Silent Hill escreve no README que o desenvolvimento é “fortemente assistido por IA (Claude Opus 4.6, 4.7 e o Fable mais novo), e somos abertos sobre isso. Não é tradução automatizada do jogo”. O recomp do Pokémon Stadium lista o Claude como contribuidor.

Os devs dos recomps de Zelda e Banjo, que passaram anos fazendo isso à mão, entraram em guerra com o que chamam de “slopcomps”, ports gerados por agente com qualidade de alpha.

E vale separar manchete de estado real também aqui. O AnyPS5 tem uma versão 0.1 de setembro que, segundo quem testou, roda um jogo indie 2D; a alegação viral de que “o PS5 está 80% portado pra PC” é dos fãs, e nenhum jogo 3D roda. Astro Bot roda, só que em emuladores (KytyPS5, SharpEmu), que fazem o caminho tradicional. O Forza Horizon 2 roda, e o Azimuth é um binário fechado de um estúdio que se declara “AI assisted” sem dizer mais nada.

“Mas daqui a dois anos o token custa nada”

A resposta padrão pra tudo isso é: hoje é difícil, em dois anos é trivial, porque IA cresce exponencialmente. Os números dizem outra coisa.

O preço da ponta mais cara caiu pouco. O GPT-4 de março de 2023 custava US$ 30 e 60 por milhão de tokens de entrada e saída; o Claude 3 Opus de 2024, 15 e 75; os modelos de ponta de hoje, Fable 5.1 e GPT-6 Astra, custam 10 e 50. Em três anos e meio, a fronteira ficou entre 1,2 e 3 vezes mais barata, dependendo de qual ponta você olha.

O que caiu de verdade foi o custo de uma qualidade fixa: a Epoch AI mediu quedas de 9 a 900 vezes por ano dependendo da tarefa, e numa revisão de 2026 resume em “muito grosseiramente 5 a 10 vezes por ano”, com o aviso de que pode desacelerar. Isso é real e é ótimo.

Só que aplica a conta no Bun. US$ 165 mil divididos por 10 dá US$ 16 mil. Por 100, US$ 1.650. Isso é pra portar um runtime com fonte, testes e autor na mão.

Pra um amador tentando clonar o Photoshop sem nada disso, a conta começa ordens de grandeza acima e cai na mesma proporção. Barato não é o mesmo que trivial.

E a premissa do “exponencial” morreu em 2024. O Ilya Sutskever disse no NeurIPS que o pré-treino como conhecemos vai acabar, porque só existe uma internet. A Epoch projeta que o escalonamento dos modelos de raciocínio converge pra taxa geral da fronteira em cerca de um ano.

Eu já escrevi sobre isso três vezes nas últimas semanas: os limites do que o modelo reproduz, a convergência dos modelos crus com o ganho vindo do harness, e o benchmark de linguagens em que os modelos de fronteira empataram no teto. A ferramenta que temos é a ferramenta que vamos ter por um bom tempo, com melhoria incremental. Planeje com ela.

Vale lembrar o número que abre o texto dos limites: pelo Octoverse 2025, relatório oficial do GitHub, 81,5% das contribuições na plataforma aconteceram em repositórios privados. É o código que importa de verdade, o que paga salário, e nenhum LLM viu uma linha dele. O modelo reproduz o que estava no treino, e esse código nunca esteve lá.

Agora estenda isso pra todo produto SaaS e pra cada componente que ele usa. O código da Adobe que realmente vale, o motor de cor, os perfis, os filtros na nuvem, não está disponível em lugar nenhum, nem como binário. Quem quiser reproduzir vai ter que refazer a pesquisa e o desenvolvimento, caro e demorado, pelos mesmos anos que a Adobe levou. E no fim ainda esbarra na propriedade intelectual licenciada de terceiros, Pantone, SDK de câmera, perfil de fabricante, que você nunca vai conseguir ter.

Respondendo a lista do começo

O PhotoCraft existe? Existe, é uma alpha de duas semanas com mais de 800 issues abertas, gerenciamento de cor rudimentar, travando acima de 8K e abrindo PSD errado. Parece Photoshop no print. Pode melhorar muito, e vai descobrir que o alvo se move e que as partes caras do Photoshop estão na nuvem ou em contrato com fabricante.

O REA existe? Existe, é bom, e é uma caixa de ferramentas pra quem já sabe usar Ghidra, exige o binário na mão, as ferramentas instaladas e centenas de milhares de tokens por análise. O próprio projeto evita dizer que ele clona programa.

Recomp e decomp aceleraram? Sim, de verdade, e a IA tem parte nisso. Aceleraram onde o binário existe, é pequeno, está documentado há 25 anos e não se move. Ou onde o console é um PC disfarçado e o trabalho é tradução de API, resolvida pelo Wine e pelo Vulkan anos antes.

A Adobe morreu? A Adobe tem uns 40 milhões de assinantes, pela estimativa mais citada, as features que vendem assinatura rodam no servidor dela, e trinta anos de GIMP ainda deixam a gráfica pedindo Photoshop. Eu queria que fosse diferente. Os dados dizem que o que vai acontecer é o que sempre aconteceu com clone de produto vivo: anos correndo atrás, e quando alcança, o valor já mudou de lugar.

Programador morreu? Reescrever o Bun precisou do autor do Bun. Os decomps que funcionam têm gente que conhece o hardware pilotando o agente, e os que não têm viraram “slopcomp” com nome e tudo. A engenharia reversa ficou mais barata e mais acessível, como ficou com o Ghidra em 2019, e continua sendo trabalho de engenheiro. Sem nós, a ferramenta devolve print bonito.

Software proprietário com binário na mão vai sofrer pressão, e deve. A maior parte do software que você usa não tem binário nenhum, e o que tem já depende de serviço na nuvem que não desmonta. Engenharia de software com IA tem um caminho ótimo pela frente. Manchete de “acabou” rende clique e não compila.

Eu uso LLM pra tudo há quase dois anos, publiquei dezenas de projetos com elas, e minha conclusão é outra: o que elas fazem de melhor é reproduzir o que já existe. E isso cobre uma fatia gigante do trabalho corporativo, não se engane. Mas tem uma fronteira que elas não cruzam com facilidade, e eu passei os últimos meses esbarrando nela de propósito.

Esse artigo mostra onde ela fica, com evidência dos meus próprios projetos e da pesquisa que existe sobre o assunto. E tem uma hipótese que eu já adianto aqui e defendo no decorrer do texto: se LLM é tão boa em código, os provedores têm muito a agradecer às décadas da comunidade open source, que protegeu a liberdade do código e publicou tudo de graça. Sem esse patrimônio, não existiria Copilot, Cursor, Claude Code, nada disso.

Um disclaimer antes de começar: o que eu vou argumentar aqui é especulativo, baseado em observação e nos dados públicos que existem. Ninguém fora dos laboratórios sabe exatamente como cada provedor treina os próprios modelos, e isso varia de provedor pra provedor e de versão pra versão. O que vale hoje pode não valer na próxima geração. Leve tudo com um grão de sal.

O ponto cego do treinamento

Todo LLM foi treinado no que é público. A internet pública inteira, e no caso de código, o GitHub público. O dataset canônico de código aberto, o The Stack v2 da BigCode, é explícito sobre isso: ele é derivado do Software Heritage, um arquivo de “todo o código-fonte de software publicamente disponível”. São 67,5 TB, 3,28 bilhões de arquivos únicos, 104,2 milhões de repositórios. Gigantesco. E todo público.

Agora olha o outro lado. O Octoverse 2025, relatório oficial do GitHub, diz que 81,5% das contribuições na plataforma aconteceram em repositórios privados. Isso é só o GitHub. Fora dele tem:

• o código interno de toda empresa que nunca encostou num servidor público;
• o fonte de todo software proprietário;
• o código de todo jogo comercial;
• e o de todo sistema embarcado.

Nada disso nunca entrou no treino.

Pensa no que isso significa: o modelo conhece profundamente o que o mundo já publicou, e é cego pro que o mundo mantém fechado. Quando você pede um formulário React, ele está reproduzindo padrões que viu milhões de vezes. Quando você pede algo que ninguém nunca fez em público, ele está operando num território onde o mapa dele é branco.

Por que tá todo mundo entregando tanto, tão rápido?

Antes de entrar nos limites, vale registrar o lado que funciona, porque é ele que explica a sensação de que todo mundo virou fábrica de app.

Olha o que tá pipocando na comunidade: o Spotifast e o ZapFast, clientes nativos de Spotify e WhatsApp escritos em Rust por uma pessoa só, rodando em Linux, macOS e Windows. Nada ali é tecnologia nova. É o serviço que já existia, embrulhado num app nativo enxuto, em cima de biblioteca que já existia, fazendo o que os times oficiais sempre puderam fazer mas nunca quiseram gastar o tempo deles. Esse trabalho ficou barato, porque LLM treinada em tudo que é público é boa demais justamente nisso: replicar.

Meus próprios projetos seguem o mesmo padrão. O FrankMD é um web app de notas em Markdown com cara de Visual Studio e features que já existiam nos meus outros apps. O Frank Sherlock é um organizador de imagens local que, no fundo, é um gerenciador de arquivos com thumbnails e busca, coisa que existe aos montes. Nenhum dos dois inventa nada: são mashups de peças conhecidas, montadas do jeito que eu sempre quis. A LLM faz a parte chata, e é por isso que a velocidade aparece.

O exemplo mais didático é o meu cliente de email. Uso o Geary há anos, e duas faltas pequenas sempre me irritaram: o autocomplete de destinatário fraco e um painel lateral que eu queria poder esconder. Coisa boba, que nunca justificou montar ambiente de build, aprender o toolchain do projeto e estudar o código só pra duas features. Esse ano eu finalmente resolvi os dois: um módulo de autocomplete, um módulo pra esconder o painel, e um fork inteiro com meus patches. Virei mantenedor de melhorias que adiei por anos, não porque eu fiquei mais rápido, mas porque a parte chata ficou barata.

Repara no que todos esses casos têm em comum: o problema já tinha sido resolvido antes, em outro lugar, de outro jeito. O mapa existia; o que não existia era mão de obra barata pra refazer o caminho. É a reprodução trabalhando a favor, e é por isso que o seu feed tá cheio de gente entregando app novo toda semana.

Agora guarda esse raciocínio. O resto desse artigo é sobre o que acontece quando o mapa acaba.

Quatro experimentos caseiros

Eu não tô teorizando. Nos últimos meses eu rodei uma maratona de projetos de retrocomputação que são exatamente o caso patológico: trabalhar com software proprietário de 30 ou 40 anos atrás, cujo código-fonte nunca foi público. É o ponto cego perfeito.

nes-to-sms: o projeto que eu desisti

O nes-to-sms é um recompilador estático de NES pra Master System. A ideia: pegar a ROM binária de um jogo de NES, traduzir instrução por instrução de 6502 pra Z80, converter os tiles, e gerar um ROM de Master System que roda no hardware real. Esqueça emulador e port manual: é uma máquina que transforma um jogo num outro.

Recompilador estático de NES existe, o NESRecomp traduz pra C e roda nativo em PC, e eu estudei ele de perto. Mas cruzar de um console pra outro console de 8 bits, com orçamento de clock e de VDP totalmente diferente, ninguém nunca fez. Não existe referência pública, não existe paper, não existe projeto abandonado pra copiar.

Os números do projeto: 349 commits, 31 dias ativos espalhados por quase 4 meses, ~110 mil linhas de engine em Rust e Z80, 668 testes passando no último run registrado no README. E o resultado? Super Mario Bros. jogável (lento, com áudio limitado, mas jogável), com a trajetória de RAM byte a byte igual à do NES numa rota de ~4.900 frames (o diff deixa o áudio e parte do buffer de VRAM de fora). Castlevania jogável na fase 1. SMB3 renderizando. E uma fila de jogos que bootam três frames e morrem.

E não foi por falta de empurrar os modelos. Só nesse projeto:

• passaram quatro gerações de Claude (Opus 4.7, Fable 5, Opus 4.8, Fable 5.1), com 213 commits co-assinados e 104 commits linkados a sessões no histórico, mais sessões de Codex nos trechos sem co-autoria, com direito a handoff documentado entre agentes;
• teve até auditoria entre gerações: uma sessão nova de agente revisou os 55 commits anteriores e reverteu conclusões que a geração anterior tinha exagerado;
• só a caçada aos travamentos do Castlevania consumiu 45 commits em 5 dias;
• o sprint final de setembro foram 176 commits em 17 dias antes de eu decretar a pausa;
• e as regressões estão registradas pelo nome no histórico: “H.7 tried and reverted”, “record the reverted map-bank-hold attempt”, “correct-but-reverted result”, além de três hipóteses de alavanca compartilhada testadas e rejeitadas nos últimos três dias de projeto.

Tokens eu não medi de forma confiável nesse projeto, então não vou inventar número. Mas 349 commits com 668 testes segurando cada passo já dão uma ideia do custo.

Repara no detalhe que importa: o único jogo que ficou realmente pronto é o Super Mario Bros. Por quê? Porque SMB é o jogo mais dissecado da história. Existe uma disassembly completa e pública que a comunidade usa há mais de uma década, com cada função nomeada e comentada. Eu alimentei isso no perfil do jogo e a LLM tinha um mapa completo pra trabalhar. Pros outros jogos, não existe mapa. E sem mapa, cada jogo novo morria alguns frames depois do boot por divergência de fluxo de controle, e cada um exigia uma caçada forense instrução por instrução que não rendia nada pro jogo seguinte.

O próprio projeto documentou o padrão de giro. Teve uma campanha inteira de otimização que durou semanas tentando cortar o custo de emular flags do 6502 no Z80.

Aí em setembro eu parei pra comparar com o port manual que um hacker chamado lackoftrack27 fez de SMB pra Master System, escrito por um humano, rotina por rotina. Pela análise que a gente fez do código dele, o port humano roda dentro do orçamento de frame, com uma folga que estimamos em ~90% de utilização. A minha máquina, depois de meses de otimização, ainda precisava de overclock.

E o documento de análise cravou por quê: quando removemos 30% das chamadas de emulação de flag, o tempo mal se moveu.

As flags nunca foram o gargalo.

A otimização certa era redesenhar a estrutura de dados: transpor o array de objetos pra páginas de RAM. É um truque que depende de saber que “o registrador X aqui é sempre um índice de objeto”.

Essa invariante existe na cabeça do programador que escreveu o jogo em 1985. Ela não existe no fluxo de instruções. Um tradutor estático não tem como descobri-la. E o LLM, por meses, não descobriu.

O banner de pausa que eu escrevi no README é direto: a paridade em hardware real “pode ser fundamentalmente inalcançável” e, citando, “this may be a limit of the current frontier coding models as much as of the approach”.

gg-to-sms: o pivô pro território com mapa

No mesmo dia em que pausei o nes-to-sms, eu comecei o gg-to-sms: converter jogos de Game Gear pra Master System com a tela alargada. A diferença que importa é que esse problema não é novo. A cena de romhacking vem convertendo jogos de GG pra SMS à mão há vinte anos, e o catálogo que eu montei no projeto contou ~186 deles. Ou seja: existe corpus, existe ground truth, existe padrão pra aprender.

Resultado: em um dia de trabalho,

• a fase de pesquisa estava completa;
• o catálogo dos 373 jogos de GG estava montado;
• o scanner de pontos de patch foi validado contra patches humanos reais, acertando os endereços com margem de 8 bytes;
• e de quebra a ferramenta achou bugs de verdade em patches de vinte anos atrás que a cena inteira nunca tinha notado.

O modelo era o mesmo; o que mudou foi o problema, que dessa vez tem referência.

E mesmo assim: até agora, zero jogos passaram na revisão de aceitação do viewport. O ponto novo do projeto (a máquina que gera os patches sozinha, que é a parte que ninguém nunca fez) continua por fazer.

super-mario-deluxe-fixed: quatro dias e 436 milhões de tokens

Esse foi um sprint de 4 dias, praticamente uma sessão única de Codex que consumiu 436 milhões de tokens de input. O objetivo: rodar Super Mario Bros. Deluxe de Game Boy Color com tela alargada em resolução de NES, coisa que nenhuma ferramenta existente faz com sprites vivos.

Subiu pra jogável em 4 dias. Mas olha o alicerce: um emulador pronto vendado como dependência, e uma disassembly dormente do jogo que alguém tinha publicado anos atrás, que a própria documentação do projeto chama de “o artefato mais importante”.

O trabalho novo foi o renderizador customizado, e ele parou em 21 de 32 fases completadas. As que faltam travam em timing de plataforma móvel. O projeto tá parado no meio do sprint desde então, e ainda não desisti dele.

E um detalhe que diz muito: eu tive que dirigir o QA olhando screenshots, porque o agente entregava coisa com glitch gráfico e não percebia sozinho.

super-mario-bros-35: tudo que funcionou tinha dono

Esse é o clone offline do Super Mario Bros. 35, o battle royale que a Nintendo tirou do ar. O que funcionou nele: tudo que foi construído em cima de artefato existente.

• O engine é uma reconstrução em C feita por outra pessoa com Ghidra.
• Os pesos iniciais da IA vieram de checkpoints publicados.
• As regras de rede foram inferidas de um reverse engineering público do netcode.
• Até a física: o bug central foi diagnosticado porque eu tinha uma trajetória de referência gravada pra comparar frame a frame.

O que não funcionou: as fases de castelo com labirinto. O treinamento por reforço estaciona nelas. 46 milhões de passos de agente, reinício de treino do zero, recompensa anti-loop, e no fim a única coisa que resolveu uma das fases foi cirurgia manual de bias no modelo treinado. Das 32 fases, 19 limpas. As piores continuam travadas.

E o processo degenerou num padrão que eu reconheço de todos esses projetos: quando o treinamento não resolve, o fluxo vira roleta de seleção de checkpoint, dezenas de variações de bias e de cabeças de saída, jogando permutação e computação no problema no lugar de uma correção de princípio.

O padrão que eu sinto

Isso é intuição de quem operou a máquina por meses, não dado duro. Mas o padrão se repete com Claude, com GPT, com Kimi, com GLM, então não parece defeito de um modelo.

O começo de qualquer projeto é uma maravilha. Os primeiros milestones voam, porque montar estrutura, escrever harness, replicar API, isso tudo é território coberto. Aí o projeto chega na parte que ninguém nunca fez, e a velocidade desaba. O agente começa a girar: tenta uma hipótese, regride outra coisa, reverte, tenta de novo. O histórico de commits do nes-to-sms tá cheio de mensagens honestas tipo “tentativa revertida” e “hipótese fechada com resultado correto mas revertido”. Muito token queimado, pouco avanço.

Minha leitura do que acontece por dentro: o sampling de tokens é probabilístico. Quando o problema é parecido com o treino, os tokens certos têm probabilidade alta e a resposta sai direto. Quando o problema é inédito, a probabilidade do caminho certo é baixa, e o processo vira uma força bruta direcionada: tentativa e erro guiada, mas tentativa e erro mesmo assim.

A saída que eu encontrei pra esse giro é sempre a mesma: dar um oráculo. Se eu consigo definir “o resultado tem que ser igual a X” (uma imagem de referência, uma trajetória gravada, um emulador ciclo-exato como ground truth), a máquina consegue iterar até esbarrar no X. No nes-to-sms, cada destravamento real veio disso: a disassembly do SMB, o frame-diff, o emulador de referência. Quando eu não consigo definir o X direito, ela gira indefinidamente.

A segunda estratégia que funciona: caçar projeto abandonado, paper, qualquer material que o modelo nunca viu mas que aproxima o problema, e enfiar no contexto. Isso aquece a distribuição e melhora muito o resultado. Mas é limitado: se nada parecido existe, não tem o que alimentar.

Não é anedota, é o que a pesquisa mede

A parte boa é que eu não preciso depender da minha intuição. Tem pesquisa séria medindo exatamente isso.

O estudo GSM-Symbolic da Apple pegou problemas de matemática de benchmark e fez duas coisas simples: trocou só os números, e depois adicionou uma única frase irrelevante no enunciado. Resultado: a performance cai só de trocar os números, e despenca até 65% com a frase irrelevante. A hipótese dos autores, no texto: “LLMs atuais não fazem raciocínio lógico genuíno; eles replicam passos de raciocínio dos dados de treino”.

O GSM1k da Scale AI criou um espelho do GSM8K escrito do zero por humanos, garantidamente sem contaminação, e viu quedas de até 8% em várias famílias de modelo, com sinais de overfitting sistemático nas piores. Pra ser justo com o paper: os autores dizem que os modelos de fronteira mostram sinais mínimos de overfitting e que todos generalizam até certo ponto pra problemas novos. O sinal existe, o tamanho dele é discutível.

O LiveCodeBench fez o teste mais limpo de todos: avaliar em problemas de código publicados depois do corte de treinamento. Performance inflada em problema pré-corte e queda em problema pós-corte em vários modelos populares, o sinal clássico de contaminação.

E tem o ARC-AGI, o benchmark do François Chollet desenhado especificamente pra ser à prova de memorização: cada tarefa é inédita, nenhuma parecida existe no treino. No ARC-AGI-2, lançado em março de 2025, a tabela oficial diz: LLMs puros marcam 0%, sistemas de raciocínio ficam em dígito único, e cada tarefa de avaliação foi resolvida por pelo menos dois humanos em até duas tentativas. O Chollet, aliás, resumiu minha tese melhor que eu, lá em fevereiro de 2024:

“LLMs não são AGI, são um grande ajuste de curva num dataset muito grande. Funcionam por memorização e interpolação. Mas essa curva interpolativa pode ser tremendamente útil, se você quer automatizar uma tarefa conhecida que casa com a distribuição do treino. Memorização funciona, desde que você não precise se adaptar ao novo.”

No mundo real, o estudo que mais me impressionou foi o RCT da METR: 16 desenvolvedores experientes, 246 tarefas reais nos próprios repositórios maduros deles, randomizado com e sem IA. Os devs apostavam que IA ia acelerar 24%. Mediu-se: ficou 19% mais lento. Repara onde isso aconteceu: código maduro, privado, cheio de contexto que o modelo nunca viu. Exatamente o ponto cego.

E o benchmark favorito da indústria pra dizer que “IA já faz engenharia de software”, o SWE-bench, é só Python, 12 repositórios open source famosos, ou seja, a fatia mais coberta do treino. A métrica de sucesso da indústria mede o território com mapa.

Até a literatura de código legado diz a mesma coisa: um paper de 2026 sobre LLMs gerando COBOL crava que, nessas linguagens legadas, “a maior parte do código de produção está em sistemas corporativos e raramente é publicamente disponível”. É a tese desse artigo, dita por outras pessoas.

O steelman: força bruta direcionada funciona, a preço de ouro

Antes de fechar, vale encarar o argumento mais forte contra mim. Steelman é isso, pra quem não conhece o termo: o oposto de espantalho. Em vez de atacar a versão mais fraca do argumento contrário, você responde à versão mais forte que ele pode ter. E ela existe e é boa.

Em maio de 2025 o DeepMind publicou o AlphaEvolve: um sistema que achou um algoritmo de multiplicação de matrizes 4x4 complexas com 48 multiplicações escalares, melhorando o recorde do Strassen de 1969 nesse cenário específico. Numa lista de mais de 50 problemas abertos de matemática, ele redescobriu o estado da arte em ~75% dos casos e melhorou a melhor solução conhecida em 20%. Isso é novidade de verdade, não reprodução.

O o3-preview da OpenAI saltou pra 75,7% no ARC-AGI-1 em dezembro de 2024, 22 pontos acima do melhor resultado anterior no mesmo conjunto de avaliação, e a configuração de compute alto chegou a 87,5% a um custo estimado de US$ 4.560 por tarefa.

E lá em 2016 o AlphaGo fez o lance 37 contra Lee Sedol, um lance que os dados do próprio DeepMind estimavam ter 1 chance em 10 mil de ser jogado por um humano, provando que busca sobre modelo pode transcender imitação.

Agora olha o mecanismo dos três:

• O AlphaEvolve é um loop evolutivo: o LLM propõe mutações, um avaliador automático pontua, a seleção itera.
• O o3 faz síntese de programas em tempo de teste, explorando o espaço de soluções.
• O AlphaGo é busca em árvore sobre aprendizado por reforço.

Se teve “insight” em algum deles, foi do sistema de busca ao redor do modelo: os três são força bruta direcionada com um verificador barato, o mesmo mecanismo que eu descrevi acontecendo nos meus projetos. A diferença é que o DeepMind tem oráculo perfeito e orçamento infinito: na configuração que chegou a 87,5%, o o3-preview gastava milhares de dólares por tarefa do ARC pra fazer o que um humano faz de graça. A própria ARC Prize escreveu a ressalva:

“Sabemos que uma busca de força bruta poderia acabar resolvendo o ARC-AGI, dados recursos e tempo de busca ilimitados. Isso não representaria inteligência de verdade.”

Resumindo: novidade sai, mas sai por busca cara sobre um oráculo, à base de tentativa e erro guiada. Se o seu problema tem verificador barato e você tem tokens pra queimar, dá pra ir longe. Foi assim que o nes-to-sms chegou onde chegou: 668 testes e ground truth de emulador segurando cada passo. Mas quando não tem oráculo, não tem corpus e não tem referência, você está pagando força bruta em dólar, com regressões no caminho, e o teto aparece.

E quando a força bruta vence, dá pra medir o tamanho da tentativa e erro. Dois casos recentes que eu já cobri em detalhe aqui no blog:

• A prova de Navier-Stokes da OpenAI: cerca de 10 mil agentes rodando em paralelo por 88 horas, queimando na casa de 130 bilhões de tokens de saída num único problema. O Noam Brown, da OpenAI, confirmou que o resultado “custou milhões”, e a New Scientist estimou uns US$ 15 milhões a preço de tabela. E nem essa montanha de compute partiu do zero: a prova se apoiou no maquinário que matemáticos humanos publicaram ao longo de décadas atacando o problema e os problemas irmãos. Sem o mapa dos humanos e sem o orçamento da OpenAI, não tem prova.
• O incidente da Hugging Face: a reconstrução forense contou ~17.600 ações de atacante até os agentes conseguirem executar código em 41 servidores de produção da Hugging Face e pegar root; de quebra, no ambiente da própria OpenAI, leram 956 segredos do gerenciador de segredos da empresa. Não foi um insight brilhante de um lance só: foi um enxame executando tentativa atrás de tentativa, com verificação automática dizendo o que colou. A “inteligência” da manchete é volume.

É esse o tamanho da conta quando você força o modelo pra fora do território do treino: tentativa e erro em escala industrial, sem garantia nenhuma de que a busca acha o que você precisa. E quem pode assinar esse cheque é meia dúzia de empresa no mundo, nível OpenAI e Anthropic, com orçamento praticamente ilimitado de compute. Pro Zé da esquina, com cartão de crédito e uma API key, o teto chega muito, muito antes.

Mas tentativa e erro não é aprendizado novo?

Aqui mora uma confusão que eu vejo toda hora, e vale desfazer porque ela contamina a interpretação de tudo que eu escrevi até agora.

Quando você lê que a Anthropic tem data centers do tamanho de cidades, dá a sensação de que existe uma IA gigante usando aquelas máquinas todas ao mesmo tempo, pensando, acumulando experiência a cada interação. A realidade é bem mais medíocre que isso.

Um modelo tipo Fable ou Astra é um arquivo de computador. Arquivo estático, nem banco de dados é: depois que o treinamento e o pós-alinhamento terminam, aquele arquivo é trancado e fica read-only. O que roda no data center são cópias desse arquivo. Cada usuário que consome o modelo está executando uma cópia dele num servidor diferente, isolada das demais, sem colaborar com nenhuma. A sua sessão não conversa com a sessão de ninguém, e nada do que acontece nela volta pro arquivo original.

Aprendizado novo só entra num lugar: na próxima leva de treinamento. Quando a Anthropic tinha o Opus 4.7 e lançou o 4.8, foi ali que conhecimento novo foi assado no modelo, num processo que custa milhões e leva semanas. Fora disso, o arquivo não muda um byte.

Seu agente queimando milhões de tokens em tentativa e erro está contribuindo exatamente zero de aprendizado novo pro modelo que ele usa.

Aquela maratona de 176 commits do nes-to-sms? Do ponto de vista do modelo, não aconteceu. O Opus que rodou o último commit sabia exatamente o mesmo tanto que o do primeiro. Quem aprendeu alguma coisa fui eu, não ele. E é por isso que a metáfora do “estagiário que aprende com o tempo” está errada: estagiário acumula. Modelo não. O que acumula na maratona é o seu contexto, suas notas, seu CLAUDE.md, seus testes. O ativo que você constrói é seu, e evapora se você não documentar.

Essa é também a resposta pra quem acha que “é só deixar o agente rodando que ele aprende o domínio”. Ele não aprende domínio nenhum: ele explora o espaço com o conhecimento congelado do dia do treino, e no dia seguinte acorda com amnésia. Se o domínio não estava no treino, cada sessão sua recomeça do zero absoluto, e toda a inteligência de navegação tem que vir de você de novo.

“Mas e se a IA treinar a IA?”

Essa é a pergunta seguinte do amador, e ela parte de uma premissa errada: a de que isso seria novidade. IA treinando IA existe há décadas e tem nome: aprendizado por reforço. O AlphaGo já fazia isso em 2016, jogando milhões de partidas contra si mesmo. O AlphaZero, em 2017, levou a ideia ao limite: aprendeu xadrez, shogi e Go partindo do zero absoluto, sabendo só as regras de cada jogo, e chegou a nível sobre-humano em questão de horas de self-play, sem ver uma única partida humana.

LLMs também já usam reforço. O RLHF que transforma um modelo base em assistente é aprendizado por reforço, e a geração dos modelos de raciocínio levou isso adiante: o DeepSeek-R1-Zero mostrou em janeiro de 2025 que comportamento de raciocínio (auto-verificação, reflexão, cadeias longas de pensamento) emerge de RL puro, sem fine-tuning supervisionado. É o AlphaZero aplicado a matemática e código.

Agora repare no que esses exemplos têm em comum: só funciona onde existe recompensa verificável e barata. Jogo tem placar, matemática tem prova, código tem teste. Fora desse território não tem de onde tirar o sinal de recompensa. É o mesmo oráculo do steelman, só que institucionalizado: eficaz, caríssimo e nichado. O AlphaZero joga Go melhor que qualquer humano que já existiu e não sabe fazer absolutamente mais nada.

E tem o detalhe que derruba a pergunta por completo: todo esse aprendizado acontece no laboratório, durante o treino. O AlphaZero que o DeepMind mostrou pro mundo já era um artefato congelado. O R1 que você baixa é um arquivo estático igualzinho aos outros.

IA treinando IA produz um arquivo novo. O arquivo, uma vez lançado, continua sem aprender nada.

Ou seja, a resposta mais sofisticada pra objeção não enfraquece a conclusão da seção: reforça. E o mercado já sabe disso. Desde o fim de 2024 os laboratórios admitem, em on e off the record, que os retornos de escala estão encolhendo: a Reuters reportou em novembro de 2024 que OpenAI, Google e Anthropic colhiam ganhos menores que o esperado no pre-training, com o Orion da OpenAI decepcionando a ponto de ser rebaixado de GPT-5 pra GPT-4.5. O Ilya Sutskever, o cara que basicamente inventou a tese do scaling, subiu no palco do NeurIPS 2024 pra declarar que “pre-training como conhecemos vai acabar”: os dados públicos são combustível fóssil, e a gente já raspou o fundo. Os ganhos de RL pós-treino são reais, mas incrementais. A era do salto de ordem de grandeza a cada geração ficou pra trás.

Onde isso deixa a profissão

A pergunta que motivou esse artigo é a que eu ouço toda semana: “LLM vai substituir programador?” Minha resposta ficou mais precisa depois desses meses: vai substituir a parte do trabalho que é reprodução.

E essa parte é grande. Formulário, relatório, CRUD, integração com API documentada, migração de framework: isso tudo já existe mil vezes no treino, e a máquina reproduz melhor que a maioria dos humanos. Quem só faz isso está mesmo com os dias contados.

Mas o trabalho que é de verdade novo continua humano:

• o sistema que ninguém construiu;
• o domínio sem documentação;
• o código proprietário que você não pode mostrar pro modelo;
• o problema em que você não sabe nem escrever o teste que define “certo”.

Tudo isso depende do que nunca foi publicado: a invariante que existe na cabeça de quem entende o problema, e não no fluxo de instruções.

Confesso que teve uma hora em que eu achei que a conta ia fechar pro lado do legado: finalmente uma ferramenta capaz de dar conta do COBOL que assombra banco e governo até hoje. Depois desses meses, acho que esse problema vai demorar muito mais do que parecia. Não existe uma comunidade open source gigante de COBOL. Quase todo esse código é privado, e privado de verdade: banco, seguradora, governo. Não tem material de treino, ou tem muito pouco. O modelo não sabe o que fazer com código que nunca viu, e COBOL de produção é quase tudo código que ele nunca viu.

Fecha o raciocínio: LLM consegue replicar o que é aberto, mas não adivinha o que é privado. E aí volta a hipótese da introdução. Se esses modelos são bons em código, é porque décadas de comunidade open source lutaram pra manter código livre, público e reutilizável, e os provedores treinaram em cima desse patrimônio sem pagar um centavo de licença por ele. O mínimo que a indústria de IA deve ao mundo é reconhecer isso: a capacidade dela é, em grande parte, a nossa generosidade compilada.

A ironia final: o programador que sobrevive é justamente o que sabe construir oráculo, definir teste, caçar referência obscura e reconhecer quando o agente começou a girar. Ou seja, a habilidade que a máquina mais precisa de você é a que ela menos consegue aprender com o treino dela. Por enquanto, isso não é um emprego ameaçado. É um emprego diferente.

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.

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

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)

DESCRIÇÃO

Errata:

• em 53:46 eu falo “1 1” mas era “aa”

Se tem um tema que eu queria fazer desde que abri o canal é apresentar algumas das fundações da computação, tanto do ponto de vista de história e da evolução, mas principalmente dos fundamentos básicos que eram vários 60 anos atrás e ainda são válidos até hoje.

O video de hoje vai abrir com um tema de videogames, mas vamos descer bem fundo no cérebro do Nintendinho pra criar um vocabulário que eu vou usar na Parte 2, quando de fato vou mexer num emulador de Nintendo. E esse vocabulário vai servir não só pra videos futuros meus como pra tudo que você for fazer em computação. Esta é a base, sem esta base tudo que você tentar aprender de avançado depois vai ser mais difícil.

Infelizmente é muito difícil empacotar estes temas de uma forma que não seja maçante. Espero ter conseguido pelo menos interessar vocês no assunto.

Canais:

• Ben Eater: https://www.youtube.com/user/eaterbc
• Retro Game Mechanics Explained: https://www.youtube.com/channel/UCwRq…

Playlist:

• Build a 65c02-based computer from scratch: https://www.youtube.com/watch?v=LnzuM…
• Building an 8-bit breadboard computer!: https://www.youtube.com/watch?v=Hyznr…

Links:

• Ben Eater “Build a 6502 Computer” Kit: https://eater.net/6502
• VASM A portable and retargetable assembler: http://sun.hasenbraten.de/vasm/

SCRIPT

Olá pessoal, Fabio Akita

Se você está cético sobre este episódio porque não tem nenhum interesse por videogames, não se preocupe, a intenção de hoje é apresentar muitos dos conceitos fundamentais pra você entender melhor o que é programação. Este vai ser mais um daqueles episódios que você vai ficar se perguntando “mas onde diabos esse japonês quer chegar” mas com paciência as peças se encaixam. E já aviso que esse também vai ser um vídeo bem complexo. Pausa, volta e assiste de novo. Não é um conteúdo que dá pra entender 100% assistindo só uma vez.

Com tudo isso fora do caminho vamos lá. Quem me acompanha nos Instagram da vida sabe que um dos meus hobbies favoritos é jogar videogames. Além dos jogos Triple A eu também gosto bastante de voltar aos jogos da minha infância, de Alex Kidd a Sonic a Super Mario. Eu não faço coleção de cartuchos porque não teria espaço físico pra tudo. São milhares e milhares de jogos. Felizmente hoje é muito simples. Basta baixar uma das dezenas de emuladores e carregar a ROM dos games. Por exemplo, posso carregar este Retro Arch que tenho no meu desktop e boom, Super Mario.

A idéia deste video veio quando eu tava assistindo dois dos meus canais de YouTube favoritos. O primeiro é o Retro Game Mechanics Explained. O cara é muito bom. Por exemplo, pra quem gosta do Pokemon original de GameBoy, ele explica bit a bit o mistério do elusivo MISSINGNO, recomendo que assistam. Mas o video que eu tava assistindo me relembrou de outro dispositivo que existia durante os anos 90.

Muitos de nós gostamos de games só que mais como passatempo, e não somos tão obsessivos em completar 100% dos jogos ou fazer speedruns pra bater o recorde de quem acaba no menor tempo, e só porque um jogo é antigo não quer dizer que é fácil. Muitos tinham dificuldade maior e mais brutal que jogos da atualidade. Tentem jogar coisas como o Megaman original ou Battletoads do Nintendinho pra ver o que quero dizer. Fora que antigamente nem todo jogo tinha uma bateria pra salvar o progresso, então se dava game over você realmente tinha que recomeçar do zero.

Então surgiram dispositivos que possibilitavam “cheats”. Quem joga online conhece essa palavra e os diversos software anti-cheat pra evitar que jogadores trapaceiem com hacks. Anti-cheats que vira e mexe criam polêmica, como no recente caso do jogo Valorant, cujo software anti-cheat foi acusado de causar até estragos de hardware.

Enfim, nos anos 90 a tecnologia era mais simples. Existiam diversas marcas diferentes como Action Replay, Game Shark ou o mais famoso, o Game Genie. Funcionava assim, você plugava o cartucho na parte de cima e daí plugava o conjunto no console. O Game Genie ficava entre o cartucho e o console. Ele engana o console. Por exemplo, o console pergunta pro cartucho, com quantas vidas que o Super Mario tem que começar? Daí tá gravado em algum lugar no cartucho o número 3, mas aí se você colocar um código mágico no Game Genie, como AATOZE, ele devolve 9 pro console no lugar de 3 e o jogo começa com 9 vidas.

Eu vou explicar o game genie em mais detalhes na Parte 2 deste video, de uma forma complementar que o Retro Game Mechanics explica. Mas antes de chegar nisso vou fazer uma longa tangente hoje com meu segundo canal favorito, o Ben Eater. O canal do Ben é hardcore, ele explica todas as fundações eletrônicas da computação, em particular exatamente a arquitetura por trás de computadores como o nintendinho. Eu vou usar muito material do canal dele e condensar num único video pra tentar fazer vocês finalmente enxergarem a mulher de vermelho no código do Matrix.

(intro)

O nintendinho roda o famoso processador MOS 6502 de 8-bits, derivado do desenho do Motorola 6800 e fabricado pela MOS Technologies a partir de 1975. Esse processador foi usado não só no nintendinho mas em dezenas de outros consoles e computadores pessoais dos anos 80 incluindo coisas como o lendário Apple II, o avô dos Macintosh, ou o concorrente Atari, e os britânicos Commodore e BBC Micro. Ele foi um dos componentes que ajudou a iniciar a revolução dos computadores pessoais dos anos 80. Exatamente por isso é um bom ponto de partida pra entender a computação de hoje em dia.

Apesar de internamente processar em 8-bits, ele possui uma interface de comunicação de 16-bits. 16-bits em hexadecimal, que são 2 bytes, se representa com 4 caracteres. Já um valor de 8-bits, ou 1 byte, se representa com dois caracteres. Como o código mágico AATOZE que falei tem 6 caracteres então já começa a ficar fácil de entender o que está acontecendo aqui. Muito provavelmente é um endereço de 16-bits e um valor de 8-bits, exatamente o que o 6502 entende. E de fato esse código se transforma no endereço 906A e no valor 09, que dá as 9 vidas ao Super Mario.

É importante que vocês entendam como enxergar binários e hexadecimais. Se você já sabe disso, pode pular pra este tempo aqui em baixo. De qualquer forma, tudo em computação é binário. Este vídeo que você tá assistindo é uma stream de bits. O jogo do Super Mario é um punhado de bits. Um arquivo de texto ou código em Javascript é um arquivo de bits. Muita gente acha que arquivos texto e binário são diferentes. Mas não, ambos são binários. A diferença é como você representa esse binário depois de abrir, pra mostrar pro usuário.

Deixa eu mostrar. Na maioria dos sistemas operacionais existem editores de texto, seja o miserável Notepad no Windows ou o moderno VS Code. Se eu abrir um arquivo que contém texto, qualquer um vai abrir sem nenhum problema. Mas se no mesmo editor eu tentar abrir o arquivo da ROM do Super Mario, vai aparecer esse monte de lixo na tela. Isso porque um editor de textos só sabe interpretar um sub-conjunto de binários que, por convensão, representa letras, números e símbolos.

Se eu abrir um editor e escrever a palavra “Hello World” e gravar, podemos abrir o binário cru com um visualizador de binário, como o comando xxd -b e pronto, isto é o que tá gravado no arquivo. Veja este primeiro bloco de 8 bits é a letra “H”, vejam estes dois blocos repetidos, são os dois “L” e assim por diante. Claro que ler bit a bit assim é bem inconveniente, então podemos pedir pra ferramenta converter esses bits em uma representação hexadecimal, rodando o mesmo comando xxd sem o parâmetro -b temos os seguite.

Agora sim, aquele bloco de bits é o número 48 em hexadecimal, que não é a mesma coisa que 48 em decimal. Já vou explicar. Essa é a letra “H”. Depois temos 6c e 6c que obviamente é o código hexadecimal pra letra “L”. E assim por diante. Quem disse que 48 é H ou que 6c é L? É uma convenção internacional conhecida como Unicode. É um conjunto de tabelas e regras que mapeiam cada caracter em todas as línguas num código de 1 ou mais bytes. Emojis também, cada um tem seu código. Tudo é número. A tabela mais antiga e mais simples que ainda acabamos usando é a ASCII.

Pra quem não sabe, o que chamamos de “ROM” em retro gaming são os bits que vem gravados num cartucho e que extraimos pra dentro de um arquivo, é isso que um emulador de nintendinho lê no lugar do cartucho de verdade. Com o mesmo comando xxd mas passando com um pipe pro more pra podermos ver as primeiras linhas, temos o seguinte. Deixa eu explicar melhor o que é essa representação do comando xxd. Aliás, existem diversas ferramentas que conseguem abrir binários, um dos mais usados é o hexdump mas prefiro mostrar o xxd pra dar outra alternativa. A diferença dos dois é que o hexdump só mostra o binário na forma de hexadecimal, o xxd faz a mesma coisa mas consegue também gravar de volta pro binário. Por isso se somar o xxd com o vim você consegue editar qualquer binário diretamente.

Bom, a coluna da direita são os endereços, seguido de uma linha de 16-bytes organizados em grupos de 4 letras, cada um com 2 bytes, num total de 8 blocos de 4 letras. Cada 1 letra é um byte em hexadecimal. Você começa no endereço 0 e vai contando até 15 que é a letra F, dai na segunda linha o endereço começa em 16 que é o hexadecimal 10. Conta mais 16 elementos, agora chega no elemento 32 que em hexa é 20 e assim por diante.

Na 3a coluna ele mostra “.” (ponto) quando o byte não tem representação em texto. Quando tem, ele mostra o que seria o código na tabela ASCII. Vocês vão notar que nos primeiros 3 bytes temos aparecendo o texto “NES” nessa terceira coluna. NES é como o Nintendinho é chamado nos Estados Unidos, o Nintendo Entertainment System. Obviamente não é coincidência, todo cartucho distribuídos nos Estados Unidos começa com esse código.

Isso é só uma etiqueta arbitrária pra facilitar identificar o que é esse binário. Muitos outros formatos de arquivo fazem a mesma coisa. Se eu abrir uma imagem formato PNG com o xxd olha só, aparece um código 89 e depois os códigos ASCII que forma a palavra PNG. Se abrirmos uma imagem JPEG todos começam com FF D8 FF E0 e alguns bytes pra direita aparece JFIF que é sigla pra JPEG File Interchange Format. Se listar um binário compilado com extensão .class de Java olha o que aparece. O identificador de todo binário Java é o hexadecimal que forma as palavras “cafe babe”.

Se não ficou claro, o que estamos vendo na tela com o xxd não é o binário de verdade, assim como um editor de textos como Notepad mostra uma representação em forma de texto legível dos números binários reais, o xxd mostra os binários de uma forma que seja fácil da gente conseguir acompanhar. Essas colunas da esquerda e direita não existem. E não existe quebra de linha. Um binário são os bits escritos um atrás do outro numa única linha contínua até o fim. Pense num arquivo binário como um rolo de fita. Entendem agora porque você vê computadores antigos gravando dados num rolo de fita? Ou num cassette? É assim mesmo que funciona até hoje. Se você já programa em alguma coisa, pense num binariozão com um Array.

Existem vários sites e videos que ensinam em detalhes como converte e faz contas em binário e hexadecimal então vou resumir hiper resumido. Basicamente sistema decimal representamos números que vão de 0 a 9. Em hexadecimal representamos números indo de 0 a F, onde A é 10, B é 11, até F que é 15. Todas as regras aritméticas de soma, subtração etc funcionam igual. Quando você faz F + 1, coloca zero e sobe 1, daí o hexadecimal 1 0 equivale a 16. Sim, você precisa se acostumar a manipular números em hexadecimal. Até mesmo quando trabalha com front-end e CSS sabe que as cores são mapeadas em números hexadecimais e você faz conta com elas pra fazer degradê de cores por exemplo, você subtrai pra tornar todas as cores mais escuras ou faz soma pra elas ficarem mais claras.

Voltando pro cabeçalho do Java, o primeiro “C” não é a letra do alfabeto “C” e sim o número 12 em hexadecimal. Já brincaram com calculadora de cabeça pra baixo? Por exemplo, você digita 07734 e vira a calculadora e temos “HELLO” ou digitamos 376006 e de cabeça pra baixo temos Google. Todo mundo já brincou disso e o CAFE BABE do java é parecido só que como em hexadecimal temos de verdade as 6 primeiras letras do alfabeto, dá pra representar palavras. Mas é só uma brincadeira mesmo.

Agora, voltando ao binário. Computar em bits tem algumas vantagens pro computador fazer alguns tipos de conta. Em particular multiplicar por 2 e dividir por 2. Pegue o número 4 que em 4-bits seria 0 1 0 0. Se eu mover 1 pra esquerda vira 1 0 0 0 que é 8. E pra dividir? Oposto, só mover tudo pra direita então o 4 que é 0 1 0 0 vira 0 0 1 0 que é 2. Estou simplificando, claro, porque se dividir um número ímpar, eu não vou ter o resto assim. Aliás, isso que eu falei de mover pra esquerda ou direita é o que se chama de operador bitwise em qualquer linguagem moderna, o shift left que é « e shift right que é ».

Se abrir qualquer navegador e inspecionar um elemento, você abre o tal console de Javascript. E aqui podemos exercitar o que eu acabei de falar. Por exemplo, se eu quiser representar um número em binário começo digitando 0b daí por exemplo 0 1 0 0 que é 4. E é exatamente isso que ele mostra. Vou criar um texto chamado “palavra” e dentro colocar “hello world” que tem 11 letras. Se eu quiser pegar a décima primeira letra dessa palavra posso fazer palavra[10] e 10 porque em programação tudo começa de 0. Então 0 é ‘h’, 1 é ’e’ etc e a posição 10 é a letra “d”.

Podemos chegar na mesma letra se fizermos palavra[0x0A] lembram que eu falei que A em hexa é 10? Pro Javascript saber que isso na verdade é um número colocamos 0 x antes. Pra ficar mais hardcore podemos fazer palavra[0b1010] e esse 0 b é pro Javascript saber que é um número binário. Tanto o 0xA quanto 0b1010 são formas diferentes de escrever o mesmo número 10. É tudo o mesmo número, só que podemos representar de formas diferentes. Internamente sempre é tudo um número binário. As linguagens de programação só facilitam e nos deixam usar números em decimal ou mesmo letras.

Se eu fizer 10 shift right 1 é divisão por 2, e eu posso fazer palavra[0xA >> 1] onde A é 10 em hexa, shift right 1 que é divisão por 2 e ele devolve espaço que é o que tem na posição 5 naquele hello world.

Entendido isso, vamos pular pra outro conceito. Todo mundo ouve falar sobre computadores 32 bits ou 64 bits. Se você pensar em base decimal dá impressão que estamos só dobrando de 32 pra 64. O que isso significa? Em resumo significa que internamente o computador consegue fazer cálculos e processar números de 32 ou 64 bits de comprimento de uma só vez. Até agora eu fiz exemplos com números de 4 bits que dá pra contar só até 255. Lembra que eu falei que cada 1 bit que eu adiciono pra esquerda eu estou multiplicando o número todo por 2? Então 5 bits já é o dobro de 4 bits. 6 bits é o dobro de 5 bits. 33 é o dobro de 32 bits e 64 é 32 bits ao quadrado. A metade de 64-bits não é 32 e sim 63-bits.

Em 32 bits podemos representar até quase 4.3 bilhões. Em 64-bits podemos representar um número gigante 1.8 x 10 elevado a 19, ou seja, um numerozão de 19 casas. É a casa dos quintilhões. Entendam essas relações de dimensão. A vantagem de usar hexadecimal é que esse numerozão de 64-bits pode ser representado por 16 caracteres. Mesmo que você ainda esteja coçando a cabeça neste ponto, veja que não é coincidência que o numerozão de quintilhões de 64-bits fica bonitinho tudo com FFFFF… em hexa. Isso porque propositalmente usamos números derivados da base 2. Por isso um megabyte não é 1000 bytes e sim 1024 bytes. Em hexa seria 4 0 0. Tendemos sempre a usar números que são redondos em hexadecimal.

De qualquer forma 64-bits é um número difícil de visualizar na cabeça. Não se preocupe, eu acho que até o final do video vocês vão começar a se acostumar com isso. Mas eu acho que a forma mais fácil de entender como as coisas funcionam hoje é ver como funcionava ontem, porque o que temos hoje são mais ou menos camadas extras em cima da mesma base de antigamente. Componentes mais modernos, métodos de fabricação melhores, mas a fundação ainda é exatamente a mesma. Por isso quero voltar pros anos 70, mais especificamente pra 1975 e olhar mais de perto o cérebro do nosso nintendinho.

Se abrirmos o nintendinho, esta é a placa mãe com os diferentes chips. Mas por agora vamos nos focar neste aqui, o MOS 6502 que eu falei antes. Se eu quisesse mostrar o nível zero de verdade da fundação, precisaria começar com o básico em eletrônica. Mas eu também só sei o básico. É o que você aprenderia em Engenharia Elétrica ou Engenharia da Computação e não em Ciências. Mas eu quero resumir pelo menos, e pra isso resolvi pegar emprestado material de outro dos meus canais favoritos, do Ben Eater, que eu falei no começo do video.

Uma das playlists dele mostra como você constrói um processador de 8-bits do zero. E outra playlist dele, por acaso é como fazer um hello world com o 6502, o mesmo CPU do nintendinho. Só pra mostrar um Hello World ele levou meses produzindo uns 9 videos com mais de mais hora cada. São horas de video e eu vou resumir tudo em alguns minutos, então depois eu recomendo assistirem os videos dele com calma. Como eu disse daria pra descer no nível da física elétrica mas eu acho que a partir do nível que eu vou mostrar neste video é o mínimo suficiente pra se ter um desenho na cabeça pra conseguir visualizar o que um programa de fato está fazendo no hardware. Eu acho muito mais difícil aprender a programar sem entender o que acontece por baixo.

Quem está iniciando em eletrônica hoje em dia tem bastante material da hora pra treinar. Uma dessas ferramentas se chama breadboard, que é uma placa feita pra montar protótipos de circuitos eletrônicos sem precisar ficar soldando os componentes, você só encaixa os chips e fios na placa, liga a força, normalmente de 5V e pronto. Fazer circuitos integrados é literalmente programação de baixo nível. Ele inclusive vende kits com todos os componentes que você vai ver. Se tiver como investir, recomendo como bom aprendizado. É como se fosse brincar de Lego, mas bem mais interessante.

A lógica por trás de linguagens de programação modernas seguem os mesmos princípios da lógica em nível de hardware. Se você já ouviu falar isso de “ter que saber lógica pra programar” mas nunca entendeu onde começar, comece entendendo portas lógicas e máquinas de estado.

https://www.youtube.com/watch?v=LnzuMJLZRdU (part 1)

Pra começar veja o diagrama do 6502. Todo chip tem essas perninhas ou pinos, nelas, você liga ou desliga corrente em alguns pinos pra se comunicar com o chip, e os traços recebem corrente quando o chip quer enviar dados. Numa placa de verdade com solda e tudo, o que liga um pino de um chip a outro são traços condutores. Num breadboard se usa fios de metal mesmo pra facilitar. Agora vamos ver o diagrama de pinos, e a primeira coisa que quero chamar a atenção são esses pinos que vão de A0 até A15 e os pinos que vão de D0 até D7. Não é coincidência que são 16 pinos A e 8 pinos D.

Eu disse que o 6502 é um processador de 8-bits então quando você quer ler o resultado de algum processamento que ele fez, serão valores de 8 bits de comprimento, e eles vão trafegar por esses pinos D0 até D7. E quando o processador quer enviar um endereço pra buscar na memória RAM por exemplo, ele pode mandar um número de até 16-bits, que trafega por esses pinos de A0 até A15. Digamos que eu quero mandar o número em hexa a9 pelos pinos de dados. Em binário seria 1 0 1 0 1 0 0 1, e cada um desses bits vai em um pino de D9 a D0.

Cada componente que coloca no Breadboard sempre vai ligar um pino de força e outro pino em ground ou Terra, é como você passa energia pro componente. Daí ele vai ligar outros pinos, por exemplo pra habilitar a CPU, outro pra conectar no clock. Um clock é exatamente o que o nome diz, é um componente com um cristal de quartzo que oscila, enviando um sinal elétrico numa frequência precisa e constante. Todo componente que processa alguma coisa no computador precisa estar ligado no mesmo clock pra tudo funcionar sincronizado. Um computador é uma grande orquestra de componentes e o clock é o maestro. Muitas instruções do CPU demoram mais de um clock, mas tudo é alinhado de acordo com a frequência desse clock. A menor unidade de processamento num computador é esse pulso que eu vou ficar chamando de clock durante o video.

Um clock de sistema convencional é pequeno como esse de 1 megahertz, ou 1 milhão de pulsos por segundo, que o Ben está mostrando, mas ele vai usar um mais feinho que ele mesmo construiu em outro video. A vantagem é operar mais devagar e dar a opção de poder pausar o clock e manualmente soltar um pulso de cada vez. todo componente do computador, incluindo a CPU, vai pausar junto e rodar um ciclo de clock de cada vez. Um processador 6502 original não suportava uma pausa dessas, mas esse que ele está usando é uma versão mais moderna que é fabricado até hoje e tem mais funcionalidades.

Continuando ele precisa ligar o pino que indica pro CPU rodar que é o RDY ou ready, depois o pino que liga com um botão de reset que é o RESB, daí liga o pino de clock e ligamos a placa do clock com força e terra na placa principal.

Só de fazer isso e ligando a placa principal numa tomada de 5V a CPU já tá funcionando e fazendo alguma coisa. Uma forma simples de monitorar pinos de dados é ligar LEDs direto em cada um deles, por exemplo ligando os pinos A0 a A4 em 5 LEDs pra gente ver se tem alguma coisa acontecendo. E de fato tem alguma coisa, mas bem aleatório.

Pra monitorar melhor, o Ben montou um sistema de monitoramento com Arduino em outro video e vai usar aqui. Um Arduino é um microcontrolador que tem algumas dezenas de pinos que servem tanto como entrada de dados ou saída. Então ele vai ligar primeiro os pinos de A0 a 15 da CPU com os pinos 22 a 52 no Arduino. O Arduino é programável, e podemos escrever programinhas simples e enviar pra ele executar. E é isso que o Ben vai fazer. Não se preocupe se você nunca viu um programa de Arduino, o código dessa demonstração é hiper simples, só prestar atenção que dá pra entender sem nenhum problema.

Primeiro vamos declarar uma lista com quais pinos do Arduino vamos trabalhar, e vai ser de 22 a 52. Daí fazemos um loop lendo número a número e mandando um comando pra dizer que vamos ouvir o que vier nesse pino, ou seja, eles são INPUT Agora fazemos outro loop pela mesma lista pra ir lendo o que vem em cada pino. Essa função devolve true ou false então quando vier true devolvemos o número 1 e quando vier false devolvemos 0 e escrevemos na tela Daí escrevemos uma quebra de linha com print line e repete tudo de novo. Finalmente não podemos esquecer de declarar a velocidade que vamos trafegar dados que vai se 57600 bauds, não se preocupe com esse número mágico.

Transmitimos o programa pro Arduino via essa interface, e abrimos o Monitorador de Sistema pra ver o resultado desse programa rodando. E vemos um monte de números binários, 16 bits no total que é o número de pinos que estamos monitorando. Entenda o que está acontecendo, o CPU está processando alguma coisa e setando bits nos pinos de endereço. Esses pinos estão ligados no Arduino que está lendo esses bits. Daí estamos num loop infinito puxando esses bits constantemente e imprimindo na tela. Mas não estamos ligados ao clock então ele vai ficar que nem doido lendo e imprimindo sem parar, sem qualquer ordem. Pra melhorar podemos sincronizar o Arduino ao mesmo clock também.

Eis um exemplo de porque os componentes precisam estar sincronizados com o clock. O Arduino não sabe quando ele precisa ler dos pinos, então fica lendo que nem doido e não faz sentido nenhum. Ligando ao clock, ele vai ler só uma vez a cada pulso. Entao em vez de fazer um loop infinito vamos ligar o código de leitura ao evento de um pulso do clock. Assim, se pausarmos o clock o programa também vai pausar, porque nenhum evento vai ativar o código de leitura.

Podemos ligar o clock em qualquer lugar, mas o Ben decidiu ligar no pino 2 do Arduino e com isso também precisamos configurar o pino 2 como entrada, pra ler o pulso que vier de lá.

A forma de ligar um evento no Arduino é criando uma interrupção pro clock. Quando o clock pulsa e enviar um sinal elétrico no pino 2, isso vai interromper o sistema e chamar essa função onClock que estamos definindo. Se você já programou front-end ou javascript já viu o mesmo conceito que é orientação a eventos. O conceito existe desde a invenção dos computadores, só pra saber.

Agora movemos o código do loop de leitura pra dentro do evento onClock.

Aproveitamos pra declarar também os pinos de 39 a 53 onde vamos ligar os pinos de dados D0 a D7 do CPU, pra poder monitorar o que acontece lá também.

Agora copiamos o mesmo código que lê dos pinos de endereço da CPU pra ler os pinos de dados da CPU, é o mesmo loop, só muda os números dos pinos.

Também copiamos o mesmo código de inicialização pra configurar os pinos 39 a 53 como INPUT pro Arduino receber bits.

E copiamos o mesmo código no evento de onClock pra ler os pinos de dados e imprimir na tela. Só que ficar mostrando os 24 bits de zeros e uns dos pinos não ajuda muito pra saber o que tá acontecendo. Mesmo gente experiente não consegue ler um monte de blocos de bits e entender exatamente o que tá rolando.

Então vamos converter de bits pra hexadecimal e imprimir do lado. Pra fazer isso inicializamos uma variável com número 0, dai pra cada pino que lemos nesse for, damos um shift pra esquerda e adicionamos o novo bit no final, faz shift pra esquerda, adiciona no final, faz shift e adiciona, e é assim que se monta um número lendo do binário.

Fazemos a mesma coisa com os pinos de dados.

Agora vamos usar uma função que é comum em quase todas as linguagens que serve pra formatar números em strings. Queremos formatar o número em uma string hexadecimal de 4 bytes pra representar o endereço de 16-bits, e como 2 bytes o valor de dados.

Os pinos de dados podem tanto receber dados quanto enviar dados e pra isso serve esse outro pino do lado, pra dizer qual o modo, se é read ou write. Então ligamos ele no pino 3 do arduino pra sabermos se o CPU está querendo ler ou escrever.

Como fizemos com os outros pinos, declaramos no codigo como 3 que é onde vamos ligar o pino RW do CPU. Dizemos ao Arduino pra ler desse pino, ou seja, input. Quando ler do pino, se devolver true escrevemos “r” pra leitura, se devolver false, escrevemos ‘W’ pra indicar write.

Pronto, agora iniciamos o clock. No monitor podemos ver que o CPU tá cuspindo alguma coisa nos pinos de endereço e de dados mas tá difícil de entender o que tá acontecendo. Isso porque não tem nada enviando dados ao CPU, daí quando ele tenta ler alguma coisa dos pinos de dados vem lixo, e tenta rodar esse lixo e fica soltando lixo, por isso parece aleatório.

Agora que temos o CPU ligado e monitorado, vamos enviar o primeiro dado de verdade pra ele. Lembrem-se, enviar ou receber dados é literalmente aumentar ou diminuir voltagem nos pinos. Envie 5 volts no pino D0 e o CPU vai ler o bit 1 do pino D0, corte a voltagem do pino D1 e o CPU vai interpretar como 0 no pino D1. Então se quisermos mandar um valor constante nos pinos de dados, podemos ligar resistores. Se quisermos o bit 0 ligamos o resistor no terra, se quisermos o bit 1 ligamos o resistor nos 5 volts da placa. E com isso configuramos o binário 1 1 1 0 1 0 1 0.

Voltando ao monitor, resetamos e veja que na última coluna vem ea que é o hexadecimal do binário que acabamos de configurar. Como não mandamos o CPU gravar, o pino de Read/Write tá só Read, e note como nos pinos de endereço, a cada clock ele vai incrementando o endereço. Vamos ver com mais calma passo a passo.

Esse clock simples do Ben tem a opção de pausar e manualmente soltar um pulso de clock de cada vez clicando num botão. Segundo o manual do processador os primeiros 7 clocks é uma rotina de inicialização do CPU então podemos ignorar.

Logo em seguida o contador de programa carrega o vetor de reset dos endereços FFFC e FFFD. Como o único dado que conectado é o 0xEA dos resistores, ele vai ler o endereço 0xEA e 0xEA e montar o endereço 0xEAEA que é pra onde o CPU vai procurar a primeira instrução do programa pra executar.

Ele vai colocar 0xEAEA nos pinos de endereço e a única resposta que vai ter continua sendo 0xEA, de novo porque é o único dado fixo nos pinos de dados. O Ben escolheu 0xEA de propósito porque é um opcode válido do 6502, se olharmos qualquer documentação dessa CPU vamos descobrir que é o opcode NOP ou No operation, que é literalmente um comando que não faz nada por 2 ciclos.

Quando o primeiro NOP terminar, o contador de programa aponta pro próximo endereço que é 0xEAEB e de novo, nos pinos de dados só vai ler só 0xEA. Daí o CPU executa NOP e o contador de programa agora vai pra OxEAEC e assim por diante infinitamente.

Até aqui você acabou de aprender alguns dos principais elementos que tem em qualquer CPU. Primeiro que ele tem pinos pra enviar endereços, segundo que ele tem pinos pra enviar e receber dados, que ele tem um contador de programa que aponta pra endereço da próxima instrução do programa. Terceiro que instruções e dados são tudo binário, e que não existe diferença entre um byte de dados e um byte de instrução.

Mas só deixar um valor fixo com resistores não é muito interessante. Pra ficar melhor, precisamos de alguma coisa que consiga enviar uma sequência maior de bytes, formando um programa.

https://www.youtube.com/watch?v=yl8vPW5hydQ (part 2)

Pra isso o Ben escolheu uma EEPROM do mesmo fabricante desse clone de 6502 que estamos usando, pra facilitar. Vale explicar o que é isso. RAM acho que todo mundo tem noção do que é, o que chamamos de memória. Podemos escrever e ler dados da memória e quando o computador desliga o que está na RAM apaga. Daí temos ROM que é sigla de Read only memory, ou seja é uma memória que só dá pra ler o que tem dentro e não é possível sobrescrever nem apagar.

Só pra ter um modelo simplificado na cabeça, pense na ROM como se fosse uma grade. Pense em cada linha dessa grade como um endereço, de 0 até X. E digamos que cada linha dessa grade tenha 8 cruzamentos. Quando um cruzamento está aberto, podemos dizer que é o bit 1, quando um cruzamento estiver queimado, pense queimado mesmo, ou seja que não tem como recuperar e mudar o bit. Podemos dizer que é o bit 0. O conteúdo de uma ROM é fixo, não tem como regravar. Você só consegue enviar endereços e ler o que estiver nesses endereços.

Agora, EEPROM é um circuito mais complicado. Quando ligamos num computador ele simula uma ROM, ou seja passe um endereço e ele devolve um dado. Porém, usando um gravador especial, ele permite que a gente escreva nela. Na prática uma evolução desse EEPROM são chips de memória flash usados em pendrives ou SSDs por exemplo. EEPROM é sigla pra Electronically-erasable programmable ROM. Nos anos 90 eu usava EEPROMs pra gravar um boot em computadores da rede da faculdade pra bootarem dessa ROM e se conectarem na rede pra baixar o sistema operacional de verdade. Dá pra usar EEPROMs pra muita coisa. Seria como bootar de um pendrive hoje mas a vantagem na época é que era difícil de pular esse boot obrigatório.

Diferente de RAM, mesmo quando desligarmos a força, o conteúdo não vai se apagar, igual um pendrive. Tanto nos videos do Ben quanto aqui vamos ficar toda hora chamando isso de ROM porque é mais curto, mas lembre-se que é uma EEPROM. E no caso é um modelo até grandinho, de 32 kilobytes.

Se olhar o diagrama vemos que a pinagem é muito simples, ele tem pinos de IO0 a IO7 pra devolver dados e pinos de A0 a A14 pra receber endereços. E porque vai só até A14 e não até A15. Porque ele só tem 32 kbytes que é metade de 64 kbytes. Com 16-bits conseguimos contar de 0 até 64kbytes, com 15-bits, que é metade conseguimos mapear os 32 kbytes que tem nessa ROM, por isso não precisa de mais 1 bit. Tão começando a se acostumar com essa história de bits? Basta associar bit com um pino num chip desses.

Repetindo, com 16-bits podemos mapear de 0x0000 até 0xFFFF. Prestem atenção no comprimento dessas palavras. Cada dígito representa 4-bits. Cada 2 dígitos é um byte. 16-bits é a mesma coisa que 2 bytes, por isso 4 dígitos. Metade de 16-bits é só 1 bit a menos, o que nos dá os endereços de 0x0000 até 0x7FFF. Se o CPU tentar mandar um endereço de 0x8000 pra cima, o primeiro bit é ignorado e o restante é igual à primeira metade, então ele devolve a mesma coisa que devolveria com o endereço de primeiro bit 0. Por exemplo, se ele pedir o endereço 0x8004 é a mesma coisa que pedir o endereço 0x0004.

Note outra vantagem de usarmos hexadecimais. Como eu sei exatamente qual é o numero do meio entre 0 e 65353? Eu disse que pra dividir um numero por dois é só fazer shift pra direita, daí 1111, por exemplo, vira 0111. E esse é o numero do meio. E em hexa? qual a metade de F? É 7 porque F é 15, então metade de FFFF é 7FFF. Que é até onde vai o endereço nessa ROM. Tão vendo porque usamos hexa? Com decimal não é intuitivo de trabalhar. Aliás, em decimal, 7FFF em hexa seria 32767.

Como o CPU consegue entender qualquer endereço entre 0x0000 e 0xFFFF não queremos que a ROM responda em todos. Aqui é uma decisão de engenharia, mas pra manter a lógica simples, podemos escolher fazer a ROM responder à primeira metade dos endereços ou à segunda metade. E o Ben resolveu fazer responder à segunda metade, ou seja, quando o primeiro bit do endereço for “1”. Isso porque já vimos que o CPU procura logo de cara nos endereços FFFC e FFFD que ficam na segunda metade dos endereços, logo é mais conveniente mapear direto pra lá.

Pra fazer isso funcionar queremos responder somente a endereços que comecem com primeiro bit sendo “1”, ou seja, quando o pino A15 por “1”. Aliás, se vocês não perceberam a ordem dos bits é o inverso da numeração dos pinos, acostumem-se com isso. Além disso, pra ROM ficar habilitado ele precisa receber baixa voltagem no pino de chip enable ou CE. É como um botão de liga e desliga da ROM, pra ele responder precisa estar habilitado também.

Isso é simples, colocamos um inversor entre o A15 e CE assim quando A15 estiver em alta voltagem, ou seja, representando o bit 1 - porque queremos todos os endereços que começam bom 1 -, o inversor vai reverter e enviar baixa voltagem, ou 0, pro CE que vai habilitar a ROM. O resto dos pinos podemos ligar direto da CPU pra ROM um pra um, A14 da CPU pra A14 da ROM, D0 da CPU pro IO0 da ROM e assim por diante.

Coisas como esse inversor que mencionei pode ser montado com uma porta lógica chamada NAND. Eu mencionei portas lógicas no começo do episódio de Supremacia Quântica, mas o canal do Ben tem videos detalhados explicando como transistores funcionam e como podemos montar portas lógicas como NAND num breadboard também. Pro protótipo de hoje ele usa um chip pré-pronto com portas NAND embutidas. Mas entenda que todos os chips que você estão vendo são montados com transistores. Imagine transistores como peças de lego e chips como sendo um conjunto de transistores conectados.

Como falei antes, é com a relação de como montamos circuitos com transistores que nasce a base da tal “lógica”. Como conectamos portas pra chegar no resultado que precisamos. Neste exemplo simples, queremos uma resposta sempre que o pino A15 estiver em alta, com bit 1. Mas a ROM precisa do pino CS em baixa, ou bit 0 pra ativar. Portanto, colocamos alguma coisa que inverte o sinal entre elas, um inversor ou porta NAND, e assim vamos completando o quebra cabeça.

Com a ROM conectada e pronta precisamos carregar algum programa nela. Pra isso o Ben vai usar Python pra criar um arquivo binário. Poderíamos usar o próprio xxd pra escrever na mão. Mas qualquer linguagem de programação também consegue fazer a mesma coisa, use o que você achar mais fácil, mas vamos seguir no código dele que é simples de entender.

Relembrando que antes a CPU recebia somente o valor fixo dos registradores, o hexadecimal 0xEA que é a instrução ou opcode NOP. Vamos gerar um binário que devolve exatamente a mesma coisa.

Primeiro declaramos uma variavel que vai ser um array de bytes. O conteúdo vai ser 0xEA 32 mil 768 vezes que é o total de bytes que dá exatamente 32 kilobytes.

Agora vamos abrir um arquivo pra escrever em modo binário. Com o arquivo aberto, escrevemos o array de bytes direto e isso vai gerar o arquivo “rom.bin”

Se fizermos um hexdump podemos ver que só tem 0xEA. Quando tem um asterisco é a ferramenta hexdump querendo dizer que o mesmo conteúdo se repete até o fim, que é o endereço 7FFF, o último em 32 kilobytes.

Lembrando que a CPU vai pedir endereços a partir de 0x8000 mas como a ROM não recebe o primeiro bit, só recebe os 15-bits restantes do endereço, então o endereço 0x8000 vira automaticamente endereço 0, como já expliquei.

Agora podemos pegar o arquivo binário e usar o programa minipro que envia os bits pro gravador de EEPROM. Isso é só um detalhe relevante se você for usar um gravador de EEPROM como na demonstração do Ben, mas é assim que se grava, se você tinha curiosidade.

Finalmente colocamos a EEPROM de volta na placa. E ligamos o Arduino de novo pra monitorar.

Podemos usar o mesmo script do Arduino de antes e ligar o Monitor e como esperado tá recebendo só 0xEA.

Pra ver passo a passo damos um reset e pausamos o clock. Agora podemos ir passo a passo. Os primeiros 7 clocks é a inicialização do CPU, depois disso ele lê dos endereços fffc e fffd e lê 0xea como antes. E com isso ele pula pro endereço 0xeaea e continua lendo só 0xea. Até aqui replicamos exatamente o que os registradores estáticos faziam. Vamos fazer algo um pouco mais útil.

Voltamos pro programa em python e depois de ter o array de bytes com 0xea, acessamos a posição 0x7ffc e colocamos o valor 0 e na posição 0x7ffd colocamos o valor 0x80. Duas coisas, lembram na explicação de binário que eu mostrei exemplos de Javascript, que expliquei que podemos acessar posições num array tanto com números decimais quanto com números direto em binário? Escrever 0x7ffc é a mesma coisa que escrever 32764.

E repetindo, por que 0x7fffc e não 0xfffc que é o que o CPU vai procurar? Porque a CPU vai mandar o endereço 0xFFFC pra ROM, mas o primeiro bit é ignorado? Lembra como o endereço 0x8000 vira 0x0000? Então é só fazer 0xFFFC - 0x8000 e voilá temos 0x7FFC. Não entendeu? 0xF em hexa é 15, subtrai 8 e temos 7.

Agora uma coisa que eu deixei pra explicar só agora. O CPU vai pedir o valor do endereço 0xFFFC e vai encontrar 0x00 e daí vai pedir 0xFFFD e vai encontrar 0x80 e esses dois valores vão formar o endereço 0x8000. Essa forma de ordenar os bytes “ao contrário” se chama Little endianess. Outros processadores como um Intel ou AMD ou mesmo os ARM de celulares também são little endian. O processador IBM PowerPC dos Macs anteriores a 2006 eram Big Endian, então os bytes iam aparecer na ordem natural que nós humanos lemos. Mesmo os processadores ARM de hoje são bi-endian, quer dizer que ele suporta ambos mas a maioria é usado como little endian.

Parece meio estranho, porque eu ia querer ler números de mais de um byte em ordem reversa? Na realidade parece estranho porque a gente lê da esquerda pra direita, mas quando implementamos em hardware é mais simples ler da direita pra esquerda, requer menos ciclos pra fazer contas. Sem entrar em detalhes do hardware vamos dar um exemplo onde a ordem natural pode não facilitar nossa vida. Imagine datas no formato brasileiro com dia, mês e ano. Mande um computador ordenar. Podemos usar o comando sort que tem em todo linux. Porém coloque as mesmas datas agora em formato japonês, que é ano, mês e dia e tente ordenar da mesma forma. E veja só, só de mudarmos a ordem dos elementos das mesmas datas, a ordenação funcionou muito mais fácil.

Aliás isso é um insight que todo programador precisa ter. Boa parte do que é programação é retrabalhar os dados pra ficar mais fácil de computar o que queremos. Little endian no nível do processador é algo parecido na hora de fazer contas. Pra agora só assuma que quando você vê dois bytes que representam endereço de 16-bits, eles vão estar invertidos e 0x0080 vai ser 0x8000.

01012000 01031998 02071999 03042003 05052005

20030403 19980301 19990702 20050505 20000101

Uma vez eu justamente precisei fazer um pequeno protocolo de rede binário pra trafegar dados entre computadores Intel e PowerPC. Acho que eu estava usando um Macbook G4 antigo. E eu recebia lixo no lado do Intel. Até que me dei conta “puts, PowerPC é Big Endian”, daí eu inverti os bytes no meu protocolo antes de mandar e do lado do Intel passou a receber direitinho. Você não vê isso porque se o único protocolo que já usou foi HTTP na camada de baixo no nível do TCP ele se vira pra reverter os bytes se trafegar entre processadores com endianess diferentes. Se você já usou algo como Google Protobufs, a biblioteca se encarrega de converter se precisar.

Isso tudo explicado, vamos fazer um programinha agora. Lembrando, um CPU tem registradores e pode guardar dados de 8-bits, ou 1 byte neles. Pense em registradores como se fossem variáveis globais numa linguagem de programação qualquer. Elas vão ser uma ordem de grandeza mais rápidas de acessar do que se tiver que sair do CPU e pedir memória pra um chip de RAM por exemplo. Registradores que podemos usar no 6502 incluem o A, X, Y e outros. Cada registrador vai ter um comando de LOAD pra jogar um valor nele e um comando de STORE pra tirar o valor do registrador e jogar em algum outro lugar na memória, se tiver RAM por exemplo.

Vamos só fazer um LOAD em A que é o opcode LDA. Assim como em linguagens modernas existe o conceito de polimorfismo, ou seja, a mesma função responder pra argumentos diferentes, no nível de máquina o mesmo comando LDA na verdade é representado por diferentes hexadecimais pra cada variação de argumentos. Por exemplo existe a instrução 0xAD, mas a versão que queremos é a que aceita só um valor simples e não um endereço de memória como argumento, então o hexadecimal da instrução LDA queremos é o 0xA9.

De volta ao python se acessarmos o primeiro valor do array, posição 0x00, colocamos o valor 0xA9 que é o comando LDA e na sequência colocamos o argumento dessa instrução que pode ser qualquer valor de 1 byte, aqui colocamos 0x42 arbitrariamente. A instrução completa são esses dois bytes. Dependendo da instrução pode ter mais argumentos, usando mais bytes na sequência. O CPU sabe quantos bytes cada instrução precisa. Tudo tem tamanho fixo em bytes na CPU, e assim ele sabe qual byte é uma instrução e quais bytes são dados.

Como agora temos um valor no registrador A podemos fazer alguma coisa com isso, tipo escrever nos pinos de dados. Pra isso usamos o STORE from A ou Grave a partir de A, que é o comando STA e ele recebe um argumento de 2 bytes que é o endereço pra onde queremos enviar o valor de A.

Então acessamos a posição 2 do array e colocamos o binário 0x8D que é a instrução STA. Agora nas posições seguintes queremos enviar esse dado pro endereço 0x6000, como já expliquei queremos o inverso disso então na posição 3 do array colocamos 0x00 e na posição 4 colocamos 0x6000.

Essa sequência de 3 bytes vai fazer o seguinte: escrever o valor que está no registrador A nos pinos de dados, mudar o bit no pino de read write pra escrever e mudar os pinos de endereço pra 0x6000.

Rodamos o script python pra gerar o novo binário, gravamos na EEPROM com o minipro de novo, recolocamos a ROM na placa e ligamos a energia e o monitor do Arduino.

Fazemos reset com clock pausado, e vamos manualmente clock a clock. Mesma coisa de antes, ignoramos os 7 primeiros clocks que é a inicialização. A CPU pede os valores de 0xfffc e 0xfffd que puxa da ROM o endereço 0x8000, esse é o reset vector e a CPU pede o que tem nesse endereço, que sabemos que é o endereço 0 da ROM e tem a instrução LDA que é 0x9a.

O contador vai incrementando a partir de 0x8000 e pede o que tem em 0x8001 que é o valor 0x42. A instrução está completa e a CPU grava no registrador. Agora o contador pula pra 0x8002, e de lá tem a próxima instrução STA que é 0x8d. O CPU vai incrementar o contador e ler os proximos dois bytes, que vai ser primeiro 0x00 e depois 0x60, esse é o endereço 0x6000.

Tudo funcionando conforme esperamos mas ao configurar os pinos pra gravar, não tem ninguém no barramento que responde a essas ordens, e nada acontece. No próximo ciclo esse dado vai sumir do barramento. Precisamos de alguma coisa pra segurar esse dado enquanto a CPU fica livre pra fazer outras coisas. Esse seria um componente chamado “Latch” que acho que podemos traduzir pra “Tranca”. Pra esse protótipo o Ben escolheu um chip que foi feito pelo mesmo fabricante desse clone de 6502 e é um adaptador que serve pra muitas coisas incluindo trancar alguns valores. Pense como se fosse um mini-memória.

Por acaso, os pinos desse adaptador são muito parecidos com o da ROM que já estamos usando, e tem espaço pra gravar até 2 dados de 8 bits no que ele chama de “Portas”. Tem uma Porta A de 8-bits e uma Porta-B de 8-bits. Por isso você tem pinos de PA0 a PA7 e pinos PB0 a PB7. A essa altura vocês já devem ter entendido a idéia de pinos serem cada um 1 bit né?

Diferente da ROM não precisamos de 16 pinos pra endereço porque esse chip só consegue armazenar no 2 valores. Sabemos que queremos ativar esse chip quando passarmos endereços que comecem com 0x60 que em binário é 0110 0000. Resumindo o que o Ben explica no video dele, ele vai ligar os endereços A15 a A13 com os pinos de chip select que são CS1 e CS2 e colocar um inversor e outra porta NAND no meio deles pra configurar o chip corretamente. Os detalhes não importam pra onde eu quero chegar, mas recomendo que assistam o episódio dele pra entender os detalhes.

O importante é entender que quando a CPU colocar endereços como 0x6000 ou 0x6001 ou 0x6002 e assim por diante, esse chip vai entender os primeiros 3 bits, ligar e receber o dado de 8 bits dos pinos de dados e gravar na Porta A ou Porta B. Quem indica a operação é o segundo byte do endereço. Entenda, o CPU chama os pinos de endereço, mas são bits, podemos ligar esses pinos com qualquer outra coisa pra montar nossa lógica.

No chip de Tranca, segundo a documentação ele espera receber 4 bits de configuração em 4 pinos registradores diferentes. Podemos ligar esses pinos aos pinos A0 até a4 que são os últimos bits do endereço de 16-bits. Se mandar 0 0 1 0 que é o número 2 ele direciona pra Porta B e se depois mandar 0 0 0 0 ele manda gravar efetivamente na Porta B, portanto a CPU precisa mandar o endereço 0x6002 pra ao mesmo tempo habilitar e configurar a direção e depois mandar o endereço 0x6000 pra de fato gravar o que estiver nos pinos de dados na Porta B. Parece complicado mas é bem simples, vamos ver.

Pra ver isso em funcionamento podemos ligar alguns LEDS nos pinos da Porta B. Assim quando o valor for trancado, ele vai ligar os LEDs correspondentes.

De volta ao python mas antes de continuar, é uma boa hora pra refatorar esse código pra ficar mais legível. É assim que se programa, primeiro fazemos a coisa mais simples que funciona primeiro. Agora vemos padrões no código que dificulta continuar, então pensamos em formas de tornar o código mais fácil de manusear.

Um das formas de fazer isso é definir um novo array de bytes em cima do array cheio de 0xEA’s, esse array vai conter nosso programa exatamente igual antes. É só colocar os bytes que estávamos posicionamento manualmente embaixo, em sequência em cima e apagar o que tava embaixo.

Agora o array de ROM vai ser esse novo array de código mais o array preenchido com 0xea, só que em vez de ser vezes 32768, vai ser 32768 menos o comprimento do novo array de opcodes. Assim o array do binário vai ter exatamente o mesmo comprimento de antes e isso é importante porque tem que ser tudo preciso.

Escrever tudo numa linha só ou dividir em multiplas linhas pro python não faz nenhuma diferença, só faz diferença pra gente conseguir ler mais fácil. E de proposito colocamos dois bytes numa linha porque o primeiro é o hexa da instrucao LDA seguido do seu argumento. E na segunda linha colocamos 3 bytes onde o primeiro é a instrucao STA seguido de 2 bytes que formam o endereço pra onde gravar o conteudo de A.

Esse código é exatamente igual o que tínhamos antes, mas agora temos a Tranca que exige primeiro uma instrucao pra dizer a direçao pra saber qual porta usar. Então precisamos mandar o endereço 0x6002. Mas também precisamos mandar algum dado pelos pinos de dados. Se mandar tudo 0 ele habilita a porta B pra ser input e se mandar tudo 1 ele habilita a porta B pra ser output e gravar o que receber.

Enviar tudo 1 em 8 bits é o hexa 0xFF. Então mudamos o nosso array de código pra em vez de carregar aquele 0x42 vamos carregar com o número 0xFF. E em vez de mandar esse valor pro endereço 0x6000, vamos mandar pro 0x6002, e com isso setamos a direção do chip pra porta B e pra ela ser output.

Na sequência podemos fazer o que queríamos antes, travar um valor, digamos o hexa 0x55. Agora é só mandar a instrução STA pro 0x6000. Por acaso 0x55 em hexa é 0101 0101 e isso vai ligar os leds alternando o primeiro apagado, o segundo aceso e assim por diante.

Pra ficar mais legal podemos agora repetir os comandos, e mandar armazenar 0xaa em hexa que é 1010 1010 em binario, alternando os bits com o valor anterior, dai os leds apagados vao acender e os acesos vao apagar. Só uma brincadeira pra mostrar como podemos controlar alguns LEDs.

Pra finalizar seria legal colocar essas duas sequências num loop pros leds ficarem piscando sem parar, repetindo essas sequências. E a forma de se fazer loop, segundo a documentação do 6502 é com um jump que é a instrução JMP. Ele manipula o contador de programa pra apontar pra outro endereço qualquer, fazendo o CPU continuar incrementado de lá.

Então podemos fazer JMP pra 0x8000 que é o endereço 0 na ROM e começar do zero, mas não tem necessidade de reiniciar tudo. Um jump pro endereço 0x8005 é suficiente, ou seja, pulando os primeiros 5 bytes. Agora podemos rodar o script, gerar o novo binário, gravar na EEPROM, ligar e testar. E pronto, LEDs piscando como esperado.

https://www.youtube.com/watch?v=oO8_2JJV0B4 (parte 3)

Se você chegou até este ponto e tá entendendo mais ou menos, no mínimo já deve tá ficando meio ansioso de ver esse monte de bytes num array. Neste ponto o Ben resolveu explicar uma forma menos feia de gerar esse binário. Obviamente ninguém escreve código em binário direto assim.

Mas considere por um instante que nos anos 50 pra trás era exatamente assim que precisava escrever. E a forma de fazer isso era com fios. Sabe os pinos de dados e endereço que ligamos registradores e agora ligamos a ROM? Antigamente era um patch panel. Lembra aqueles seriados ou filmes antigos dos anos 50 que mostra uma telefonista conectando uma ligação colocando ou tirando fios de um painel? É algo parecido. Configura os bits e manda pro computador, um conjunto de bits de cada vez.

Se você já leu alguma mini biografia do Bill Gates e do Paul Allen, vai lembrar que o primeiro computador comercial pra qual eles escreveram Basic foi o Altair 8800 que vinha com o processador Intel 8080 de 8-bits. Isso foi um ano antes de aparecer o processador Motorola 6800 que foi a base pro 6502 que estou mostrando aqui. Se você nunca viu um Altair veja esta foto, tá vendo esses switches no painel? A etiqueta em cima deles tá escrito D0 a D7 e embaixo A0 a A15. Agora você já sabe pra que serve esses switches.

Você tinha que escrever bit a bit subindo ou descendo esses switches, um a um os bits de dado e os bits de endereço e depois puxar o switch de “DEPOSIT NEXT” que tem nesse painel pra registrar na memória e fazer isso instrução a instrução, que é o equivalente do nosso array de bytes. Se você tá achando tedioso o que estamos fazendo, imagina escrever um programa inteiro só com esses switches, bit a bit, e sem errar nenhum bit. Essa é a verdadeira definição de “escovar bits”. Felizmente os computadores caseiros que vieram depois ganharam teclados e monitor e isso facilitou ordens de grandeza a programar.

De qualquer forma, havia uma opção um nível acima de escrever binários direto, e é escrever em Assembly. E é assembly com “y” no final, que é escrever usando mnemônicos como usar a palavra LDA em vez de escrever o binário pra 0xa9.

Em vez de escrever direto 0xa9 0xff podemos escrever LDA # $ F F. O dólar indica que estamos escrevendo um número hexa e o hash significa que é um valor imediato e não um endereço. Quando compila sem o hash apesar do mnemonico ser LDA, temos um tipo de polimorfismo como já expliquei. Se passarmos um valor com hash vamos escolher o 0xa9, mas sem o hash, FF é um endereço e o opcode é diferente, o 0xa5.

Continuando em vez de 0x8d 0x00 0x60 podemos escrever STA $6000, ou seja, também não precisamos nos preocupar com a inversão de little endian como falei antes e escrever na ordem natural de leitura humana.

Nas linhas seguintes fazemos lda 55, sta 6000, lda 11, sta 6000, jmp 8005

É exatamente a mesma coisa que fizemos no binário. Pra declarar que o início do programa é o endereço 0x8000 colocamos um indicador no começo do arquivo .org 8000 que declara a origem. Lembre-se, na ROM o endereço inicial vai ser 0x00 mas do ponto de vista do CPU esse é o endereço 0x8000.

No final do código colocamos um novo .org fffc que é o primeiro endereço que o CPU sempre vai pedir pra buscar qual é o próximo endereço onde tem a primeira instruçao do programa, já repetimos isso várias vezes. E aí colocamos um word 0x8000 que indica o endereço inicial pro CPU buscar. Word é como chamamos um conjunto de 2 bytes.

Salvamos esses comandos num arquivo texto e agora podemos passar isso pra um Assembler, com “er” no final, que vai traduzir esse texto em binário. Em inglês Assembly que termina em “y” significa “montagem”, que é a instrução de montagem, ou o código-fonte. E Assembler que terminar com “er” é o montador, que vai pegar essa instrução de montagem e montar o binário propriamente dito.

Pra gerar o binário correto precisamos do Assembler específico pro 6502. Na maioria dos Linux basta instalar o pacote vasm. Pra quem tá em Windows ou Mac vou deixar o link do site nas descrições abaixo e o video do Ben explica em detalhes como usar.

Existem vários assemblers diferentes pra família 6502, do Apple II é diferente do Atari que é diferente do 6502 genérico. O assembler que precisamos se chama vasm6502_oldstyle. Se abrirmos o binário que ele gera com hexdump e compararmos com o nosso produzido com o script de python, vemos que é idêntico ao array de bytes que estávamos escrevendo na mão.

Pra completar os 32k vemos que faltou só 2 bytes no final, pra isso só adicionamos um novo word no fim com 2 bytes pra completar. Mas agora que estamos escrevendo em Assembly podemos usar funcionalidades do Assembler Vasm que melhoram um pouco nossa qualidade de vida de programação em baixo nível. A maioria dos Assembler implementam macros e outras coisas pra evitar que a gente tenha que ficar fazendo repetições ou decorando endereços de cabeça.

Por exemplo, lembra que temos um JUMP pra um endereço fixo 0x8005? E se colocarmos mais instruções antes disso? Toda hora ia precisar ficar atualizando esse endereço na mão. Em vez disso podemos adicionar um label e fazer o jump pular pra esse label e deixar o assembler calcular qual é o endereço certo.

A diferença no código é que precisamos sempre identar com espaços ou tab, e labels começam na primeira coluna sem identação. Só de fazer isso já nos livramos de um número hard-coded. Números mágicos como aquele sempre são ruins e em Assembly isso não é diferente.

Ainda dá pra melhorar o codigo. Podemos deliminar a região de reset com um label e só pra brincar, vamos mudar o valor 0x55 pra ser 0x50. No loop vamos tirar o que tinha antes e colocar uma instrução nova que é o ROR ou rotate right. Lembra o conceito de shift pra direita? Pense que 0x0050 é 0 0 0 0 0 1 0 1 daí quando der shift right vai virar 1 0 0 0 0 0 1 0 e a cada loop ele vai dar shift e rotacionar pra direita. Significa que vai ter só dois leds acesos a cada clock e eles vão se “movimentando” pra direita.

Podemos compilar com o Vawm pra gerar o binário, gravar na EEPROM e fazer o de sempre, colocar a ROM na placa, ligar força, resetar e ver se funciona. No caso ele tá rotacionando pra esquerda porque a placa tá de ponta cabeça no video, mas você entendeu.

https://www.youtube.com/watch?v=FY3zTUaykVo (parte 4)

Com os LEDs fazendo o que esperávamos, sabemos que a trava está funcionando e gravando o dado na porta certa. Então podemos ir um passo além. Essa trava pode funcionar como um buffer pra uma tela e o Ben conseguiu uma tela de LCD simples. Novamente, vamos pular a configuração do hardware mas a parte importante é que ele recebe 8 pinos de dados como a ROM e o latch, e assim como o latch ele tem 3 pinos de controle onde podemos ativar configurações.

Em resumo o LCD pode ou receber instruções ou receber dados, que seriam as letras que queremos que apareça na tela. Instruções são coisas como limpar a tela, mudar a posição, configurar um cursor e assim por diante. O manual da tela tem os detalhes de cada configuração mas vou mostrar o valor que vamos mandar no Assembly. Pra receber dados vamos conectar os pinos de dados do LCD com os pinos da Porta B do latch, e pra configurar os 3 pinos de controle vamos ligar em 3 pinos da Porta A do latch.

Vamos refatorar o código de novo criando alguns simbolos ou constantes pro codigo ficar um pouco mais legivel. Criamos PORTB = 6000 e PORTA = 6001. DDRB é a direção se vamos escrever na porta B o endereço é 6002 mas se quisermos escrever na PORTA temos que setar DDRA que é 6003

0xff significa tudo 1 em hexa, podemos deixar mais claro escrevendo o número em binario, bit a bit. Dizemos pro Assembler que isso é um número binário colocando % (porcento) no começo e ; (ponto e vírgula) é comentario, que não aparece no binário final.

Agora os pinos de controle do LCD, pra isso vamos setar só os primeiros 3 bits que são os que conectamos nos pinos de controle da tela. Agora é uma sequência específica desse modelo LCD, então não se preocupem tanto com os detalhes dessa parte.

Pra inicializar a tela começamos mandando 00111000. O primeiro bit seta modo 8-bits, o segundo seta 2 linhas na tela e o 3o seta fonte de 5 por 8 pixels. Por fim um STA mandando pra PORTB.

Carregamos zero com LDA e mandamos Porta A com STA pra limpar os pinos de controle RS, RW e E. RS é o pino que seleciona se estamos mandando instruções ou dados pra tela, RW se estamos lendo ou escrevendo e E se tá habilitado pra receber comandos.

Agora queremos habilitar com LDA do valor E e depois desligamos esse enable. É uma sequencia bem burocrática mesmo, a maioria dos hardware tem alguma sequência de controle assim mesmo, mas é o que a documentação do LCD diz que precisa fazer. Mas já tá quase acabando.

Cada nova instrução que queremos mandar precisa copiar toda essa sequencia. Agora mandamos 0000 1110. De novo 3 bits, mas agora é pra ligar o display, ligar o cursor e não fazer blink que é ficar piscando na tela.

Copiamos todo o bloco de controle e colamos embaixo. A última configuração é mandar 0000 0110 que é dizer pro LCD que pra cada nova letra que mandarmos é pra incrementar a posição e não fazer nenhum tipo de scroll.

E tem que copiar todo o bloco de controle de novo.

Finamente podemos enviar a letra que queremos escrever no LCD. Poderíamos dar LDA do número em binário ou hexa que representa a letra na tabela ASCII. Mas como estamos usando um Assembler, ele sabe converter sozinho então podemos escrever o string “H” entre aspas que ele se vira.

Daí mandamos pra Porta B com STA.

O bloco seguinte é um pouco diferente do que fizemos antes. Em vez de zerar os pinos de controle temos que ligar o pino que seleciona o registrador pra em vez de receber instrução, receber dado, entao configuramos com a constante RS que tínhamos declarado antes.

Na sequência, além de só habilitar com a constante “E”, tem que mandar junto o bit de RS. Pra isso usamos o operador bitwise de OR que é uma barra vertical. O que isso faz? Ele faz um OR bit a bit. De novo, isso é lógica. Na prática o resultado é mesclar os bits de RS e de E. Como RS é 0010 e E é 1000 o resultado vai ser 1010. Aqui valeria uma tangente mas como já está comprido só quero deixar um lembrete que essa é uma técnica muito usada especialmente pra quem mexe com protocolos de rede. Isso é como trabalhamos Bit Fields, procurem sobre isso no Google. É uma forma eficiente de enviar várias características de alguma coisa embutido num único byte em vez de ter um byte separado pra cada valor.

Por fim zeramos o bloco de loop pra quando chegar nele ficar num loop infinito e não fazer nada. Assim ele termina de escrever na tela e não faz mais nada.

Compila, grava a eeprom, e testamos. E aparece o “H” na tela como queríamos.

Pra escrever o resto das letras do hello world, por agora vamos fazer do jeito mais porco e sujo só pra ver o resultado rápido. Ou seja, copy e paste nervoso de toda a sequência da letra “H” pra cada uma das outras letras. Isso é obviamente péssimo de se fazer. Pra testar a primeira vez quando você ainda não sabe se vai dar certo tudo bem, mas obviamente vamos voltar e melhorar isso depois.

Vamos compilar e não só o código Assembly ficou longo, mas o binário reflete isso. Olha como o binario no hexdump ficou gigantesco com mais de 300 bytes só pra escrever um mísero hello world. Escrever código longo e sujo além de feio e ruim de manter, também gera instruções redundantes e aumenta o tamanho do binário.

Agora podemos transferir pra ROM, ligar na placa e, como esperávamos, temos um Hello World aparecendo. Se o objetivo for só escrever Hello World do jeito mais feio do mundo, já acabamos, mas podemos só acrescentar uma última coisa pra melhorar muito esse código.

https://www.youtube.com/watch?v=xBjQVxVxOxc (parte 5)

Vamos aumentar nosso arsenal de Assembly aprendendo o conceito de sub-rotinas, que é uma forma primitiva de funções. Aliás, pra quem já é programador e já ouviu falar do conceito de “GO TO” isso é o Jump pra um endereço fixo que mostramos com o mnemônico JMP. Mas nem em Assembly é obrigatório usar só jumps.

Pra refatorar esse codigo vamos criar uma subrotina chamada lcd_instruction que manda os comandos pra escrever os dados na tela depois do LDA. Toda aquela sequência que demos copy e paste várias vezes no começo do código.

Já sabemos que JMP pula pra um endereço fixo. O problema é que uma vez que você pula, não tem mais como voltar pra trás. Pra ter esse recurso podemos usar o opcode JSR que é Jump Sub Routine, que pula pra uma subrotina e grava o endereço atual do contador de programas. Daí, no final da subrotina usamos o comando RTS que é tipo return num Javascript, que vai pegar o ultimo endereço gravado pelo JSR e colocar de volta no contador de programas, e com isso o CPU continua na instrução logo depois do JSR.

Essa é a forma mais rudimentar de uma função em linguagem de máquina. Fazemos a mesma coisa criando uma subrotina print_char, chamamos JSR depois do load da letra e no final da subrotina colocamos RTS pra voltar pro byte seguinte da instrução de jump.

Depois de recompilar podemos comparar o tamanho dos binários, o anterior sujo tinha 333 bytes. Agora ficou bem menor em tamanho. Só que isso não sai de graça. A versão anterior era maior mas era pouca coisa mais rápido porque agora a CPU vai executar um monte de Jump e Return que não tinha antes. Cada uma dessas novas instruções usa clocks pra executar. Porém é aquele caso em que o ganho de performance não compensa a sujeira do código. Via de regra você sempre deve preferir código legível do que otimização prematura.

Isso faz parte do dia a dia de um programador: ter que escolher quando você escreve um pouco mais sujo pra ganhar performance e quando o ganho de performance é tão pequeno que não compensa. Não existe uma receita, só com experiência você vai saber. Mas via de regra você só toma essa decisão depois de conseguir testar o código e mensurar se o ganho vale a pena ou não. Nunca ache que só porque um código rodou a primeira, já tá pronto e nunca mais vai mudar. Neste exemplo besta já refatoramos o código várias vezes, imagina num código grande de verdade.

Gravamos na ROM, testamos e …. nada acontece, o programa parece que travou. Por que? Pra descobrir vamos ligar o monitor de Arduino de novo, resetar e colocar em clock manual pra ir linha a linha. Vamos acelerar direto pro suspeito mais óbvio que é o JSR.

Temos o LDA que vai configurar a primeira configuração pra tela. Em seguida temos o opcode 0x20 que é o JSR.

Deveríamos ver algo como um 0x20 e depois 0x5d e 0x80 representando o endereço 0x805d que é onde está a subrotina. Mas em vez em disso vemos essa sequencia estranha 5d 80 0e. Aí parece que volta ao normal continuando a instrucao com o 0x80 restante pra formar 0x805d. Ou seja, ele pula pra subrotina e podemos ver que ele segue normalmente.

Seguimos mais algumas instruções e chegamos no opcode 0x60 que é o RTS ou return, mas pra onde ele vai retornar? Deveria ser pra 0x800f que é o próximo endereço depois do último JSR em 0x800e.

Estamos vendo no monitor que o CPU tenta ler alguma coisa em 0x0123 e 0x0124. O lance é que JSR e RTS dependem de algum hardware que responde nesses endereços pra gravar o endereço de retorno, mas no momento nao temos nenhum hardware que responde.

Quando chama JSR ele tenta gravar nesses endereços, mas não tem ninguém esperando isso então o endereço de retorno vai pro limbo. Quando chega no RTS ele tenta recuperar o endereço, e não tem ninguém pra responder, então acaba tendo algum lixo nos pinos e o CPU assume que é um endereço e tenta pular pra lá. No caso veio um lixo 0x8d8d e o CPU vai pra lá mas não tem nada e o programa se perde.

Esses endereços 0x0123 0x0124 são específicos do processador 6502. Segundo a documentação, de 0x0100 a 0x01FF temos o Stack, uma pilha. E temos mais um registrador que ainda não mencionei, chamado SP. Todo CPU tem uma série de instruções implementadas em hardware como o LDA STA JSR e outros. Instruções como LDA grava no registrador chamado “A”. Até agora só vimos 2, o registrador A e o PC que é o contador de programa. E o ultimo registrador novo importante pra hoje é esse SP é o Stack Pointer, que guarda um endereço do topo de uma pilha. O SP é quem permite a existência do conceito de sub-rotinas e funções.

Stack ou Pilha é uma estrutura de dados. Lembra a tal fundação que eu sempre falo? Se você estudar estrutura de dados, vai descobrir a Pilha, uma das estruturas mais básicas e que você aprende logo no começo dessa matéria. Todo iniciante tem que saber o que é uma pilha e quando usar ela. Em resumo, é uma cadeia de elementos onde você vai colocando um elemento de cada vez no topo. E toda vez que pedir pra devolver um elemento, vai removendo do topo.

Essa pilha é um tipo particular chamado LIFO, Last In, First Out, ou seja, quem entra por último, sai primeiro. A vantagem de uma estrutura dessas é que basta guardar o endereço do topo. Depois que adiciona um elemento, decrementa o endereço do topo. Pra puxar da fila, devolve o dado do topo e incrementa o endereço no registrador SP. Quando falamos topo, não necessariamente começamos do zero e vamos subindo um a um. No caso do 6502 ele prefere iniciar no meio da pilha, em 0x0124 e vai subindo até 0 e quando chegar no zero ele rotaciona pro fim da pilha em 01FF e continua subindo.

Toda vez que você faz um JSR, ele vai acumular um endereço na pilha. Se você fizer mais que 255 jumps sem fazer um Return, ele vai estourar o tamanho da pilha e vai começar a sobrescrever o primeiro endereço gravado. É isso que se chama de transbordar da pilha ou, em inglês, Stack Overflow. Mesmo com uma pilha pequena dessas é muito difícil fazer 255 jumps sem retorno. Quando isso acontece normalmente é uma recursão mal feita. Recursão é uma sub-rotina que dá JSR pro começo dela mesma. É muito fácil um iniciante errar com recursão.

Outra coisa interessante de saber é que registradores são literalmente variáveis globais. Se você já trabalhou com C ou Javascript já deve ter ouvido falar de quão tenebroso uma variável global pode ser. Antes de fazer o JSR no nosso código, setamos o registrador A com um valor usando LDA, mas quando pulamos pra subrotina, dentro dela modificamos esse registrador A. Se depois que retornássemos o programa esperasse encontrar o mesmo valor original em A, teríamos problemas.

Como no nosso caso, depois que retornamos não faz diferença porque vamos escrever a próxima letra em cima do A mesmo, então tudo bem, mas se quiséssemos evitar algum efeito colateral num código maior, poderiamos primeiro empurrar o valor de A pro stack também, usando a instrução de push A que é PHA.

E antes de retornar com RTS podemos puxar o valor de A do topo do stack usando pull A ou PLA. Por garantia então devíamos usar isso no começo e fim de toda sub-rotina né? Mais ou menos, esse hardware antigo só tem 255 slots na pilha lembram? Se você souber que não vai estourar, pode fazer isso. Como eu falei, tudo é um trade-off. Se eu quiser garantias demais, os recursos podem acabam cedo demais e podemos acabar ganhando um bug de stack overflow sem querer.

Só por comodidade podemos mudar o registrador SP de 0x0124 pra 0x01FF pra começar do fim da pilha em vez do meio. Pra isso podemos procurar uma instrução como o LOAD A, mas nao tem LOAD pro registrador SP da pilha, e sim TRANSFER que é TXS, que transfere um valor do registrador X pro SP. E aqui aprendemos que existe um registrador chamado X além do A.

Assim como fazemos com o registrador A, primeiro usamos a instrução LOAD to X que é LDX com #$FF e daí transferimos X pra SP com TXS. Note que colocamos FF e não 0x01FF porque os endereços do stack sempre começam com 0 1 em binário entao na pratica estamos contando sempre de 00 a FF. Já expliquei que é um stack pequeno com 255 posições.

Tudo isso entendido, precisamos de algum lugar que tem espaço pra gravar 255 elementos de uma pilha e responde aos endereços de 0x0100 a 0x1FF. Nosso chip de trava só tem 2 portas então não serve. Chegou a hora de adicionarmos um chip de memória RAM. E fica outro insight, memória RAM pode ser opcional se o que você pretende fazer com um hardware são operações simples que sobrevivem só com registradores ou com uma trava simples.

https://www.youtube.com/watch?v=i_wrxBdXTgM (parte 6)

O Ben escolheu um chip de RAM que é muito parecido com a pinagem do EEPROM e da Trava que já estamos usando, então vamos pular a configuração do hardware que é a mesma coisa: liga força, liga terra, liga os pinos de dados e de endereço. Assim como todos os outros chips por acaso tem 3 pinos de controle que importam, um pra write enable que como o nome diz habilita escrita, um pra output enable e outro pra chip select. Write enable é fácil, porque o 6502 tem um pino read write que indica escrita, daí ligamos direto um no outro.

Assim como no caso do ROM e do LCD precisamos definir os endereços que a RAM vai responder. Sabemos que o stack precisa pelo menos dos endereços 0x0100 até 0x01FF. Mas vamos mapear o primeiro 1/4 dos endereços do topo que vai de 0x000 até 0x3FFF que é bem longe dos endereços 0x6000 que o LCD usa e do endereço 0x8000 que a ROM usa.

Isso é suficiente pra 16 kilobytes de RAM. Por acaso este chip moderno tem mais espaço que isso, então vamos desperdiçar um pouco neste protótipo. Pra usar tudo daria mais trabalho pra criar um mapeador de endereços. Mas lembre-se que um nintendinho tinha só 2 kilobytes de RAM e 2 kilobytes de memória de video. E no próximo episódio vou explicar porque não dava pra ter muito mais que isso mesmo.

Existe um pequeno circuito que precisa ser adaptado e vou pular essa explicação, mas em resumo a forma de conectar a RAM na CPU é ligar o A14 da cpu com o A14 da RAM cruzando com o output enable e o A15 da cpu de novo através de um inversor e um nand no chip select. O que precisamos saber é que isso vai habilitar a RAM quando o endereço começar com 0 0 que cobre os endereços que queremos. Pra entender porque a ligação em hardware é dessa maneira, veja o video do Ben.

Feito isso, agora temos RAM ligado e configurado respondem nos endereços que precisamos, então teoricamente já temos uma pilha disponível e com isso o programa deveria funcionar. Se ligarmos e dermos reset, de fato, agora o hello world aparece como deveria.

Tudo resolvido, vamos ligar o Arduino pra entender como o programa se comporta. Fazemos reset e deixamos o clock em manual de novo. Como sempre, vamos ter os 7 clocks pra inicializar a CPU e pulamos rápido até o ponto onde o programa faz o jump JSR que é o opcode 0x20.

Lembrando que configuramos o registrador SP pra começar de 0x01ff, que é o fim do espaço de endereços da pilha, e de fato vemos no monitor que tá escrevendo 0x80 no final do stack em 0x01ff. Daí o cpu atualiza o registrador SP pro próximo endereço ser 0x01fe e escrever 0x11 lá. 0x8011 é o endereço de retorno da subrotina.

Agora ele salta pra subrotina que tá em 0x8060, como já fazia antes, executa a sequência pra escrever a letra no LCE e chega na instrução RTS que é o opcode 0x60.

A instrução de retorno vai desempilhar o primeiro byte do topo da pilha, que está em 0x01fd, e lê 0x11. Daí decrementa o registrador SP e lê 0x80 e isso forma o endereço 0x8011 que é pra onde o programa tem que voltar. E com isso temos o suficiente de hardware pra fazer jumps o que garante que podemos programar praticamente qualquer coisa só com o que temos aqui.

Os dois registradores de controle de um CPU são o contador de programa ou PC que tem o endereço da próxima instrução ou byte que ele tem que ler. E o apontador de pilha ou SP que é o endereço do topo da pilha. Tendo esses dois controle você consegue executar uma instrução após outra e consegue dar jumps pra continuar executando de outro endereço e retornar pro endereço anterior. Ou seja, você tem o equivalente a um loop com WHILE numa linguagem de alto nível. Daí existem instruções de Branch e Compare que servem pra comparar valores e dar jumps dependendo das condições que você configurar, e isso é o equivalente a um IF numa linguagem moderna.

Com essas poucas instruções que vocês viram já dá pra ter o modelo da maioria das funcionalidades básicas de qualquer linguagem: loops, funções e ifs ou branches que não cheguei a mostrar mas acho que vocês já conseguem imaginar como seria. Na série do Ben tem um episódio extra depois que ele configurar o LCD onde ele troca o clock que está montado num breadboard por um clock de 1 Megahertz de verdade. Mas quando ele faz isso o programa pára de funcionar. Tudo funciona quando o clock é bem lento, mas quando o clock fica rápido demais, o CPU envia os comandos pro LCD rápido demais e o LCD não responde a tempo. Pra evitar isso precisa adicionar um comando no CPU pra perguntar pro LCD se já pode mandar a próxima letra.

De qualquer maneira eu queria passar pelos principais pontos dos videos do Ben pra que vocês pudessem ver como um CPU funciona, como ele se comunica com outros componentes como memória RAM ou um LCD simples. Como um CPU carrega um programa e executa. No fim do dia, não importa que linguagem você está usando, ele vai ser convertido em bytes de instruções parecidas como o que acabei de mostrar. Vocês viram que só de pular do binário pra escrever em Assembly já ganhamos algumas conveniências que o Assembler Vasm nos dá.

Quanto mais conveniências uma linguagem adiciona, mais abstrações ele faz e mais lento ele tende a ser. Como falei antes existe um trade off sempre, sempre existe um balanço entre ser conveniente e ser rápido, entre ser rápido e ser seguro e assim por diante. Em outros videos eu vou tentar explicar as diferenças das diferentes linguagens levando em consideração que vocês assistiram este vídeo.

No próximo video eu vou usar o que mostrei aqui de uma maneira mais prática. Eu mostrei a idéia do Game Genie no começo do video mas não fiz nada com ele hoje, é o que vou começar mostrando na parte 2. A parte 2 vai ser bem menos tedioso que esta parte 1, isso eu garanto, porque agora podemos usar tudo que eu mostrei aqui na prática em programas de verdade.

Muitos programadores associam “linguagem de máquina” com algo difícil e inatingível que não foi feito pra eles, mas isso não é verdade. Linguagem de máquina e o hardware em si são razoavelmente simples, peças de lego. Tudo funciona em cima das mesmas peças e você vai ser um programador melhor se pelo menos tiver uma imagem mental de como seu código interage com esses componentes.

Uma coisa parece difícil só porque você nunca viu. É que nem um truque de mágica. Mas depois que a gente revela o truque, as coisas ficam muito mais claras. Se você não entendeu o video todo, não se preocupe, eu literalmente resumi o equivalente a umas 5 horas de aula do canal do Ben Eater aqui. Vou deixar os links pro canal dele nas descrições. Se quiserem adicionar mais a esta conversa não deixem de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho pra não perder o próximo episódio e, como sempre, compartilhem o video pra ajudar o canal. A gente se vê na próxima, até mais.

Se tem um tema que eu queria fazer desde que abri o canal é apresentar algumas das fundações da computação, tanto do ponto de vista de história e da evolução, mas principalmente dos fundamentos básicos que eram vários 60 anos atrás e ainda são válidos até hoje.

O video de hoje vai abrir com um tema de videogames, mas vamos descer bem fundo no cérebro do Nintendinho pra criar um vocabulário que eu vou usar na Parte 2, quando de fato vou mexer num emulador de Nintendo. E esse vocabulário vai servir não só pra videos futuros meus como pra tudo que você for fazer em computação. Esta é a base, sem esta base tudo que você tentar aprender de avançado depois vai ser mais difícil.

Infelizmente é muito difícil empacotar estes temas de uma forma que não seja maçante. Espero ter conseguido pelo menos interessar vocês no assunto.

DESCRIPTION

Hoje quero voltar a contar algumas histórias. Se vocês assistiram os vídeos do começo do canal já devem ter visto alguns trechos de como eu era no começo de carreira.

Mas desta vez quero ir bem pra trás, até o momento zero! Muita gente tem essa dúvida: como começar? Como devo escolher o que aprender? Como eu sei que não estou perdendo tempo? E pra ajudar a responder essas perguntas vou dar como perspectiva como foi pra mim mesmo, dos 13 aos 18 anos, até o 1o ano de faculdade.

Esse período compreende os anos de 1990 a 1995. E eu acho que você pode se surpreender com a minha resposta a essas perguntas.

Vídeos complementares:

• Procure o que você Ama … só que não! (https://www.youtube.com/watch?v=A2-yU3YjB1U)
• Dúvida! Devo fazer faculdade? (https://www.youtube.com/watch?v=XWVcF7BoCSc)
• O Diário de Henry Jones (https://www.youtube.com/watch?v=ii5Q2fCl8C0)
• Devo fazer faculdade? (https://www.youtube.com/watch?v=iRjEa7N8wEo)
• Sua Linguagem é Especial? - Parte 1 (https://www.youtube.com/watch?v=NwAvovzHRDU)
• Sua Linguagem é Especial? - Parte 2 (https://www.youtube.com/watch?v=O4CWVQLbi48)
• O que eu devo estudar? (https://www.youtube.com/watch?v=Ll1uAZ-WRa0)
• Minha Máquina do Tempo (https://www.youtube.com/watch?v=0KNGiOp7eoE)
• A Dimensão do Tempo para Iniciantes em Programação (https://www.youtube.com/watch?v=Qb5b8ZE9tIY)

Links:

• Globo Reporter 1991 - A Febre dos Videogames (https://www.youtube.com/watch?v=8GirQPUdlTM)
• Encoded, Decoded How Usenet—a protocol intended for conversations—was forever changed once the public figured out you could transfer binary files through it. (https://tedium.co/2017/10/03/usenet-binaries-history/)

SCRIPT

Olá pessoal, Fabio Akita

Muita gente se pergunta como aprender as coisas. Como aprender Linux? Devo escolher Java primeiro ou Python primeiro? Melhor esquecer Web e ficar no Mobile? O que devo aprender primeiro? Eu sempre venho respondendo essas perguntas no canal de diversas formas, mas cada caso é um caso.

Muita gente olha pra mim, hoje, com quase 30 anos na área e por alguma razão tem dificuldade de imaginar como chegar no mesmo nível. Pra quem esta chegando agora no canal eu fui programador minha vida inteira na última década só que passei a fazer outras coisas como palestras, geração de conteúdo e abri minha própria empresa.

Na realidade, a maioria das pessoas superestimam o que eu realmente sei e aí parece ainda mais longe. Mas todo mundo também esquece que qualquer um com X décadas de carreira teve seu dia 1 igualzinho todo mundo, sem saber nada de nada, zero conhecimento, zero experiência, e zero noção de pra onde ir. Isso é o normal, ninguém nasce sabendo o que vai fazer pro resto da vida.

Eu já vim contando algumas histórias, como no Diário de Henry Jones, na Dimensão do Tempo, Sua Linguagem é Especial, e neste episódio quero contar alguns trechos de história dos meus primeiros cinco anos, que encaixa entre esses outros episódios. Vocês vão ver que no geral as histórias não são nada especiais, nenhum episódio sobrehumano tipo entrar no MIT com 15 anos ou algo assim. Esses casos existem mas não sou eu.

Essa história é para os iniciantes ansiosos. Muitos que estão assistindo o canal, ou são jovens que estão pensando em entrar na faculdade ou estão nos primeiros anos, ou então pessoas mais experientes nos seus 30 ou 40 querendo pular pra área. Pra vocês que querem saber como muitos de nós que já passamos pela área começamos. O objetivo não é dar uma receita pra ser copiada, só dar um contexto e perspectiva. Eu realmente acho que não é tão importante ficar encanado demais nos primeiros anos. Iniciantes tem muito pouca informação pra ficar tentando escrever em pedra “é isso que eu vou fazer pelos próximos 5 anos”. Permita-se explicar.

Meus primeiros anos tendo exposição à computação foi do meio pro fim dos anos 80. Eu não tinha computador na época, eu tinha primos e amigos da escola que tinham e eu podia mexer quando ia na casa deles. Na minha cabeça um computador era uma coisa cara e inacessível pra mim, então eu só sonhava com o dia que eu teria meu próprio computador. Pensa que crianças como eu naquela época liam gibi da Turma da Mônica ensinando o que era o Dragão da Hiper Inflação e o Leão dos Impostos destruindo tudo. A gente cresceu entendendo que era normal nosso dinheiro não só não valer muita coisa. Felizmente minha família, que veio do interior tentar a vida na cidade grande, não era pobre, mas eu tinha noção que tinha coisas que eu não devia esperar ter.

Em 88 eu tinha uns 11 anos de idade, meu primeiro contato com alguma coisa que lembra código era no MSX hotbit do meu primo onde a gente minimamente precisava digitar um comando como LOAD pra carregar os games das fitas cassete. Foi assim que eu comecei a ter noção da idéia de que a gente dava comandos pra máquina executar. Eu via os códigos em revistas como a Micro Sistemas mas eu não tinha computador pra digitar. Eu via as propagandas de computadores da época como o MSX, os clones de Macintosh como o Unitron, os CP-400 ou CP-500 da Prológica, eram meus sonhos de consumo. Eu não tive nenhum deles, só pude mexer no dos outros de vez em quando.

Meu primeiro contato com programação de verdade foi em 1990, eu tinha 13 anos. Se eu não me engano alguém de telemarketing ligou em casa oferecendo desconto num curso de computação, e meus pais resolveram do nada me colocar nesse curso. Fomos eu e meu pai na verdade, aprender MBasic e Wordstar na Data Center, que já nem existe mais. Eu ouço as pessoas atrelando o aprendizado com algum objetivo fixo. Eu não entendo isso. Meu único desejo naquela época era programar qualquer coisa num computador, só isso, o único desejo de dar um comando e o computador me responder. Não tinha nenhum objetivo concreto, eu não estava pensando em aprender a programar pra ter uma carreira, ou porque eu queria abrir um negócio, nada disso. Era 1990, pensa que foi o ano que saiu Esqueceram de Mim e De Volta pro Futuro 3 nos cinemas, eu tinha 13 anos e zero noção do mundo.

Não lembro se foi nesse mesmo ano ou no ano seguinte, mas provavelmente entre 1990 e 1991, acho que meus pais se convenceram que eu realmente gostava de programar já que eu não desisti do curso, e modéstia a parte, eu entendia o Basic bem mais rápido que meu pai na época. Eu tinha um tio que era analista de sistemas, se não me engano ele fazia sisteminha pra uma loja de shopping e outros projetinhos pra outras pequenas empresas. Ainda estávamos na reserva de mercado, pra conseguir um bom computador, só indo no Paraguai, e esse tio conhecia alguém que trazia. Que nem hoje em dia que todo mundo conhece alguém que trás hardware de Miami. A gente não tinha Mercado Livre ou Gearbest, o mais próximo disso era a página de classificados nos jornais.

Enfim, meu pai resolveu investir num PC XT, com poderosos 1 MB de RAM, muito acima dos normais 640 kilobytes, um drive de floppy disk de 5 1/4" e outro mais moderno de 3 1/2" que suportava disquetes dupla face!!E poderosos 10MB de HD, que sei lá porque a gente chamava de Winchester naquela época. E junto um monitor CGA de 4 tons de fósforo verde e uma impressora matricial Epson FX 1050. O computador vinha com MS-DOS 3 e eu tinha GW-Basic e meu tio deixou instalado dBase III. Isso deve ter sido bem caro, hoje eu estimo que deve ter custado quase 2000 dólares em dinheiro dos anos 80! Eu tinha noção que era bem caro. E era basicamente isso que eu tinha. E era tudo que eu precisava, a partir daí eu me virei.

Pra ter uma noção de como eu tava feliz eu queria fazer meu próximo trabalho da escola no computador e imprimir na novíssima impressora, claro! Mas eu sequer tinha um editor de textos, e não tinha internet pra baixar. Como que eu fiz? Bom, a única coisa que eu sabia era Basic. Pois bem, abri o interpretador e fui digitando linha a linha do trabalho usando o comando PRINT. Detalhe, que eu não sabia e nem lembro se dava, pra navegar de volta pras linhas de cima. Uma vez que digitou era difícil de corrigir depois. Então da primeira vez eu tive meio que digitar do começo ao fim sem errar, felizmente era um texto curto. E foi assim que imprimi meu primeiro trabalho!

Em pouco tempo eu comecei a juntar mais programas. O DOS 5 eu acho que foi onde apareceu o editor Edit e o Quick Basic. Eu consegui uma cópia do Wordstar, do Lotus 1-2-3. A primeira apostila de dBase III eu acho que peguei emprestado com um primo mais velho que tava estudando. E o que eu fiz na época? Lembram que no episódio de Henry Jones eu contei que antes de ter um computador um hobby que eu tinha era copiar textos da enciclopédia na máquina de escrever? Então, eu copiei digitando, página a página dessa apostila no Wordstar pra imprimir minha própria versão. Detalhe que eu usei pouco porque depois de copiar todas as sei lá, 100 páginas da apostila, eu acabei aprendendo o dBase III.

Os anos meio que não são exatos mas acho que foi alguns meses depois, talvez final de 91? Meu tio perguntou se eu aprendi o tal dBase e me convidou pra ajudar ele nas férias da escola. E foi assim que consegui meu primeiro estágio. Ele passava os dias na tal loja, visitava clientes, e chegava no fim do dia com especificações e explicava o que ele queria, dai eu passava o dia seguinte na casa dele programando. Ele tinha um computador muito melhor que o meu, acho que já era um 386 com monitor VGA e eu obviamente já tava muito feliz só de poder usar um computador mais potente, e colorido! E assim eu comecei a migrar do dBase pro Clipper Summer 87 que tinham linguagem compatível, e logo na sequência pro Clipper 5. Fiz programas de controle de estoque, programa pra gerenciar um escritório de advocacia, programa que gerenciava não lembro o que de avião particular, e coisas assim.

Sendo bem honesto eu não tenho idéia de quanto do meu código era realmente aproveitável, mas eu seguia o exemplo dos outros programas do meu tio e ouvia os feedbacks dele no dia seguinte. Lembrando que eu programava do computador dele direto porque era mais eficiente, não tinha internet pra eu poder trabalhar remoto, não tinha Git, não tinha nada disso ainda. Controle de versão era basicamente um conceito desconhecido. Backup era em disquete. Assim foi uns dois meses das minhas férias de verão quando eu tinha uns 14 anos.

Clipper pra mim era o que provavelmente Javascript, ou Java, ou Visual Basic é pra muitos de vocês: a minha primeira linguagem favorita. Eu achava que dava pra fazer tudo em Clipper. Meu editor favorito na época era o Norton Editor, meu tio me apresentou pro Sidekick que era um programa residente em memória no DOS que tinha um help pros comandos do Clipper, utilitários como calculadora. Era tudo que eu precisava no meu ambiente de desenvolvimento. A partir desse ponto meio que já tava decidido que eu provavelmente ia escolher computação como faculdade. Outro contexto: fazer faculdade nunca foi uma opção, eu sempre encarei como o próximo passo natural depois do colégio, então eu nunca parei pra pensar em não fazer. De qualquer forma, depois desse estágio com meu tio, eu peguei mais alguns projetinhos por conta. Lembro de ter feito um programa de controle de estoque pra uma loja de bebidas do bairro por exemplo, e vocês não imaginam como eu fiquei contente quando consegui fazer um joguinho e meu próprio editor de textos simples, tudo em Clipper.

Pra ser mais honesto, ainda havia uma outra direção que eu ficava flertando. Desde criança tinha outra coisa que eu gostava de fazer e era desenhar. Olhando em retrospecto, claro que eu não era tão bom quanto eu achava que eu era. Mas vamos lá, eu era um pré-adolescente. A gente nunca tem noção de quanto é bom ou ruim em alguma coisa. Mas de qualquer forma eu gostava de desenhar. Eu tinha poucos amigos na época, eu nunca joguei bola na rua ou coisas assim, eu passei minha infância basicamente dentro de casa. Lá pelos 14 anos um menino da rua que estudava na mesma escola que eu acabou fazendo amizade comigo e foi interessante porque ele era o oposto de mim: eu sempre fui o japonês CDF introspecto e quieto e ele era o extrovertido. Vocês tem que entender que famílias japonesas eram bem mais rígidas, particularmente nos anos 80. De qualquer forma, nessa época a gente tava aprendendo computador ao mesmo tempo e ele sendo mais atirado conseguiu um bico pra gente na Fenasoft. Antigamente existiam 2 grandes feiras de tecnologia, a Fenasoft e a Comdex, coisa tamanho da Feira do Automóvel de hoje, que acontecia no Centro de Convenções do Anhembi.

Esse meu amigo era um ano mais novo que eu mas o filho da mãe era ligeiro, e inteligente. Ele puxou conversa num quiosque da Brasoftgames no shopping e eles ficaram impressionados e convidaram ele pra trabalhar na Fenasoft apresentando jogos. Porém teve um problema, a idade limite pra trabalhar era 15 anos e ele sendo um ano mais novo acabou não podendo ir e ele me mandou no lugar dele. Enfim, como eu disse o evento era gigantesco, ocupava o pavilhão do Anhembi inteiro, então imagina o tamanho. A estande da Brasoftgames era um dos maiores, com um super telão com palco e vários quiosques menores. Acho que o ano era 1992 e as novidades eram os novos kits multimidia que adicionavam CD-ROM, com super velocidades de 2x e 4x eu acho, e placas de som, os Adlib e Soundblaster. E jogos como Star Wars Rebel Assault, X-Wing e Tie Fighter.

Eu contei tudo isso pra chegar no seguinte episódio. E aqui eu devo dizer que não lembro de todos os detalhes mas se não me falha a memória aconteceu a seguinte situação. Imagina que a gente ficava nesses quiosquinhos espalhados pelo estande gigante, com um microfoninho que saia nas caixas de som daquela época, apresentando os jogos, e juntava um pessoal ao redor pra ver. De vez em quando nosso chefe subia no palco do telão e falava algumas merdas e fazia piadas sem graça. E aqui vem a parte que eu não lembro se foi assim mesmo que aconteceu mas eu lembro que eu tava ficando irritado com as piadas sem graça e as informações erradas que ele falava. E meio sem perceber, quando isso acontecia, meu quiosque que ficava perto do palco era interrompido porque o som do palco era mais alto. O que eu fiz? Eu comecei a gritar mais alto no meu quiosque. E eu acho que tava funcionando, o povo ficava olhando minha apresentação. Daí o chefe do meu chefe apareceu no meu quiosque uma hora.

Eu não entendi nada, mas acho que ele disse alguma coisa tipo “você, pra lá” e me mandou pro palco. De novo, vocês lembram que eu falei que eu sempre fui o japones CDF introvertido que nunca fala. Ênfase no “nunca”. Eu aquele tipo que na escola fazia trabalho em grupo sozinho sem ajuda dos outros só pra não precisar falar na frente de classe, e deixava alguém só falar no meu lugar. Já era um esforço sobrehumano eu estar naquele quiosquinho me acostumando a apresentar pra meia dúzia de pessoas aleatórias. Eu não sabia falar em público, nunca foi natural, especialmente aos 15 anos. E de repente lá estava eu, num palco, numa feira, na frente de um telão e com uma multidão olhando pra mim, esperando eu apresentar.

Esse foi um daqueles momentos “ou vai ou racha”. A imagem que me veio à cabeça foi que quando eu tinha uns 10 anos ou menos, eu tive que fazer uma pequena apresentação em público, num eventinho da comunidade japonesa do bairro, eu gaguejei, muito, eu desesperei e eu fugi do palco. Foi um trauma e agora, 5 anos depois, eu tive quase certeza que ia acontecer a mesma coisa. E pra minha surpresa eu tomei uma decisão consciente de não fugir. Essa foi a primeira vez que eu consegui falar em público direito e foi a primeira vez que eu me dei conta que talvez fosse possível eu falar em público. Muita gente me conhece hoje como palestrante, vocês não tem idéia de como foi difícil eu aprender isso. Eu nem sei dizer se a apresentação foi boa ou não, mas como não me expulsaram do palco, vou acreditar que foi bom o suficiente.

Porém, meu chefe, o alemão que me irritava quando subia no palco, acho que não gostou do chefe dele ter me colocado no palco porque no ano seguinte ele me barrou de trabalhar de novo. Mas aí aquele meu amigo conseguiu um bico no concorrente no mesmo evento e fomos pra Magnasoft. Com 16 anos eu já tava um pouco mais confiante e acho que foi nesse evento que outro episódio interessante aconteceu. Um dos programas que eu tinha que apresentar não era grandes coisas, era algum tipo de pacote educativo que tinha um programa nível de Paintbrush do Windows, pra desenhar. E eu disse que eu gostava de desenhar. Um dos jogos que eu gostava naquela época pela arte era o Tazmania e eu fiquei lá desenhando. Pensa que desenhar com um mouse de bolinha era muito ruim, mas eu já estava acostumado. E por acaso apareceu um jornalista que gostou daquilo e me convidou pra aparecer em algum jornal local da época. Como eu disse antes, eu não tinha muita idéia se o que eu desenhava era considerado bom ou não, mas isso foi um empurrãozinho.

Eu sempre fui fã de quadrinhos, games, mangás, animes, tokusatsu, era o que eu desenhava. Das revistas de videogames, como a Ação Games e Videogame eu era fã de alguns gamers da época e por acaso conheci um deles nessa Fenasoft, o Toni Ricardo Cavalheiro. Se vocês tem perto da minha idade talvez se lembrem desse Globo Reporter de 1991 ou 1992.

E ele aparecia lá também. Por causa desses eventos nessa época eu finalmente fiquei mais comunicativo e fiz amizade com ele. Cheguei a ir na casa dele com disquetes copiar jogos, e foi como tive acesso a coisas como Doom, The Lost Vikings, Lemmings e mais. E ele me apresentou pra revista Videogame, onde ele trabalhava fazendo reviews dos jogos. Naquela época, pra conseguir programas e jogos você tinha que pegar sua caixa de sapatos com disquetes, pegar um ônibus e ir na casa de alguém que tinha. Vocês não tem idéia de como a vida de vocês é fácil com internet hoje.

Eu pensei em fazer ilustrações pra revista já que apesar de gostar de games eu nunca fui nível de gamer profissional. Levei meu portfolio pra editora, e eu não sei se o editor não curtiu meus desenhos ou se foi sincero, mas ele começou perguntando se eu sabia fazer ilustração em computador, e claro, eu não sabia. Esses desenhos que estão aparecendo aqui do lado são meus lápis de 91 a 92 se não me engano. E ele disse “pois é, hoje em dia as ilustrações são todas digitais e vetoriais, precisa saber usar um CorelDraw”. Naquele mesmo dia eu fui pra uma livraria e comprei um livro de CorelDraw 3.

Passei o próximo mês aprendendo a ilustrar com CorelDraw. Em 1993 eu tinha ganhado meu segundo computador, um 386 de poderosos 66Mhz e acho que já tinha 2 ou 4 MB de RAM com uns 30 MB de HD. E agora eu tinha um monitor VGA. Coloque em perspectiva, era um monitor de 640 x 480 de resolução. O que chamamos de HD hoje em dia é 1920 por 1080, era 4 vezes menos densidade de pixels e tinha só 256 cores. Ah sim, e o mouse mais barato que você acha hoje já é ótico, o meu mouse naquela época era de bolinha, e ele era muito impreciso, enrolava fio de cabelo e sujeira dentro, era uma desgraça. Pensa ilustrar naquela época como era. Mesmo assim, eu treinei o quanto pude. Passava meus fins de semana fazendo ilustrações e depois de algumas semanas eu aprendi a maioria das técnicas e montei um novo portfolio, e fui bater na porta da editora de novo. E pra minha surpresa, acho que eles gostaram porque por alguns meses eu fiz ilustrações pra revista Videogame. Era uma ilustração de matéria por mês, por alguns meses só, não era grande coisa, mas eu já tava bem feliz de ter meus primeiros trabalhos publicados.

Em 94 eu parei tudo. Foquei exclusivamente em terminar o 3o colegial e conseguir passar em alguma faculdade. E eu me coloquei na obrigação de passar em alguma faculdade pública porque eu não queria que meus pais passassem os próximos 4 ou 5 anos tendo que pagar faculdade particular ou eu ter que trabalhar e estudar ao mesmo tempo pra dar conta. Eu saía de casa sei lá, 6 horas da manhã e voltava sei lá, 8 horas da noite, todos os dias e só parei depois do último vestibular do ano. Eu realmente levei isso a sério. Tinha 3 cursos que eu podia fazer naquela época: tecnólogo em processamento de dados na Fatec, um curso que na época era novo de engenharia de software ou engenharia de computação na Unicamp e bacharelado em ciência da computação na USP. No final passei nos 3 e escolhi fazer ciências da computação. Eu não tinha a mínima idéia da diferença dos 3 cursos naquela época.

Vamos pra 1995. Pra dar contexto, eu vi alguns dias atrás que vão lançar o terceiro filme da franquia Bad Boys do Michael Bay com o Will Smith e Martin Lawrence e eu dei risada de como o Martin tá gordo nesse filme. Mas o primeiro saiu em 95, pensa que foi 24 anos atrás. Nesse ano também saiu o 1o Toy Story, que foi uma revolução absurda em ser o primeiro longa metragem inteiro renderizado por computador numa época onde pouquíssimas pessoas tinham computador em casa e normalmente era alguma coisa como um 486 de 100Mhz e onde 4MB de RAM era considerado bastante.

Finalmente, na faculdade, eu podia deixar meus dias de CDF introspecto na escola pra trás e resolvi treinar pra ser mais extrovertido. Na minha época a gente chamava os novatos de bichos, acho que hoje ainda é bicho? Pra dar uma idéia de como eu tava testando meus limites, eu acabei ficando amigo de um grupo que resolveu que no 1o semestre a gente ia concorrer ao centro acadêmico contra a chapa de veteranos e nos auto entitulamos Chapa Bicho. Lembra meus desenhos de Taz na Fenasoft e meus skills de CorelDraw? Pois é, foi assim que eu fiz cartazes como esse aqui do lado. A gente era bem ativo, e não ganhamos por muito pouco. Meu primeiro semestre na USP já começou conturbado, e em paralelo a isso me engracei com a empresa junior e fiz cartazes pra eventos na faculdade como esse outro pra Oracle.

Pense que em 95 o Linux ainda não tinha muito mais que uns 4 anos de vida. Internet era absolutamente opcional ainda. Muita gente ainda nem tinha idéia direito de pra que servia Internet. Não se pode negar que eu tive o privilégio de poder cursar ciências da computação no Instituto de Matemática e Estatística da USP. Universidades como USP ou Unicamp estavam sentadas em cima do backbone da Fapesp, um dos poucos backbones que conectavam as universidades ao resto do mundo. Não era incomum algum problema nesse backbone deixar a gente ilhado e restrito a navegar só no Brasil, por exemplo.

Se formos falar de sistemas operacionais como MS-DOS com a interface gráfica do Windows 3.1 por cima, por exemplo, o stack TCP ainda era opcional. Você precisava instalar o Windows 3.1 for Workgroups ou instalar a stack TCP separadamente. Pra ter uma idéia de quão antigo estou falando, hoje em dia a gente usa redes cabeadas usando cabos 1000base-t ou 10Gbase-t, cabos twisted pair com conector RJ-45 em topologia de estrela. Antigamente eu trabalhava cabeando as salas da USP usando ethernet sobre cabo coaxial com conectores em T em rede que exigia um terminador, que é um resistor no final da rede em daisy chain. Qualquer ponto em T no meio da rede que alguém mexesse podia derrubar toda a rede local. Eu lembro que eu não sabia disso e justo na minha máquina ficava o terminador da rede. Eu não sabia o que era aquilo e desconectei. Dali a pouco desce a diretora do Centro de Computação e Eletrônica da Politécnica, o CCE, xingando “quem foi que derrubou a rede”. Pois é, isso acontecia em 1995, a gente usando tecnologia de 1985.

Enfim, eu mudei de assunto aqui, foi só pra lembrar que eu já fui estagiário um dia também. Falando em ser estagiário, eu preciso deixar registrado um outro conhecimento aleatório que queimou no meu cérebro e eu nunca mais esqueci. Quem aqui sabe o que é uma gaiola de faraday? Eu fazia manutenção dos micros das salas de computação. O CCE onde eu trabalhava era lotado de periféricos e peças. Numa das manutenções eu fui trocar o HD quebrado de um computador por um novo. O que eu fiz? Tirei o HD novo do saco plástico, coloquei em cima do saco e liguei o cabo de força pra testar. Dali a pouco sobe um cheiro de queimado e eu descobri que eu fritei a placa embaixo do HD. Por que? Pelo menos naquela época o saco tinha uma redinha desenhada do lado de fora e eu não sabia pra que servia. Nesse dia eu entendi, era uma gaiola de faraday pra proteger o HD dentro. Assim como seu carro. Do lado de dentro ele é eletricamente isolado, mas do lado de fora é altamente condutor, e eu encostei a placa do HD em cima da redinha do lado de fora e liguei o HD, altamente condutor, fritou tudo na hora … Coisas de estagiário. Pelo menos eu nunca mais esqueci.

Sobre esse estágio no CCE. Antes de entrar na USP, de vez em quando eu ajudava a BBS de um amigo meu, que era o meu vizinho da mesma rua. Lembra do meu amigo extrovertido que conseguiu os bicos na Fenasoft? Caso alguém das antigas se lembre, a BBS dele era a Medusa, o apelido online dele era Jungle. Uma das coisas que ele fazia era distribuir warez, pirataria mesmo, eu ajudava de vez em quando. Não me julguem, eu também já tive minhas épocas de não ter grana e a única forma de experimentar algum programa ou jogo era pirateando. Mesmo porque muita coisa de fora simplesmente nem chegava aqui. Não era incomum a gente usar blue boxes, que se vocês já viram algum documentário sobre Steve Wozniak deve lembrar quando ele conta a história do apito que vinha de brinde na caixa de cereais norte americanos Captain Crunch que conseguia emitir o sinal de 2600 hz que resetava a linha de trunk e com isso a gente conseguia habilitar ligação de longa distância de graça nas linhas telefônicas.

Eventualmente o povo criou software que rodava em placas de som como Soundblaster e com isso a gente conseguia fazer ligação internacional cobrando pulso de ligação local. Era só pegar o telefone, abrir a linha pra operadora, pegar o fone de ouvido ligado na Soundblaster, rodar o programa que rodava o tom e com alguma sorte ele abria a linha e agora a gente podia discar internacional. Era uma técnica de phreaking e embora nós só fôssemos os equivalentes a script kiddies hoje em dia, o povo gostava de se auto entitular phreaks. Acho que chegamos a testar black boxes também.

Enfim, a intenção era conseguir conectar em BBS de outros países como Alemanha. E além disso eles conectavam em servidores UNIX que estavam abertos na rede. Antigamente a senha hasheada ficava armazenada no arquivo passwd que era legível a um usuário guest. E o algoritmo de hash era fraco, e com brute force e rainbow tables a gente eventualmente conseguia quebrar algumas senhas e com isso tínhamos acesso a armazenamento em algum servidor. Daí a gente conseguia transferir programas pra essas contas que dávamos hijack pra fazer download com calma depois.

Lembrando que era hiper lento baixar coisas via modens de 19200 baud ou menos na época, nem estamos falando ainda de modens de 56k da última geração. Aliás, por causa desse tipo de coisa eu acho que separaram os hashes de senha nos arquivos shadow que tem permissões mais restritas. Vocês nunca se perguntaram porque existem os arquivos passwd e shadow num UNIX e Linux? O arquivo shadow já existia desde 86 mas muitos servidores UNIX rodando na época não estavam atualizados, lembrando de novo que atualizar um servidor naquela época não era só rodar um simples ‘apt upgrade’.

Essa época de BBS era quando eu tinha uns 15 a 16 anos. Depois que eu entrei na faculdade ficamos sabendo que era possível eu conseguir ganhar uma conta num servidor UNIX da faculdade com acesso à internet se eu fosse trabalhar como monitor na sala do CCE na Politécnica. Internet banda larga em 95 quando a gente usava modems hiper lentos. Lógico que eu decidi tentar e essa foi a motivação pra eu ir estagiar no CCE e pra eu aprender UNIX: baixar warez de forma mais rápida. Pois é!

De qualquer forma, uma coisa leva à outra. O acesso à internet que eu tinha era logando via telnet do pczinho da sala de computação onde eu era monitor. Era acho que um mísero 386 com monitor VGA de 256 cores, mas isso não importava porque o acesso era via Telnet, ou seja, terminal texto. Uma vez logado você caía num shell, acho que era Korn Shell. Uma das chatices dos computadores da sala era que eles tinham um timeout, não lembro se era de 1 hora. O computador fazia boot remoto. Ele tinha uma placa de rede e um EPROM que no boot ele baixava o DOS e Windows do servidor então não adiantava modificar os arquivos locais porque a cada boot ele zerava tudo e baixava de novo. No DOS era carregado um programa que depois de 1 hora ou algo assim ele forçava acho que um Halt and Catch Fire ou HCF e derrubava o computador inteiro.

A primeira coisa que os estudantes mais dedicados queriam era ficar mais tempo e daí a primeira coisa que os mais espertos aprenderam a fazer foi derrubar esse programa. Como era DOS alguns estudantes mais ligeiros entenderam que se tratava de um Terminate and Stay Resident ou TSR com uma system call chamada talvez pela INT 21h, eu posso estar errado mas era algo assim. Então era só carregar qualquer outra coisa nessa interrupção e assim apagar a rotina de derrubar a máquina que era carregado no boot do DOS. A gente era insistente.

Agora eu caía no shell do UNIX. Você acha Linux hoje complicado? Você não tem idéia de como era chato um UNIX de verdade, no caso um HP-UX pra ser mais exato. Era engraçado que por alguma razão os servidores da Politécnica tinham nomes de animais como Lion, Spider. Depois resolveram colocar nomes de origem indígena, a máquina que eu tinha conta era no Amandy. Bom, pra conseguir fazer qualquer coisa útil eu precisava primeiro aprender a navegar pelo shell. E repetindo que naquela época não existia stackoverflow nem muito menos Google. Aliás, também não tinha Amazon pra comprar livros nem nada disso. A gente tinha que aprender as coisas na marra mesmo.

Como eu venho da época do MS-DOS onde basicamente a gente precisava saber comandos pra fazer qualquer coisa, o UNIX era só outra linha de comando diferente. Eu não tive o choque de ter começado numa interface gráfica e de repente cair na linha de comando. Pra mim foi o oposto, a interface gráfica que sempre foi opcional. Assim começou minha jornada pra aprender o básico, no DOS eu sabia listar as coisas com o comando ‘dir’ agora no UNIX era usando ’ls’, no DOS eu copiava as coisas com comando ‘copy’ no UNIX era ‘cp’ e assim foi indo, um comando de cada vez. Ajudava bastante que fiquei amigo de veteranos do curso de Engenharia Elétrica da Poli, que por alguma razão eram muito mais tech savvy que o povo do IME na época. Por causa disso eu tive mais amigos na engenharia da Poli do que no meu curso no IME. Era um pessoal que desenhava circuitos integrados no café da manhã. Eu falo que cursar uma faculdade não é só pelo curso em si, mas sim por esse tipo de networking. Eu era o mais novo e o mais noobie de todos, e eu era uma esponja aprendendo tudo que conseguia deles.

Como em linha de comando não havia um navegador gráfico e como a Web no começo era muito simples, eu usava o Lynx como navegador. Hoje em dia com HTML 5, CSS 3, WebGL é impossível usar o Lynx. Eu costumo dizer que quebraram a Web hoje, mas se quiser navegar via linha de comando recomendo tentar o Browsh, que é bem mais moderno. Pra acessar meus e-mails tinha o comando ‘mail’ que era bem primitivo e eu nunca aprendi a usar direito mas felizmente tinha o cliente de e-mail ‘pine’. Se você já usou o editor Nano no Linux de hoje em dia, ele é o clone do editor Pico, que era o que vinha no cliente Pine e que eu usava todo dia em 95. Na época eu não usava Vim mas sim o Vi original e eu lembro do desespero de entrar e não conseguir sair da primeira vez, como todo mundo. Aprender o dois pontos “q” foi uma revolução! Aliás, uma versão alternativa mais moderna do que o Pine hoje parece ser o Aerc, ou você pode usar o fetchmail pra popular o maildir, ou eu “acho” que tanto o Pine quanto o Mutt suportam IMAP pra se conectar em servidores de e-mail mais modernos. Antigamente o protocolo era o POP3 e procmail.

Na sequência, aprendi a usar a Usenet, um pouco de Gopher, IRC e assim meu arsenal começou a aumentar. Mas preciso confessar que eu gastava a maior parte das minhas horas perdendo tempo em chat de IRC mesmo. E eu não estou falando de mIRC no Windows, mas do cliente de IRC original do UNIX na linha de comando. A gente fuçava mensagens na Usenet, descobria servidores onde o povo deixava arquivos, baixava bastante coisa via FTP. Tinha bastante coisa gratuita não-warez no FTP da Unicamp na época, foi onde eu baixei o beta do Java que ficava numa pasta chamada Oak, que depois fui entender que era o codenome do Java antes do 1.0.

Os protocolos de internet na época eram muito simples, a maioria baseado em texto e estamos falando de uma época anterior a encriptação como TLS, então hoje usamos SSH mas antigamente era só Telnet. Hoje usamos SCP mas antigamente era FTP e assim por diante. Além de FTP, muitos programinhas e mesmo imagens e outros arquivos binários eram trafegados no corpo das próprias imagens na Usenet ou até IRC. Pense google groups ou stackoverflow de hoje. Porém na usenet só trafegava texto, então como trafegar binários? Assim eu aprendi sobre unix to unix copy protocol ou UUCP e as ferramentas uuencode e uudecode, que transformava binários de 8-bits em textos de 7-bits. O equivalente hoje seria o encode e decode de Base64. Finalmente o tráfego de warez estava começando a acontecer agora que eu sabia como me comunicar, onde procurar, e como trafegar os binários.

Mesmo em banda larga às vezes a fonte vinha de servidores lentos. E às vezes os arquivos eram quebrados em múltiplas mensagens na usenet. Daí a gente aprendeu a deixar os downloads via FTP rodando em background e com isso eu aprendi que UNIX suporta o conceito de jobs. Rodar o comando com o “E” comercial no final ou fazendo Ctrl + Z e aprendi a usar comandos como ‘bg’ e ‘jobs’ e ’nohup’. Eu não me recordo de ter usado comandos como ‘disown’, eu não entendia muito bem o conceito de signals ainda, como o HUP de hang up quando o terminal desconecta, fui aprendendo aos poucos. De qualquer forma, assim eu podia deixar as coisas baixando em background, deslogar da minha sessão, ir pra casa e no dia seguinte, se nada deu errado, pegar meus arquivos. Vocês podem ver que eu fui aprendendo a usar UNIX com a motivação de baixar pirataria, um motivo super nobre!

Não era comum na época consumir as coisas online como fazemos com YouTube ou Spotify. A banda era limitada, a velocidade era baixa, então a gente baixava tudo pra poder consumir depois. Vou dizer que a essa altura eu já estava menos interessado nos warez e mais engajado nas salas de chat de IRC e tentando entender melhor como a Web funcionava. Interessante que eu usava Windows 3.1 e Windows NT já naquela época, a gente tinha navegadores como Netscape Navigator Gold onde eu aprendi a editar HTML, FrontPage da Microsoft, editores como o HotDog eu acho, mas pra coisas como IRC, FTP, Usenet a gente usava terminal mesmo. A internet era mais devagar nas máquinas locais e mais rápido do servidor, então era um incentivo pra continuar no terminal. Eu finalmente comecei a me sentir confortável com essa tal de Internet e suas tecnologias de base.

E esse foi um pequeno resumo de alguns episódios que eu lembro entre 1990 e 1995. O episódio não tem nenhum objetivo muito educativo a não ser contar minha história mesmo. Pode ser que eu esteja sendo leviano mas até hoje eu nunca atrelo aprender alguma coisa com nenhum objetivo muito grandioso. Eu nunca penso “vou aprender X porque isso pode ser mais lucrativo no futuro” ou “quero aprender Y porque parece que vai me levar pra uma carreira mais promissora” ou qualquer coisa planejada assim. Todas as memórias que eu tenho de aprender alguma coisa sempre tiveram objetivos super banais, como vocês puderam ver. Se resumir a última metade do vídeo você pode dizer que eu aprendi UNIX pra baixar pirataria mais rápido. Só que tudo que eu aprendi: copiando apostila de programação, sendo estagiário do meu tio, apresentando games na Fenasoft, fazendo ilustrações pra revista videogame, aprendendo as tecnologias de internet pra baixar warez, tudo me levou a aprender coisas como dBase, Clipper, CorelDraw, UNIX e aprender a falar em público.

Eu falei no episódio de Procure o que Ama só que não, que eu gosto do meu esforço, e é isso que eu quero dizer. Naquela época dos 13 aos 18 anos eu sequer tinha essa noção de que a gente devia procurar alguma coisa que ama. Eu só fui fazendo, sendo curioso. Aliás, a definição de hacker pra mim é uma pessoa curiosa com tecnologia. Uma coisa foi levando a outra, e sem querer se passaram 5 anos que eu fui aprendendo um monte de coisas que se tornariam importantes nos anos seguintes.

Se eu ficasse toda hora pensando “ah, não vou perder tempo com isso porque não sei se vai ser útil daqui 5 anos” eu ia ficar estagnado o tempo todo só planejando, planejando e nunca de fato fazendo. Esquece, nessa fase da vida é inútil ficar planejando, a gente é jovem demais pra ter noção real de qualquer coisa. E eu estou parando a história exatamente antes de começar a primeira bolha da internet, nesse ano eu ainda ia ver o lançamento de coisas como Java 1.0, Delphi 1.0, Flash 1.0 no ano seguinte, .NET nem existia ainda, todo mundo ainda usava Perl e não Python, UNIX e não Linux, PHP ainda não tinha começado.

Esse foi um breve resumo dos meus primeiros 5 anos, eu sei que não é um conhecimento geral mas eu queria deixar registrado essa fase pra posteridade, espero que tenha ajudado a dar alguma perspectiva pra alguns de vocês. E vocês, como foram os seus primeiros 5 anos? Não deixem de compartilhar nos comentários abaixo, se curtiram mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê, até mais!

Descrição no YouTube

Uma coisa que recomendo que todo mundo faça: backups. Faça backup de todos os seus trabalhos. Daqui 20, 30 anos, você vai se agradecer por ter feito isso.

Aproveitando a dica, quero abrir uma pequena janela pra um hobby que eu tinha nos anos 90: os sites de anime que eu fazia.

E ainda terminando com uma confusão que deu até boletim de ocorrência :-D

Links:

• Meu Passado Otaku – A revista de anime que publicou… um Boletim de Ocorrência (!!!) (https://maisdeoitomil.wordpress.com/2016/03/07/meu-passado-otaku-a-revista-de-anime-que-publicou-um-boletim-de-ocorrencia/)

AkitaOnRails:

• [Off-Topic] Meu Backup Pessoal (Drobo/Time Capsule) (http://www.akitaonrails.com/2009/09/19/off-topic-meu-backup-pessoal-drobo-time-capsule)
• [Off-Topic] Faça Backup do seu Ambiente (http://www.akitaonrails.com/2011/03/01/off-topic-faca-backup-do-seu-ambiente)

Script

Olá pessoal, Fabio Akita

Se vocês ainda não me seguem nas redes sociais procurem por AkitaOnRails no Facebook, Twitter e Instagram. Quem me segue no Instagram sabe que alguns dias atrás eu resolvi finalmente abrir minha cápsula do tempo. Os códigos que vocês viram nos episódios da série Sua Linguagem É especial? vieram daí.

Quando eu era criança eu não lembro se foi no Show de Beakman ou outro programa infantil desse tipo, onde eu vi o conceito de Cápsula do Tempo pela primeira vez. Não é só acumular velharias. É empacotar seu presente intencionalmente pra ser aberto bem no futuro.

Intuitivamente eu nunca tive vontade de fazer o mais óbvio: pegar uma caixa de sapato e colocar pertences meus da época como uma fita cassette ou brinquedo. Em vez disso eu queria de alguma forma preservar o que eu era. E eu me defino não pelo o que eu possuo, mas o que eu penso e produzo. Eu não sou apegado a nenhuma posse. Por sorte, tudo que eu produzo é digital.

Eu já tinha visto os disquetes de 8 polegadas e depois os de 5 1/4 polegadas ficarem obsoletos, eu estava vendo os disquetes de 3 1/2 ficarem obsoletos. Então eu fui gradativamente passando tudo de disquetes pra zip drives, de zip drives pra CD-ROMs (quando finalmente os gravadores ficaram acessíveis), de CD-ROMs pra DVD. E de DVD pra HDs. As coisas hoje em dia estão muito fáceis, antigamente eu tinha caixas e caixas de disquetes, CDs e DVDs, hoje cabe tudo num HDzão.

Em 2008 obviamente eu tinha noção que HDs tem vida útil e costumam falhar, são dispositivos mecânicos que não foram feitos pra durar pra sempre. Assistindo os primeiros video casts, programas tech que existiam desde antes do YouTube, que você via no iTunes, eu vi um programa da Kali Lewis sobre Drobos. Eu já sabia o que era uma configuração RAID de storage pra servidor mas eu achava complicado pra ter em casa. Mas o Drobo tinha a intenção de ser portátil e plug and play. Então eu resolvi pedir pra um amigo trazer pra mim.

E o Drobo realmente funcionou. Eu fiquei com esse Drobo por 10 anos. Nesses 10 anos eu troquei discos 2 vezes porque falharam, e isso justificou essa compra. Custou caro pra caramba, na época foi quase 800 dólares se somar com os HDs. Mas se considerar que foi 800 dólares que protegeram minha história por 10 anos, eu digo que foi extremamente barato. Eu troquei de Drobo ano passado. A porta USB 2 era muito lenta, troquei pelo mesmo modelo com USB 3, que ainda não chega a ser um Thunderbolt, mas já ajuda. Eu tirei todos os 4 HDs do antigo, coloquei no novo, e boom, plug and play, tudo funciona. Impressionante.

O objetivo não é fazer propaganda do Drobo, claro, mas eu não confiaria em nenhum HD externo que não seja redundante. Aliás, muito cuidado, existem muitas configurações de HD externo com 2 ou mais HDs em layout de RAID-0 com striping. É só a pior configuração imaginável porque se você tem 2 HDs de 500 GB em striping, você enxerga como se fosse um único HDzaão de 1 TB. Só que não tem proteção contra erro nem redundância, se um dos HDs falhar, você perde os dados DOS DOIS. Jamais use RAID-0. E RAID-1 é o pior custo benefício porque é basicamente um HD fazendo cópia do outro.

Temos outro problema hoje em dia. Tudo está no maldito cloud. O problema não é o cloud, o problema são serviços que dificultam você sincronizar uma cópia local. Você está tão acostumado que o Google vai cuidar dos seus e-mails, que o Dropbox ou Microsoft OneDrive ou Google GDrive vai cuidar dos seus arquivos, que o Slack vai cuidar dos seus chats, que a Apple vai cuidar das suas fotos e músicas, que você literalmente não pensa em fazer mais backup hoje em dia.

Eu prefiro partir do princípio que qualquer um deles pode ter uma falha amanhã, nem estou dizendo falir, uma falha mesmo, e podem perder meus dados. Eu não preciso guardar tudo, mas de meses em meses eu acho saudável exportar os arquivos do Twitter, eu gosto de abrir um Mozilla Thunderbird e conectar nos meus diversos e-mails pra sincronizar tudo local via IMAP, prefiro baixar tudo do Dropbox e manter um backup local no meu Drobo, e assim por diante.

Nos últimos anos eu confesso que tenho sido menos cuidadoso com meus backups por conta de todos esses serviços cloud, mas é bom não descuidar. 25 anos depois, eu me arrependo de não ter guardado os fontes dos meus primeiros programas em Basic. Existem coisas que quando você tiver conseguido guardar dinheiro vai ainda conseguir encontrar algum colecionador vendendo, um MSX, um TK-85, mas seu primeiro programa? Isso não tem mais como.

De qualquer forma, este mês eu finalmente resolvi abrir meus arquivos antigos. Meus e-mails de 1997 a 2006, quase 10 anos de e-mails foram preservados em arquivos PST do Outlook que, felizmente, são fáceis de abrir. De 2006 em diante está tudo no Gmail. Viu meu vídeo sobre Sua Linguagem É Especial que eu mostro os sites que eu trabalhava pra PSN como o do Corinthians e Cruzeiro? Eu tenho as imagens porque eu ainda tenho o Photoshop original que eu usei pra recortar as imagens pro site. Estavam como anexo nesses e-mails.

Essa é uma daquelas coisas que de vez em quando dá trabalho, você gasta dinheiro e tempo, mas o prêmio é que eu tenho uma oportunidade única: de viajar no tempo, pra qualquer lugar de hoje até mais de 20 anos no passado. Eu ainda ia esperar mais uma década antes de abrir, mas eu sinto que agora é a hora de fazer isso. Vai que amanhã eu morro e perco a oportunidade de deixar registrado pra posteridade?

Eu não guardei todos os instaladores de todos os programas que eu usava. Mas por sorte achei esse site WinWorld que tem instaladores de tudo que é programa dos anos 90. Achei até o instalador de Clipper, FoxPro e tudo mais que eu usava. E graças ao VMWare Workstation Pro que eu uso todo dia, ele também suporta Windows 95 em diante. Eu comecei antes do Windows 95, no MS DOS 3 e usei tudo que a Microsoft lançou do fim dos anos 80 até 2004 que foi quando migrei pra Apple e Mac até voltar pro Windows 10 anos depois em 2015. O Windows 98 foi um dos que eu mais usei nos anos 90 por isso instalei ele.

Como eu já falei bastante, por hoje quero mostrar um dos primeiros sites pessoais que eu fiz. É tão velho que se não for Internet Explorer 4 ou Netscape Navigator 4, o site nem renderiza direito. Essa é uma época anterior a eu aprender ASP ou PHP, quando eu fazia sites estáticos com HTML puro, estamos falando de 1997.

Em 1994 o Brasil foi pego de surpresa quando a Manchete resolveu lançar Cavaleiros do Zodíaco. De repente eu comecei a ver mais gente falando de anime. Até então gostar de anime era um troço bem solitário. Eu cresci assistindo anime gravado em fita Betamax e VHS que vinha do Japão no meio dos anos 80. Mas depois de 1994 todo mundo queria mais e mais anime. Shurato, Sailor Moon, Yuyu Hakusho, e tantos mais. Em 1995 surgiu uma das primeiras revistas especializadas em anime e cultura japonesa, a revista Herói. Daí na sequência saiu um pasquim de pior qualidade chamado Japan Fury que depois se tornou Animax em 1996.

Por coincidência eu fazia parte de um grupo de pessoas que se auto-intitulava Orcade e participava dessa revista, então eu mesmo escrevi um ou dois artigos, em particular sobre Evangelion, que eu me considerava especialista na época - típico de amador se achar especialista mesmo . Como eu tinha acabado de aprender HTML e quando virei monitor na sala de computação da USP eu ganhei acesso ao servidor Unix da Politécnica e como em toda faculdade da época, toda conta tinha uma pasta exposta no Apache pra internet, então decidi fazer um site pra revista. Essa foi a Animax Plug-In.

Essa é a primeira versão, que eu fiz usando o bom e velho Microsoft FrontPage 3.0. Eu sei, eu sei, nem precisa dizer, esse design é tenebroso até pros padrões da época, se bem que em 1997 não se tinha tanto padrão assim pras coisas, em outro vídeo vou mostrar os sites profissionais que fazia com designers de verdade da época. Mas por agora veja que a gente usava framesets e frames e muito table. Não tinha CSS ainda. E o destaque é o menu lateral que abre e fecha, quer dizer, abre e fecha no Netscape mas não no Internet Explorer. Pois é, diferença de Javascript entre navegadores é antiga, a web nasceu quebrada e a gente vem tentando consertar desde então. Mas é legal ver funcionando de novo, em navegador novo nada funciona. Nessa época Internet Explorer era superior ao Netscape já. Renderizava bem mais rápido, Javascript era mais rápido. Eu escrevia pra caramba, vocês podem ver que minha mania de fazer textão não vem de hoje.

Lendo meus textos fica claro que eu escrevia bem mal. Eu ainda não tinha adquirido a noção de editar meus textos. É como programador júnior que ainda tem dó de apagar o código que escreveu. Hoje em dia eu às vezes escrevo páginas e páginas e no meio do caminho eu vejo que está ruim e jogo tudo fora e começo do zero, ou vou refinando o texto, apago seções inteiras. Não existe escrever em apagar. O melhor fluxo é deixar tudo crú sair da sua cabeça, e quando terminar esse dump, daí sim reler e começar a ajustar e apagar e reorganizar.

De qualquer maneira, esse design está um pouco mais engolível. Eu ficava tentando fazer jeitos bizarros de navegação. Dessa vez em vez de um menu lateral eu tinha um menu no fim da página que ia abrindo sub menus pra cima. E eu tinha conceito de uma página que abre a próxima. Naquela época não era muito claro qual a melhor abstração pra organizar conteúdo. Vocês vão notar que nessa época era comum a gente querer simular o estilo de layout editoração de revista. E eu tinha de tudo nesse site, até uns textos tentando ensinar japonês, como se isso fosse fazer alguma diferença. E como ainda não existia Google também era comum os sites terem páginas linkando outros sites, como uma bibliografia ou recomendação.

Na sequência essa é a terceira ou quarta versão. Isso já era 1999, 3 anos fazendo isso. Esta é um pouquinho mais aceitável, pelo menos um pouco mais limpo. De novo note o estilo de layout inpirado em revistas. Eu gastava meu parco salário comprando revistas importadas de anime nessa época, eu queria fazer juz ao investimento. E, de novo, note o menu lateral em Javascript só que dessa vez com inspiração em ícones do Mac OS 8 que eu tinha acesso na agência onde fazia estágio. E continuando no mesmo estilo das outras versões eu colocava mais e mais seções de mangás novos explicando um a um em detalhes, olhando agora eu fico pensando se teria paciência de fazer a mesma coisa hoje em dia.

Eu cheguei até a iniciar um projeto onde eu escaneei vários volumes de um manga que eu gostava e ficava traduzindo balão a balão no photoshop, puta trampo, mas antigamente não existia mangareader e mesmo no mangareader, alguém faz esse tipo de trampo. Eu sei exatamente como dá trabalho

Essa atividade durou uns 3 anos. Durante esse tempo o site ficava hospedado na minha conta no UNIX da faculdade, mas na realidade eu não podia usar a conta da faculdade pra um site de revista comercial, mesmo que eu não ganhasse nada por isso. Eu ganhei zero reais, a revista não dava dinheiro, o site não dava dinheiro, a gente fazia tudo isso porque gostava. Vocês podem ver que isso de eu gastar todo meu tempo livre fazendo coisas trabalhosas só pela diversão vem de longa data.

Mas o que eu ganhei com isso foi outra coisa: com esse exercício todo, eu fiquei rápido pra layoutar sites no estilo da época. Podia me dar qualquer photoshop que eu recortava e montava muito rápido na agência. Sabia otimizar as imagens, otimizar o HTML - pelo menos pros padrões da época, e eu exercitei muito o Javascript da época. Isso seria muito útil nos anos seguintes.

Além disso eu treinei muito minha escrita. Como eu disse antes, lendo agora, é fácil ver que meus textos não eram bons, mas também dá pra ver que mesmo nesse curto período eu escrevi o suficiente pra encher as páginas de um pequeno livro. Eu escrevia em detalhes sobre as séries que eu gostava, indo de personagem em personagem, isso deu tipo MUITO trabalho. Mas novamente, esse trabalho também me ajudou muito, os meus e-mails no trabalho sempre foram completos e concisos, porque eu tinha treinado muito escrever em grande quantidade em pouco tempo.

Ou seja, quando eu comecei meu blog em 2006 eu já tinha escrito muito texto anos antes. E agora escrevendo scripts aqui pro canal, é tudo uma sequência. Eu não sou escritor profissional, mas eu vim aprendendo as técnicas e tentando refinar com o passar do tempo. Mesmo em 1999 comparado com 1997 eu já tinha melhorado.

E como última curiosidade, uma das coisas que atraía as pessoas pra Animax Plug-in e minhas matérias na revista é porque eu era um troll. Como eu disse, a revista Herói era uma droga em termos de conteúdo. Ela vendia porque na época não tinha nada na internet, e todo mundo queria qualquer coisa Cavaleiros do Zodíaco e outros animes. Então eu tinha vários artigos listando um a um todos os erros dos textos da Herói, e não era errinhos ortográficos - que tinha de monte aliás - eram erros conceituais, contava a história errada mesmo. E eu não era sutil, eu chamava pro pau mesmo, eu diz sr Fulano, você não manja porque esse ponto X tá errado, ah e esse ponto Y tá totalmente errado. Ah, e eu nos meus 20 sou que nem vocês nos seus 20, só que em vez de ficar tweetando, eu fazia matéria de revista. E eu sei porque todo mundo gosta de extravazar no twitter, é extremamente satisfatório enfiar o dedo na cara dos outros, cagar um monte de regra, pisar no calo dos outros e ainda ter gente aplaudindo você fazendo isso. Mais satisfatório ainda quando o outro lado reage e vira uma briga. Acho que faz parte da natureza humana.

Hoje eu não faço mais isso. Pelo menos não desse jeito e jamais em público. E não é só por questões de imagem ou qualquer coisa assim. Deixa eu dar uma perspectiva: minhas matérias e artigos circularam entre 1997 e 1999. Hoje em dia, não tem uma pessoa que se lembra mais disso. Os assuntos da época foram todos esquecidos. Pra todos os efeitos, é como se nunca tivessem existido. As brigas são divertidas na hora, mas no final ninguém vai se lembrar, com exceção de quem você pisou no calo. E depois daquela satisfação momentânea, você se sente vazio porque no final, não mudou nada. E você fica querendo ir atrás da próxima briga pra ter de novo a satisfação momentânea, é um vício.

Dê tempo suficiente e qualquer briga que você achou que valia a pena apostar tudo, depois de alguns poucos anos não tem valor nenhum. Não deixa de ser um pouco o: faça o que eu falo mas não faça o que eu fiz. Por outro lado tinha gente que me dizia isso na época, quem disse que eu dei atenção?

O cara da revista Herói ficou tão puto que foi atrás do editor da Animax e socou ele na rua. Foram parar na polícia. E quem escreveu o texto ainda fui eu :-) hahaha Coitado. Vou deixar linkado na descrição se alguém se interessa nesse tipo de história.

Minha recomendação de hoje é: guarde o que você produz, mesmo que você ache que é uma droga. Daqui 20 ou 30 anos vai ser interessante constatar que você realmente evoluiu nesse tempo. Não confie nos serviços de cloud, você provavelmente vai viver mais do que eles. Muitos serviços que eu usava nos anos 90 e começo dos anos 2000 já não existem mais. Lembram do ICQ? Hotmail? Orkut?

E como eu disse no vídeo anterior, eu venho praticando deliberadamente a atividade de escrever desde o meio dos anos 90, agora vocês sabem porque eu escrevo tanto. Estamos no episódio 30 deste canal. Cada episódio tem em média umas 6 páginas no Google Docs, então desde Agosto eu já escrevi 180 páginas de texto, mais de 10 páginas semanalmente, ininterruptamente por umas 15 semanas já. Vou dizer que eu estou bem cansado, vamos ver até onde meu corpo aguenta.

E por hoje é isso aí, faça backups! E não deixe de comentar abaixo! Se curtiram mandem um joinha, compartilhem o vídeo com seus amigos, assinem o canal e cliquem no sininho. A gente se vê, até mais.

Esta revista foi lançada em novembro de 1984. Não lembro exatamente quando meu pai a comprou para mim, mas provavelmente foi entre novembro e dezembro daquele ano, quando ainda estava em circulação. Não fazia nem um ano que a Apple tinha lançado o primeiro Macintosh, que inaugurou a primeira geração de desktops com interface gráfica e mouse.

Eu ainda era criança nessa época, mas já tinha apreciação por computadores, especialmente a “atividade” de controlar a máquina pelo teclado. Minha brincadeira era trocar a sensação de digitar num teclado pela de datilografar numa máquina de escrever mecânica, exercício que até hoje me mantém touch-typist.

Esta revista foi especial por um motivo. A maioria dos “hackers” se foca em controlar o computador, em programá-lo, em “hackeá-lo”. A revista me abriu para um horizonte maior: a história dos computadores.

Naquela época não tínhamos Google e muito menos Wikipedia. Felizmente meus pais, sempre preocupados com educação, já tinham a enciclopédia Mirador, de onde eu pude aprofundar o assunto. Foi assim que, nos anos 80, alguns dos meus “heróis de infância” viraram Charles Babbage, Konrad Zuse, John von Neumann e Robert Noyce. Somados a outros nomes que ajudaram a formar meu raciocínio, como Carl Sagan, essa revista foi um pilar importante na minha formação nos anos seguintes.

Recomendo como leitura para qualquer criança. É leve e instrutiva, com um toque Disney. Eu ainda guardo meu exemplar, já razoavelmente surrado depois de mais de 26 anos. Nos últimos dias resolvi escanear suas páginas e montar um PDF, que você pode baixar neste link. Fiz também uma versão em EPUB, boa pra ler duas páginas lado a lado num monitor widescreen. Não sei quanto a direitos autorais depois de tanto tempo, ainda mais sem a chance de encontrar uma cópia para comprar hoje em dia. Se alguém me enviar uma notificação de cease and desist, eu retiro. Até lá, divirtam-se.

Um dos motivos para publicar isso é encontrar outras pessoas da mesma época que tenham comprado e ainda guardem seu exemplar. A revista tinha um encarte central em papel glossy, com 32 páginas, detalhando o lançamento do Macintosh original, com artigos sobre o MacPaint e outras coisas. Se alguém tiver, eu adoraria pelo menos os scans dessas páginas. Na época eu gostava tanto do encarte que acabei destacando ele da revista, e, soltas, essas páginas se perderam. Não deixem de comentar aqui embaixo se tiverem um exemplar!

Aproveitem!