Colgo l’invito di Paolo Giannelli a parlare dei propri hobby raccontandovi il mio: i videogiochi. Avendoli visti praticamente nascere, sono stato subito affascinato da questo incredibile mix di talento artistico e tecnologia, nata come forma di intrattenimento ludico ed evoluta fino a quella di espressione interattivo-narrativa. Personalmente, debbo molto ai videogiochi; grazie ad essi, alla curiosità di capire come erano fatti, mi sono avvicinato al mondo della programmazione che è poi diventato il mio mestiere, il che oggi fa di me una delle fortunate persone che di lavoro fa ciò che gli è sempre piaciuto.
Nel tempo ho posseduto diverse console per videogiochi ed oggi ne sono un discreto collezionista, imparando anche a programmarne alcune, anche se un gioco completo non l’ho mai sviluppato.
Tra le tante, una delle macchine da gioco che mi è più cara è l’Atari 2600, che ho posseduto da ragazzino, regalatami dal mio zio materno il Natale del 1984. Essa è stata la prima console a diffusione di massa, ed una delle più longeve, rimasta sul mercato per un arco di ben 15 anni, dal 1977 al 1992, resistendo alla concorrenza dei prodotti di nuova generazione, ben più performanti e vicini all’esperienza arcade, che tutti i produttori tentavano di raggiungere. Non fu la prima in assoluto; la Magnavox Odyssey lo fu, e la Fairchild
Channel F introdusse per prima il sistema a cartucce rom per espandere il parco giochi della piattaforma, ripreso poi dall’Atari per la 2600 e da tutti i produttori di console fino al 1994 circa, quando si passò all’uso di dischi ottici come sistema per la distribuzione dei giochi.
Ma l’Atari aveva dalla sua un asso nella manica non da poco: Nolan Bushnell. Fondatore dell’azienda e con capacità manageriali e marketing fuori dal comune, Bushenll intuì l’enorme potenziale che questa forma di intrattenimento sottendeva e riuscì a portare la sua società ad un livello tale da identificarla con i videogiochi stessi.
Nata per portare i videogiochi dai bar ai salotti di casa, sotto la guida di Bushnell la 2600, riuscì ad eclissare tutti i sistemi concorrenti dell’epoca.
Fu concepita come sistema ultraeconomico per lo sviluppo di giochi palla e racchetta (pong) o di combattimento con carrarmati che andavano di moda nella seconda metà degli anni ’70, perciò la dotazione hardware era davvero minimale per usare un eufemismo.
Basata sul processore MOS 6507, versione ridotta del già economico 6502, la 2600 era dotata di:
- Due porte I/O dove venivano collegati una serie di controller utente come joystick, paddle (comandi basati su potenziometri), tastierini e pistole lightgun (usate in un unico gioco, Sentinel, verso la fine del ciclo vita del sistema)
- Un generatore audio a due canali con capacità di produrre onde quadre o rumore bianco
- Un chip grafico (si fa per dire) in grado fornire una risoluzione massima di 192x228 pixel e di gestire 5 sprite (oggetti posizionabili arbitrariamente sullo schermo), più due elementi di sfondo. Poteva generare da un minimo di 8 colori fino ad un massimo di 128, a seconda dello standard televisivo utilizzato
- 128 byte di RAM (si, avete letto bene, proprio 128 byte)
- Elettronica varia per mandare immagini e suoni ad un televisore e accedere alla circuiteria delle cartucce ROM contenenti il software di gioco
Niente BIOS, niente memorie di massa, niente coprocessori, niente di niente. Nemmeno un framebuffer, per cui il programmatore era responsabile oltre che della logica di gioco, anche di disegnare lo schermo, fotogramma per fotogramma, tenendo impegnato il processore per la quasi totalità del tempo, correndo insieme al pennello elettronico della TV, accendendo e spegnendo pixel per comporre il quadro di gioco, secondo la sincronizzazione del color clock, ossia i colpi di clock del TIA, il chip grafico (sempre per modo di dire).
Guardando lo schema seguente:
scopriamo che in pratica, per 262 cicli necessari ad un giro completo di fotogramma, abbiamo solo 76 cicli per la logica di sistema, ossia quei cicli che in cui lo schermo non dev’essere disegnato perché il pennello elettronico è fuori dall’area visibile.
Tutto questo comportava che per sviluppare giochi per questa console, bisognava essere dei programmatori più che abili: era necessario produrre codice di un rigore ed una disciplina perfetta, che tenesse accuratamente conto dei tempi di esecuzione di ogni singola istruzione assembly, pena immagini piene di artefatti grafici o, più frequentemente, che scorrevano dall’alto in basso (o viceversa) continuamente invece di restare stabili sullo schermo,
Tornando a quelle che erano eufemisticamente chiamate “capacità grafiche” del summenzionato TIA, gli sprite (MOG nella terminologia del TIA) utilizzati per i personaggi del giocatore e degli avversari, erano larghi al massimo 8 pixel o meglio, 8 color clock, quelli dei proiettili e della palla solo uno, raddoppiabili agendo su un preciso registro del TIA. I MOG del giocatore/opponente potevano inoltre replicare il proprio pattern grafico fino a tre volte all’interno dello stesso oggetto, dando l’impressione di essere composto da tre sprite invece che uno solo. mentre l’elemento utilizzato per il fondale era costruito con un pattern di 20 color clock, utilizzato per comporre la metà di sinistra del campo di gioco. Per la destra veniva riutilizzato lo stesso pattern eventualmente riflesso specularmente.
La differenza tra pixel e color clock è importante: poiché era il programmatore ad avere l’onere di rendere visibile o meno ogni pixel a video e tenendo presente che il clock del TIA andava a velocità tripla rispetto a quello del processore, quanto era largo davvero un pixel? La risposta è… dipende da quanto eravate veloci ad accenderlo e spegnerlo. Il tempo minimo per l’operazione era un ciclo di clock del processore, che moltiplicato per tre da appunto 3 color clock.
La dimensione verticale degli sprite dipendeva dall’abilità del programmatore nel mostrarne ogni riga allineata con la precedente. Perciò, finché si continuava ad aggiungerle, magari variando anche il pattern grafico, lo sprite continuava a crescere, dando origine ad immagini più complesse del rettangolo utilizzato per rappresentare una racchetta.
Lo spostamento orizzontale degli sprite, era gestito automaticamente in termini di posizione relativa, a scatti di massimo 7 pixel verso destra o verso sinistra. Lo spostamento verticale era a carico del programmatore, che doveva accendere e spegnere uno sprite al momento giusto, in base a quale linea stava tracciando il cannone elettronico, per dare l’impressione che il personaggio si fosse spostato verso l’alto o verso il basso.
Scrolling del fondale, non previsto, era statico e te lo beccavi come tale.
E non dimentichiamo i lussuosi 128 byte di RAM. Il codice del gioco era nella ROM della cartuccia e da lì veniva eseguito, ma per le variabili? Beh, 128 byte di ram, più tre registri del processore potevano bastare no?
É facile quindi capire perché la 2600 gode ancora oggi della fama di console più difficile da programmare, roba per uomini veri (anche se siete donne) e non adatta ai deboli di cuore o di mente.
Come fu possibile allora, per un sistema dalla dotazione così scarsa, avere giochi come Demon Attack, Pitfall! o Solaris, quando i progettisti al massimo avevano previsto di tirarci fuori giochi tipo pong e scontri tra due carrarmati?
La risposta è proprio nella debolezza del sistema: poiché il programmatore doveva occuparsi di gestire tutto, voleva anche dire che aveva il controllo quasi completo dell’hardware. E questo, quando si capì come manipolarlo a dispetto delle specifiche, offrì un enorme ventaglio di soluzioni, roba che nemmeno i creatori della piattaforma avrebbero mai immaginato.
Innanzitutto la memoria: il ridotto bus di indirizzi del 6507 poteva gestire al massimo 4K. I programmatori realizzarono presto che, poiché il bus delle cartucce era bidirezionale, potevano anche inviare dati alla cartdrige oltre che leggerli. In breve, per i giochi più complessi, nelle cartucce venne introdotta una circuiteria per il bank switching, pilotata dal programma allocato nei primi 4K. In questo modo, rimappando ulteriori banchi da 4K presenti nella cartuccia sugli stessi indirizzi del primo, si poteva accedere ad un massimo di 32K, senza che il processore sospettasse di nulla.
Lo stesso accadde con la RAM. 128 bytes erano davvero troppo pochi per tenere tutte le variabili necessarie per i giochi che vennero rispetto a quelli per cui la console era stata progettata; la soluzione fu integrarne di aggiuntiva nelle cartucce e utilizzarla lì, pilotandone l’hardware attraverso il bus della cartdrige.
Anche le sfide poste dalla risicata capacità grafica vennero affrontate e brillantemente risolte: 5 sprite a schermo, monocolore, di cui solo due avevano una dimensione più grande di un pixel erano davvero troppo pochi.
Larry Kaplan, uno dei più talentuosi programmatori di Atari, fu il primo a scoprire che, poiché il TIA non aveva memoria di quello che aveva combinato dopo aver disegnato una riga, manipolandone i registri in maniera appropriata lo si poteva forzare a ridisegnare uno stesso sprite più volte, cambiandone anche il colore. Il primo gioco ad utilizzare questa tecnica fu Air Sea Battle e fu portata poi allo stato dell’arte da David Crane, un vero genio della programmazione nonché un mito assoluto tra i game developer, nel suo gioco Pitfall!, dove utilizzò lo sprite dedicato alla palla duplicato una quantità notevole di volte per disegnare ed animare le liane a cui il personaggio Harry Pitfall, si aggrappava per superare gli ostacoli del gioco.
La capacità che questa tecnica offriva nel disegnare sprite multicolore, unita ad una buona palette (fino a 128 su sistemi NTSC) fu utilizzata dalla Imagic per creare il proprio marchio di fabbrica, producendo sprite con sprite e fondali coloratissimi.
In maniera in qualche modo simile fu risolto anche il problema dello scrolling (assente) del fondale. Modificandone il pattern grafico al volo, tra un fotogramma e l’altro, si poteva simulare lo scorrimento verticale e orizzontale dello schermo.
Nessuna delle soluzioni a questi problemi fu facile da implementare su questo sistema, in fondo nulla è facile sull’Atari 2600, ma i programmatori che si occuparono dello sviluppo di giochi per questa console erano dei veri miti, persone geniali e con brillanti capacità tecniche, che scrissero, letteralmente, la storia dei videogiochi.
Ci sarebbe ancora molto altro da dire su questa console e dei suoi programmatori, ma credo di aver già abusato abbastanza del vostro tempo.
Se volete saperne di più o se vi va di rifare un tuffo nel passato, vi consiglio di leggere i numeri di Retro Magazine World, una rivista completamente gratuita che si occupa di giochi, programmazione e storie della retro informatica, di cui mi onoro essere uno dei membri fondatori.
La trovate qui: https://www.retromagazine.net
E se vi va di rimanere aggiornati, c’è anche un gruppo facebook: RetroMagazine World
Grazie a tutti per il tempo che avrete voluto dedicare a leggere questo post e ci vediamo il 6 ottobre.
