Come Vendettero Zork
The Digital Antiquarian (la traduzione ufficiale italiana)



Rieccoci fedeli lettori al nostro appuntamento settimanale con l'Avventura (con la "A" maiuscola). E dopo aver esplorato gli aspetti tecnici dello sviluppo di Zork e della sua incredibile conversione per le umili piattaforme casalinghe dell'epoca, il sapiente Antiquario ci racconterà di quando la neonata Infocom impegnò tutte le risorse di cui disponeva per presentare la propria creatura al grande pubblico.
Nel 1980 il mercato videoludico era praticamente agli albori
 e le avventure testuali in circolazione erano, più o meno, quelle di Scott Adams pubblicate dalla Adventure International e poco altro...niente a che vedere con Zork!
 
Ma prima, l'imperdibile lista degli articoli del ciclo Infocom:
 
– Le Radici della Infocom
– Zork sul PDP-10
– La Nascita della Infocom
– Lo ZIL e la Z-Machine
– Come Vendettero Zork
– Giochi col Parser
– Esplorando Zork, Parte 1
– Esplorando Zork, Parte 2
– Esplorando Zork, Parte 3
– Infocom: Come Cavarsela da Soli
– Zork II, Parte 1
– Zork II, Parte 2
– Lo Zork User Group
– Zork III, Parte 1
– Zork III, Parte 2
 
Buona lettura avventurieri... e raccogliete tanti zorkmid!
 
Festuceto
 
Quando ci siamo lasciati, era la fine dell'estate del 1979 e sette dei nove soci della Infocom vivevano a Boston, ognuno col proprio lavoro a tempo pieno, discutendo -quando il tempo lo permetteva- di quello che avrebbe dovuto fare la loro società nuova di zecca. Nel frattempo gli altri due soci, Marc Blank e Joel Berez vivevano a Pittsburgh e stavano affrontando il problema in modo più pratico, progettando (per ora interamente su carta) un sistema che permettesse di convertire Zork (o almeno una buona metà di Zork) dal PDP-10 ai microcomputer. Mentre Blank e Berez continuavano il proprio lavoro in quell'autunno, si convincevano sempre di più che, sì, la loro idea avrebbe potuto funzionare e così iniziarono a fare pressioni sugli altri di Boston per fare in modo che Zork diventasse il primo progetto della Infocom. Il loro piano era così allettante che alla fine persino il riluttante Al Vezza accettò.
 
In quel periodo Berez era stato ammesso a un programma di economia post-laurea alla Sloan School of Management del MIT; così quel Novembre rientrò a Boston per frequentare – e per assumere la carica di Presidente di una Infocom ancora esistente principalmente sulla carta. Dinanzi alla prospettiva di restare intrappolato da solo a Pittsburgh mentre i suoi amici implementavano il suo progetto, Blank prese la decisione -importantissima sul piano personale- di lasciare l’internato medico e trasferirsi a Boston. Così, all’alba dell’anno 1980, la proverbiale banda era di nuovo riunita e i lavori sul nuovo Zork procedevano di buona lena.
 
Con i loro rapporti al MIT e alla DEC, del tempo su un PDP-10 non era poi difficile da recuperare, anche se tutti quelli della Infocom avevano ormai ufficialmente lasciato il MIT. Nonostante il loro scopo finale fosse quello di vendere Zork sui microcomputer, in questa fase la Infocom continuava a lavorare interamente sul PDP-10; probabilmente il vecchio motto “Noi odiamo i micro!” non era ancora  completamente passato di moda. Blank e Lebling scrissero sul PDP-10 l’intero sistema di sviluppo ZIL, incluso il compilatore, nonché (per poter fare delle prove) la prima versione funzionante della macchina virtuale Z-Machine. Sorprendentemente, il progetto astratto che Blank e Berez avevano ideato su dei tovagliolini e su dei pezzi di carta usata, si rivelò perfettamente funzionante nella realtà. Come dicevo nel mio ultimo post, implementare di nuovo il gioco in ZIL diede loro l’opportunità di migliorare ancora da diversi punti di vista l’originale Zork.
 
Perfino quando arrivò il momento di abbandonare il PDP-10, le preferenze della Infocom restarono evidenti: la seconda implementazione della Z-Machine non era né per la macchina della Radio Shack, né per quella della Apple, bensì per un DEC PDP-11. Se il PDP-10 era l’ammiraglia della DEC (tanto grande e potente che forse si meriterebbe di essere etichettato come mainframe piuttosto che come minicomputer), il PDP-11 era un modello più piccolo, più economico, pensato per “portare il pane a casa”. Si stima che la DEC ne avesse venduti più di 170.000 nei soli anni ‘70. Relativamente trasportabile (se la possibilità di trasportare un computer con un singolo camioncino lo rende “trasportabile”) e senza che necessiti di un pavimento sopraelevato o di altre macchinazioni da "data-center", i PDP-11 erano ovunque: nelle fabbriche, nei laboratori, nei centri di controllo del traffico aereo, e… nella camera da letto di Joel Berez (!!!). In un certo senso il PDP-11 aveva già il suo Zork, essendo stata la prima piattaforma su cui fu creato il porting in FORTRAN di Dungeon, ma ciò non fermò la Infocom dal rendere lo Zork per PDP-11 il suo primo prodotto commerciale. Nonostante la diffusione del PDP-11, il suo mercato non era esattamente una roccaforte del gaming: è riportato che Zork su quella piattaforma vendette meno di 100 copie (una delle quali di recente è apparsa su eBay: sul sito di "Get Lamp" di Jason Scott trovate una scansione del suo manuale, sorprendentemente completa, seppur battuta a macchina e ciclostilata [Il link originale è stato rimosso, ma potete trovare una copia del manuale qui, ndFestuceto]). Era del tutto evidente che la Infocom doveva convertire Zork per i microcomputer.
 
In questo spirito, la Infocom comprò un sistema TRS-80 e Scott Cutler (uno dei pochi soci che avesse avuto una qualche esperienza con i microcomputer) si mise al lavoro, con l’aiuto di Blank, per  costruire un’ apposita Z-Machine. Il momento della verità era arrivato:
 
Scott e Marc dimostrarono che Zork I poteva vivere al suo interno, avviando il gioco e riuscendo a fare dei punti con l’incantamento “N.E.OPEN.IN.” (che di certo non sono meno memorabili del “Come here, Mr. Watson; I want you!” di Alexander Graham Bell). 
 
È sempre un momento teso quando un progetto finalmente prende vita e mostra qualcosa di concreto. Ricordo ancora quanto fossi eccitato quando il mio personalissimo interprete di Z-Machine, Filfre, visualizzò il testo d’apertura del primo gioco con cui avevo deciso di provarlo, Infidel. Posso solo immaginare l’eccitazione di Blank e Cutler, quando tutto questo era così nuovo e la posta in gioco era così tanto più alta. Quel che conta però è che l’idea della Z-Machine funzionò. Quando il giocò fu completamente giocabile, la Infocom (erede di una lunga tradizione di informatica istituzionale che faceva le cose come dovevano essere fatte) fece qualcosa di virtualmente senza precedenti per un gioco per microcomputer: sottopose il proprio gioco a una fase di betatesting rigorosa e ripetuta. Il suo tester principale fu uno studente del MIT chiamato Mike Dornbrook, che si era innamorato del gioco al punto di diventarne oltremodo ossessionato, tracciando delle bellissime mappe dettagliate della sua geografia e lavorando sodo per affinare non solo i problemi tecnici ma anche gli enigmi peggiori e le difficoltà del parser (se solo in quei primi tempi la On-Line Systems, Scott Adams, e gli altri sviluppatori avessero avuto una pazienza simile e altrettanta dedizione alla qualità...)
 
Se si esclude il betatest che era ancora in corso, la Infocom a quel punto aveva un vero prodotto da commercializzare. Ora dovevano solo decidere come lo avrebbero venduto. Un’opzione era quella di fare ciò che Ken Williams stava decidendo di fare più o meno proprio in quel periodo: provarci da soli. Tuttavia, data la poca esperienza e la scarsa conoscenza della giovane industria dei microcomputer, ciò sembrò rischioso e nessuno dei soci era poi così eccitato all’idea di inventarsi un packaging e di duplicare migliaia (questa, almeno, era la speranza) di dischi. Iniziarono quindi a proporre Zork a vari publisher. Un tentativo con Microsoft fu respinto dal dipartimento di marketing: avevano già la loro avventura testuale (niente di meno che Adventure in persona) e evidentemente credevano che una fosse più che sufficiente per un singolo publisher. In seguito Bill Gates (che era stato un fan di Zork sul PDP-10) seppe dell’offerta e provò a riaprire la trattativa, ma a quel punto la Infocom stava già trattando con Dan Fylstra della Personal Software, facendo dello Zork della Microsoft un qualcosa di affascinante che sarebbe potuto essere ma non è mai stato.
 
Personal Software oggi è stata quasi completamente dimenticata, ma all’epoca era la stella più luminosa della giovane industria, in grado di eclissare facilmente anche la Microsoft. Fondata da  Peter R. Jennings e Dan Fylstra, fondatori della seminale rivista Byte, la Personal Software trovò la sua miniera d’oro nel 1979, quando raggiunse un accordo con Dan Bricklin e Bob Frankston per la pubblicazione del loro VisiCalc per l’Apple II. Col supporto di un’intelligente campagna promozionale da parte della Personal Software (che enfatizzava opportunamente la natura rivoluzionaria di questo prodotto autenticamente rivoluzionario), al tempo in cui la Infocom si presentò a bussare alla porta del publisher, VisiCalc era sulla bocca di tutto il mondo degli affari, diventando la hit della giovane industria dei microcomputer e arrivando così a vendere centinaia di migliaia di copie. VisiCalc non solo fece della Personal Software il più grande publisher del pianeta, nonché l’oggetto di articoli su riviste come il Time, ma gli conferì anche un enorme potere all’interno del settore. Questo potere si estendeva perfino sulla Apple stessa: un numero infinito di clienti metteva il carro davanti ai buoi, e comprava gli Apple II solo per avere un computer su cui far girare la loro nuova copia di VisiCalc. Fu, insomma, la prima “killer application” dell’era dei PC, e come tale vendette tutti gli Apple II che ciò comportava. Con così tanti soldi e con un tale potere, la Personal Software non sembrò alla Infocom una brutta strada per far uscire il loro nuovo gioco. Fylstra aveva frequentato la scuola di economia al MIT, dove aveva conosciuto sia Vezza che la versione PDP-10 del gioco. Non fu quindi troppo difficile per Berez e Vezza chiudere la trattativa, che incluse anche un anticipo sulle future royalty, aspetto questo per loro assolutamente indispensabile, giacché la Infocom aveva sostanzialmente già speso i suoi 11.500 $ iniziali in hardware, betatester, e tempo sul PDP-10.
 
Nel mezzo dei rispettivi compiti, gli altri soci scrissero anche un paio di articoli per le riviste, che servissero per stimolare un po’ l’attenzione. “Come far entrare un programma grande in una macchina piccola”, una spiegazione un po’ evanescente dei concetti di virtual machine e di virtual memory, apparso nel numero di Luglio di Creative Computing; e “Zork e il futuro delle simulazioni fantasy su computer”, un articolo più teorico sulla nascente arte delle avventure testuali, apparso nel grande numero dedicato alle avventure di Byte di dicembre. Non avendo ancora adottato l’elegante nome di “interactive fiction”, in questo secondo articolo Lebling affibbiò a Zork e ai suoi simili l’etichetta (alquanto scomoda) di “computerized fantasy simulations” (“CFS”). La versione per TRS-80 di Zork stava ormai per sbarcare sul mercato sotto l’ombrello della Personal Software.
 
Le vendite iniziali non furono eccezionali: la versione TRS-80 vendette circa 1.500 copie nei suoi primi nove mesi. Questi numeri possono forse essere in parte spiegati con il marketing poco convinto e privo di immaginazione della Personal Software, che (alla luce del colosso VisiCalc) era sempre meno convinta di voler essere coinvolta nel mercato videoludico. È altresì vero che il mercato del software per TRS-80 non ha mai prosperato nel modo che ci si potrebbe aspettare se lo paragoniamo alle vendite del rispettivo hardware. Uno dei colpevoli principali era da ricercarsi nelle politiche di Radio Shack. Radio Shack insisteva infatti nel voler vendere nei propri negozi solo il software pubblicato sotto la propria etichetta. E al tempo stesso offriva agli sviluppatori delle royalty davvero modeste se confrontate col resto dell’industria, rifiutandosi perfino di attribuirgli adeguatamente la paternità del prodotto sul software stesso, preferendo promuovere l’immagine di una caritatevole Tandy Corporation che apparentemente generava immacolate creazioni software direttamente dal suo didietro. Nel frattempo i proprietari dei negozi di computer (come quelli di ComputerLand, che stavano esplodendo in tutta la nazione) lasciarono Radio Shack da sola a vendere e a occuparsi delle proprie macchine, concentrandosi piuttosto su altre piattaforme. È probabile che lo Zork per TRS-80 fosse finito, almeno in parte, in questa specie di buco nero distributivo, che stava già trasformando il TRS-80 in uno sconfitto, in contrasto con il nuovo gioiellino dell’industria dei microcomputer, l’Apple II. Infatti, quello stesso dicembre la Apple si quotò in borsa, facendo seduta stante dei suoi fondatori e di altre 300 persone, dei miliardari: la prima grande Offerta Pubblica Iniziale del mercato tech, il segno che presto “l’industria dei microcomputer” sarebbe diventata semplicemente “l’industria dei computer”.
 
A proposito dell’Apple II, Bruce Daniels (l’unico membro del team originale di Zork che all’epoca non si era associato alla Infocom) aveva accettato un posto alla Apple, trasferendosi in California dopo la laurea. Accettò di creare sotto contratto la Z-Machine per l’Apple II. Lo Zork dell’Apple II fu così pubblicato nel Febbraio del 1981 e fece molto meglio della versione per TRS-80, vendendo costantemente circa 1.000 copie al mese. Adesso la Infocom aveva finalmente un flusso costante di introiti, oltre all’infrastruttura tecnologica di base (lo ZIL e la Z-Machine) che avrebbe caratterizzato la società per il resto della sua vita. Le cose iniziavano ad andare per il verso giusto, ma dei risvolti imprevisti erano già all’orizzonte.
 
Ve ne parlerò molto presto, ma la prossima volta voglio lasciare da parte la realtà storica in favore di quella virtuale. Ebbene sì, faremo un piccolo viaggio nel Grande Impero Sotterraneo di Zork.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

ZIL e la Z-Machine
The Digital Antiquarian (la traduzione ufficiale italiana)


Bentrovati fedeli lettori di OldGamesItalia e del Digital Antiquarian, vi siete mai chiesti come sia possibile giocare a Zork sui moderni computer e tablet? Nulla di più semplice: per prima cosa, come ogni avventuriero che si rispetti, munitevi di foglio e matita, poi scaricate la nostra epica traduzione di Zork, infine procuratevi un interprete di Z-Machine.
La Z-Machine, ecco, è solo grazie alla mitica "Macchina Z" se Zork e la sua ricca eredità sono stati convertiti per una moltitudine di piattaforme e giocati da milioni di persone per decenni fino ai giorni nostri, un'impresa che nel 1979 era quasi impossibile... ma non per Joel Berez e Marc Blank
L'Antiquario ci trasporta in quel delicato momento della storia di Infocom.
 
La rassicurante lista degli articoli del ciclo Infocom:
 
 
Lo ZIL e la Z-Machine
Come Vendettero Zork
Giochi col Parser
Esplorando Zork, Parte 1
Esplorando Zork, Parte 2
Esplorando Zork, Parte 3
Infocom: Come Cavarsela da Soli
Zork II, Parte 1
Zork II, Parte 2
Lo Zork User Group
Zork III, Parte 1
Zork III, Parte 2
 
Buona lettura avventurieri... e non perdete la bussola!
 
Festuceto
 
Quando ci siamo lasciati l’ultima volta, Marc Blank e Joel Berez stavano valutando come portare Zork sui microcomputer. In realtà stavano cercando di risolvere tre problemi interconnessi. A costo di risultare pedante, lasciate che ve li riassuma:
 
1. Come portare Zork (un gioco enorme, che consumava 1 MB di memoria sul PDP-10) sui microcomputer di fascia più bassa che avevano selezionato: Apple II o TRS-80 con 32 K di RAM e un singolo floppy-disk.
 
2. Come farlo in modo che fosse facilmente convertibile per altre piattaforme, affinché fosse il più indolore possibile trasportare Zork non solo sull’Apple II e sul TRS-80, ma anche (se tutto fosse andato bene) sulle molte altre piattaforme incompatibili, presenti e future.
 
3. Come usare il codice sorgente esistente di Zork in MDL come base per una nuova versione per microcomputer, piuttosto che dover ripartire da zero e implementare da capo il gioco su un qualche nuovo ambiente di programmazione.
 
Volendo potete considerare questo elenco come una classifica di problemi in ordine di importanza, da “assolutamente essenziale” fino a “non sarebbe male”. Ma non è strettamente necessario, perché -come vedremo di qui a poco- Blank e Berez (col successivo aiuto degli altri) riuscirono a risolverli tutti in modo assolutamente brillante. Vorrei potermi occupare singolarmente di ognuno di questi problemi, ma (come sa chiunque si sia cimentato con delle complicate mansioni di programmazione) le soluzioni tendono a intrecciarsi l’una con l’altra. Quindi mi limiterò a chiedervi di tenere a mente questi tre obbiettivi, mentre io vi spiegherò come funzionava nel suo insieme il progetto di Blank e Berez.
 
Quando ci troviamo davanti a un gioco troppo grande per essere accomodato in un nuovo ambiente, la soluzione più ovvia sarebbe quella di rendere semplicemente il gioco più piccolo, rimuovendo dei contenuti. E questa è appunto una di quelle cose che la Infocom fece con Zork. Stu Galley:
 
Dave esaminò la sua mappa completa di Zork e tracciò un confine intorno a una porzione della stessa che includeva circa 100 location: tutte le stanze all’aperto e un’ampia sezione intorno alla Round Room. Lo scopo era quello di creare uno Zork più piccolo, che rientrasse nei limiti fissati dal progetto di Joel e Marc. Tutto quello che restava fuori sarebbe stato messo da parte per un altro gioco, da realizzare in un altro momento.
 
Dimezzando il mondo di Zork, la Infocom potette ridurre drasticamente le dimensioni del gioco. 191 stanze divennero 110; 211 oggetti divennero 117; 911 parole conosciute dal parser divennero 617. Non era la soluzione definitiva ai loro problemi, ma di certo aiutava, lasciandoli comunque con in mano un gioco enorme, delle dimensioni approssimative simili a quelle dell’originale Adventure come numero di stanze, ma capace comunque di annichilirlo in termini di oggetti e di parole, e che era comunque più grande di ogni altro gioco d’avventura per microcomputer. E, come spiega Galley qui sopra, li lasciava comunque in possesso di abbondante materiale con cui costruire un possibile seguito.
 
Altri risparmi potevano essere conseguiti spostando l’attenzione sul compilatore per MDL. Essendo un linguaggio progettato per eseguire molti compiti di computazione generici, molte delle capacità dell’MDL risultavano ovviamente inutilizzate in un gioco d’avventura come Zork. Ma, anche se inutilizzate, esse consumavano comunque memoria preziosa. La Infocom dette un paio di sforbiciate all’MDL, proprio come avevano fatto con il mondo di Zork, eliminando le librerie e la sintassi superflua, e tenendo solo ciò che era strettamente necessario per implementare un gioco d’avventura. Chiamarono il nuovo linguaggio ZIL (Zork Implementation Language [“Linguaggio per l’Implementazione di Zork”; ndAncient]), mentre il compilatore che attivava il linguaggio (che girava ancora su un PDP-1) lo chiamarono Zilch. Lo ZIL restò abbastanza simile, come sintassi e impostazione di base, all’MDL, tanto è vero che convertire Zork verso lo ZIL fu piuttosto indolore, ma nonostante ciò il nuovo linguaggio non solo produceva degli eseguibili più compatti e più veloci, ma era anche molto più pulito sintatticamente. Infatti lo ZIL incoraggiò la Infocom non solo a convertire Zork per il nuovo linguaggio, ma anche a migliorarlo da molti punti di vista; in particolare fu il parser che, implementato nel più congeniale ZIL, divenne ancora migliore.
 
Questa è la lanterna di Zork in MDL:
 
<OBJECT ["LAMP" "LANTE" "LIGHT"]
["BRASS"]
"lamp"
<+ ,OVISON ,TAKEBIT ,LIGHTBIT>
LANTERN
()
(ODESCO "A battery-powered brass lantern is on the trophy case."
ODESC1 "There is a brass lantern (battery-powered) here."
OSIZE 15
OLINT [0 >])>
 
E questo è il medesimo oggetto in ZIL:
 
<OBJECT LANTERN
                (LOC LIVING-ROOM)
                (SYNONYM LAMP LANTERN LIGHT)
                (ADJECTIVE BRASS)
                (DESC "brass lantern")
                (FLAGS TAKEBIT LIGHTBIT)
                (ACTION LANTERN-F)
                (FDESC "A battery-powered lantern is on the trophy
               case.")
                (LDESC "There is a brass lantern (battery-powered)
               here.")
                (SIZE 15)>
 
Per i posteri darò una veloce spiegazione del codice ZIL mostrato qui sopra. La prima linea semplicemente ci dice che quel che segue descriverà un oggetto chiamato “lanterna”. La linea successiva ci dice che esso si trova nel soggiorno della casa bianca. Poi vediamo che il giocatore si può riferire a esso anche con i termini “lamp,” “lantern,” or “light,”, con l’aggettivo opzionale di “d’ottone” (che del resto può rivelarsi utile per distinguerla dalla lanterna rotta che si trova in un’altra zona del gioco). Quella che viene chiamata descrizione breve (e cioè, con maggior precisione, il nome col quale appare nell’inventario e in altri punti dove deve essere inserito nel testo) è “lanterna d’ottone”. Il flag TAKEBIT indica che è un oggetto che il giocatore può raccogliere e portare in giro con sé; il flag LIGHTBIT significa che proietta luce, illuminando qualunque stanza buia in cui viene lasciato o trasportato.  LANTERN-F è la speciale routine d’azione della lanterna: un pezzo di codice che ci permette di scrivere delle “regole” speciali per la lanterna, che valgono solo per essa, come ad esempio le routine che permettono al giocatore di accenderla e di spegnerla (come ho spiegato in precedenza, questo livello di programmabilità e il conseguente approccio “orientato agli oggetti” era ciò che davvero contraddistingueva l’MDL -e di conseguenza lo ZIL- da tutti gli altri sistemi di sviluppo di avventure testuali dell’epoca). FDESC è la descrizione della lanterna che appare prima che essa sia spostata, e quindi come parte della descrizione della stanza del soggiorno; LDESC invece appare dopo che l’oggetto è stato spostato e depositato altrove. Per finire, SIZE determina le dimensioni e il peso della lanterna ai fini di stabilire quanto il personaggio possa trasportare con sé in un certo momento. Vi lascerò come esercizio quello di tradurre il più caotico codice per MDL...
 
E così a questo punto la Infocom aveva in gran parte risolto il problema n° 3 e aveva fatto dei grandi passi in avanti con il problema n° 1. Il che però li lasciava ancora con in mano il problema n° 2. Probabilmente state pensando che fosse abbastanza facile progettare un’accoppiata engine/database simile a quella ideata da Scott Adams. La verità però è che era assai problematico. Vi ricorderete infatti che una delle cose che rendevano unico l’ambiente di sviluppo di Zork (che fosse l’MDL o lo ZIL) era la sua programmabilità. Passare a una soluzione simile a quella di Adams avrebbe significato sacrificare proprio questo e, nel mezzo, anche lo ZIL. Perché lo ZIL funzionasse doveva poter eseguire del codice che gli consentisse di gestire le interazioni speciali (come, appunto, l’accensione e lo spegnimento della lanterna); doveva, in altre parole, essere un vero linguaggio di programmazione “Turing-complete” e non un mero sistema di inserimento dati. Ma come riuscirci senza rinunciare ad avere un sistema che fosse anche portabile da macchina a macchina (incompatibile)? La risposta: avrebbero ideato una macchina virtuale, un computer immaginario ottimizzato proprio per giocare alle avventure testuali (proprio come lo ZIL era ottimizzato per scriverle) e poi avrebbero scritto il codice di un interprete che avrebbe simulato quel computer su ogni piattaforma per cui avrebbero voluto pubblicare Zork.
 
Oggi le macchine virtuali sono ovunque. Le app del vostro smartphone Android in realtà girano dentro una virtual machine. Potete utilizzare qualcosa tipo VMWare sul vostro computer per utilizzare Linux dentro Windows, o viceversa. I grandi mainframe e, sempre di più, anche i server di fascia alta hanno sistemi operativi tipo Linux che funzionano all’interno di macchine virtuali astratte dal sottostante hardware; ciò, fra i vari benefici, permette anche di suddividere un unico gigantesco mainframe in tanti mainframe più piccoli. A parte gli scenari di questo tipo, le virtual machine sono così interessanti essenzialmente per due motivi; e virtualmente (ah!) chiunque decida di usarle lo fa per un motivo o per l’altro, o per entrambi. Innanzitutto sono molto più sicure. Se un codice malevolo (come un virus) viene introdotto in una macchina virtuale, rimane al suo interno, anziché infettare l’intero sistema che la ospita, e il codice che manda in crash la virtual machine (che lo faccia intenzionalmente o accidentalmente) in realtà manda in crash solo la virtual machine stessa, e non tutto il sistema che la ospita. La seconda cosa è che una virtual machine consente di eseguire lo stesso programma su macchine che sarebbero altrimenti incompatibili. È un caso di “scrivilo una volta e poi gira ovunque”, come erano soliti ripetere i sostenitori di Java. Nel loro caso, ogni piattaforma su cui doveva girare il programma in questione doveva solo essere dotata di un’implementazione aggiornata della virtual machine di Java (non necessariamente il linguaggio, anche solo la virtual machine). Le macchine virtuali hanno però anche un grosso svantaggio: poiché la piattaforma che le ospita sta emulando un altro computer, tendono a essere molto più lente dello stesso codice sorgente eseguito direttamente sulla propria piattaforma (lo so, tecnologie come la compilazione just-in-time possono fare molto per alleviare questo difetto, ma qui non è il caso di addentrarsi ulteriormente nell’argomento). Tuttavia oggi il potere computazionale è poco costoso e molto diffuso, e quindi questo in genere non è un grande problema. E infatti la situazione attuale può diventare a tratti anche abbastanza ridicola: la mia versione per Kindle di The King of Shreds and Patches è costruita su una virtual machine (Glulx) che viene eseguita dentro un’altra virtual machine (quella di Java), il tutto eseguito su un minuscolo lettore portatile... e nonostante questo le performance restano accettabili.
 
Già nel 1979 le virtual machine non erano un’idea nuova. Fra il 1965 e il 1967 un team dell’IBM aveva lavorato in stretto contatto con il Lincoln Laboratory del MIT per creare un sistema operativo chiamato CP-40, nel quale fino a 14 utenti potevano loggarsi all'interno di un proprio computer mono-utente, interamente simulato da un software eseguito su un grande mainframe della IBM. In seguito il CP-40 divenne la base del sistema operativo opportunamente chiamato VM, pubblicato per la prima volta dalla IBM nel 1972 e ancora oggi largamente usato sui mainframe odierni. Nel 1978 un’implementazione in Pascal, nota come UCSD Pascal introdusse la P-Machine, una macchina virtuale portatile che consentiva ai programmi scritti in UCSD Pascal di girare su molte macchine diverse, incluso perfino l’Apple II (in seguito alla pubblicazione dell’Apple Pascal nell’agosto del 1979). Proprio la P-Machine ebbe una grande influenza sulla virtual machine della Infocom, la Z-Machine.
 
Nell’optare per una virtual machine, dovettero ovviamente pagare (come con ogni altra virtual machine) la penalità in termini di performance, ma essa non era troppo severa come invece ci si aspetterebbe. Proprio come avevano ottimizzato lo ZIL, Blank e Berez resero infatti la Z-Machine il più leggera ed efficiente possibile, includendovi solo quelle caratteristiche davvero utili per eseguire un’avventura testuale. E poi avrebbero implementato l’interprete di ogni piattaforma solo in un linguaggio assembly altamente ottimizzato, col risultato che Zork (pur girando all’interno di una virtual machine) girava comunque molto, molto più velocemente delle tipiche avventure scritte in BASIC di quegli anni. E infatti il potere computazionale dei microcomputer, per quanto limitato, non era mai stato la loro preoccupazione principale durante la conversione di Zork: il vero collo di bottiglia era la memoria. Sì, avrebbero dovuto sacrificare della memoria aggiuntiva per l’interprete, ma ne avrebbero risparmiata ancora di più lavorando sull’efficienza della Z-Machine. Per esempio, una speciale codifica gli permetteva di immagazzinare la maggior parte dei caratteri in 5 bit invece che in 8 bit, e gli permetteva di rimpiazzare le parole più comunemente usate con delle loro abbreviazioni. Una tale compressione del testo era molto rilevante, specie se consideriamo che, dopotutto, è il testo che compone la maggior parte di un'avventura testuale. Con tali tecniche di compressione, insieme alle sforbiciate al gioco stesso e al linguaggio ZIL, finirono per avere un gioco di soli 77 K di dimensioni, senza ovviamente considerare l’interprete della macchina virtuale che era necessario per eseguirlo; quest’ultimo fu chiamato Zip (da non confondersi ovviamente con il formato di compressione dei file). Il file del gioco da 77 K, che la Infocom iniziò a chiamare “story file” [“file della storia”; ndAncient] è sostanzialmente uno "snapshot" della memoria della virtual machine.
 
Quando parliamo di capacità di immagazzinamento di un computer, in realtà stiamo parlando (confondendo così genitori e nonni di tutto il mondo) di due quantità separate: la capacità su disco e la capacità di memoria (RAM). Un Apple II poteva contenere 140 K su un singolo dischetto, mentre il TRS-80 in realtà faceva un po’ meglio con i suoi 180 K. E così ora la Infocom aveva un gioco che poteva essere comodamente alloggiato, insieme al suo necessario interprete, su un singolo dischetto. Il problema era la RAM: anche dimenticandoci il necessario interprete, 77 K non entrano in 32 K, per quanto ci si sforzi di ficcarceli. Oppure sì?
 
Non era la prima volta nemmeno in quegli anni che si sentiva usare il disco come una sorta di memoria secondaria, leggendo dei pezzetti di dati e trasferendoli nella RAM, per poi scartarli quando non erano più necessari. La Microsoft aveva usato proprio questa tecnica per infilare Adventure nei 32 K del TRS-80: ogni pezzo di testo, tutti immagazzinati in un file esterno al gioco stesso proprio come nel progetto originale di Crowther e Woods, veniva letto dal disco solo quando doveva andare a schermo. Tuttavia il sofisticato sistema orientato agli oggetti della Infocom mischiava necessariamente testo e codice, rendendo quantomeno poco pratico un tale approccio. Per questo Blank e Berez si spinsero un passo oltre: avendo già progettato una virtual machine, vi aggiunsero un’implementazione della memoria virtuale.
 
Anche il concetto di memoria virtuale non era nuovo, in generale, nel mondo dell’informatica. E infatti la memoria virtuale risale ancora più indietro nel tempo delle virtual machine, fino a uno dei primi supercomputer, sviluppato dalla University of Manchester e chiamato Atlas, che era stato ufficialmente commissionato nel 1962. In un sistema con memoria virtuale, ogni programma non ha un punto di vista “onesto” sulla memoria fisica del computer host. In sostanza gli viene data una mappa “idealizzata” della memoria, che potrebbe avere ben poco a che fare con il vero layout della RAM fisica del computer che lo ospita. Quando legge e scrive dei pezzi di questa mappa, l’host automaticamente traduce gli indirizzi virtuali in indirizzi reali dentro la sua memoria fisica, in modo trasparente. Ma perché mai fare una cosa del genere, specialmente se consideriamo che produce necessariamente uno spreco di risorse? Anche stavolta per due principali ragioni, entrambe le quali di solito si considerano applicabili solo a sistemi operativi multitasking (che ovviamente erano poco più di un sogno per i microcomputer del 1979 o del 1980). Per prima cosa, isolando la memoria di ciascun programma da quella di ogni altro (oltre che da quella del sistema operativo) la memoria virtuale si assicura che un programma non possa (per malizia o semplicemente a causa di bug) corrompersi e danneggiare altri programmi, se non addirittura far crashare l’intero sistema. Per seconda cosa, la memoria virtuale fornisce al computer una specie di “seconda spiaggia”, un’alternativa al semplice fallimento di sistema, qualora un programma (o più programmi) in esecuzione chiedessero più memoria fisica di quella concretamente disponibile. Quando ciò accade, il sistema operativo cerca nella propria memoria dei pezzi che non vengono usati spesso. A quel punto li archivia nella cache su disco, facendo così spazio nella RAM fisica per allocare la nuova richiesta. Quando si deve accedere nuovamente alle aree così archiviate nella cache, esse devono essere riportate nella RAM, possibilmente scambiandole con altri chunk, se la memoria è scarsa. Tutto ciò avviene in modo trasparente rispetto al programma (o ai programmi) in questione, che continuano a vivere all’interno del loro punto di vista idealizzato sulla memoria, gioiosamente ignari di quanto il sistema sottostante stia in realtà ansimando per tenere tutto in piedi. La memoria virtuale ormai è con noi da molti anni nel mondo dei PC desktop. In uno schema del genere c’è inevitabilmente un punto in cui il gioco non vale più la candela: se avete provato ad aprire tantissime finestre o programmi su un vecchio PC, avrete notato che tutto diventava terribilmente lento, mentre l’hard disk lavorava come un mulino; ecco, adesso sapete quello che stava succedendo dietro le quinte (sempre che non lo sapeste già; qui al The Digital Antiquarian non presupponiamo nessun livello di conoscenze tecniche nei nostri lettori).
 
Per la Z-Machine, Berez e Blank adoperarono una versione molto più semplice della memoria virtuale rispetto a quella che oggi troviamo in sistemi operativi come Windows, Linux, o OS X. E se certe importanti informazioni dinamiche (come la posizione attuale di oggetti all’interno del mondo di gioco) deve essere sempre tracciata e aggiornata dinamicamente, la gran parte dei dati che compongono un gioco come Zork è in realtà statica e non cambia nel tempo: tanto, tanto testo, ovviamente, mischiato a un bel po’ di codice. Berez e Blank riuscirono a progettare il compilatore ZIL in modo tale che esso collocasse tutta la roba che poteva realisticamente cambiare (e che noi chiameremo “dati dinamici”) all’inizio dello story file. Tutto il resto (che noi chiameremo “dati statici”) veniva dopo. Ebbene, dei 77 K dello story file di Zork, solo 18 K erano di dati dinamici. Ecco quello che fecero, quindi...
 
I dati dinamici (cioè la memoria in cui la virtual machine avrebbe scritto, oltre che letto) è sempre immagazzinata nella RAM del computer host. I dati statici tuttavia sono caricati e scaricati dalla RAM ad opera dell'interprete, secondo il bisogno, in blocchi di 1 K chiamati “page” [“pagine”; ndAncient]. In altre parole: dal punto di vista del gioco, esso ha 77 K di memoria con cui lavorare. L’interprete nel frattempo scambia freneticamente blocchi di memoria dentro e fuori dalla molto più limitata RAM fisica, per mantenere in piedi questa illusione. Come la virtual machine, anche la memoria virtuale porta ovviamente con sé un rallentamento, ma è un male necessario. Su un sistema a 32 K, con 18 K riservati ai dati dinamici, la Infocom aveva ancora 14 K liberi per ospitare al loro interno l’interprete della macchina virtuale, un piccolo “stack” (cioè un’area dove i programmi immagazzinano le informazioni temporanee di cui hanno bisogno per il “moment-to-moment processing”) e una “page” o due di memoria virtuale. Certo alle volte poteva rallentare vistosamente, ma funzionava. E, quando veniva avviato su un sistema con, ad esempio, 48 K, l’interprete se ne accorgeva automaticamente e usava questa memoria addizionale per tenere più dati statici nella RAM fisica, velocizzando così il tutto e ripagando l’utente per il suo investimento nell’hardware.
 
Con l’impianto ZIL / Z-Machine, la Infocom aveva creato un sistema, robusto e riutilizzabile, che avrebbe potuto godere di vita propria ben al di là del compito specifico di infilare Zork sul TRS-80 e sull’Apple II. Sono certo di non spoilerare niente a nessuno, se vi svelo già adesso che ciò è esattamente ciò che accadde.
 
Forti di tali fondamenta tecniche, la prossima volta osserveremo il percorso che portò infine Zork sul mercato.  

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

 

DunjonQuest
The Digital Antiquarian (traduzione ufficiale italiana)

Non si può enfatizzare abbastanza quanto i war games e i giochi di ruolo da tavolo (e in particolare, ovviamente, Dungeons and Dragons della TSR) abbiano influenzato le prime narrative ludiche su computer. A volte tale influenza è del tutto palese, come nel caso di giochi tipo Eamon che cercavano esplicitamente di trasportare su computer l'esperienza del D&D. Altre volte però tale influenza è meno apparente.

A differenza dei tipici giochi da tavolo, o perfino dei war game, il D&D e i suoi contemporanei non erano commercializzati come prodotti singoli, ma come delle vere e proprie raccolte di esperienze, quasi uno stile di vita. Solo per iniziare a giocare con la punta di diamante, l'Advanced Dungones & Dragons, si dovevano acquistare tre grandi volumi dalla copertina rigida (Monster Manual, Players Handbook, e Dungeon Masters Guide), a cui si aggiunsero presto molti altri volumi, che descrivevano nuovi mostri, nuovi tesori, nuovi dei, nuove classi di personaggio, e nuove regole sempre più complesse per nuotare, per creare oggetti, per muoversi nelle ombre, per rubare, e -ovviamente- per combattere. Ma, soprattutto, c'erano i moduli d'avventura: avventure preconfezionate, vere e proprie narrative ludiche che potevano essere messe in scena utilizzando il sistema di gioco di D&D. Ne uscivano a dozzine, meticolosamente catalogate con un sistema alfanumerico che permetteva ai collezionisti compulsivi di tenerne traccia; una trilogia di moduli dedicati ai giganti fu etichettata da “G1” a “G3”, una serie di moduli creata nel Regno Unito fu etichettata “UK” [che sta per “United Kingdom”; ndAncient]. A parte i vari vantaggi ludici, questo sistema era indubbiamente il sogno di ogni addetto alle vendite. Perché limitarsi a vendere un solo gioco ai tuoi clienti, quando puoi incatenarli a un intero universo in continua espansione di prodotti?

La strategia di marketing della TSR (basata sulla filosofia di “un solo gioco / molti prodotti”) e il suo zelo per la catalogazione possono essere ritrovati anche fra quei primi sviluppatori di giochi per computer che non stavano provando esplicitamente ad adattare le regole del D&D ai loro mondi digitali. Scott Adams, per esempio, numerò tutte le sue avventure, arrivando così a una dozzina di giochi canonici (altre avventure, presumibilmente non scritte di proprio pugno dal maestro, furono invece pubblicate dalla Adventure International come delle specie di opere apocrife ufficiali sotto l'etichetta “OtherVentures”). I giocatori venivano incoraggiati a giocarle in ordine, visto che aumentavano gradualmente di difficoltà; in questo modo il giocatore principiante poteva affilarsi i denti con opere relativamente “forgiving” tipo Adventureland e Pirate Adventure, per poi gettarsi nei giochi successivi assurdamente difficili tipo Ghost Town e Savage Island. La On-Line Systems adottò un modello simile, sottotitolando retroattivamente Mystery House in Hi-Res Adventure #1 dopo aver pubblicato la Hi-Res Adventure #2 (The Wizard and the Princess). Il gioco successivo Mission: Asteroid, apparso all'inizio nel 1981, fu battezzato Hi-Res Adventure #0 (nonostante la cronologia delle uscite) perché era stato pensato come gioco per principianti, con un po' meno assurdità ed enigmi iniqui del solito. A tutti gli effetti queste similitudini con l'approccio del D&D erano qualcosa di più di un semplice fenomeno di marketing. Del resto entrambe le linee di giochi erano basate su motori riutilizzabili. Nello stesso modo in cui un gruppo di giocatori viveva intorno al tavolo molte avventure diverse usando le regole alla base del D&D, così le linee di avventure di Scott Adams o le Hi-Res Adventures erano essenzialmente delle regole base (il motore di gioco) applicate a molte narrative ludiche diverse.

Tuttavia, fra gli sviluppatori che abbiamo esaminato fin qui, quelli che imitavano in modo più palese il modello del D&D erano -logicamente- quelli che provenivano direttamente dalla cultura del D&D: Donald Brown con il sistema di Eamon, e le Automated Simulations, gli sviluppatori della linea DunjonQuest che era iniziata con Temple of Apshai. J.W. Connelley, il principale sviluppatore del motore dell'Automated Simulations, aveva progettato per Temple of Apshai un motore riutilizzabile che leggeva i file di dati che rappresentavano i livelli del dungeon che si esplorava. Proprio come accadde per Scott Adams e per la On-Line Systems, questo approccio da un lato rese il gioco più facile da convertire (e infatti le versioni per tutte le principali macchine del 1979 -TRS-80, Apple II, Commodore PET- furono pubblicate quello stesso anno), e dall'altro lato velocizzò lo sviluppo di nuove iterazioni del medesimo concept. Tali iterazioni furono etichettate come un set unico di esperienze, che prese il nome di DunjonQuest. Il pittoresco appellativo dalla dizione medievale fu probabilmente scelto per evitare conflitti con la litigiosissima TSR, che, oltre alle regole del D&D, stava commercializzando anche un gioco da tavolo chiamato semplicemente Dungeon!

E la Automated Systems non fece certo mancare tali iterazioni! Altri due titoli della collana DunjonQuest apparvero lo stesso anno di Temple of Apshai. Sia Datestones of Ryn che Morloc’s Tower facevano parte di quelle che la Automated Simulations chiamò MicroQuests, nelle quali gli elementi di costruzione del personaggio erano completamente assenti. Al loro posto il giocatore doveva guidare un personaggio pregenerato attraverso un ambiente molto più piccolo. Ci si aspettava che il giocatore affrontasse più volte l'avventura, cercando di conseguire risultati sempre migliori. Nel 1980 la Automated Simulations pubblicò invece il “vero” seguito di Temple of Apshai, Hellfire Warrior, che conteneva i livelli dal quinto all'ottavo del labirinto iniziato col gioco precedente. Sempre quell'anno pubblicarono anche due titoli più modesti, Rescue at Rigel e Star Warrior, le prime e uniche uscite di una nuova serie, StarQuest, che catapultava il sistema DunjonQuest nello spazio.

Almeno secondo una prospettiva moderna, c'è una sorta di dissonanza cognitiva in queste serie, se le esaminiamo nel loro complesso. I manuali spingevano molto sull'aspetto sperimentale di questi giochi, come ben dimostrato da questo estratto del manuale di Hellfire Warrior:

Quali che siano il tuo background e le tue esperienze precedenti, ti invitiamo a proiettare nel “dunjon” non solo il tuo personaggio, ma anche tutto te stesso. Ti invitiamo a perderti nel labirinto. A sentire la polvere sotto i tuoi piedi. Ad ascoltare il suono di passi non umani che si avvicinano o il lamento di un'anima persa. Lascia che l'odore di zolfo assalga le tue narici. Brucia al caldo delle fiamme dell'inferno, e gela sopra un ponte di ghiaccio. Passa le dita in un cumulo di monete d'oro e immergiti in una pozza d'acqua magica.
Entra nel mondo di DunjonQuest.

Nonostante tutto questo, nessuno di questi giochi aveva la benché minima trama. Temple of Apshai e Hellfire Warrior non hanno nemmeno una fine vera e propria, ma solo dei dungeon che si rigenerano all'infinito da esplorare e un personaggio giocante da migliorare in eterno. Mentre le MicroQuests ricompensano i giocatori solo con un insoddisfacente punteggio finale al posto di un epilogo vero e proprio. Sebbene il background narrativo del suo manuale sia ideato con un'attenzione insolita, Datestones of Ryn ha un limite temporale di soli 20 minuti, che gli dà più un feeling da gioco d'azione, giocabile all'infinito e quasi privo di contesto, piuttosto che da gioco di ruolo per computer. Invece il gameplay della serie nel suo complesso, oggi, ci balza all'occhio per le sue similitudini con i roguelike, dei dungeon crawl senza storia (o, almeno, con pochissima storia) attraverso labirinti generati casualmente. Questa però sarebbe una lettura anacronistica: Rogue, il capostipite del genere, in realtà è uscito un anno dopo Temple of Apshai.

Credo che tutte queste stranezze possano essere spiegate se comprendiamo che Jon Freeman, il principale designer dietro il sistema, stava puntando a creare un tipo di narrativa ludica diverso da quella delle avventure testuali di Scott Adams e da quella tipica della On-Line Systems. Lui sperava che, dati un background, una descrizione degli ambienti, un set di regole per controllare ciò che vi accadeva, e una buona dosa di immaginazione da parte del giocatore, dal gioco emergesse autonomamente una narrativa ludica. In altre parole, usando un termine che appartiene ad un'era molto successiva, stava tentando di creare una narrativa emergente. Per comprendere meglio il suo approccio, ho pensato di dare una breve occhiata da vicino a uno dei suoi giochi, Rescue at Rigel

Rescue at Rigel trae ispirazione dalla classica space opera, un genere che è stato recentemente riportato in vita dal fenomenale successo dei primi due film di Star Wars [l'articolo è stato scritto nel 2011, quindi l'autore si riferisce alla seconda trilogia di Guerre Stellari; ndAncient].

Nell'arena della vostra immaginazione, non tutti i nostri eroi (o le nostre eroine!) indossano armature nere o di uno scintillante argento, né prendono a mazzate dei barbari nemici su dei moli sferzati dal vento, né affrontano dei macabri destini per mano di depravati adepti le cui arti nere erano già vecchie quando il mondo era giovane. La fantascienza ci fa viaggiare su navi stellari con nomi come Enterprise, Hooligan, Little Giant, Millenium Falcon, Nemesis, Nostromo, Sisu, Skylark, e Solar Queen. Navi che viaggiano su mari stellati, che non sono percorsi da tempeste o infestati da demoni, ma che non per questo sono meno spaventosi. Navi che ci fanno approdare su nuovi mondi impavidi le cui forme, i cui panorami e i cui suoni sono più plausibili (ma non meno sbalorditivi) di quelli sperimentati da Sinbad.

In questo titolo il giocatore assume il ruolo di Sudden Smith, un classico ed energico eroe pulp. Sta per teletrasportarsi nella base di una razza di alieni insettoidi conosciuti col nome di Tollah, che hanno catturato un gruppo di scienziati per le loro “ricerche” e fra questi c'è anche la fidanzata di Sudden. I Tollah sono uno dei pochissimi accenni ad eventi di un mondo più ampio che troverete nei primissimi videogiochi, al di là delle opere di fantasy e science-fiction. La casta che comanda i Tollah sono gli “High Tollah”, un chiaro riferimento allo Ayatollah Khomeyni, che a quel tempo aveva recentemente preso il potere in Iran e che teneva in ostaggio 52 Americani [“High Tollah”, cioé “Alto Tollah”, si pronuncia infatti in modo molto simile a Ayatollah; ndAncient]. Gli “High Tollah” ci dice il manuale, “sono altezzosi, autoritari, intolleranti, ottusi, privi di immaginazione e inflessibili.” Alla luce di tutto questo, è palese quale sia stata l'ispirazione per questo scenario di salvataggio degli scienziati.

Il gameplay si sviluppa intorno all'esplorazione della base dei Tollah, convenientemente strutturata come un labirinto, respingendo i Tollah e i robot della sicurezza, mentre cerchiamo i dieci scienziati che vi sono tenuti in ostaggio. Si tratta sostanzialmente, come in tanti altri giochi di ruolo per computer, di un gioco di gestione delle risorse: Sudden ha un numero limitato di medikit, di munizioni, e soprattutto una riserva limitata di energia all'interno del suo zaino che deve essere usata per tutto (dallo sparare agli Tollah, fino al teletrasportare gli scienziati al sicuro). Quel che è peggio è che Sudden ha soltanto 60 minuti di tempo reale per salvare il maggior numero possibile di scienziati e teletrasportarsi al sicuro. Freeman fa di tutto per rendere il gioco un motore di eccitante narrativa emergente. Ad esempio, se Sudden finisce completamente l'energia, ha comunque un'ultima possibile via di fuga: se riesce a tornare nei 60 minuti al punto in cui lo ha depositato il teletrasporto, un altro teletrasporto automatico lo riporterà in salvo. È facile immaginarsi una situazione disperata, che pare uscita direttamente da una storia di Guerre Stellari o di Dominic Flandry, con il giocatore che torna sui suoi passi, in mezzo al fuoco dei laser, mentre il tempo scorre e i Tollah gli sono alle calcagna. Di certo ci possiamo immaginare che Freeman si fosse immaginato tutto questo.

Ma per vivere queste storie è necessaria una notevole dedizione e una fervida immaginazione da parte del giocatore, come potrà probabilmente convenire chiunque abbia osservato l'orrendo screenshot di cui sopra. Effettivamente i giochi della serie DunjonQuest sembrano proprio una sorta di ibrido fra l'esperienza di un gdr da tavolo e di uno digitale, in cui ciò che emerge direttamente dall'immaginazione del giocatore è importante quanto quello offerto dal gioco stesso. È per questo che probabilmente è stata una mossa saggia per la Automated Simulations quella di usare come target del marketing di DunjonQuest proprio i giocatori di ruolo cartaceo. Del resto loro sono abituati a rimboccarsi le maniche e a usare la loro immaginazione per inventare delle narrative soddisfacenti. La Automated Simulations pubblicizzò ampiamente DunjonQuest sulla rivista Dragon Magazine della TSR, e (con una mossa che non potrebbe essere più indicativa della tipologia di pubblico che pensavano potesse apprezzare DunjonQuest) arrivarono persino a regalare il gioco da tavolo strategico chiamato Sticks and Stones con ogni acquisto di un gioco della serie DunjonQuest.

Negli ultimi mesi del 1980 la Automated Simulations cambiò il suo nome nel meno prosaico Epyx, adottando il motto: “Computer games thinkers play” [traducibile all'incirca come “Videogiochi a cui giocano le persone che pensano”; ndAncient]. I giochi della serie DunjonQuest continuarono comunque a uscire per altri due anni. Fra le ultime pubblicazioni ci furono anche un paio di espansioni per Temple of Apshai e Hellfire Warrior, che credo siano i primi esempi del genere tra i giochi commerciali per computer. Invece l'utilizzo più strano e creativo dell'engine di DunjonQuest arrivò nel 1981 con Crush, Crumble, and Chomp!: The Great Movie Monster Game, nel quale il giocatore assumeva il controllo di Godzilla (anzi, no, di Goshzilla!), o di qualche altro mostro famoso lanciato nella distruzione di una città. Per un esame dettagliato di tutta la serie di DunjonQuest, che alla fine si compose di una dozzina di titoli, potete leggere questo articolo di Hardcore Gaming 101.

Crush, Crumble, and Chomp! fu l'ultimo lavoro di Freeman per la Epyx. Alla West Coast Computer Faire of 1980 incontrò infatti una collega programmatrice chiamata Anne Westfall e di lì a poco i due iniziarono a frequentarsi. Westfall si unì alla Epyx per un po', andando a lavorare come programmatrice su alcuni degli ultimi giochi di DunjonQuest. Lei e Freeman però ben presto si stufarono del disinteresse di Connelley nel miglioramento dell'engine di DunjonQuest. Scritto in BASIC sull'ormai vetusto TRS-80 Model I, tale engine era sempre stato tremendamente lento e ormai iniziava a sembrare davvero datato nei porting per le piattaforme più moderne e capaci. In più Freeman, un designer irrequieto e creativo, si stava annoiando delle continue iterazioni del solito concept di DunjonQuest; perfino creare Crush, Crumble, and Chomp! aveva richiesto una dura battaglia da parte sua... Alla fine del 1981 Freeman e Westfall lasciarono la Epyx per creare una casa di sviluppo indipendente, la Free Fall Associates, della quale avrò molto altro da dire in futuro. E, dopo un paio di ultime pubblicazioni per DunjonQuest, la Epyx si trasformò da “Computer games thinkers play” in qualcosa di molto diverso, e anche di questo avrò molto da dire in futuro. Con incassi buoni, ma mai enormi, neppure al massimo del proprio splendore, i giochi della serie DunjonQuest sfiguravano abbastanza nel confronto con la nuova generazione di giochi di ruolo per computer, dei quali -come avrete immaginato- avrò molto altro da dire in futuro.

Se volete sperimentare l'esperienza di DunjonQuest, posso fornirvi un pacchetto con un immagine per Apple II che include Temple of Apshai, Rescue at Rigel, Morloc’s Tower, e Datestones of Ryn, oltre ai relativi manuali.

La prossima volta inizieremo a esplorare un'opera con una profondità tematica senza precedenti, che fa già drizzare tutte le mie antenne di studioso di letteratura.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.

Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

Cestinando il Trash del TRS-80
The Digital Antiquarian (traduzione ufficiale italiana)

Nel 1980 il panorama dei microcomputer appariva molto diverso rispetto ai tempi in cui la “trinità del 1977” irruppe sulle scene. Per gli hacker e gli altri utenti pionieri che ne avevano decretato il successo, il TRS-80 era un passo verso la sanità mentale (almeno rispetto alle follie da saldatori di chi si era costruito l'Altair in garage partendo da degli schemi e da un ammasso sciolto di chip), ma... si trattava proprio solo di un passo. Possedere e far funzionare un computer era ancora costoso e difficile, e alla domanda che era sulle labbra di mogli e fidanzate di tutta la nazione ("Ma, esattamente... a che serve?") in realtà non c'era ancora alcuna risposta veramente convincente. Tuttavia già nel 1980 le cose iniziavano a cambiare, quanto basta almeno perché dei segmenti di popolazione iniziassero ad acquistare computer non per il mero fascino della tecnologia in sé, ma piuttosto per ciò che la tecnologia avrebbe permesso loro di realizzare. E questo per merito del lavoro di tutti quegli utenti pionieri, che avevano hackerato come pazzi per creare delle cose utili che avessero potuto giustificare il tempo investito secondo gli standard dell'economia di mercato (e cioè in termini di dollari e centesimi), il tutto per potersi così permettere altro tempo per... hackerare ancora.

Oggi la più celebrata di queste prime "killer application" (tale, forse, per essere comparsa nel documentario  The Triumph of the Nerds) è VisiCalc, il foglio di calcolo il cui approccio di base è ancora oggi echeggiato da quel Microsoft Excel che tutti noi conosciamo e amiamo (?). Introdotto alla fine del 1979, VisiCalc ha dato ai commercialisti, ai piccoli imprenditori, e perfino agli utenti comuni delle ragioni per possedere un microcomputer: che fosse per calcolare le tasse, o per preparare le fatture, o anche solo per tenere il saldo del blocchetto degli assegni. Ma ci sono anche altri esempi. Il primo rozzo programma per scrittura si chiamava The Electric Pencil, ed era perfino antecedente alla “trinità del 1977”, essendo apparso nel Dicembre 1976 per i primissimi computer assemblati a partire da un kit. Ci volle però WordStar per rifinire il concetto di programma di scrittura in uno strumento flessibile e abbastanza potente da poter rimpiazzare le costose macchine da videoscrittura che al tempo della sua pubblicazione nel Settembre 1978 occupavano ancora le scrivanie di tutte le segretarie della nazione. Invece dBase (il primo database relazionale programmabile per i microcomputer) fece la sua comparsa nel 1979. E poi, anche se venivano menzionati apertamente solo raramente come una buona ragione per acquistare uno dei primi computer, c'erano i giochi, sempre presenti come una sorta di piacere proibito e segreta motivazione all'acquisto. Nel 1980 i giochi per computer erano ancora grezzi e limitati, ma crescevano a passi da gigante (sia nelle ambizioni che nelle vendite) mano a mano che spuntavano i primi publisher specializzati nell'entertainment (come la  Adventure International) e che i nuovi microcomputer (molto più adatti al gioco) iniziavano ad apparire sulla scia dello scalpore suscitato dalla console Atari VCS, che iniziò a diffondersi sul serio in tutta la nazione durante il periodo delle feste del 1979.

Ah, sì, le nuove macchine. Mano a mano che le nuove applicazioni mostravano quanto potevano essere utili e/o divertenti i computer, sia a lavoro che a casa, e mano a mano che le vendite rispondevano di conseguenza, tanti nuovi attori si affrettavano a gettarsi nel mercato. Alcuni, come lo Exidy Sorcerer e il Texas Instruments 99/4, vi trovarono ben poche soddisfazioni, diventando solo delle note al margine e degli oggetti per il moderno collezionismo. Altri invece portarono con sé dei significativi sviluppi tecnologici e culturali. Prima o poi ci occuperemo di loro, ma in questo articolo lasciate che provi a mettere un po' di ordine (vale a dire a costruire alcune categorie) nel pazzo intreccio dei microcomputer disponibili al pubblico nel 1980. Stranezze come il TI 99/4 (il primo microcomputer a 16 bit del mondo, basato su una CPU ideata dalla stessa Texas Instruments) a parte, la maggior parte dei computer erano basati su due CPU distinte, entrambe con architetture a 8 bit.

Erano l'Intel 8080 (il chip al cuore dell'originale "computer da assemblare" Altair e degli altri suoi contemporanei) e lo Z80 (una CPU per lo più compatibile prodotta dalla Zilog, che tuttavia offriva un design più flessibile ed efficiente); questo ultimo -come forse vi ricorderete- era il chip che la Tandy aveva scelto per il suo TRS-80. Al di là del TRS-80, che rimase nel bene e (come vedremo tra poco) nel male una cosa a parte, queste macchine generalmente montavano il primo sistema operativo "platform-agnostic" [tecnologicamente neutrale] ad ampia diffusione: il CP/M (Control Program for Microcomputers ["Programma di Controllo per Microcomputer"]). Sviluppato da Gary Kildall all'alba dell'era dei microcomputer e pubblicato dalla sua società Digital Research, il CP/M era l'MS-DOS (o, se preferite, il Microsoft Windows) di quest'epoca, uno standard -di fatto, se non ufficiale- che consentiva a un ampio numero di produttori di condividere software e informazioni (a dire il vero ci sarebbe anche un collegamento più tangibile fra CP/M e MS-DOS: a seconda di chi è l'interlocutore, l'MS-DOS originale del 1981 era o "ispirato dal" CP/M o addirittura un'opera di spudorato reverse engineering di quello. Ma su questo argomento torneremo sicuramente in futuro...).
Però, perché un computer potesse far funzionare il CP/M, aveva bisogno di due cose: di una CPU Intel 8080, o Zilog Z80, e di un certo design standard del bus per le comunicazioni con i  "disk drive" e le altre periferiche, noto come S-100; un design che risaliva al primo Altair. (AGGIORNAMENTO: Come giustamente segnalato da Jonno nei commenti, strettamente parlando l'S-100 non era un requisito necessario per far funzionare il CP/M).

Il CP/M, e le architetture basate sulle CPU Intel e Zilog su cui funzionava, divennero l'ambiente standard per i microcomputer "seri" della fine degli anni '70 e dell'inizio degli '80, quelli cioè utilizzati dalle piccole e medie imprese.  Fu su questi computer che nacquero WordStar e dBase, e che vi approdò rapidamente anche VisiCalc (pur se concepito sull'Apple II). Il CP/M tuttavia non aveva alcuna capacità grafica e aveva solo un supporto limitato per le operazioni in tempo reale, risultando di conseguenza una piattaforma difficile da usare per molti tipi di giochi e perfino per i programmi educativi. E poi si affidava alla presenza di almeno un "disk drive" sulla piattaforma che lo ospitava, in un periodo in cui tendevano a essere molto costosi. Questi fattori fecero sì che il CP/M e l'8080 fossero poco adatti per essere impiegati nei computer meno costosi, e solitamente funzionanti a cassette, destinati agli utenti domestici.  Quella fascia di mercato era dominata da un'altra architettura hardware: la CPU 6502 delle MOS Technologies.

Quando il 6502 comparve per la prima volta nel 1975, la MOS era solo un minuscolo produttore indipendente di chip, ma le cose erano destinate a cambiare quando la Commodore acquistò l'intera società nel 1976. Questa mossa (una delle più astute mai fatte da Jack Tramiel, il capo della Commodore), mise la  Commodore nell'invidiabile posizione di guadagnare non solo quando vendeva le proprie macchine come il PET, ma anche ogni volta che un rivale acquistava il 6502 per i suoi prodotti. Tali rivali inizialmente includevano solo la Apple con la linea Apple II e tutta una serie di computer da assemblare tramite kit di svariati produttori; ma anche questo era rapidamente destinato a cambiare.

Non fu però mai sviluppato l'equivalente del CP/M per le macchine basate su 6502; il che comportò che tali macchine restassero sostanzialmente incompatibili le une con le altre. Il BASIC funzionò in parte da "lingua franca", visto che praticamente tutte queste macchine ospitavano nelle loro ROM una versione del BASIC della Microsoft (che era ormai lo standard dell'industria), ma ogni implementazione di tale BASIC era sufficientemente diversa dalle altre da far sì che la maggior parte dei programmi necessitassero comunque di un minimo di ritocchi. E poi, ovviamente, quando ci si spostava dal BASIC al linguaggio assembly per sfruttare al meglio tutto quello che il 6502 aveva da offrire (e in particolare grafica e sonoro, capacità che oltretutto variavano enormemente da modello a modello), si doveva sostanzialmente riprogrammare tutto da zero per ogni macchina che si voleva supportare. Erano tempi folli, anche se con l'attuale [era il 2011; ndAncient] proliferazione di device mobili incompatibili fra loro, lo scenario inizia nuovamente ad assomigliare a quello del 1980.

Tuttavia quello che l'universo del 6502 perdeva in compatibilità, di certo lo acquistava in flessibilità. Liberi dal gravoso compito di dover lavorare con un sistema operativo relativamente complesso e inefficiente come il CP/M, i programmatori avevano molto più controllo su queste macchine, potendo manipolare direttamente ogni elemento dell'hardware per ottenere la massima efficienza. Inoltre le macchine basate sul 6502, generalmente indirizzate ai mercati domestici e educativi, erano tendenzialmente dotate di capacità grafiche e sonore, che erano invece del tutto assenti nell'universo spoglio e testuale del CP/M; l'Apple II per esempio era l'unico membro della “triade del 1977” a supportare una grafica bitmap vera e propria; ma di questo argomento inizierò a parlare in maggior dettaglio nel mio prossimo articolo.

Ora forse vi starete chiedendo in tutto questo dove fosse finito il TRS-80, che di diritto non apparteneva a nessuna delle due categorie appena descritte. Anche se il TRS-80 era costruito sulla CPU Z80, Radio Shack per spilorceria aveva scelto di non implementare il design del bus S-100 (AGGIORNAMENTO: Come accade di quando in quando da queste parti, quest'ultima affermazione non è corretta. In realtà il problema è relativo alla "memory map" del TRS-80, nella quale la ROM veniva prima della RAM; mentre invece una macchina CP/M richiedeva l'opposto. I miei ringraziamenti a Jonno per avermelo fatto notare nei commenti di questo post).  Questo lo rendeva incompatibile con il CP/M. Nonostante l'enorme successo dei primi anni e nonostante avesse ancora la base di installato più ampia di qualunque altro microcomputer, il futuro del TRS-80 era (almeno col senno di poi) già offuscato nel 1980. La sua incompatibilità con il CP/M lo tagliava fuori da tutta la base del software professionale in netta espansione su quel sistema operativo. E poi, nonostante il prezzo abbastanza conveniente del TRS-80, la reputazione di Radio Shack di essere fornitori di spazzatura a buon mercato per le masse faceva ben poco per attrarre gli utenti "business" e -nel classico scenario del gatto che si morde la coda- a sua volta l'assenza di utenti "business" scoraggiava gli sviluppatori dal convertire i loro prodotti dal CP/M alla piccola macchina stravagante della Tandy. A questo si aggiunge il fatto che anche nell'altra metà del mercato dei microcomputer (e cioè nel mondo delle macchine da gioco e dell'informatica hobbistica, dominato dal 6502) il TRS-80 sembrava sempre più inadeguato a causa della sua assoluta mancanza di grafica e sonoro. L'arrivo dell'Atari 400 e dell'Atari 800 (due macchine piene di colori, basate sul 6502, e con capacità grafiche e sonore stupende per il tempo) e, poco dopo, all'inizio del 1981, del Commodore VIC-20 (una macchina con assai meno capacità al confronto, ma comunque dotata di grafica a colori e sonoro, e venduta ad un prezzo che non aveva precedenti) erano presagi particolarmente infausti.

Per quanto la saggezza di molte delle sue scelte fosse quantomeno discutibile, la Tandy se non altro non rimase inerme di fronte a questi sviluppi. Rilasciò infatti un gran numero di nuovo macchine, nessuna della quali però si avvicinò nemmeno lontanamente a recuperare la quota di mercato di cui godeva il TRS-80 alla fine degli anni '70.

La Tandy uscì con una nuova macchina chiamata TRS-80 Model 2 (il primo TRS-80 fu retroattivamente rinominato Model 1) a fine 1979. Il Model 2 era progettato per catturare il mercato aziendale che stava saltando a piè pari il Model 1; veniva venduto con i "disk drive" integrati e implementava correttamente il bus S-100 bus includeva una ROM di tipo bank switching, che gli consentiva di far girare il CP/M. Ma era anche una macchina molto più costosa del Model 1 e, cosa che era ancora peggio, del tutto incompatibile con esso. Grazie al tipico scarso acume per il marketing di Radio Shack, alla loro passione per le linee goffe e pacchiane unite a un prezzo molto alto, il Model 2 non fu un successo nel mercato "business" e al contempo la sua incompatibilità lo rese scarsamente appetibile anche per chi già possedeva un Model 1.

Il Model 3, che doveva rimpiazzare il Model 1 nell'estate del 1980, fu quasi un passo obbligato per Radio Shack. Il Model 1 infatti emetteva talmente tante interferenze radio che, in un classico esempio di sconfinata ingenuità tipica della prima era dei microcomputer, la gente iniziò a scrivere programmi che manipolando la memoria producessero musica utilizzando l'interferenza prodotta dal TRS-80 su una radio a transistor nelle vicinanze. Le nuove regole della FCC [la Commissione Federale per le Comunicazioni] del 1981 costrinsero Radio Shack a costruire un adeguato schermo per le interferenze radio, rovinando per sempre tutto quel divertimento. Oltre a risolvere questo problema, il Model 3 presentava anche una versione leggermente più veloce dello Z80 e (evviva!) fra le varie migliorie c'era anche il supporto per delle vere lettere minuscole sia in fase di input che di output. Non fece invece niente per migliorare le magre capacità di visualizzazione del Model 1. E, nel tipico balletto da un passo in avanti e due indietro che sembrava contraddistinguere sempre Radio Shack, il Model 3 era ottimisticamente definito come "compatibile all'80%" con il Model 1, nonostante ancora una volta l'assenza del bus S-100  la sua progettazione non gli consentisse di far girare il CP/M. A questo punto Radio Shack, autentico genio del marketing, aveva tre macchine separate, tutte etichettate come TRS-80, ognuna parzialmente o interamente incompatibile con le altre. Provate a immaginare cosa significava cercare di capire quale era il software compatibile con la vostra versione della macchina...

E -incredibile a dirsi!- nel 1980 fu rilasciato ancora un altro TRS-80 completamente incompatibile con gli altri, questo però si rivelò il più significativo di tutti. Anche se ufficialmente si chiamava TRS-80 Color Computer, era radicalmente diverso da tutto ciò che si era visto fino ad allora: costruito intorno a quella che probabilmente era la CPU a 8 bit più avanzata mai prodotta, il nuovo Motorola 6809E. Come tanti altri sistemi della Radio Shack, esso coniugava un potenziale interessante a delle debolezze sconfortanti. Gli aspetti positivi erano il potente 6809E e un Microsoft BASIC avanzato che gli fece conquistare i favori dei programmatori per hobby; fra gli aspetti negativi c'erano le sue capacità sonore e grafiche che, seppur un passo sopra agli altri modelli di TRS-80, non lo rendevano ancora competitivo con i modelli nuovi e in arrivo di compagnie come Atari e Commodore. Nonostante questo, il CoCo  -come venne presto chiamato amichevolmente [abbreviando il nome di "Color Computer"; ndAncient]- fece bene nel lungo periodo, durante il quale restò costantemente lontano dalla portata dei radar del mercato mainstream (incapace di attirare poco o niente in termini di giochi e di applicazioni da parte della maggior parte dei  publisher e perfino da parte della stessa Radio Shack), ma riuscì a sopravvivere eleggendosi a prodotto di culto dell'industria e sostenendosi grazie a una base utenti che si rivelò leale fino al fanatismo. La linea del CoCo uscì di produzione solo nel 1991.

Ci sarebbero moltissime altre storie interessanti da raccontare in merito agli stravaganti piccoli computer di Radio Shack, ma la verità è che nessuno di loro riuscì mai nemmeno lontanamente ad avvicinarsi al dominio dell'industria che fu del TRS-80 Model 1 in quei primissimi anni. In verità però va detto che lo stesso Model 1 era divenuto così popolare perché era ampiamente disponibile (in un tempo in cui i canali di distribuzione degli altri marchi erano quasi inesistenti) e perché il suo prezzo era assolutamente ragionevole, e non tanto in virtù delle sue eccellenti qualità tecniche. Il TRS-80 in realtà non era poi così diverso dagli altri prodotti di Radio Shack: nella sostanza faceva ciò che doveva fare, solo che lo faceva nel modo meno cool e meno sexy immaginabile. Tuttavia seppe stimolare l'industria degli home computer e portò i giochi di avventura nelle case della gente per la prima volta; ma nel 1980 era già superato.

Quindi ora non ci resta che cestinare tutto il TraSh del TRS-80 e passare oltre. La prossima volta esamineremo la macchina creata dalla società che è poi riuscita a definire tutto ciò che nella tecnologia è cool e sexy. Sì, sto parlando proprio di quei due ragazzini impavidi nel loro garage in California.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.

Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto

Articoli precedenti:

Sulle tracce di The Oregon Trail
In difesa del BASIC
A Caccia del Wumpus
L'Avventura di Crowther
TOPS-10 in a Box
L'Avventura completata
Tutto il TRaSh del TRS-80
Eliza
Adventureland
Dog Star Adventure
Qualche domanda per Lance Micklus
Un 1979 indaffarato
The Count

Due diverse culture di avventurieri
Microsoft Adventure
La Narrativa Ludica già nota come Storygame
L'Ascesa dei Giochi Esperienziali
Dungeons And Dragons
Una Definizione per i Giochi di Ruolo per Computer
Dal Tavolo al Computer
- I Primi Giochi di Ruolo per Computer
- Temple of Apshai
- Un 1980 Indaffarato
- L'Interactive Fiction di Robert Lafore



Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

Emulare il TRS-80
The Digital Antiquarian (traduzione ufficiale italiana)

Tempo permettendo, mi accingo a esplorare alcune delle opere prodotte per il TRS-80, la piattaforma più popolare della primissima epoca degli home-computer. Ho così pensato di offrirvi dei consigli per emulare al meglio un TRS-80.

Nel momento in cui scrivo l'emulatore più popolare e pubblicizzato sembra essere il TRS-32 di Matthew Reed. Sicuramente è il più snello e rifinito che ho trovato. Tuttavia, oltre a essere compatibile solo con Windows, ha anche dei problemi sotto Windows 7 64-bit: si blocca per oltre un minuto prima di mostrare i "file dialogs". E, non essendo open source, non posso nemmeno provare a risolvere il problema.

Ho quindi deciso di utilizzare un emulatore molto meno noto, lo SDLTRS, che non solo funziona correttamente sul mio Windows, ma è disponibile anche per Mac e Linux.
A dire il vero anche il MESS Project include un TRS-80 emulato che funziona piuttosto bene, ma configurarlo richiede maggiori sforzi.
Segnalo anche l'esistenza di molti altri emulatori, apparsi negli anni passati, ma credo che la maggior parte di loro sia ormai obsoleta per un verso o per un altro. Gli emulatori di David Keil, per esempio, accedono direttamente all'hardware del sistema su cui sono eseguiti e sono quindi soggetti a una serie di limitazioni quando funzionano su versioni più recenti di Windows, che non consentono questo genere di cose.

Quale che sia l'emulatore che sceglierete di usare, vi serviranno anche le ROM del TRS-80. Queste sono ancora coperte dal copyright di Radio Shack e quindi non vengono distribuite con la maggior parte degli emulatori. Correrò però il rischio di hostarle qui, confidando che Radio Shack si sia dimenticata di loro o non gli interessino più (ovviamente, se scoprissi che non è così, dovrò rimuoverle immediatamente). Incluse nel file zip ci sono dunque le ROM del BASIC originale scritto da Steve Leininger ("level1.rom") e di quello più utilizzabile della Microsoft che Radio Shack distribuì nel 1978 ("level2.rom").

Se avete dei problemi a far funzionare l'emulatore, contattatemi e proverò ad aiutarvi.

Aggiornamento, 17 Giugno 2011:
Devo ammettere che non riesco a far funzionare poi tanto bene lo SDLTRS e, apparentemente, anche voi lettori non ne siete particolarmente entusiasti. Il suo sistema di gestione delle cassette, insieme ad un bel po' di altre cosette, sembra infatti essere buggato in modo irreparabile.
Ho così deciso di fare proprio quello che speravo di evitare: da questo momento, l'Emulatore di TRS-80 Ufficiale Del Digital Antiquarian è quello incluso nel MESS Project. Questo emulatore può rivelarsi un vero bastardo da configurare e da far funzionare, e ha sicuramente la sua buona dose di problematiche, ma è anche l'emulatore di TRS-80 più completo e utilizzabile che ho trovato. E MESS sia, quindi.
Portate dunque pazienza mentre cercherò di rendervi operativi nella maniera più indolore possibile.

Scaricate l'ultima versione del MESS dalla home page ufficiale. Mettete il tutto in una cartella qualunque (credo che gli utenti Linux dovranno compilarlo per avere un eseguibile).

Poi scaricate questo piccolo "add-on", specifico per il TRS-80, che ho appositamente creato. Scompattatelo nella stessa cartella in cui avete messo il resto del MESS, assicurandovi che il vostro programma di decompressione scompatti tutta la struttura delle cartelle. Oltre ad un file "mess.ini", verranno create due cartelle: "roms" e "sta".
La cartella "roms" contiene le ROM Level 1 e Level 2 del TRS-80, che il MESS archivia in un formato diverso dalla maggior parte degli altri emulatori. Con questa cartella non dovrete fare altro (sempre che in futuro non decidiate di emulare con il MESS altre piattaforme).
La cartella "sta" invece è quella dove verrano archiviati i vostri salvataggi statici; ma di questo vi dirò meglio fra poco.

Per far partire il vostro TRS-80 dovete aprire il prompt di comando nella directory di root della vostra installazione del MESS e scrivere "messpp trs80" per il BASIC del TRS-80 Level 1, oppure "messpp trs80l2" per il BASIC del Level 2 (notate bene che tutte le risorse che fornirò su questo blog faranno riferimento a quest'ultimo). Preciso che io utilizzo MESS per Windows; su altri sistemi operativi il suo eseguibile potrebbe avere un nome leggermete diverso.

Quando esaminerò un'opera per questo blog, vi fornirò sempre anche un modo per provarla sull'emulatore. Distribuirò prevalentemente "state file", poiché sembra l'approccio più semplice da utilizzare per questa piattaforma. Tuttavia il MESS ha qualche bug (beh, diciamolo pure: numerosi bug). Infatti selezionando dal menù "Save State As..." mentre l'emulatore è in funzione, questo spesso va in crash. Stessa cosa se si prova a caricare uno "state file" dal menù. 
Si può quindi salvare lo stato dell'emulazione solo con un semplice "Save State" dal menù, il che però dà al file il nome di default e lo salva solo nella cartella "sta/trs80” o in quella “sta/trs80l2”. In modo analogo è possibile caricare uno stato solo dalla linea di comando. 

Diciamo che volete lanciare il programma Eliza, l'opera di cui mi accingo a parlarvi. Per farlo dovreste mettere il relativo "state file" ("eliza.sta"), che prossimamente fornirò sul blog, nella cartella "sta/trs80l2". Poi non vi resterà che lanciare l'emulatore con il comando "messpp trs80l2 -state eliza" (ovviamente senza virgolette e senza includere l'estensione ".sta")

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon!

Articoli precedenti:
- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80

Il sito ufficiale di The Digital Antiquarian

Discutiamone insieme sul forum di OldGamesItalia!

Tutto il TRaSh del TRS-80 - Parte 3
The Digital Antiquarian (traduzione ufficiale italiana)

Nel 1977 e nel 1978 i computer iniziavano a entrare nelle case. Le mogli, i genitori, i figli, i fratelli, i compagni di stanza, tutti -confusi (o forse no)- ripetevano la stessa domanda: "... ma, concretamente, che cosa puoi farci?"
I nuovi orgogliosi proprietari si resero presto conto che non era affatto facile rispondere a quella domanda, perché quelle macchine erano oltremodo limitate; il TRS-80 non aveva colori, aveva solo minime capacità grafiche, niente sonoro, e non aveva neppure le lettere minuscole, perdinci (Radio Shack infatti si era rifiutata -come ormai potete ben immaginare da soli- di "sperperare" i circa 2 dollari necessari per implementarle)! Non ci si poteva nemmeno connettere una stampante prima dell'avvento della costosa "interfaccia d'espansione", che Radio Shack distribuì a partire dalla metà del 1978. Perfino quella che qualche anno dopo sarebbe diventata la scusa principale per acquistare un computer ("Possiamo usarlo per scrivere e poi i bambini potranno farci i compiti a casa...") in realtà non era applicabile alle macchine del '77.

Il TRS-80 veniva equipaggiato con due programmi distribuiti su una cassetta: le versioni digitali del backgammon e del blackjack. Radio Shack aveva però anche quattro "applicazioni di produttività" già disponibili al lancio. Tanto per iniziare c'erano dei software didattici che avrebbero dovuto aiutare i bambini con la matematica e poi c'era un sistema di gestione della contabilità familiare ("Quicken", in 4 K!). C'era anche un programma per le buste paga, presumibilmente lo stesso che French e Leininger avevano mostrato a Charles Tandy, il capo della società, per convincerlo del potenziale del TRS-80; lo stesso programma che andò in crash quando Tandy vi inserì uno stipendio annuale (il suo) troppo grande perché il programma potesse gestirlo...

E poi c'erano le utility "da cucina", per convertire le unità di misura e per archiviare dei messaggi da lasciare agli altri membri della famiglia. Questo ultimo software è un buon esempio di come la stessa Radio Shack avesse le idee molto confuse su come il loro computer sarebbe stato veramente utilizzato.
Si direbbe però che fossero piuttosto eccitati all'idea vedere i propri TRS-80 alloggiati nelle cucina delle famiglie, arrivando a includere molte foto del genere nei loro materiali promozionali; viene però spontaneo chiedersi quale vantaggio potesse offrire a quel tempo un complicato computer a cassette, rispetto a una normale calcolatrice, o a un buon vecchio quaderno con lapis. Soluzioni di questo tipo, assai più complicate e dispendiose in termini di tempo dei metodi tradizionali che volevano rimpiazzare, erano tipiche di questo primo periodo del mercato del software.
Per quanto Radio Shack e i suoi utenti si sforzassero di dipingere il TRS-80 come uno strumento "per fare cose serie", possiamo affermare con certezza che praticamente tutti coloro che lo acquistarono volevano per prima cosa... giocarci. Non dobbiamo quindi stupirci se esso venne commercializzato con due giochi nella sua dotazione di base. 

Tuttavia Radio Shack dette prova di una notevole lungimiranza, comprendendo da subito che le loro macchine necessitavano di software a supporto. Incoraggiarono attivamente i primi acquirenti a creare programmi per la loro macchina, diffondendo la notizia che avrebbero messo in vendita nei loro negozi i migliori programmi realizzati; si rivelò una buona idea, che senza dubbio contribuì a far sì che il TRS-80 avesse nel 1979 una libreria di software ben più ampia di quella dei suoi concorrenti, Apple e Commodore.
Tuttavia, nell'attesa che questa libreria di software venisse sviluppata, gli utenti dovettero trovare altri modi per far fare qualcosa al loro TRS-80. Una possibilità, ovviamente, era scriversi da soli i propri programmi. Per incentivare questo tipo di iniziative il TRS-80 fu venduto con un guida al BASIC scritta da David Lien, chiara e dettagliata, e che ancora oggi è considerata un specie di classico del genere.
Nonostante questo erano in molti a desiderare dei programmi già pronti, che potessero essere inseriti e lanciati, se non altro per imparare a programmare e per usarli come base da cui partire nelle proprie esplorazioni del BASIC.



Per fortuna queste persone ben presto trovarono un'ampia libreria di codice da cui attingere. Nel 1977 infatti il BASIC era già in uso sui grandi computer istituzionali da più di dieci anni, con una vasta libreria di programmi in attesa di esseri inseriti in tutti quei nuovi TRS-80. Nei suoi primissimi mesi di vita c'erano stringenti limitazioni imposte dalla poca memoria disponibile e dal primitivo BASIC che implementava, ma con l'arrivo delle macchine a 16 K e del BASIC Level 2 fu possibile senza grandi sforzi convertire per il TRS-80 la maggior parte del software BASIC esistente e trasportare i programmi fra i tre home-computer dell'epoca (che diversamente sarebbero stati del tutto incompatibili). Fu così che il BASIC divenne una "lingua franca", un ponte fra tutte quelle macchine diverse (o, se preferite, divenne una sorta di Java di fine anni '70).
Tutto quel codice BASIC che gli utenti di macchine come l'HP-2100 avevano creato e si erano scambiati per anni, ora arrivò nelle camere da letto e nei soggiorni. Di colpo i vecchi software pubblicati su riveste come Creative Computing assunsero una nuova rilevanza. Nel 1976 e nel 1977 Creative Computing pubblicò con un tempismo perfetto due "best of" pieni di programmi da inserire e di problemi di programmazione da risolvere; entrambi i libri vendettero benissimo fra il nuovo pubblico di utenti di microcomputer. Nel 1978 Creative Computing pubblicò "BASIC Computer Games", una revisione di un libro che il suo fondatore David Ahl aveva pubblicato per la prima volta nel 1973. Esso conteneva 101 giochi presi dai primi cinque anni di vita della rivista (e alcuni anche ad essa antecedenti), nati in posti come la People’s Computer Company, e si rivelò presto un clamoroso successo, una pietra miliare per un'intera generazione di giocatori e programmatori in erba.

Fra i programmi di cui ho precedentemente parlato in questo blog, Hunt the Wumpus arrivò sul TRS-80 assai rapidamente, insieme ai suoi predecessori.
The Oregon Trail invece inizialmente non lo fece, forse perché il MECC aveva intuito che fra le mani aveva una proprietà di un certo valore e quindi aveva iniziato a invocare il proprio diritto d'autore. Tuttavia nel numero di Ottobre del 1979 della rivista SoftSide fu pubblicato un titolo chiamato "Westward 1847", attribuito a un certo John C. Sherman. Un rapido sguardo al codice rivela che questo Westward 1847 non è altro che il nostro vecchio amico The Oregon Trail, leggermente modificato per farlo girare sul TRS-80.
Invece, per quanto rigurda Adventure... beh, quello ero un programma assai più complesso e per di più non era scritto in BASIC, il che lo rendeva assai più difficile da affrontare. Ma su questo punto tornerò più in dettaglio molto presto.



Fra i programmi che iniziarono ad apparire su questi nuovi microcomputer c'era anche una curiosa simulazione di una seduta di psicoterapia. Nel prossimo articolo mi occuperò di questo importantissimo programma e del suo retaggio.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon!

Articoli precedenti:
- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80

Il sito ufficiale di The Digital Antiquarian


Discutiamone insieme sul forum di OldGamesItalia!

Tutto il TRaSh del TRS-80 - Parte 2
The Digital Antiquarian (traduzione ufficiale italiana)

Nella metà degli anni '70 un tizio chiamato Don French lavorava alla sede centrale di Radio Shack a Fort Worth (Texas). A differenza di quasi tutti gli altri suoi colleghi, Don era un vero appassionato di elettronica e comprendeva davvero quella strana merce che si vendeva nel retro dei negozi della catena. Era anche affascinato dall'idea dei computer, così tanto che a metà del 1974 fu uno dei pochi che riuscì ad assemblare una versione funzionante del Mark-8 di Jonathan Titus, dopo averlo visto in un numero della rivista Radio-Electronics. Appena sei mesi dopo (con l'arrivo dell'infinitamente più accessibile MITS Altair 8800) gli appassionati di tutta la nazione iniziarono ad assemblarsi le proprie macchine, formando piccole community autonome come il celebre Homebrew Computer Club, frequentato anche da Jobs e Wozniak, oltre che da tante altre personalità (che erano già dei luminari del settore, o che lo sarebbero diventati di lì a poco).
Le persone coinvolte in questi nuovi "microcomputer", come erano chiamati all'epoca, erano per lo più saldatori esperti che si erano fatti le ossa sulle apparecchiature da radioamatori o sulle macchine radio-comandate - cioè, in altre parole, proprio quelle persone appassionate di "fai-da-te" che avevano passato gli anni nel retro di tutti quei negozi di Radio Shack a rovistare nelle scatole e nelle mensole in cerca di cavi e di diodi. Ora che tutti erano passati ai computer, queste persone continuavano a usare Radio Shack come la loro fonte principale per i componenti non specifici di cui avevano bisogno.



Don French intuì che tutta questa gente aveva fame di computer, perché lui stesso aveva sperimentata in prima persona quella fame. Pensò quindi che Radio Shack avrebbe potuto fare degli ottimi risultati se avesse assecondato questo bisogno, offrendo attrezzatura per computer direttamente nelle sue migliaia di negozi, anziché lasciare che questi appassionati si rivolgessero alle minuscole società (spesso di dubbia affidabilità) che si erano tuffate in questo nuovo mercato. Il suo problema era solo convincere i dirigenti, e non fu per niente facile; del resto quasi nessuno ha mai accusato la dirigenza di Radio Shack di lungimiranza...

Tuttavia alla fine perfino loro dovettero constatare che qualcosa stava cambiando, quando a Marzo 1975 la World Altair Computer Convention aveva attirato oltre 700 persone da sette diversi stati fino ad Albuquerque (New Mexico), la patria del MITS [la Micro Instrumentation and Telemetry Systems, i creatori dell'Altair 8800, e non -ovviamente- il più celebre Massachusetts Institute of Technology; ndTraduttore]. Fu allora che il management di Radio Shack iniziò a prendere un po' più seriamente le idee di Don French e, all'incirca a Maggio del 1976, lo autorizzò ufficialmente a iniziare la progettazione di un computer per loro.
Ovviamente non vollero strafare: per lavorare al progetto French potè assumere ben... un ingegnere. Per fortuna fece la scelta giusta con Steve Leininger, membro del Homebrew Computer Club, importato direttamente dalla Silicon Valley. Insieme si misero faticosamente al lavoro sul TRS-80 in una stanza in disuso nella fabbrica di altoparlanti di Radio Shack, con French che assumeva il ruolo di Jobs alle pubbliche relazioni (e, più in generale, all'articolazione della visione generale del progetto), e con Leininger nel ruolo di Wozniak come tecnico progettista.



Dopo pochi mesi accadde qualcosa che cambiò drasticamente rotta al progetto (questo aneddoto, insieme a molti altri, è ripreso da Priming the Pump, la storia della scena del TRS-80 raccontata in modo divertente, seppur un po' sconclusionato, da David e Theresa Walsh.)

Un giorno l'intero progetto fu sul punto di essere cancellato, quando gli ingegneri ricevettero un pesante pacco postale. All'interno c'era un costoso orologio digitale, che un cliente aveva messo insieme e poi rispedito al mittente. Il cliente affermava di aver seguito tutte le istruzioni ma che, nonostante questo, l'orologio non funzionava; anzi, aveva perfino bruciato un fusibile di casa quando lo aveva attaccato alla corrente. "Lo aprimmo," racconta Leininger, "e vedemmo che sul fondo di quel coso c'era oltre un centimetro di saldatura. Le istruzioni dicevano: 'mettete tutte le parti sulla scheda, rigiratela, e saldate tutto nella parte bassa'."

È per questo, amici miei, che è meglio per tutti se il nostro zio Jerry se ne resta confinato nella parte frontale del negozio.
Immaginandosi migliaia di computer "fai-da-te" che tornano indietro in uno stato simile, la dirigenza di Radio Shack quasi cancellò il progetto. Invece, miracolosamente, French riuscì a convincerli a fare diversamente: a fare della macchina che fosse un computer già completo, "chiavi in mano", invece che un semplice kit da assemblare. E fu un bene che lo abbia fatto, perché nel Gennaio del 1977 un produttore di calcolatrici in difficoltà economiche (chiamato Commodore Business Machines) annunciò il PET, un evento che segnò l'inzio della fine dell'era dei computer (letteralmmente) "home-brewed" [cioé "fatti in casa" ndTraduttore] che era stata dominata dall'Altair.
Con pochi fondi a disposizione e con i sistemi "chiavi in mano" di Commodore e Apple in dirittura d'arrivo, French e Leininger fecero del loro meglio con le risorse e il tempo che il management di Radio Shack concesse loro. Il risultato, annunciato ufficialmente il 3 Agosto del 1977 e in consegna dal mese successivo circa, era composto da un cuore progettato in modo solido con intorno un cumulo di scelte discutibili: il classico prodotto che poteva venire fuori solo da Radio Shack.



A differenze del PET e dell'Apple II (che per la CPU usavano il MOS 6502), il TRS-80 usava lo Zilog Z80. E infatti la prima parte del nome "TRS-80" stava per Tandy Radio Shack e la seconda per Z80. Aveva un clock da 1.78 MHz, il 78% più veloce della CPU montata da Commodore e Apple, e si dimostrò decisamente espandibile e modificabile. Il che fu una fortuna, perché la versione che Radio Shack mise in vendita quell'autunno era a dir poco limitata.

Dentro il pesante case di plastica c'erano solo 4 K di RAM, perché Radio Shack non voleva spenderci di più. Si rifiutarono anche di acquistare la licenza d'uso del BASIC da quello che all'epoca era il fornitore principale di BASIC per i microcomputer, una piccola società chiamata Micro-Soft. Il che comunque faceva ben poca differenza, perché tanto non avrebbero mai investito nei 12 K di ROM necessari per ospitarlo. Fu quindi Leininger in persona ad assemblare un limitato subset del linguaggio basandosi sullo standard Tiny BASIC, che potesse stare nei 4 K di ROM che Radio Shack gli aveva concesso. La versione finale di questo ambiente di sviluppo era dotata di tre (tre!) messaggi di errore: "HOW?" per gli errori logici tipo la divisione per zero; "SORRY" quando esauriva la memoria (cosa che doveva capitare abbastanza spesso); e "WHAT?" quando proprio non ci capiva (un'altra cosa che doveva essere abbastanza frequente).

Ad un certo punto della fase di progettazione, Radio Shack decise di vendere il TRS-80 come un computer davvero completo, con tanto di monitor e di una soluzione di “storage” permanente. Presero quindi il televisore in bianco e nero più piccolo ed economico del loro catalogo (tanto il TRS-80 non supportava i colori) e anche il registratore di audio-cassette più economico, e il pacchetto "chiavi in mano" era fatto e finito. Il computer vero e proprio era di un colore che Radio Shack battezzò (non senza una buona dose d'ottimismo) "argento Mercedes", perché quello era il colore della "TV-cum-monitor" abbinata. Non si presero nemmeno la briga di rimuovere la manopola del volume dal registratore, cosa che generò ogni sorta di assurdità.
Ecco qua alcuni consigli dell'epoca su come calibrarlo, affinché funzionasse (sig!), presi da uno dei primi numeri della rivista SoftSide:

Prendete una radio AM e mettetela accanto alla testiera (sul lato opposto del registratore, in modo che non vi intralci). Sintonizzatela in un punto fra due stazioni e abbassate il volume in modo che non risulti fastidioso. Questo vi aiuterà a tenere traccia di ciò che avviene nel computer quando state caricando una cassetta. Se c'è rumore o ce n'è poco, allora o state sentendo una cassetta vuota o il volume è troppo basso e il computer non riesce a raccogliere le informazioni che la cassetta contiene. Se ottenete un brusio con delle interruzioni, allora il volume è troppo alto o troppo basso. Modificate il volume (sul registratore, non sulla radio) affinché il tono sia costante. Poi riavvolgete il nastro e ripartite da capo. Se il tono è costante, allora il volume è grossomodo (sì, purtroppo, solo "grossomodo") corretto.

Trucchi del genere erano possibili solo in virtù del livelli di interferenza davvero epici emessi dal TRS-80. Era opportuno collocare eventuali altri televisori nell'altro lato della casa e le leggende (speriamo false) affermavano che una manciata di TRS-80 ben disposti potevano far fuori interi quartieri! Non a caso la vendita della versione originale del TRS-80 fu cessata nel 1981, perché violava gli standard per le interferenze dettati dalla Federal Communications Commission (ma come abbia fatto a ottenere l'approvazione iniziale resta ancora oggi un mistero). I lealisti del TRS-80 ipotizzano ancora oggi, in modo alquanto inquietante, che ci sia stata una soffiata alla FCC da parte della Texas Instruments, che stava appunto per entrare nel mercato con una sua macchina e che quindi voleva sfoltire la concorrenza.



A conti fatti il TRS-80 mi ricorda un po' le vecchie auto sportive della MG e della FIAT con cui io e i miei amici ci divertivamo qualche anno fa. Come ci ripetevamo fiduciosi ogni volta che provavamo a far partire il motore, i tergicristalli, i fari, o la radio (e sistematicamente l'impianto elettrico della Lucas ci faceva trovare un cumulo di fumante plastica fusa là dove sarebbe dovuto esserci il pannello dei fusibili...), i suoi difetti gli donano personalità fino a renderlo adorabile.
Ma non è stata certo la sua adorabile personalità il motivo per cui il TRS-80 è diventato la macchina più popolare del trio del 1977, restando in pratica il leader di mercato fin quasi al 1980 o 1981. No, ciò è avvenuto perché con i suoi 600 dollari era abbastanza economico (a differenza dell'Apple II, che costava 1.300 dollari per un sistema con 4 K e privo monitor), e perché fu immediatamente disponibile in migliaia di negozi in tutta la nazione, quanto meno dopo l'iniziale ondata di interesse che convinse Radio Shack a produrlo in grandi quantità (a differenza del Commodore PET, tormentato da problemi di consegna per tutto il 1977 e il 1978).

Avendo finalmente compreso di avere per le mani la gallina dalle uova d'oro, Radio Shack iniziò ad allungare un po' quel braccino corto che da sempre li caratterizzava, trasformando gradualmente il TRS-80 in un piccolo sistema utilizzabile per davvero. I 4 K di RAM furono rapidamente aumentati a dei ben più ragionevoli 16 K, e il primitivo BASIC scritto da Leininger fu rimpiazzato da una versione assai migliore su licenza di Microsoft. Chi aveva già acquistato, ebbe il privilegio di poter pagare per aggiornare il proprio sistema (del resto la munificenza di Radio Shack non poteva essere illimitata...). Per il suo primo compleanno, il TRS-80 erano già dotato anche di lettori di dischi, oltre alla possibilità di espandere ulteriormente la RAM fino a 48 K. Tuttavia queste due possibilità, che non erano state prese in considerazione in fase di progettazione, richiedevano l'acquisto di un ingombrante box d'espansione in cui alloggiarle e di certo non erano a buon mercato; ma, se non altro, esistevano e lentamente furono adottate da coloro che continuarono ad usare questa piattaforma.

Ma stiamo andando troppo avanti.
Per ora facciamo finta che sia la fine del 1977, o l'inizio del 1978, e che voi abbiate appena portato a casa un fiammante "Trash-80". Cosa potreste farci? Di questo parlerò la prossima volta, e nel farlo mi occuperò di un programma molto più vecchio di ogni altro programma di cui ho parlato fin qui, che però riveste un ruolo di grande importanza nella storia della narrativa interattiva.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon!

Articoli precedenti:
- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80

Il sito ufficiale di The Digital Antiquarian


Discutiamone insieme sul forum di OldGamesItalia!