Come funzionava il TURBOTAPE di C/64 e Vic20?

I Computer Commodore erano venduti senza alcuna periferica. Contrariamente allo ZX Spectrum, non era possibile collegare un registratore analogico “normale” ai Commodore.

La periferica di I/O che costava meno era il registratore a cassette, che era un dispositivo “custom”, al cui in terno in pratica c’era un piccolo modem che modulava il segnale.

Le audio cassette negli anni ottanta erano economicissime (contrariamente ai floppy, che erano meno diffusi) e gli editori potevano duplicarle facilmente per creare “magazines” da vendere nelle edicole, sfruttando i sistemi di distribuzione che esistevano per la musica tradizionale.

Ora il caricamento da nastro era abbastanza lento, poiché l’algoritmo di Commodore era bastato sulla codifica digitale dei bit, e il codice era abbastanza convoluto. Si sospetta che fosse derivato da un vecchio codice legacy di Commodore, riciclato e piazzato nel Kernal di sana pianta.

Era molto affidabile, e aveva un meccanismo di correzione che consisteva nello scrivere il programma due volte, per poter correggere eventuali errori di lettura alla seconda passata.

Però anche il dispositivo a cassette era molto affidabile, quindi esisteva spazio per semplificare l’algoritmo, prendersi qualche rischio e renderlo addirittura più veloce del caricamento da disk drive (!).

Il Turbo Tape semplificava all’osso sia l’algoritmo di codifica che il sistema di checksum. Non è facile trovare gli autori, ma per certo una delle versioni fu fatta da Sephan Senz:l’articolo entra nei dettagli, ma qui vorrei darvi solo un assaggio delle sottigliezze del TurboTape, citando un paio delle funzionalità implementate.

TurboLoad Rulez

Se avessimo dovuto caricare prima un “TurboLoad” per caricare il programma, avremmo perso gran parte dei vantaggi del meccanismo. Era necesario che i programmi salvati potessero essere caricati usando le rotudine standard della Commodore. Per cui il caricamento era basato su un header “standard”, compatibile con il “LOAD” di Commodore che ovviamente doveva essere il più compatto possibile, sennò il vantaggio si perdeva.

Questo header usava un paio di idee innovative per funzionare: aveva come indirizzo di caricamento $032C, e sovrascriveva quindi il vettore della funzione CLALL (Close All File), chiamata alla fine del caricamento del turbo load: il vettore veniva fatto puntare a $32E. Da $32E veivano copiati tra i 10 e i 14 bytes…un po’ pochi per implementare il meccanismo di caricamento turbo.

Però dovete sapere che ogni programma ha un nome file, che può essere lungo ben 187 caratteri e che tali dati rimangono in un “buffer” dopo il caricamento che “casualmente” si trova poco dopo questo vettore, nell’intervallo $33C-$3FB. Per cui la procedurina che sovrascrive il vettore in $032C e che ha come indirizzo di partenza $32E può allegramente continuare da $33C fino a $3FB sfruttando il “nome del file” come code area…

Uno schemino vale più di mille parole:

Formato di memorizzazione

Come accennato il registratore a cassette della Commodore consentiva di scrivere direttamnte segnali digitali (impulsi di 0v e 5v).

L’algoritmo della Commodore usava segnali di diversa lunghezza per trovare un marker e poi un bit di valore 0 o 1. TurboTape usava un approccio più libertino, usando una singola lunghezza d’onda per codificare un bit: più lunga per 1 e più corta per 0. Per sicronizzarsi, il turboloader scriveva 256 byte uguali a “2” seguiti da un count down che andava da 9 a 1. Durante il caricamento il sistema iniziava a contare i 2, e quando trovava un 9 iniziava il conto alla rovescia.

Ora l’aspetto imbarazzante per il disk drive del Comodore64 era che un file di 12 Kb impiegava 44 secondi dal nastro (di cui 28 per il programma vero e proprio) mentre ne impiegava 34 dal disco! Di fatto il turbo tape era più veloce del disk drive.

Comandi TurboSave e TurboVerify

Come funzionava la rotudine che implementava il turno save e verify?

La rotudine implementa due nuovi comandi TURBOSAVE e TURBOVERIFY. Anche qui viene usato un approccio un po’ diverso dal solito: piuttosto che sovrascrivere i vettori standard del BASIC, viene sovrascritto il vettore che serve a scrivere “?SYNTAX ERROR”, e cioé l’error vector in $300-$301. Ora il “parser” del BasicV2 non era un grande sistema: in pratica una liena veniva “tokenizzata” prima di essere interpretata. Il tokenizzatore trasforma in un token ogni parola chiave del BASIC (ragione per cui le variabili non possono chiamarsi come una parola chiave).

Per cui quando il basic interpreta “TURBOSAVE” suppoone che TURBO sia una variabile, procede e si trova il token SAVE, anziché per es un assegnazione. Per cui salta al vettore di errore. Qui il TurboTAPE vede se la sintassi di SAVE o VERIFY è corretta: se no, va di Syntax error, altrimenti entra in azione. Per cui anche GIOORGISAVE funzionerebbe. L’idea geniale qui è che questo approccio consente di usare TurboTape con altre estensioni del BASIC, che non si sognano quasi mai di rilocare il vettore di errore (!) ma agiscono su altri punti di entrata più “standard”.