Valutazione attuale:  / 0

Il microcomputer continua a crescere (1978 - 1981)

Ormai la mia macchina cominciava ad assomigliare sempre di più ad un vero piccolo computer, ma conoscendo bene tutto quanto era stato realizzato in software sulle macchine IBM con le quali lavoravo, mi rendevo conto che avrei potuto continuare per anni a migliorare quell'oggetto.

Sapevo di poter migliorare la macchina sia nell'hardware che nel software e mentre mi sentivo forte per quest'ultimo, ero sicuramente meno capace negli interventi hardware.

Ma un giorno fortunato incontrai un mio vecchio amico (Antonio), dipendende di un'altra importante azienda napoletana nel cui centro elettronico svolgeva il mio stesso lavoro; appassionato come me della materia, mi raccontò che da qualche tempo aveva cominciato a ...trafficare con un piccolo microcomputer (il suo usava l'8080 Intel) con il quale si divertiva a fare esperimenti vari; lui era però particolamente interessato all'hardware ed aveva, al contrario di me, ottime conoscenze in quel campo.

Ci volle pochissimo a capire che dovevamo metterci a lavorare insieme, perchè con le sue capacità in hardware e le mie in software avremmo potuto sicuramente realizzare cose interessanti; d'altra parte le mie modeste conoscenze di elettronica erano più che sufficiente per capire quello che lui proponeva di fare o di proporre a mia volta; insomma quel provvidenziale incontro segnò l'inizio di una collaborazione che durò per oltre quattro anni; aggiungo che dopo qualche mese dall'inizio del nostro lavoro, si unì a noi un altro amico, giovane ingegnere elettronico (Carlo) che costituì un nuovo valido aiuto.

Da questo momento tutto quanto descriverò come realizzazione di hardware dovrà essere considerato come una realizzazione di noi tre; lavoravamo insieme quasi tutte le sere per tre o quattro ore utilizzando le mie apparecchiature elettroniche (strumentazione ed attrezzi) che per la mia passione in elettronica erano abbastanza complete, mi mancava solo un buon oscilloscopio a doppia traccia, ma non appena Antonio mi dimostrò che era proprio necessario, lo acquistai.

Il primo problema che ci ponemmo fu quello di aumentare la memoria Ram della mia macchina che come ho detto prima era di soli 4 Kbytes installati sulla motherboard (4 chip da 1kb); come ogni buon costruttore di computer decidemmo di costruire una scheda di espansione di memoria sulla quale avremmo inizialmente posto altri 16 Kbytes di Ram (ormai potevamo usare i chip da 16kbits); sulla scheda avremmo aggiunta anche 4 nuove Eprom da 1Kb, una PIO ulteriore e un UART che avrebbe dotato la macchina di altre due porte parallele e di una porta seriale.

Il ChildZ, aveva disponibili tre slots, su di essi potevano essere inserite orizzontalmente tre schede di uguali dimensioni; il primo e il secondo erano utilizzati per la scheda madre e per la scheda video che avevo successivamente aggiunta; il terzo e ultimo slot avrebbe ospitato quindi la nostra scheda di espansione di memoria; decidemmo insieme di realizzare la scheda con una filatura in wire-up in modo da poterla facilmente modificare; oltre tutto in questo modo potevamo utilizzare una scheda che il costruttore del ChildZ aveva in vendita per chi avesse intenzione di preparare schede "custom" da aggiungere alla macchina; la scheda dovendo essere universale, aveva un circuito stampato che oltre ai contatti opportuni per essere inseriti negli slots liberi, aveva un'infinità di piazzuole forate nelle quali si potevano inserire sia i piedini degli appositi zoccoletti per accogliere i circuiti integrati necessari, sia gli "spadini" ai quali potevano far capo componenti passivi quali resistenze e condensatori.

Una foto della "ModerBoard" del CHILDZ.

La scheda madre del ChildZ era sistemata orizzontalmente nella parte superiore del contenitore.

Si vede in basso a sinistra la ventola per il raffreddamento e in basso a destra il trasformatore di alimentazione.

Questa invece è la parte superiore della scheda di espansione.

Si notino i chip tutti montati su zoccoletti e in basso a sinistra la parte per l'alimentazione; sulla destra si intravedono i contatti per il collegamento al "BUS".

Come si vede i collegamenti per la nuova scheda di espansione da me realizzata erano stati fatti con la tecnica del "wire up" utilizzando i sottili appositi fili avvolti con un apposito attrezzo sui cosiddetto "spadini".  

Più da vicino si può vedere l'infinità di collegamenti e l'intreccio dei sottili fili. cosiddetto

La realizzazione si concluse nel giro di qualche settimana; la difficoltà maggiore fu quella di sincronizzare il refresh delle memorie dinamiche, ma il favoloso oscilloscopio a doppia traccia ci fornì il supporto necessario per venire a capo di quei problemi.

Antonio era bravissimo e per facilitarsi il compito aveva costruito uno "scatolotto" sul quale aveva montato uno zoccolo per una CPU Z80 ed una serie di LED che mostravano contemporaneamente tutti i segnali presenti sui vari piedini; dallo zoccolo partiva un cavo che terminava con uno spinotto che veniva inserito al posto della CPU del ChildZ che veniva tolto e montato sullo zoccolo derivato presente sullo strumento; il segnale del clock proveniente dal quarzo del ChildZ veniva fatto passare anch'esso per lo "scatolotto" dove vi era un deviatore che poteva interromperlo e sostituirlo con un segnale generato da un pulsante sullo strumento stesso.

Utilizzando questo "accrocco" potevamo fermare il clock e sostituire ogni suo impulso con un impulso inviato con il pulsante; il computer funzionava ugualmente, soltanto che la sua frequenza di clock passava dai suoi classici 2Mhz a un Herz per ogni pressione di pulsante; poichè tutti i segnali presenti sui piedini della CPU erano visualizzati dai LED, eravamo in grado di esaminarli ad ogni ciclo di macchina; potevamo vedere quando un indirizzo veniva presentato sul BUS e tutti i cicli dell'esecuzione di ogni istruzione, dal fetch del suo primo byte, all'interpretazione del codice operativo, all'impostazione dell'indirizzo del dato sul BUS, fino al load o allo store del dato; oltre che ad indagare sui malfunzionamenti quello strumento mi dette l'emozione di toccare quasi con mano quello che mi avevano insegnato al primo corso sul 7070, mostrandomi anche che, sia pure in piccolo, il microprocessore si comportava esattamente come la CPU di un grosso mainframe.

Il computer era cresciuto molto, ma mi mancava ancora una periferica importante: desideravo completare il mio sistema con una stampante e a quell'epoca un simile strumento era abbastanza costoso e non facile da reperire; ma mi venne in aiuto il mondo informatico professionale che mi circondava. Infatti accanto ai mainframe IBM, il Banco di Napoli aveva cominciato ad acquistare ed usare anche i minicomputers della DIGITAL; scoprii che tra il materiale che quell'azienda stava mettendo da parte perchè superato dalle nuove macchine, c'erano delle consolle che venivano usate per la gestione dei PDP (una dei più famosi mini della DEC); si trattava di una typewriter (quindi tastiera alfanumerica e organo di stampa) con una testina di stampa ad aghi che in modo monodirezionale e alla velocità di 30 caratteri al secondo consentiva di stampare righe di 132 caratteri su moduli continui con fori laterali per il trascinamento. Qualcuna di queste macchine usate era disponibile a Roma presso la Digital ed al prezzo di ...solo 900.000 lire l'acquistai; l'andai a ritirare di persona a Roma con la mia 127 Fiat alla quale dovetti levare la poltroncina del passeggero per riuscire ad ospitare l'ingombrante apparecchio.

La stampante aveva tre modi di essere interfacciata al computer: poteva funzionare in RS232, in current loop o anche con segnali di livello TTL (5 volts). In ogni caso comunque il protocollo era seriale asincrono a velocità selezionabile da 300 a 9600 bps.

Naturalmente avuto l'hardware, per gestire la macchina occorreva il software (in quei tempi non si parlava neanche di driver software). Mi dedicai subito all'impresa e decisi di gestirla utilizzando un bit di una mia porta parallela che producendo livelli TTL poteva ben essere collegata all'ingresso TTL della nuova macchina. Naturalmente la parte di programma che l'interfacciava doveva occuparsi di realizzare i segnali asincroni necessari, e quindi per ogni carattere ASCII da inviare alla stampante, doveva generare un segnale di START, poi i segnali relativi ai 7 bits del carattere, un segnale che riproduceva il bit di parità ed infine il segnale di STOP; tutto questi segnali dovevano essere inviati tempificati opportunamente (io avevo scelto di far comunicare il computer e la stampante a 1200 bps) e come al solito i tempi di attesa erano calcolati e generati con opportuni loop di attesa software. La routine per la stampa fu installata in Eprom e bastava richiamarla dai programmi applicativi passandole un'intera riga di stampa, che essa provvedeva ad inviare i dati alla stampante come di dovere.

La storia di questa periferica non finì così, infatti dopo qualche tempo mi capitò di leggere su una rivista che un'azienda inglese aveva realizzato una nuova elettronica per quella macchina Digital (in pratica veniva sostituita l'intera motherboard) che sfruttando il fatto che la parte meccanica della macchina era tutta gestita da STEPPER MOTORS riusciva a pilotare la testina di stampa ad una velocità di ben 120 caratteri al secondo e in maniera bidirezionale e ottimizzata. Spendendo altre 600.000 lire mi procurai la scheda e dopo averla sostituita mi ritrovai possessore di una delle più veloci stampanti dell'epoca.

Ora che la mia macchina cominciava ad essere ..sufficientemente potente potevo pensare nuovamente al software e decisi di scrivermi un vero assemblatore; considerando che la scrittura di un programma così complesso sarebbe stata molto lunga e difficile utilizzando le istruzioni di macchina pensai che sarebbe stato molto più agevole scrivere prima un cross-assemblatore per Z80 utilizzando una macchina che avesse già disponibile un suo assembler; chiesi allora al mio capocentro di consentirmi l'uso di uno dei 360 IBM del nostro CED e scrissi il cross-assemblatore per Z80 in assembler 360; il cross-assemblatore era in grado di accettare codice mnemonico Z80 e produrre il corrispondente codice assoluto in linguaggio macchina Z80; l'output era previsto semplicemente in stampa in quanto nessun altro supporto del 360 poteva essere utilizzato in input dalla mia macchina.

Il cross-assemblatore servì ad assemblare l'unico programma che mi interessava realizzare con quello strumento, cioè l'assemblatore per Z80 che potetti quindi scrivere in mnemonico Z80; il risultato fu una grossa lista di istruzioni assolute espresse in esadecimale che dovetti avere la pazienza di caricare nella memoria del mio computer da tastiera; naturalmente al termine del caricamento portai l'intero programma su una cassetta magnetica e cominciai ad utilizzarlo leggendolo quando necessario da quel supporto; ovviamente il processo di assemblaggio e caricamento dovette essere ripetuto un certo numero di volte per correggere gli inevitabili errori.

Non appena però l'assemblatore cominciò a funzionare in maniera accettabile caricai su nastro l'intero source (utilizzando un text editor che già avevo preparato tempo prima e che avevo residente in Eprom) ed incominciai ad utilizzarlo per riassemblare se stesso; da quel momento mi affrancai dall'uso del 360 e anche dal noioso caricamento da tastiera; il mio assemblatore produceva infatti l'output direttamente su nastro ed in formato adatto ad essere caricato ed usato.

L'assemblatore funzionava in due passi: nel primo passo veniva letto dal registratore a cassette di lettura, il file con il source, venivano tradotti i codici operativi e venivano assegnati gli indirizzi alle istruzioni e alle aree di lavoro indicate dalle istruzioni dichiarative; durante la lettura del source veniva creata una tabella in memoria con l'elenco delle label incontrate con accanto l'indirizzo assegnato a ciascuna di esse e veniva prodotto un primo output su nastro che conteneva per ciascuna istruzione oltre che la sua codifica in linguaggio macchina anche l'indirizzo assegnatole; gli indirizzi dei dati rimanevano ancora in simbolico per essere trasformati in assoluto successivamente

Il nastro di output del primo passo veniva poi montato nuovamente sul registratore di lettura dal quale il programma lo leggeva; in questo passo il programma utilizzava le informazioni presenti nella tabella delle labels provvedendo a completare la traduzione delle istruzioni applicandovi gli indirizzi assoluti; l'ouptut finale era un file assoluto completo che poteva essere poi caricato in memoria per l'esecuzione utilizzando un programma di caricamento presente in Eprom; contemporaneamente alla produzione del file con l'assoluto veniva prodotta una stampa con la lista dell'intero source completa del relativo codice assoluto; la lista veniva completata con una cross-reference di tutte le label presenti accanto ad ognuna delle quali compariva l'elenco delle righe della lista in cui erano state citate.

Ormai lo sviluppo di nuovi programmi era diventato molto più veloce, ma la mia passione per le macro-istruzioni non poteva farmi considerare finito il progetto ASSEMBLER se non dopo avervi aggiunto un preprocessor che utilizzando dei prototipi fosse in grado di generare gruppi di istruzioni.

Prima di avviare il programma per l'assemblaggio, se il source di un programma conteneva delle macro-istruzioni, occorreva farlo trattare dal pre-processor; il pre-processor doveva prima leggere il file contenente i macro-generatori (cioè i prototipi delle macro-istruzioni) che si portava in memoria; leggeva poi il source e produceva un file di output che era ancora un source, ma dove ogni macro-istruzione era stata sostituita dal gruppo di istruzioni generate.

Per migliorare ancora la velocità di sviluppo non mi restò che scrivere una serie di macro-generatori che caricai sul nastro apposito e che aggiornavo frequentemente; per le routine più comuni e più spesso usate decisi di non generarle in linea ma di scriverle una volta per sempre e di memorizzarle in Eprom; la macro-istruzione che doveva svolgere una certa funzione doveva quindi soltanto preparare dei parametri (in genere nei registri di macchina) eseguire una Call all'indirizzo di Eprom che conteneva la funzione e portare i risultati ricevuti nelle aree indicate dal programmatore; in questo modo l'espansione della macro era più semplice e lo spazio impegnato dal programma diminuiva.

Dato il fatto che in un microcomputer a 8 bits potevano essere gestiti solo campi di un byte, un'esigenza che sentivo molto era quella di gestire campi di più bytes e di eseguire almeno le quattro operazioni su valori con un alto numero di cifre; fu questo un grosso lavoro che mi impegnò per mesi, ma che alla fine venni in possesso diun sistema completo per la gestione dei campi; memorizzai tutte le routines in Eprom e per ciascuna di esse scrissi una macro-istruzione che la richiamava; da allora nei miei source potevo cominciare ad usare macro-istruzioni di MOVE, COMPARE, ADD, SUBTRACT, MULTIPLY e DIVIDE che operavano su campi anche di grosse dimensioni o su valori ad alto numero di cifre; le routines per la gestione dei campi si avvalevano di un primo byte associato al campo che ne descriveva il contenuto, esistevano campi carattere e campi numerici per i quali avevo prevista anche una forma packed che impegnava un semibyte per ogni cifra nonchè una forma binaria pura; il MOVE tra i campi era possibile anche nei casi in cui poteva essere effettuata la necessaria trasformazione, per cui una cifra espressa in formato carattere poteva essere tranquillamente spostata in un campo numerico packed o binario e viceversa; infine scrissi anche delle routines per l'editing dei campi numerici (soppressione di zeri non significativi e punteggiatura); tutto questo sistema di gestione dei campi fu pubblicato nel numero 12 del novembre 1980 della rivista BIT (prima rivista italiana dedicata ai microcomputers).

Come ho detto spesso arricchivo le mie Eproms con altre routines e stanco di disturbare l'ingegnere amico che mi consentiva di usare il suo programmatore di Eprom decisi insieme ad Antonio di rendermi più indipendente; fu così che Antonio costruì un programmatore di Eprom da collegare ad una porta parallela del ChildZ; naturalmente io scrissi il necessario software e da allora mi bastava scrivere il source del software che mi interessava, assembrarlo con il mio assemblatore e poi leggere il codice oggetto da nastro con l'apposito programma che provvedeva a comandare il programmatore per creare la Eprom desiderata.

Torna all'indice