Programmare come se fosse il 1982. Parte I - Gli anni 80, il Commodore 64 e perché conta ancora

Quando sono entrato nel settore tecnologico, nella seconda metà degli anni 2010, i linguaggi ad alto livello erano già lo standard. Quando ho studiato Ingegneria Informatica, persino i sistemi embedded si scrivevano in C++, e quello veniva considerato il livello più basso. Nel mondo del software e dei giochi, l’astrazione andava ancora più in profondità. Java dominava l’industria, e Unity era nel pieno del processo di democratizzare lo sviluppo di giochi al punto che chiunque con un weekend libero poteva pubblicare qualcosa di giocabile.

Ma c’è stato un tempo in cui i programmatori non avevano questo lusso. Nessun livello intermedio, nessuna rete di sicurezza. Lavoravi direttamente sull’hardware, al livello più basso possibile, scegliendo l’indirizzo esatto di memoria in cui scrivere e l’istruzione esatta che il processore doveva eseguire.

Essendo nato all’inizio degli anni 90, in coda alla generazione Millennial, sono cresciuto con i PC, che erano già lo standard consolidato quando sono arrivato. Non sapevo nulla di quello che c’era prima. Nomi come Atari ST, Apple II, Commodore Amiga, ZX Spectrum erano cose che riuscivo a collocare vagamente negli anni 80, ma non sarei stato in grado di distinguerli se li avessero messi in fila davanti a me. Il mio primo computer era una macchina dei primi anni 2000 con Windows 98 e un sorprendente disco da 512 MB. Non ricordo tutte le specifiche, ma so che era già obsoleto all’epoca, una donazione, macchine scartate dalla squadra di calcio locale. Questa è stata la mia infanzia tecnologica. Per molto tempo, quello era il retrocomputing per me.

È stato solo nel 2021, attraverso il podcast brasiliano “Primeiro Contato”, che ho scoperto il vecchio nuovo mondo del retrocomputing e dei microsistemi. Il podcast, prodotto e narrato magistralmente da Henrique Sampaio, racconta la storia di come i computer e internet sono arrivati in Brasile. Mettendo da parte il contesto specificamente brasiliano, non riuscivo a smettere di immaginare come doveva essere vivere gli anni 80 da programmatore. Quella particolare miscela di curiosità e programmazione byte per byte, senza nessuna astrazione a tenerti se scivolavi, mi ha genuinamente affascinato.

Con questo umile background, propongo una serie di post chiamata “Programmare come se fosse il 1982”, per spiegare ai ritardatari come me come funzionava la programmazione 44 anni fa.

Lo stato dell’informatica nel 1982

I primi anni 80 sono stati il momento in cui i computer hanno lasciato i centri di ricerca e sono atterrati nei salotti. Scatole di plastica collegate al televisore di famiglia, vendute nei negozi di elettronica accanto a radio ed elettrodomestici. Chi c’era lo descrive come trovarsi nel mezzo di qualcosa di completamente nuovo, senza nessuna certezza di dove sarebbe andato a finire tutto.

Il mercato esplose, ma era completamente frammentato. Decine di produttori lanciarono macchine incompatibili tra loro. Atari, Apple II, ZX Spectrum, TRS-80. Ognuna con il proprio processore, la propria architettura, il proprio ecosistema. L’IBM PC era appena uscito, ma era ancora un sistema enterprise che avrebbe impiegato anni a raggiungere l’adozione di massa attraverso i suoi cloni. Quella è una storia per un’altra volta.

Il software arrivava su cassette o floppy disk, comprato nei negozi o copiato a casa di un amico. E poi c’erano le riviste. Le pubblicazioni di microcomputer erano gli hub degli appassionati dell’epoca, ed era del tutto normale che le loro pagine fossero riempite di nient’altro che codice sorgente, stampato perché il lettore lo ricopiasse riga per riga a casa. Quel tipo di esercizio, che oggi sembra tedioso e dolorosamente manuale, è uno degli ingredienti chiave della nostalgia che le persone che hanno vissuto quel periodo si portano dietro. Sono un po’ invidioso di quello, onestamente.

Il Commodore 64

In quel contesto, nell’agosto del 1982, Commodore Business Machines lanciò il computer che sarebbe diventato il modello più venduto della storia. Il nome diceva tutto. Commodore 64, sì, 64 kilobyte di RAM. In un’epoca in cui i concorrenti vendevano macchine con 16 o 48 KB, quel numero significava qualcosa. Il prezzo di lancio era di 595 dollari, caro per il consumatore medio, ma economico per un personal computer. In pochi mesi, Commodore tagliò i prezzi in modo aggressivo e spinse fuori dal mercato gran parte della concorrenza. Si stima che tra i 12 e i 17 milioni di unità siano state vendute nel corso della sua vita, un record che rimane valido ancora oggi per un singolo modello di computer.

Ma quello che rendeva speciale il C64 non era solo il prezzo o la memoria. Era l’hardware al suo interno. Mentre i concorrenti offrivano video e audio di base, il C64 veniva fornito con tre chip sviluppati internamente alla Commodore, ognuno eccezionale per l’epoca.

Il MOS 6510 era il processore, un’evoluzione del leggendario 6502, funzionante a 1 MHz, semplice e documentato fino all’ultimo bit. Il VIC-II era il chip video, capace di visualizzare 16 colori, muovere fino a 8 sprite indipendenti sullo schermo, produrre scrolling fluido e generare effetti che altri computer dell’epoca semplicemente non riuscivano a replicare. E il SID era il chip audio, un sintetizzatore completo con 3 voci indipendenti, forme d’onda programmabili, filtri ed envelope di ampiezza. Così sofisticato che decenni dopo i musicisti cercavano ancora chip originali per fare musica. Il SID non suonava come un computer a 8 bit. Suonava come uno strumento vero.

Non c’era nessun sistema operativo a proteggere nulla. Nessuna eccezione, nessun messaggio di errore amichevole. Se scrivevi all’indirizzo sbagliato, il computer andava in crash o si comportava in modo imprevedibile, e tu stesso dovevi trovare il problema. In cambio di questo, avevi il controllo totale. Nessuno strato tra il tuo codice e la macchina.

BASIC e Assembly

Quando il C64 si accendeva, la prima cosa che vedevi era un cursore lampeggiante e il messaggio READY. Era il prompt del BASIC, il linguaggio masterizzato nella ROM del computer, pronto da usare senza installare nulla.

BASIC è l’acronimo di Beginner’s All-purpose Symbolic Instruction Code. Era stato progettato per essere abbastanza semplice da usare per chiunque, senza background tecnico richiesto. Scrivevi direttamente sulla tastiera e vedevi il risultato immediatamente. I bambini lo imparavano a scuola. Le riviste pubblicavano programmi che i lettori potevano copiare. Genitori e figli lo esploravano insieme. Il BASIC è stato responsabile della democratizzazione della programmazione negli anni 80, e molti di coloro che in seguito hanno padroneggiato assembly e C hanno iniziato scrivendo PRINT "HELLO" su una tastiera di gomma nel salotto di casa.

Il problema era esattamente uno, ed era la velocità. Il BASIC del C64 era interpretato, il che significa che ogni volta che un programma veniva eseguito, ogni riga veniva letta, tradotta ed eseguita sul momento, una alla volta. Quella traduzione in tempo reale consumava la maggior parte della potenza del processore. Un semplice ciclo in BASIC girava circa 1.000 volte al secondo. Lo stesso ciclo in assembly girava 1.000.000 di volte al secondo. Una differenza di 1.000x.

Per un gioco che doveva muovere sprite, rilevare collisioni, riprodurre musica e rispondere al joystick, tutto entro 1/50 di secondo per frame (sulle macchine europee con standard PAL), il BASIC non era abbastanza veloce. Andava bene per calcoli semplici, utility e per imparare i fondamentali. Per giochi e demo, era un vicolo cieco.

L’assembly era l’opposto del BASIC in quasi tutto. Mentre il BASIC veniva tradotto in fase di esecuzione, l’assembly veniva tradotto in anticipo da un programma chiamato assembler. Il risultato era codice macchina puro, byte che il processore eseguiva direttamente, senza intermediari. Nessun livello di interpretazione. Ogni istruzione che scrivevi diventava esattamente uno o pochi byte in memoria, eseguiti senza alcun overhead.

Il guadagno era ovvio ma il costo era reale. Ottenevi tutta la velocità della macchina, e rinunciavi a ogni comodità che il BASIC offriva. Nessun PRINT automatico, nessuna variabile con nome, nessun FOR o IF già pronti. Controllavi ogni registro, ogni byte di memoria, ogni ciclo di clock. Tedioso e granulare. Ma era l’unico modo per fare in modo che l’hardware desse tutto quello di cui era capace.

In pratica, i due mondi coesistevano. Molti programmatori scrivevano la struttura principale in BASIC e chiamavano routine in assembly solo nelle parti che richiedevano velocità. Pragmatico, non ideologico.

Non c’era Stack Overflow. Nessun tutorial su YouTube. Nessun corso online. C’erano le riviste. Le pubblicazioni stampavano il codice sulle pagine, e il lettore digitava ogni riga a mano sulla tastiera del C64, sperando di non sbagliare un singolo carattere. I manuali hardware erano i testi sacri. Il Commodore 64 Programmer’s Reference Guide, un mattone da 493 pagine, descriveva ogni registro di ogni chip, ogni indirizzo di memoria, ogni opcode del processore. Padroneggiare quel libro significava padroneggiare la macchina. Completamente.

Perché studiare questo oggi

Puoi passare un’intera carriera in Python o JavaScript senza pensare nemmeno una volta ai registri, e va benissimo così. Questo è il punto centrale delle astrazioni moderne. Funzionano, e ti lasciano concentrare sul costruire cose invece di gestire la memoria manualmente.

Ma ci sono momenti in cui il pavimento sparisce e hai bisogno di capire cosa c’è sotto. Quando un sistema deve rispondere in microsecondi, che si tratti di trading ad alta frequenza, elaborazione del segnale o giochi con fisica complessa, sapere come funziona davvero l’hardware smette di essere opzionale. I microcontrollori negli elettrodomestici, nelle automobili e nelle attrezzature mediche vengono ancora programmati vicino al metallo, e la logica di un Arduino è un discendente diretto di quello che tratteremo in questa serie. Vulnerabilità come il buffer overflow esistono perché il codice ad alto livello alla fine diventa byte in memoria, e la memoria non ha opinioni su quello che ci fai. Le persone che capiscono questo livello comprendono perché esistono queste vulnerabilità, non solo come correggerle.

C’è anche qualcosa di più difficile da quantificare. C’è una differenza tra sapere usare uno strumento e capire come funziona. Un compilatore non è magia, è una trasformazione sistematica di testo in istruzioni macchina. Un sistema operativo non è un mistero, è un programma che gestisce memoria, tempo di CPU e accesso all’hardware. Le persone che hanno programmato vicino al metallo lo vedono con chiarezza, perché un giorno hanno fatto quel lavoro a mano.

Il C64 è un punto di partenza ideale proprio perché il suo processore ha un insieme di istruzioni ridotto, circa 56 istruzioni in totale, rispetto alle centinaia di un x86 moderno. Puoi imparare l’intera architettura in poche settimane. L’hardware è mappato direttamente in memoria, quindi la relazione tra codice ed effetto è immediata. Scrivi un byte e lo schermo cambia, un suono parte, uno sprite si muove. Non è nascosto nulla. E ci sono emulatori precisi e gratuiti disponibili oggi, come VICE, che permettono di eseguire e fare debug del codice C64 su qualsiasi computer moderno.

Nei prossimi post scenderemo lungo questa pila di astrazioni. Non per scartare quello che già sai, ma per capire da dove viene. Impareremo come il processore conserva i dati, come è organizzata la memoria, come vengono eseguite le istruzioni, come vengono prese le decisioni e come scrivere a un indirizzo può far suonare una nota musicale o far muovere uno sprite sullo schermo. Nel linguaggio di chi programma davvero, senza misticismi.

Edit, 9 maggio 2026. Questa serie presuppone una familiarità minima con la programmazione. Variabili, cicli, condizionali, qualche struttura dati di base. Se hai più esperienza, alcuni post ti sembreranno troppo basilari. È intenzionale. L’obiettivo è sempre stato rendere il contenuto accessibile a chi è curioso, non solo a chi ha una formazione in informatica.