Basic 8 e VDC in dettaglio

Basic 8 e VDC in dettaglio
Articolo a cura di Tommaso Mauro Tautonico

In una serie di post ho già raccontato come è nata la mia passione per le estensioni ed i dialetti BASIC in grado di superare le limitazioni del Basic del Commodore 64, un BASIC davvero povero. 

Non so voi, ma una delle cose che mi faceva davvero innervosire della Commodore era il fatto che dava sempre l’impressione di una società senza un vero interesse a fare le cose fino in fondo, della serie fatto trenta potevano fare trentuno ed invece no, si fermavano o cambiavano obiettivo, l’importante era vendere con il margine di profitto migliore, ed il fatto di usare un linguaggio senza pagare royalties al produttore era di sicuro un buon guadagno. 

In questa “filosofia” rientrava proprio il Basic V2 del Commodore 64, un computer con una buona dotazione hardware, basti pensare al contorno di “coprocessori”, come il MOS 6569 (VIC -II) o il MOS 6581 (SID) che coadiuvavano la CPU 6510, ma che era quasi impossibile sfruttare con il Basic in dotazione a meno di smanettare con PEEK e POKE o passare al Linguaggio Macchina. 

Ecco perché nacquero quasi subito le estensioni al Basic, e qui si potrebbe aprire un capitolo enorme, anche perché, ad oggi, non sono riuscito a catalogarle tutte e non so di preciso quante ne sono state create. 

Comunque tra le più famose torno a ricordare il Simons’ Basic, la Super Expander 64 (che esiste anche per Vic20), l’ULTRABASIC-64, il Graphics BASIC, le Routines grafiche di Danilo Toma, addirittura un GW-BASIC, sono davvero tante ed a questo link (https://telarity.com/~dan/cbm/languages.html#BASIC-extenders) potete leggerne di alcune, oltre all’elenco di altri linguaggi diversi dal Basic. 

Basic 7 Commodore 128

Ritornando al discorso dell’incompiutezza propria di Commodore, la stessa cosa l’ho trovata nel Commodore 128, computer che, a mio parere, era la macchina definitiva del mondo ad 8 bit: tre computer in uno (C128, C64 ed uno Z80 a bordo che permetteva di avviare come sistema operativo il CP/M), diversi coprocessori come il C64, una MMU che permetteva di gestire più di 64Kb di memoria, un Basic completo (ver. 7.0) ed un processore grafico che permetteva la modalità 80 colonne. 

E qui partiva l’incazzatura: il MOS 8563 (VDC-Video Display Controller), il chip che sul C128 gestisce la modalità ad 80 colonne (640x200 pixel) in formato RGBI (RGB + Intensity), come già lessi sulla PROGRAMMER'S REFERENCE GUIDE COMMODORE 128, aveva (ed ha) come “compito primario quello di visualizzare caratteri sullo schermo. Il chip 8563 ha due set di caratteri, ognuno con 256 elementi. A differenza del chip VIC, tuttavia, l’8563 può mostrare tutti i 512 caratteri simultaneamente. Il VIC visualizza (invece) un solo set di caratteri la volta. Il Chip 8563 supporta una limitata modalità bit map. È possibile gestire il bit mapping per mezzo dei propri programmi, preferibilmente in linguaggio macchina. I comandi grafici del BASIC 7.0 non supportano lo schermo ad 80 colonne. La programmazione dello schermo in modalità grafica in BASIC non è raccomandata poiché il linguaggio non è orientato alla manipolazione del singolo bit sul display.” 

Della serie: per prima cosa visualizziamo caratteri però li facciamo belli, poi, forse, se ci riuscite e trovate il modo, c’è anche grafica bit mapped. 

Ancora una volta la Commodore, inspiegabilmente, si fermava al trenta. Tra le altre cose il VDC disponeva di una propria memoria (16kb espandibili a 64kb), 37 registri interni (38 nella versione 8568 DVDC) un clock indipendente a 16 Mhz (anche se questo dava problemi di sincronismo con il VIC chip ed il resto del sistema, che viaggiava a 14.318Mhz) e, pur non potendo gestire sprites, supportava il bit blit. 

In realtà il motivo per il quale il VDC non è supportato direttamente dal BASIC 7.0 lo ha spiegato direttamente Bil Herd (chi non lo conosce peste lo colga), il quale si era sempre lamentato della difficoltosa integrazione del VDC nel Commodore 128. 

La ragione della poca aderenza del VDC agli standard del computer che stava progettando (il c128) era dovuta al fatto che il chip MOS 8563 nasceva come parte di un progetto di computer in seguito abbandonato, il Commodore 900, basato su CPU Z8000 (qui trovate un approfondimento http://www.floodgap.com/retrobits/ckb/secret/900.html), architettura nella quale tutto l’I/O funzionava tramite porte I/O dedicate, mentre sul C128 abbiamo due soli (diconsi due!!!) registri mappati in memoria per accedere a tutti i registri del VDC, che troviamo locati a $D600-54784 (Address Register) ed a $D601-54785 (Data Register). 

Basic 8 Editor

Non mi addentrerò nella descrizione dettagliata del funzionamento del VDC (rimando ad un’altra serie di articoli), ma parlerò del fatto che, come era successo a David Simon per il C64 ed il suo Basic, ci furono due programmatori, L.R. Wallace e D.P. Darus, che svilupparono un’estensione al Basic 7.0 per permettere a chi programmava in Basic di accedere alla grafica a colori del modo 80 colonne del C-128, appunto il BASIC 8 della Walrusoft (estensione del loro programma Ultra Hires Graphics 1.0 pubblicato sulla rivista RUN Magazine, nel mese di febbraio 1986). Per una introduzione al linguaggio rinvio all’ottimo articolo presente sul sito Retrocommodore (https://www.retrocommodore.com/it/articoli/il-basic-8-della-walrusoft.html ) 

Come ben sapete sono un grande appassionato di estensioni Basic ma il BASIC 8 è stata per me una scoperta relativamente recente (all’epoca ero già passato al mondo x86) ed ho voluto approfondire il funzionamento di questa estensione. 

Il Basic 8 si incunea nella memoria del Commodore 128 in modo che i suoi comandi vengano eseguiti insieme a quelli del Basic 7.0, più precisamente viene utilizzata la tecnica che prende il nome di “Syntax Error Wedge”. 

In questa tecnica viene intercettata la subroutine “Syntax Error”, la routine che stampa messaggi di errore quando si commette un errore di sintassi e, per far si che questo avvenga, ai comandi del BASIC 8 è stato anteposto il carattere @, che non è usato in alcuno dei comandi BASIC 7 ordinari. Quando l’interprete Basic del C128 incontra questo carattere, trasferisce il controllo alla Syntax Error subroutine, la quale normalmente visualizza il messaggio di errore e ferma l’esecuzione del programma. 

Invece, nel BASIC 8 sono stati modificati i vettori che puntano a questa subroutine puntando ad una apposita routine che verifica se l’errore è un vero errore o è uno dei comandi aggiuntivi del BASIC 8. 

Nel caso di un reale errore di sintassi il programma restituisce il controllo al sistema operativo per la normale valutazione, altrimenti, trattandosi di un comando BASIC 8, la routine salta al nuovo interprete per l’esecuzione dello specifico modulo. 

Entrando nel dettaglio, nel Kernal, all’indirizzo di memoria $0300-$0301 (768-769), è localizzato il vettore IERROR (Indirect vector for BASIC ERROR handling routine) che viene utilizzato dalla routine di gestione degli errori del Basic 7 presente in ROM (ERROR [$4D3C]) che, all’inizio della propria esecuzione, esegue un JMP mediante questo vettore. 

Praticamente, nel BASIC 7.0 quando l’interprete incontra un carattere non riconosciuto come parte di un comando esegue il codice presente all’indirizzo $796C/31084

Nel momento in cui viene effettuato questo salto, il registro X contiene l’errore BASIC corrente (0-41, o 128 per READY), l’accumulatore memorizza l’ultimo carattere letto dal programma e prosegue all’indirizzo di default del salto è $4D3F/19775, il quale semplicemente rientra nel punto immediatamente successivo.

Infatti, andando a visualizzare mediante il Monitor del Vice (l’emulatore che ho usato per questa prova) il contenuto dell’indirizzo $0300 si ottiene:

> m 0300

>C:0300 3f 4d

Che è l’indirizzo di default al quale salta il Basic 7.0.

È possibile modificare questo vettore per cambiare il modo in cui il Basic aggancia gli errori, infatti, avviando il BASIC 8 nell’emulatore Vice, il vettore il cui indirizzo è $0300 riporta:

> m 0300

>C:0300 e4 03

Cioè il vettore contiene l’indirizzo $03e4 (996) localizzato in un range di indirizzi ($03E4-$03EF - 996-1007) non usati da alcuna routine delle ROM di sistema che possono essere liberamente utilizzate e che la Walrusoft ha ben utilizzato 😊 inserendo il codice che si incunea impartendo disposizioni alla MMU per la gestione della memoria ed avvia la fase di verifica del comando per poi passare il controllo alla specifica parte dell’interprete del BASIC 8.

Disassemblando la routine con il monitor del VICE

La routine utilizzata per acquisire l’input dei caratteri è la CHRGET, locata nella parte alta dell’area comune con inizio all’indirizzo $0380/896.

In realtà la subroutine CHRGET è progettata per recuperare il successivo carattere che non sia “spazio” della stringa BASIC, pertanto il primo step della CHRGET è incrementare l’indirizzo a cui punta.

In questa sede viene utilizzato invece il punto di ingresso alternativo chiamato CHRGOT, che è localizzato proprio all’indirizzo $0386/902, il quale recupera il carattere corrente senza incrementare il contatore e se tale carattere è il carattere @, che introduce tutti i comandi BASIC 8, salta all’esecuzione del modulo specifico all’interno dell’interprete Basic 8 altrimenti prosegue con la valutazione ordinaria.

Geniale.