Programando como se fosse 1982. Parte I - Os anos 80, o Commodore 64 e por que isso importa

Quando entrei no mercado de tecnologia, na segunda metade dos anos 2010, as linguagens de alto nível já eram o padrão. Quando estudei Engenharia da Computação, até sistemas embarcados eram escritos em C++, e isso era considerado o nível mais baixo. No mundo do software e dos jogos, a abstração ia ainda mais longe. Java dominava a indústria, e a Unity estava no meio do processo de democratizar o desenvolvimento de jogos a ponto de qualquer pessoa com um fim de semana livre conseguir publicar algo jogável.

Mas houve uma época em que programadores não tinham esse luxo. Sem camadas, sem redes de segurança. Você trabalhava diretamente no hardware, no nível mais baixo possível, escolhendo o endereço exato de memória onde escrever e a instrução exata que o processador deveria executar.

Como alguém nascido no início dos anos 90, na cauda da geração Millennial, cresci com PCs, que já eram o padrão estabelecido quando cheguei. Não sabia nada do que existia antes. Nomes como Atari ST, Apple II, Commodore Amiga, ZX Spectrum eram coisas que eu conseguia situar vagamente nos anos 80, mas não conseguiria distinguir um do outro se colocassem todos na minha frente. Meu primeiro computador foi uma máquina do início dos anos 2000 rodando Windows 98, com impressionantes 512 MB de armazenamento. Não lembro todas as especificações, mas sei que já era obsoleto na época, uma doação, máquinas descartadas pelo clube de futebol local. Essa foi minha infância tecnológica. Por muito tempo, isso era retrocomputação pra mim.

Foi só em 2021, por meio do podcast brasileiro “Primeiro Contato”, que descobri o velho novo mundo da retrocomputação e dos microssistemas. O podcast, produzido e narrado com maestria por Henrique Sampaio, conta a história de como os computadores e a internet chegaram ao Brasil. Deixando de lado o contexto especificamente brasileiro, não conseguia parar de imaginar como devia ser viver os anos 80 como programador. Aquela mistura particular de curiosidade e programação byte a byte, sem nenhuma abstração pra te pegar se você escorregasse, genuinamente me fascinou.

Com esse humilde background, proponho uma série de posts chamada “Programando como se fosse 1982”, para explicar a retardatários como eu como a programação funcionava 44 anos atrás.

O estado da computação em 1982

O início dos anos 80 foi o momento em que os computadores saíram dos centros de pesquisa e chegaram às salas de estar. Caixas de plástico conectadas à TV da família, vendidas em lojas de eletrônicos ao lado de rádios e eletrodomésticos. Quem estava lá descreve aquilo como estar no meio de algo completamente novo, sem nenhuma certeza de onde tudo aquilo ia dar.

O mercado explodiu, mas era completamente fragmentado. Dezenas de fabricantes lançavam máquinas incompatíveis entre si. Atari, Apple II, ZX Spectrum, TRS-80. Cada um com seu próprio processador, sua própria arquitetura, seu próprio ecossistema. O IBM PC havia acabado de ser lançado, mas ainda era um sistema corporativo que levaria anos para conquistar adoção em massa por meio dos seus clones. Essa é uma história para outra hora.

Os programas vinham em fitas cassete ou disquetes, comprados em lojas ou copiados na casa de um amigo. E depois havia as revistas. As publicações de microcomputadores eram os hubs dos entusiastas da época, e era completamente normal que suas páginas fossem preenchidas com nada além de código-fonte, impresso para o leitor copiar linha por linha em casa. Esse tipo de exercício, que parece tedioso e dolorosamente manual pelos padrões de hoje, é um dos ingredientes principais da nostalgia que as pessoas que viveram aquele período carregam consigo. Sou um pouco enciumado disso, honestamente.

O Commodore 64

Nesse cenário, em agosto de 1982, a Commodore Business Machines lançou o computador que se tornaria o modelo mais vendido da história. O nome dizia tudo. Commodore 64, sim, 64 kilobytes de RAM. Numa época em que os concorrentes vendiam máquinas com 16 ou 48 KB, esse número significava algo. O preço de lançamento era de 595 dólares, caro para o consumidor médio, mas barato para um computador pessoal. Em poucos meses, a Commodore cortou os preços de forma agressiva e tirou boa parte da concorrência do mercado. Estima-se que entre 12 e 17 milhões de unidades foram vendidas ao longo da sua vida útil, um recorde que permanece até hoje para um único modelo de computador.

Mas o que tornava o C64 especial não era só o preço ou a memória. Era o hardware por dentro. Enquanto os concorrentes entregavam vídeo e som básicos, o C64 vinha com três chips desenvolvidos internamente na Commodore, cada um excepcional para a época.

O MOS 6510 era o processador, uma evolução do lendário 6502, rodando a 1 MHz, simples e documentado até o último bit. O VIC-II era o chip de vídeo, capaz de exibir 16 cores, mover até 8 sprites independentes na tela, produzir scroll suave e gerar efeitos que outros computadores da época simplesmente não conseguiam replicar. E o SID era o chip de som, um sintetizador completo com 3 vozes independentes, formas de onda programáveis, filtros e envelopes de amplitude. Tão sofisticado que décadas depois músicos ainda caçavam chips originais para fazer música. O SID não soava como um computador de 8 bits. Soava como um instrumento de verdade.

Não havia sistema operacional protegendo nada. Nenhuma exceção, nenhuma mensagem de erro amigável. Se você escrevesse no endereço errado, o computador travava ou se comportava de forma imprevisível, e você caçava o problema sozinho. Em troca disso, você tinha controle total. Nenhuma camada entre o seu código e a máquina.

BASIC e Assembly

Quando o C64 ligava, a primeira coisa que você via era um cursor piscando e a mensagem READY. Era o prompt do BASIC, a linguagem gravada na ROM do computador, pronta para usar sem instalar nada.

BASIC é a sigla de Beginner’s All-purpose Symbolic Instruction Code. Foi projetado para ser simples o suficiente para qualquer pessoa, sem formação técnica necessária. Você digitava diretamente no teclado e via o resultado imediatamente. Crianças aprendiam nas escolas. Revistas publicavam programas para os leitores digitarem. Pais e filhos exploravam juntos. O BASIC foi responsável por democratizar a programação nos anos 80, e muitos dos que mais tarde dominaram assembly e C começaram digitando PRINT "HELLO" num teclado de borracha na sala de casa.

O problema era exatamente um, e era a velocidade. O BASIC do C64 era interpretado, o que significa que toda vez que um programa rodava, cada linha era lida, traduzida e executada na hora, uma por vez. Essa tradução em tempo real consumia a maior parte do poder do processador. Um loop simples em BASIC rodava cerca de 1.000 vezes por segundo. O mesmo loop em assembly rodava 1.000.000 de vezes por segundo. Uma diferença de 1.000x.

Para um jogo que precisava mover sprites, detectar colisões, tocar música e responder ao joystick, tudo dentro de 1/50 de segundo por frame (nas máquinas europeias com padrão PAL), o BASIC não era rápido o suficiente. Era ótimo para cálculos simples, utilitários e para aprender os fundamentos. Para jogos e demos, era um beco sem saída.

O assembly era o oposto do BASIC em quase tudo. Enquanto o BASIC era traduzido em tempo de execução, o assembly era traduzido antes, por um programa chamado assembler. O resultado era código de máquina puro, bytes que o processador executava diretamente, sem intermediário. Nenhuma camada de interpretação. Cada instrução que você escrevia virava exatamente um ou alguns bytes na memória, executados sem nenhum overhead.

O ganho era óbvio mas o custo era real. Você ganhava toda a velocidade da máquina, e abria mão de todo conforto que o BASIC oferecia. Sem PRINT automático, sem variáveis com nome, sem FOR ou IF prontos. Você controlava cada registrador, cada byte de memória, cada ciclo de clock. Trabalhoso e detalhado. Mas era o único caminho para fazer o hardware entregar tudo que era capaz.

Na prática, os dois mundos coexistiam. Muitos programadores escreviam a estrutura principal em BASIC e chamavam rotinas em assembly só nas partes que exigiam velocidade. Pragmático, não ideológico.

Não havia Stack Overflow. Nenhum tutorial no YouTube. Nenhum curso online. Havia revistas. As publicações imprimiam código nas páginas, e o leitor digitava cada linha à mão no teclado do C64, torcendo para não errar um único caractere. Os manuais de hardware eram os textos sagrados. O Commodore 64 Programmer’s Reference Guide, um tijolo de 493 páginas, descrevia cada registrador de cada chip, cada endereço de memória, cada opcode do processador. Quem dominava aquele livro dominava a máquina. Completamente.

Por que estudar isso hoje

Você pode passar a carreira inteira em Python ou JavaScript sem pensar uma vez em registradores, e está tudo bem. Esse é o ponto central das abstrações modernas. Elas funcionam, e deixam você focar em construir coisas em vez de gerenciar memória manualmente.

Mas há momentos em que o chão some e você precisa entender o que está embaixo. Quando um sistema precisa responder em microssegundos, seja em trading de alta frequência, processamento de sinais ou jogos com física complexa, saber como o hardware realmente funciona deixa de ser opcional. Microcontroladores em eletrodomésticos, carros e equipamentos médicos ainda são programados perto do metal, e a lógica de um Arduino é descendente direto do que vamos cobrir nessa série. Vulnerabilidades como buffer overflow existem porque código de alto nível eventualmente vira bytes na memória, e a memória não tem opinião sobre o que você faz com ela. Quem entende esse nível entende por que essas vulnerabilidades existem, não só como corrigi-las.

Tem também algo mais difícil de quantificar. Existe uma diferença entre saber usar uma ferramenta e entender como ela funciona. Um compilador não é mágica, é uma transformação sistemática de texto em instruções de máquina. Um sistema operacional não é mistério, é um programa que gerencia memória, tempo de CPU e acesso ao hardware. Quem já programou perto do metal enxerga isso com clareza, porque um dia fez esse trabalho na mão.

O C64 é um ponto de partida ideal exatamente porque seu processador tem um conjunto de instruções pequeno, aproximadamente 56 instruções no total, contra as centenas de um x86 moderno. Você consegue aprender a arquitetura inteira em algumas semanas. O hardware é mapeado diretamente na memória, então a relação entre código e efeito é imediata. Escreva um byte e a tela muda, um som toca, um sprite se move. Nada está escondido. E há emuladores precisos e gratuitos disponíveis hoje, como o VICE, que permitem rodar e depurar código do C64 em qualquer computador moderno.

Nos próximos posts vamos descer essa pilha de abstrações. Não para descartar o que você já sabe, mas para entender de onde veio. Vamos aprender como o processador guarda dados, como a memória é organizada, como as instruções são executadas, como decisões são tomadas e como escrever num endereço pode fazer uma nota musical tocar ou um sprite se mover pela tela. Na linguagem de quem programa de verdade, sem misticismo.

Edit, 9 de maio de 2026. Esta série assume familiaridade mínima com programação. Variáveis, loops, condicionais, uma estrutura de dados ou outra. Se você tem mais experiência, alguns posts vão parecer básicos demais. Isso é intencional. O objetivo sempre foi tornar o conteúdo acessível para quem é curioso, não só para quem tem formação em ciência da computação.