Ok...ma come posso usare il token per creare nuovi comandi?Tipo un estensione del basic 2.0?
Progetto ambizioso?
Ok allora vediamo di chiarire alcune cose.
Il
token altro non è che la codifica in un singolo byte (il BASIC 7.0 del C128 aveva anche token di due byte, ma qui divaghiamo) di un'intera parola-chiave del BASIC: codificando PRINT con il token 153 in luogo della sequenza di 5 caratteri P, R, I, N, T si ottenevano come vantaggi:
1) una maggiore compattezza del programma in memoria, e quindi la possibilità di ospitare ed eseguire programmi più lunghi
2) una (relativa) maggiore velocità di esecuzione dell'interprete BASIC, dal momento che è più rapido ricavare l'indirizzo della routine di PRINT ricavandolo dall'associazione nella tabella degli indirizzi del suo token 153, che non ripetere ad ogni esecuzione il riconoscimento della sequenza P, R, I, N, T.
A pagina 62 di CCC n. 35 (presente sul sito) puoi trovare la lista di tutti i token dei BASIC 2.0, 3.5 e 7.0 (se possibile ti consiglio di leggere l'intero articolo di cui la tabella fa parte).
Come usare i token per espandere il BASIC, ti chiedi. Ebbene, la domanda è mal posta. I token preesistenti nell'interprete BASIC 2.0 non sono uno strumento per espandere il BASIC, caso mai nell'atto di espandere il BASIC puoi definire i tuoi token.
Mi spiego meglio. Nella ROM dell'interprete BASIC sono presenti due liste: una associa le stringhe (PRINT, POKE, LIST, SAVE, ecc.) ai token, l'altra associa i token agli indirizzi di memoria ai quali iniziano le relative routine che l'interprete chiama per eseguire i comandi e le funzioni. Un approccio che puoi utilizzare per espandere il BASIC è, quindi, quello di fare ricorso allo stesso espediente: crearti una tua coppia di tabelle che associno la stringa PIPPO al token x e il token x alla routine che inizia all'indirizzo 50987 (routine scritta in linguaggio macchina, da te o da altri), la stringa PLUTO al token y e il token y alla routine che inizia all'indirizzo 51234, ecc.
In questo senso utilizzi i token per espandere il BASIC: è a tuo carico scrivere il nuovo interprete BASIC in linguaggio macchina, magari prevedendo in qualche modo una retrocompatibilità; ad esempio i "tuoi" token possono essere gestiti dal "tuo" interprete, il quale incontrando un token del BASIC 2.0 li dà in pasto all'interprete su ROM.
È un progetto ambizioso espandere il BASIC 2.0? Be', soprattutto se intendi farlo "da zero", indubbiamente sì. Ma c'è un'altra domanda da porsi: è realmente utile? IMHO se il tuo intento è quello di imparare a conoscere il funzionamento del C64 e a programmarlo in assembly, applicandoti in un progetto, la cosa ci può stare, altrimenti scrivere oggi un'estensione del BASIC 2.0 è quantomeno anacronistico: tutti coloro che sono interessati alla programmazione del C64 (per giochi, demo, ecc.) hanno imparato o imparano l'assembly... difficilmente qualcuno userà una nuova estensione del BASIC per fare alcunché, il massimo che possa capitare è che qualche nostalgico programmi qualcosa con un'estensione esistente all'epoca d'oro del C64 (il Simons' BASIC sarebbe l'esempio principe), per pura nostalgia appunto. Non si può avere nostalgia di qualcosa che ai vecchi tempi non c'era...
Poi ripeto, se il tuo intento è imparare l'assembly fai pure, non sarò io a biasimarti se farai una scelta di questo genere, magari dettata dal fatto che non ti senti di programmare un gioco (con il quale otterresti probabilmente maggiore interesse da parte di altri utenti) per mancanza di creatività o che so io.