In modo molto complicato…. ora ci arriviamo
I Computer Commodore erano venduti senza alcuna periferica. Quella che costava meno, era il registratore a cassette, che era un dispositivo “custom”. Contrariamente allo ZX Spectrum, non era infatti possibile collegare un registratore analogico “normale” ai Commodore. 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 codice interno di Commodore, 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ò 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 tal 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 Turbo.
Era necesaroi che i programmi salvati potessero essere caricati all’accensione del PC. Per cui il caricamento era basato su un header “standard”, compatibile con il “LOAD” di Commodore.
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. Ora qui venivano copiati tra i 10 ed 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 (828-1019). 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…
Comandi TurboSave e TurboVerify
Come funzionava la rotudine che implementava il turno save e verify?
La rotudine implementa due nuvoi comandi TURBOSAVE e TURBOVERIFY.
Anche qui viene usato un approccio un po’ diverso dal solito: piuttosto che sovrascrivere i vettori standard, viene sovrascritto il vettore che serve a scrivere “?SYNATX 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.