Programmare Vic 20, C64, Amiga & co oggi: perchè

Ben ritrovati. Oggi tocchiamo il tema del perché sia interessante utilizzare vetusti mitici home computers dopo oltre 30-35 anni dalla loro commercializzazione per sviluppare nuovo software, sebbene le tecnologie nel frattempo abbiano beneficiato di un’immensa evoluzione sul piano della performance hw, della standardizzazione, della nascita di tantissimi nuovi linguaggi di programmazione, e via dicendo.

Per chi comincia oggi a sviluppare, desiderando nello specifico creare giochi, le possibilità sono moltissime (a volte tale numero potenzialmente quasi distoglie dall’atto creativo-implementativo in sè). Tutte queste soluzioni godono della maggiore maturità dell’Informatica, acqua sotto i ponti ne è passata parecchia dai tempi del “vecchio” Basic… (che, comunque, usato da mani esperte è molto più tosto di quanto risulti per qualche novizio o tendenza di moda più recente).

Senza considerare ambienti ad hoc, come Unity che impiega il C#, c’è ad esempio Phaser, un framework utilizzabile con Javascript, oppure Pygame per il comodissimo linguaggio di scripting Python, fornito già con un po’ di tutto (come dice Guido Van Rossum: con “batterie incluse”). Proprio Python viene visto da alcuni come “il Basic d’oggi”; tra l’altro mediante il suo interprete è possibile impartire comandi interattivamente per fare pratica con comodo, per passi incrementali, proprio come con Basic.

Realizzare giochi in stile classico anni ’80 è tranquillamente fattibile con qualsiasi game engine o framework e anche la pletora di “retroremakes” app per Android e iOS lo  dimostra bene su Google e Apple Store.

Fatte queste premesse, insomma… perché cimentarsi con Vic 20, C64, Amiga 500 o compagnia bella per sviluppare software videoludico oggi?

Ripartiamo da alcuni numeri: come case study ci focalizziamo su Pygame, con cui è stato ad esempio ricreato il celeberrimo “Gorillas“, uno dei programmi che Microsoft rilasciava assieme al proprio interprete QBasic, per illustrarne le potenzialità. Parentesi: optando per Python il testo “Making games with Python and Pygame” di Al Sweigart è un ottimo punto di partenza; l’autore tra l’altro ha reso disponibile online la versione pdf. Se vi piace rendetegliene merito e acquistate il cartaceo, comodissimo da leggere anche in spiaggia sulla sabbia. Torniamo ai numeri: in questo caso Al se l’è cavata con circa mille righe di codice Python.

gorillas in Python by Al Sweigart

Per fare un paragone e farsi un’idea, vediamo quante righe sono servite (provate ad indovinare) a Simon Taylor programmando il Vic 20 per realizzare nel 1982 il gioco “Blitz“, pubblicato da Commodore UK (uno dei primi per Vic e di “complessità” analoga a Gorillas):

Sono 70 righe (!) – non è un errore – di CBM Basic.

Un differente ordine di grandezza. Un risultato divertente con pochissimo codice.

Arriva la parte migliore: possiamo prendere il meglio dei due mondi e coniugarlo, cioè evitare il linguaggio Basic (lo utilizziamo solo al fine di conoscere con notevole rapidità l’architettura di Vic 20 e/o C64 e/o Amiga ecc tramite prove mirate dove serve) e sviluppare in linguaggio Assembly.

Proprio questo è uno dei principali motivi sul perchè soffermarsi su queste vecchie piattaforme: l’Assembly. Un linguaggio che permette di imparare molto sviluppando direttamente sul “bare metal” (il nudo metallo architetturale della macchina), non accontentandosi di approcci “black box” offerti dagli ambienti attuali e, nel contempo, rimanendo ad uno stadio di complessità ridotto rispetto all’assembly x86 e analoghi.

Un gioco come “Amok!” o come “Astro Panic” per Vic (ambedue già citati su NonSolo8Bit) in Assembly è realizzato in circa un migliaio di righe di istruzioni, esattamente quanto visto per Gorillas usando Pygame (ed altrettante righe per gli assets, cioè grafica, audio e tutti i dati utili al programma). Ci sono però importanti differenze: vista la semplicità di microprocessori come il 6502 e 6510 e dell’architettura dei due home di casa Commodore, è possibile conoscere un Vic o un C64 partendo da ogni singolo chip, passando per l’architettura globale, arrivando alle routines del Kernal (con la “a”: kernel Linux & co. sono altra cosa). Queste ultime tra l’altro sono un’ottima palestra: disassemblatele per vederne l’implementazione ed affinare le vostre capacità.

L’instruction set dell’assembly 6502/6510 è molto contenuto e semplice confrontato con macchine successive: costituisce un training fantastico nei fondamentali anche per approcciare altro in seguito, volendo; ad esempio, e con questo concludiamo facendo una piccola digressione, è possibile dedicarsi successivamente al retro game development per MSDOS, usando Fasm per rimanere in ambito Assembly e programmare direttamente l’hw tramite porte e interrupts, senza API calls. Ci sono ottimi esempi di demo grafiche realizzate proprio con questo assemblatore a partire da… 32B! Oppure facendo il passaggio a C/C++ si può utilizzare, sempre in MSDOS, il compilatore DJGPP e le librerie Allegro, o Watcom C/C++, di cui oggi esiste anche la versione opensource Open Watcom (ad esempio per il gioco Retro City Rampage Vblank Entertainment nel 2015 ha proprio usato il compilatore Watcom per il coraggioso e muscolare porting MSDOS). DosBox (unito a D-Fend Reloaded come frontend per Windows o a Boxer per Mac OS X) in quest’ultimo caso è fantastico come ausilio.

Alla prossima!

 

Leave a Reply

Your email address will not be published. Required fields are marked *