a cura di Glauco

Note sull'autore

INDICE

Il primo computer non si scorda mai

Da qualche anno ormai esistevano sul mercato degli elaboratori definiti "Personal Computer".
Per quanto di dimensioni (e costi) più contenuti rispetto ai mini-computer per uso industriale e scientifico, erano comunque degli oggetti destinati ad impieghi di produttività individuale (professionisti, ricercatori, ecc...) piuttosto che a semplici appassionati.
L'Apple II, uno dei personal computer più famosi e ricercati, aveva un costo di circa 2.000 dollari (che, sopratutto allora, era una discreta cifra....).
Per chi, come me, aveva la passione e l'interesse, ma non disponeva di cospicue somme da destinare a quello che tutto sommato era un semplice hobby, cominciavano ad esserci delle proposte alternative, anche se meno professionali e blasonate: parallelamente a quello dei personal computer stava, infatti, nascendo il mercato degli home computer.

Visti i succitati problemi (costo & dimensioni) io optai per il più piccolo (ed economico) home computer disponibile sul mercato italiano: il Sinclair ZX80.
Grosso all'incirca quanto un mouse-pad, aveva una tastiera a membrana con tasti piccolissimi, e utilizzava un normale TV come monitor; dati e programmi si caricavano dal tipico registratore a cassette.
I dati tecnici?
Processore Zilog Z80A (a 8 bit) con frequenza di clock di 1 MHz, memoria RAM pari a 4 KByte, interprete BASIC residente in ROM da 1 KByte; il costo era di circa 200.000 lire.

Non esisteva un sistema operativo vero e proprio, ma accendendo il computer veniva automaticamente caricato in memoria ed eseguito (visto che risiedeva in ROM) un interprete BASIC: questo consentiva di digitare semplici programmi in linguaggio BASIC, il primo ed unico linguaggio di programmazione accessibile da parte dei "non professionisti informatici".
Questi programmi venivano eseguiti in modalità "interpretata", vale a dire che ogni linea di istruzioni veniva analizzata e convertita in codice eseguibile dal computer, prima di passare ad analizzare ed eseguire la linea successiva. Tale operazione di "traduzione istantanea", se da un lato evitava di ricorrere alle macchinose procedure comunemente utilizzate di editing, debug e compilazione, come avveniva con il linguaggio assembler, dall'altro rallentava notevolmente la velocità di esecuzione dei programmi stessi, già penalizzata dalle scarse prestazioni dell'hardware.
Per applicazioni più esigenti (come i "giochi d'azione") si doveva ricorrere a criptiche routine scritte in linguaggio macchina: in pratica incomprensibili sequenze di caratteri e cifre da gestire tramite le pseudo-istruzioni di "peek" e "poke" del BASIC.
I programmi, tanto faticosamente digitati sulla mini-tastiera del micro-computer, potevano (con un po' di fortuna....) venire registrati e successivamente riletti su un supporto molto diffuso ed economico: la normale casetta audio dei comunissimi registratori portatili.
Perchè occorreva fortuna?
Perchè queste "periferiche", sicuramente non progettate in origine per memorizzare dati bensì suoni, si rivelavano spesso inaffidabili: questo però si scopriva inevitabilmente quando ormai il programma tanto faticosamente digitato era ormai stato cancellato dalla memoria del computer. Quindi: se il programma appena scritto e registrato non veniva riletto (e spesso accadeva...) occorreva..... riscriverlo daccapo!
Oltre a ciò, la lentezza delle operazioni di caricamento (spesso duravano decine e decine di minuti), unite all'inaffidabilità potenzialmente insita nel mezzo / supporto impiegato, facevano sì che la maggior parte del tempo trascorso al computer fosse appunto impiegato nella digitazione dei programmi, e nella loro successiva registrazione e rilettura, piuttosto che nel loro utilizzo...

Commodore, altra prestigiosa marca di personal computer dell'epoca, non aveva ancora immesso sul mercato il suo modello di home computer, il VIC 20, che avrebbe fatto la sua comparsa solo l'anno successivo. Era invece già presente una serie di macchine "professionali", chiamate PET.
Io ebbi occasione di passare lunghe ore di programmazione su uno di questi computer: un PET 4032.
Era (decisamente) un altro pianeta: monitor (monocromatico a fosfori verdi, 40 colonne), unità centrale e tastiera (una vera tastiera standard, con tanto di tastierino numerico) erano inglobati in un unico contenitore. Il processore, un 6502 a 1 Mhz (lo stesso dell'Apple II) era dotato di ben 32 KByte di memoria RAM, il Basic risiedeva in una ROM da 4 KByte.

Qualcuno di voi si chiederà: ma che ci si poteva fare, con computer dalle prestazioni e dalla dotazione così irrisoria? Possibile che ce ne venisse fuori qualcosa di utile?
Ebbene si, eccome. Ricordo programmi di analisi matematica e calcolo scientifico su Apple II, e perfino un programma di contabilità e fatturazione su Commodore 64. Certo, erano programmi essenziali: non esistevano coloratissime e rutilanti interfacce grafiche, suoni ed animazioni, e nemmeno i menù a tendina oggi onnipresenti. Ma i programmi assolvevano alle funzioni a loro richieste. E la velocità era comunque accettabile, sopratutto se paragonata allo svolgimento manuale delle operazioni che venivano a loro richieste.
I programmatori erano dei veri "maghi": nel programmare una routine si cesellava il codice per risparmiare 2-3 Byte (la memoria era scarsa e costosissima), e così facendo si acceleravano anche i tempi di esecuzione dei programmi. In qualche caso, per "spremere" il massimo della velocità, si ricorreva alla programmazione in linguaggio macchina di quelle parti del codice che risultavano particolarmente critiche. Questa modalità di programmazione richiedeva una profondissima conoscenza non solo del linguaggio di programmazione, ma anche dell'hardware della macchina su cui il programma veniva fatto girare, in quanto si accedeva direttamente ai "registri" del processore e alle locazioni di memoria, senza aiuto alcuno da parte del sistema operativo.
Chi di voi può dire di avere una pari conoscenza del sistema su cui opera? Oggi neppure i programmatori professionisti vi si addentrano più: e se il programma diventa troppo grosso e pesante, semplicemente si aumentano le richieste di "Requisiti di Sistema" sulla confezione del programma stesso, obbligando l'utente a sostenere i costi per l'up-grade (se possibile) o per la sostituzione del computer con uno più potente.