ADPnetwork reloaded

Dopo l'esperimento ADPbasic reloaded... è stato il turno di "Sua Maestà".

Ci sono progetti che restano in un cassetto. E poi ci sono progetti che nel cassetto non ci stanno nemmeno più, perché nel frattempo il cassetto è stato svuotato, il computer su cui giravano è stato venduto (o regalato, o rottamato: la memoria, a una certa età, non fa sconti a nessuno) e i sorgenti sono finiti chissà dove. Uno di questi, per me, è ADPnetwork: una rete per Amiga, rigorosamente ad anello, senza token, con una scheda intelligente basata su Transputer che smistava i pacchetti al posto del 68000. Una cosa di cui, lo ammetto senza falsa modestia, vado ancora parecchio fiero.

Sua Maestà, perché rappresenta per me la cosa più bella e importante, abbia fatto a MC.

Vengo al punto. Della scheda di rete basata su Transputer mi era rimasto pochissimo: qualche circuito stampato nudo, qualche foto non proprio ad altissima risoluzione e una serie di articoli tecnici. Dello schema elettrico, invece, nemmeno l'ombra. E senza schema, si sa, una scheda non si rifà: al massimo si contempla, magari con un pizzico di nostalgia. La domanda che mi sono posto qualche giorno fa era quindi semplice e, nella mia testa, retorica: è possibile ricostruire lo schema elettrico reale partendo da questi brandelli? Risposta che mi aspettavo: no. Risposta che ho avuto dopo una manciata di ore di lavoro con Claude, l'intelligenza artificiale di Anthropic: sì. Con tanto di netlist verificata, schema in KiCad e, ciliegina sulla torta, il software della scheda ricompilato con il compilatore originale dell'epoca. Fantastico, vero? Ma andiamo con ordine.

Cosa avevo in mano

Facciamo l'inventario, che in un reverse engineering è sempre la prima cosa da fare. Sul tavolo: alcuni PCB della scheda, perfettamente integri ma senza un solo componente montato; le scansioni delle pagine di rivista in cui la scheda veniva descritta, con un paio di foto della versione «quasi definitiva»; i miei ricordi, che come vedremo si sono rivelati utili ma non sempre affidabili (sulla data di nascita della scheda, per dire, ho sbagliato di qualche anno).

Il piano iniziale, concordato con Claude, era quello classico: scansione del PCB su entrambe le facce, allineamento delle due immagini, ricostruzione delle piste una alla volta con verifica al tester, identificazione dei componenti dalle foto. Lento, ma a prova di errore. Claude aveva anche messo subito le mani avanti su un punto, con un'onestà che ho apprezzato: «su piste fitte posso sbagliare a seguire un tracciato, il metodo sicuro è che io proponga ogni connessione e tu la confermi col tester». Bene, si parte.

Prima però c'era da capire cosa fosse esattamente quella scheda. Qui i ricordi hanno fatto la loro parte: il processore era un Transputer Inmos T222, 16 bit e 4 KB di RAM interna, con quattro link seriali fisici. Due servivano per l'anello (uno verso la macchina precedente, uno verso la successiva), uno per parlare con l'Amiga attraverso il bus Zorro, il quarto... beh, su quello avevo le idee confuse. Ci torneremo, perché è stato uno dei piccoli gialli di questa storia.

Le pellicole che non sapevo di avere

Mentre preparavo le scansioni mi è venuto in mente di dare un'occhiata ai backup dei miei vecchi Macintosh, che conservo da decenni e che da Windows si leggono senza problemi. Tra file senza estensione e cartelle dai nomi improbabili sono saltati fuori alcuni file EPS. Il telefono, ovviamente, non sapeva cosa farsene, e allora li ho passati a Claude così com'erano: «vedi tu se c'è qualcosa di interessante».

C'era eccome. Tre di quei file, generati con Adobe Illustrator 88 e datati settembre 1990, erano niente meno che i master del circuito stampato: lato componenti, lato saldature e piano delle piazzole e dei fori, in vettoriale e in scala 2:1, come si usava allora per produrre le pellicole. Altro che scansioni: avevamo il disegno originale, pista per pista. In mezzo c'erano anche lo schema dei processi software che giravano sul Transputer e la topologia della scheda di sviluppo a quattro Transputer usata per i collaudi.

Claude ha installato al volo Ghostscript nel suo ambiente di lavoro, ha convertito tutto in immagini a 400 dpi, me le ha rimandate per farmele vedere e ha cominciato a leggerle. Prima osservazione, a colpo d'occhio: «il processore è proprio un T222, lo zoccolo PGA da 68 pin corrisponde; la scheda è una Zorro II con pettine a 86 contatti e sul pettine sono etichettate tutte le sedici linee dati». Il che, come vedremo, sembrava contraddire uno dei miei ricordi. Ma era solo l'inizio.

Dai disegni alla netlist

Qui viene la parte che, confesso, non mi aspettavo. Il piano era seguire le piste «a occhio», ma con i master vettoriali a disposizione Claude ha proposto un approccio decisamente più furbo: rasterizzare i due strati sullo stesso sistema di coordinate e lasciare che fosse un programma a stabilire cosa è collegato a cosa.

Detta così sembra banale, ma in pratica ci sono un po' di ostacoli. Primo: il disegno conteneva anche la griglia millimetrata di Illustrator, che a 400 dpi diventava una ragnatela di linee sottili collegate a tutto. Soluzione: un'operazione morfologica (una «apertura», per i più tecnici) che cancella i tratti più sottili di qualche pixel lasciando intatte piste e piazzole.

Secondo: lo strato lato saldature era sfalsato di una quarantina di pixel rispetto agli altri due. Soluzione: una correlazione tra le piazzole dei due strati per trovare lo spostamento esatto, verificata poi in otto zone diverse della scheda per escludere deformazioni (scarto massimo: due pixel).

Terzo: le dita del pettine esistono su entrambe le facce ma portano segnali diversi, quindi non vanno «cortocircuitate» tra loro come si fa con le piazzole passanti.

Risolto tutto questo, il resto è algoritmica pura: ogni zona di rame contigua su ciascuno strato diventa un pezzo di nodo, ogni foro passante unisce i pezzi dei due strati che tocca, e alla fine si ottiene l'elenco completo delle connessioni. In gergo, la netlist. Il tutto in pochi minuti, contro le settimane (e le diottrie) che avrebbe richiesto il metodo manuale.

Una netlist, però, è solo un elenco di piazzole collegate tra loro. Per farne uno schema elettrico bisogna sapere quale integrato sta dove, come è orientato e quale pin è quale. Ed è qui che il lavoro è diventato davvero divertente.

Chi è chi

Sul PCB c'erano quattordici integrati: lo zoccolo PGA del Transputer, due chip a 28 pin «larghi», due a 24 pin «stretti» e una manciata di 14 e 16 pin. Per dare un nome a ciascuno, Claude ha usato un metodo che definirei investigativo: si prende l'ipotesi, si guarda dove vanno a finire alimentazione, massa e segnali noti, e si vede se torna.

Il Transputer, per esempio. Un PGA è una griglia quadrata e simmetrica, quindi può essere orientato in otto modi diversi. Con la piedinatura del datasheet alla mano, Claude ha verificato che nell'orientamento scelto i due pin VDD finivano sul +5 V, i due di massa sulla massa, il ClockIn sullo stesso nodo del clock dei link adapter e il Reset sulla rete di reset. Quattro conferme indipendenti su quattro: orientamento certo.

Più istruttivo il caso dei chip a 28 pin. La prima ipotesi di Claude era che fossero due link adapter C011, che hanno proprio quel contenitore. Poi, guardando le piste, si è corretto da solo: dal Transputer arrivava a entrambi un bus di molte linee in parallelo, mentre un link adapter si coll a ottobre la dr.ega al Transputer con soli due fili. Erano le RAM, due 62256 da 32 KB per i 64 KB indirizzabili dal T222 (e io, per la cronaca, l'ho confermato subito). Montate ruotate di 180 gradi e con le linee di indirizzo rimescolate sui pin: un vecchio trucco per semplificare lo sbroglio, perché a una RAM l'ordine degli indirizzi non importa.

I due chip a 24 pin stretti, invece, si sono rivelati i link adapter, ma nella versione C012, quella pensata per il bus di un microprocessore. Il datasheet riporta esattamente «standard 24 pin 0.3” plastic package». E qui si risolve il giallo del quarto link: sul PCB ce ne sono due, uno sul byte basso del bus dati (link 0) e uno sul byte alto (link 3). L'hardware, quindi, era predisposto per trasferimenti a 16 bit. Il software pubblicato, però, usa solo il link 0: il quarto link è rimasto davvero inutilizzato, come ricordavo. Avevamo ragione tutti e due, io e il PCB.

La prova del nove è arrivata dal pettine. Sul disegno erano stampate 43 etichette (A12, D5, R/W, INT6 e così via). Claude le ha confrontate con la piedinatura standard dello slot Zorro dell'Amiga 2000, pin pari sul lato componenti e dispari sul lato saldature: tutte e 43 al posto giusto. Quando i conti tornano a quel livello di dettaglio, si può cominciare a fidarsi anche del resto.

I 74LS raccontano

Restavano i chip piccoli, quelli della logica TTL, di cui non ricordavo una sola sigla. Nessun problema: in un integrato 74LS la sigla è scritta nella sua piedinatura. Se i pin 1 e 2 di un chip ricevono due linee di indirizzo e il pin 3 va a un altro integrato, è una porta a due ingressi con l'uscita sul 3: una 7400, una 7408 o una 7432. Se un chip ha otto ingressi e una sola uscita sul pin 8, è una 74LS30, la NAND a otto ingressi. Funziona come un Sudoku: ogni pin collegato toglie ambiguità.

Sono saltati fuori un 74LS04 (sei inverter), due 74LS30, un 74LS32 e un 74LS74, e con loro la logica di decodifica. Sorpresa: la scheda non usava l'AutoConfig dello Zorro, ma rispondeva a un indirizzo fisso, $97C000. Il primo 74LS30 riconosce $97 sulle linee alte del bus (con tre di quelle linee negate dal 74LS04), il secondo aggiunge A15, A14 e il segnale di strobe del 68000, e una porta del 74LS32 combina le due uscite nel chip select dei link adapter. Due linee di indirizzo (A12 e A13) selezionano i quattro registri del C012: dato in ingresso a $97C000, stato ingresso a $97D000, dato in uscita a $97E000, stato uscita a $97F000. Una scelta furba: $97xxxx sta in fondo allo spazio di espansione dell'A2000, e avrebbe dato fastidio solo a chi avesse montato più di 7,5 MB di Fast RAM. Nel 1990, praticamente nessuno.

Ancora: un 74LS01, porte NAND open collector, porta all'Amiga gli interrupt dei link adapter (INT6 per «dato ricevuto», INT2 per «buffer di trasmissione vuoto») e, con un'altra porta, una resistenza e un condensatore, genera il reset all'accensione per Transputer e link adapter. Un quarzo con il suo oscillatore e un flip-flop del 74LS74 producono i 5 MHz puliti richiesti dal T222, che poi li moltiplica internamente. Due integrati differenziali pilotano i link dell'anello verso il connettore a 20 poli da cui partivano i due cavetti per le macchine adiacenti. Persino due ponticelli a filo, che generano il segnale di abilitazione in lettura delle RAM a partire da quello di scrittura, sono stati «visti» dalla netlist: piazzole isolate che altrimenti non avrebbero avuto senso.

Non tutto è stato risolto, sia chiaro. Per tre integrati (l'oscillatore e i due chip differenziali) la famiglia è probabile ma la sigla esatta no, e qualche dettaglio va verificato con il tester sul PCB fisico: un pin di configurazione dei link che dal disegno risulta a massa, il segnale di reset dell'Amiga che sembra non arrivare da nessuna parte (forse c'era un filo volante), la polarità delle coppie differenziali. Claude li ha elencati uno per uno, con la spiegazione di cosa cambierebbe in ciascun caso. Esattamente come farebbe un buon progettista.

Dalla carta al compilatore

Una scheda senza software è un fermacarte, e la nostra il software lo riceveva dall'Amiga a ogni accensione: niente EPROM, il Transputer partiva dal link. Quel codice, scritto in Occam, il linguaggio nato insieme ai Transputer, all'epoca fu pubblicato integralmente. Solo che le scansioni delle riviste hanno un livello di testo ricavato con l'OCR, e su un listato stampato ruotato di 90 gradi l'OCR aveva prodotto un minestrone illeggibile di simboli.

Claude ha fatto quello che avrebbe fatto un redattore paziente: ha rasterizzato le pagine a 300 dpi, le ha raddrizzate, le ha tagliate in strisce leggibili e ha trascritto il codice riga per riga. Con un'accortezza in più, perché in Occam l'indentazione fa parte della sintassi (come in Python, ma trent'anni prima): ha misurato in pixel il rientro di ogni riga sulla stampa, convertendolo in livelli da due spazi. La tabella del CRC a 32 bit, 256 valori esadecimali, non l'ha ricopiata a mano: l'ha rigenerata con l'algoritmo standard citato nel copyright del listato e l'ha confrontata con i valori leggibili sulla pagina. Identica.

Poi la domanda inevitabile: ma questo codice compila? Claude ha scaricato i sorgenti di KRoC, un progetto che mantiene vivo l'Occam, ci ha trovato dentro occ21, il compilatore originale SGS-Thomson/Inmos, l'ha ricompilato per Linux (con un paio di aggiustamenti, perché il codice C di trent'anni fa non piace ai compilatori moderni) e l'ha lanciato sul sorgente con target T2, la famiglia del T222. In pratica lo stesso strumento che si usava allora.

Primo errore: colpa di Claude, che nella tabella del CRC aveva messo un a capo dopo la parentesi quadra, cosa che l'Occam non accetta. Corretto quello, ne è rimasto uno solo: una costante usata nel codice ma mai definita nel file di include. Un errore già presente nell'originale pubblicato, che Claude aveva segnalato ancora prima di compilare, insieme a qualche altra incongruenza (una routine di risincronizzazione che controlla il checksum nel posto sbagliato, una tabella di validazione rimasta alle dimensioni della versione precedente del protocollo). Definita la costante in una copia di prova, il compilatore ha risposto con un laconico «Code generated ok». E ha anche calcolato la memoria richiesta dall'insieme dei processi: circa 54,4 KB su 64, quasi tutti buffer per i pacchetti nelle RAM esterne. Nell'articolo originale si leggeva che la memoria era «utilizzata per un buon 90-95% come buffer». I conti tornano anche qui.

Il software che non c'è più

Il Transputer, però, era solo metà della storia. L'altra metà girava sull'Amiga: i processi che impacchettavano i messaggi, li ritrasmettevano se qualcosa andava storto e li ricomponevano a destinazione, più lo strato che faceva apparire la rete come un normale disco, con tanto di icona sul Workbench. Di quel codice C, purtroppo, non esiste più una riga: stava sull'hard disk dell'Amiga 2000 su cui lavoravo, e quella macchina non ce l'ho più da un pezzo. Ecco il vero reverse engineering, quello in senso ampio: ricostruire un software di cui resta solo la descrizione.

La materia prima erano una dozzina di articoli tecnici, che ho passato a Claude in blocco. Lui li ha letti tutti e ne ha estratto, pezzo per pezzo, l'architettura completa. Il software di rete sull'Amiga si basava su una mia libreria di comunicazione tra processi, scritta sopra le porte di Exec, con spedizioni sincrone, asincrone e a «rendez-vous esteso», ricezioni bloccanti e non bloccanti e, nella versione di rete, un indirizzamento del tipo «macchina/porta». Sopra questa giravano cinque processi: il Packer spezzava i messaggi in frame, il Sender li consegnava alla scheda, il Replay ne teneva una copia, il Timer lo svegliava dopo un paio di secondi per ritrasmettere i frame di cui non era tornato l'ACK, il Recomposer rimetteva insieme i pezzi in arrivo anche fuori ordine, una lista per ogni mittente. È questo meccanismo, tra l'altro, che permetteva di staccare i cavi nel bel mezzo di un trasferimento e di vederlo ripartire dal punto esatto una volta ricollegati.

Il pezzo più raffinato era l'interfaccia con AmigaDOS, il device NET:. Il principio, ricostruito nei dettagli, è elegante: quando un programma chiede di aprire, leggere o elencare un file in NET:Platone/DH0/..., AmigaDOS manda un normale pacchetto DOS all'handler della rete. L'handler lo «traghetta» fino alla macchina remota, dove un processo server lo ripresenta tale e quale al file system locale, e la risposta fa il percorso inverso. Il problema, ovviamente, sono i puntatori: un indirizzo di memoria non significa nulla su un altro computer.

La soluzione era una struttura, ricostruita campo per campo, che porta con sé nomi delle macchine, codice dell'azione, risultati e un vettore di lunghezze in cui lo zero indica un valore semplice, un numero positivo una struttura puntata alla maniera BCPL e uno negativo una puntata alla maniera C, con le strutture accodate subito dopo. E per far digerire tutto al Workbench, i primi due livelli dell'albero (macchine e volumi) erano directory simulate, con lock «finti» e perfino i file .info delle icone generati al volo dall'handler.

La parte che mi ha divertito di più è stata vedere i pezzi incastrarsi tra fonti diverse. Il formato dei pacchetti descritto negli articoli sul protocollo coincideva al byte con le posizioni dei campi nel file di include del sorgente Occam. I tipi di frame elencati nell'include come semplici lettere, H, S, N, trovavano il loro significato negli articoli sull'handler: Handler, Server e «Next», un indirizzamento al nodo successivo che i server rimandavano avanti fino a farlo tornare al mittente, cioè un broadcast sull'anello usato per l'autoconfigurazione.

 E infatti il Dispatcher sul Transputer consegna all'Amiga i frame di tipo Next senza rimetterli in circolo: l'eco lo faceva il server, via software. Due documenti scritti a mesi di distanza, da persone diverse, che si confermano a vicenda: per chi fa reverse engineering è la soddisfazione più grande. Persino uno dei file EPS ritrovati ha trovato la sua collocazione: lo schema dei processi Occam che conteneva era quello della configurazione di collaudo, con un processo che simulava l'Amiga e un link richiuso su se stesso al posto dell'anello.

Il risultato è che oggi di quel software abbiamo un progetto completo, che in buona parte mancava anche nella mia memoria: processi, protocollo, formato dei messaggi, azioni private tra handler e server, codici di esito dell'autoconfigurazione. Non è il sorgente originale, e qualche dettaglio implementativo (come la gestione dei file aperti sulle macchine remote) non fu mai pubblicato. Ma è abbastanza per riscriverlo fedelmente.

111 su 111

Ultimo passo: trasformare tutto questo in uno schema elettrico vero, apribile con un CAD moderno. Claude ha installato KiCad nel suo ambiente, ha disegnato i simboli di tutti i componenti (Transputer, link adapter, RAM, i vari 74LS, il pettine Zorro con i suoi 86 contatti) e ha generato lo schema direttamente dalla netlist, assegnando a ogni pin il nome del suo nodo. Uno schema «da ingegnere», più che da rivista: niente fili che si intrecciano, solo etichette di rete. Meno bello da guardare, ma impossibile da sbagliare.

E infatti la verifica finale è stata spietata: KiCad ha riesportato la netlist dallo schema e Claude l'ha confrontata, nodo per nodo, con quella estratta dal PCB. Risultato: 111 nodi su 111 identici. Non prima, però, di aver trovato e corretto un ultimo errore suo: una via del circuito stampato, capitata esattamente sulla stessa fila dei pin di un link adapter, falsava la numerazione dei piedini. Me lo ha segnalato lui, senza che chiedessi nulla, prima di consegnarmi il lavoro.

Nel frattempo erano stati identificati anche i componenti passivi, partendo dalle piazzole che non appartenevano a nessun integrato: i condensatori di disaccoppiamento sparsi sulla scheda, quelli obbligatori sui pin CapMinus del Transputer e dei link adapter, la rete RC del reset e i due ponticelli a filo. Il tutto è finito in un PDF formato A2, in un file KiCad e in un documento di riferimento che raccoglie l'intero progetto: hardware, mappa dei registri, formato dei pacchetti, processi software e l'elenco dei punti ancora da verificare.

E adesso?

Tiriamo le somme, che è il momento più interessante. In poche ore di lavoro, partendo da un PCB nudo, qualche vecchio file e una pila di scansioni, abbiamo ottenuto: la netlist completa della scheda, l'identificazione di tutti i componenti (di quasi tutti con certezza), la mappa dei registri vista dall'Amiga, il sorgente del software del Transputer trascritto e ricompilato, il progetto completo del software Amiga e dell'interfaccia AmigaDOS ricostruito dagli articoli e uno schema elettrico verificato in KiCad. Un lavoro che, fatto a mano, avrebbe richiesto settimane, e che probabilmente non avrei mai trovato il tempo di fare.

Attenzione però a non trarre la conclusione sbagliata, cioè che l'AI «fa tutto da sola». Non è andata così. I file giusti li ho trovati io, rovistando nei backup. Alcune domande cruciali (era davvero un Transputer? quelle erano RAM? i cavetti dell'anello erano uno o due?) le ho chiarite io, con i miei ricordi. E Claude ha sbagliato, più di una volta: sul tipo dei chip a 28 pin, sulla sintassi della tabella del CRC, sulla numerazione di un integrato. Ogni volta, però, se ne è accorto da solo o grazie a una verifica che aveva previsto lui stesso, e me l'ha detto senza giri di parole. È questo, secondo me, il punto vero: non un oracolo infallibile, ma un collaboratore instancabile che verifica tutto due volte, dichiara cosa sa e cosa suppone, e non si offende se lo correggi. Ne ho conosciuti pochi così, e quasi tutti in carne e ossa.

Resta da fare la parte più «fisica». Prima un giro di tester sul PCB vero, per chiudere i pochi punti aperti. Poi la scelta di fondo: una replica fedele, cercando T222, C012 e RAM tra le rimanenze di magazzino (ce ne sono ancora, a prezzi variabili), oppure una rinascita in chiave moderna, con la stessa architettura ma un FPGA o un microcontrollore che emula i link Inmos. Lo confesso: la seconda strada mi tenta parecchio. Un Amiga di quasi quarant'anni che scambia file con un altro Amiga attraverso un anello token-free ricostruito con l'aiuto di un'intelligenza artificiale... se me l'avessero raccontato nel 1990 avrei pensato a un racconto di fantascienza. Anzi, probabilmente l'avrei pubblicato.

Vi terrò aggiornati. Nel frattempo, se avete un progetto sepolto in qualche cassetto (o in qualche backup), sapete cosa fare.

AdP

Video generato da NotebookLM, fornendogli solo il link a questo articolo.

Simulazione AI della demo allo SMAU 91 con la famosa palla Amiga che rimbalza tra le macchine in rete.