Codifica e decodifica dei dati sulle cassette: una questione di impulsi

Premetto che questo non è un articolo ideale per i principianti; per comprenderne i punti chiave è infatti necessario avere una conoscenza approfondita dell'hardware della macchina e una buona padronanza dell'assembler del 65xx, perché, tra le altre cose, vedremo del codice per registrare e caricare i nostri programmi su nastro.

A differenza del drive, il registratore non è una periferica "intelligente", nel senso che non può trasferire dati binari al computer; non disponendo né di memoria, né di un bus seriale, esso può solo trasferire e ricevere impulsi verso (dal) C64. Sorge allora spontanea una domanda: come può il datassette caricare e salvare dati binari? La risposta a questa domanda si trova a monte.

Qualsiasi programma binario presente nella memoria del C64 viene salvato su nastro sotto forma di impulsi. Per scrivere un impulso sul nastro è sufficiente commutare due volte il bit 3 del registro $01, che (guarda caso) è collegato alla porta del registratore.

Come forse qualcuno di voi già saprà, quando il datassette invia un impulso al C64 esso trasmette un segnale elettrico attraverso questa porta, provocando la commutazione del bit 3 del suddetto registro (da 0 a 1, e viceversa). Ogni volta che il bit 3 del registro $01 commuta sul fronte di discesa (cioè passa da 1 a 0) il registro 56333 ($DC0D esadecimale) genera una interruzione. Questo tipo di interruzione non avrebbe nessun significato se non venisse catturata dal loader, un programma preregistrato scritto in assembler che ha il compito di determinare se il bit corrispondente vale 0 oppure 1. Questo valore dipende dal tempo intercorso tra gli ultimi due impulsi consecutivi.

Per completezza, occorre notare che è anche possibile leggere il registro $DC0D periodicamente, senza far ricorso alla gestione delle interruzioni; tuttavia, in questo articolo non tratteremo i loader basati su questa modalità alternativa.

Esistono almeno due tecniche per determinare la durata di una pausa tra due impulsi (e quindi il valore del bit corrispondente) nei loader basati su interruzioni:

• Caricare uno dei timer di cui sono provvisti i chip CIA, dando la possibilità di generare un'interruzione sia a questo che al registro 56333; la prima delle due sorgenti a generare l'interruzione determina il valore del bit attuale;
• Caricare uno dei timer dei chip CIA e, ad ogni interruzione, andare a vedere quanti cicli macchina sono trascorsi dall'ultimo impulso (in questo modo si determina direttamente il tempo intercorso tra gli ultimi due impulsi; se questo valore è inferiore ad un intervallo prestabilito, chiamato soglia, il bit vale 0, altrimenti 1 (questo è l'approccio più usato e che preferisco).

All'inizio il loader viene caricato in memoria come un normale programma assembler; dopodiché, il C64 gli passa l'esecuzione.

Per avere la certezza che i dati vengano ricevuti correttamente, i byte di programma sono preceduti da una serie di byte ripetuti (il cui valore è arbitrario, e viene stabilito quando si registra il programma stesso) e da uno o più byte di sincronizzazione (anch'essi del tutto arbitrari, dipendono solo dal loader con cui andranno interpretati gli impulsi), che segnalano al loader l'imminente presenza dei byte di programma (quelli che il loader dovrà caricare in memoria).

In sintesi, quindi, ecco la struttura di un nastro del C64

Abbiamo spiegato (seppur sommariamente) come vengono (de)codificate le informazioni su un nastro, ma non vado più in là con inutili sproloqui, preferendo mostrare un esempio pratico di quanto esposto fino ad ora. Questo sorgente commentato contiene una routine per la registrazione di un programma su nastro.

Do per scontata la sintassi assembler, soffermandomi solo sulla routine leng, che determina l'intervallo di tempo tra due impulsi successivi.
Questa routine crea un ciclo di ritardo dipendente dal bit che si vuole registrare; nel caso di un bit 0 il ciclo di ritardo è molto più breve, e la nuova commutazione 1-0 del bit 3 di $01 avviene circa 300 microsecondi dopo la precedente (ricordo che un ciclo macchina, nel C64, dura circa 1.015 microsecondi).
Invece, per registrare i bit 1 viene creato un ciclo di ritardo doppio, per un totale di circa 600 cicli macchina tra una commutazione 1-0 e la successiva.
Nota inoltre che ho scelto come byte ripetuto (255 volte) $80, e come byte di sincronizzazione $FF (un solo byte di sincronizzazione, ma nulla vietava di metterne un'intera sequenza).

Adesso ci vuole un loader che decodifichi correttamente ciò che è stato codificato dalla routine precedente; quello che segue è il suo codice sorgente.

Questo è un semplice esempio di loader. Per stabilire se l'impulso ricevuto è associato a un bit 0 o 1, esamino il contenuto del timer B del chip CIA1 e vedo se sono trascorsi più di 450 cicli macchina dall'ultimo impulso. Non appena il byte ricevuto coincide col byte ripetuto ($80), passo alla seconda fase, che consiste nell'attesa del byte di sincronizzazione (nel nostro caso, $FF). Quando è stato ricevuto anche questo byte, comincia la fase di caricamento dei dati: prima i quattro byte di indirizzo, che definiscono il segmento di memoria in cui caricare i byte del programma (indirizzo iniziale-finale in formato basso/alto); poi i byte di programma veri e propri.

Occorre notare tre cose:

1. Con l'ultima istruzione (JMP $A7AE) il loader si aspetta che il programma inizi con un'istruzione Basic del tipo SYS [primaistruzione];
2. Gli ultimi 4 byte costituiscono i vettori di sistema $300-$302; la modifica al vettore che punta al main loop del BASIC ($302) è necessaria per permettere al C64 di mandare in esecuzione il loader; in caso contrario il C64 torna all'interprete BASIC dopo aver terminato di caricarlo.
3. Al termine del caricamento è necessario ripristinare le badlines, i puntatori alle aree di memoria del BASIC e il puntatore alla prima istruzione, in modo che l'interprete processi il tutto correttamente.

Inoltre, questo loader è (volutamente) limitato; non prevede il caricamento di un byte per la verifica del corretto caricamento dei byte di programma (la cosiddetta checksum), né consente di tornare indietro se viene incontrato un byte che sfasi la canonica sequenza $80-...-$FF; inoltre, è piuttosto lento, per cui la soglia e le pause tra gli impulsi andrebbero ridimensionate. Comunque, a beneficio dei lettori, viene fornito il codice completo del recorder e del loader appena illustrati, oltre alle routines accessorie necessarie per poterli utilizzare su un emulatore o un C64 reale.

Viene lasciato ai lettori più volenterosi il compito di migliorarlo (magari mostrando qualche animazione in interrupt durante il caricamento del programma principale) e di provarlo su un vero C64 corredato di datassette.