In rete si trovano spesso file .crt che sono dump di cartucce e altri programmi in linguaggio macchina. Quando questi file non funzionano viene spesso il dubbio che siano stati dumpati male, ossia che l’indirizzo di destinazione del codice sia sbagliato. In questo articolo cercheremo di capirci qualcosa di più e impareremo qualche utile trucco per sistemare le cose usando il monitor integrato nell’emulatore VICE.
Un pò di concetti di base
Ogni file caricabile dal VIC-20 inizia con due byte che rappresentano l’indirizzo di caricamento del file, seguito dai dati che rappresentano il codice del programma stesso.
Per esempio, prendiamo questo programma BASIC semplicissimo digitato sul VIC inespanso, che verrà memorizzato di default a partire dall’indirizzo di memoria 4096 (in esadecimale 1000). Se serve da qui in poi vedi la mappa di memoria del VIC e usa il convertitore a esadecimale).
Verifichiamo a situazione in memoria. Digitiamo Alt-M (mnemonico: M come monitor) e diamo il comando monitor M (Memory):
M 1000 (invio)
otteniamo il dump in esadecimale della memoria dalla locazione hex 1000 (decimale 4096) in avanti.
Cosa notiamo?
- La prima locazione di memoria della RAM BASIC contiene sempre uno zero
- Seguono due numeri (0D e 10) che indicano dove finisce il programma, in esadecimale 100D, il puntatore si scrive sempre byte basso prima e byte alto dopo. La locazione di memoria hex 100D conterrà uno zero, seguito da altri due zeri che per il BASIC indicano “fine del programma”
- Segue il codice del programma BASIC. 0A 00 infatti è il numero di linea “10” rappresentato in esadecimale, byte basso prima, byte alto dopo. Il 99 è il codice numerico della istruzione PRINT, seguono i caratteri ascii di “CIAO” virgolette incluse.
Digitiamo X (invio) per eXit nel monitor per tornare al BASIC.
Agganciamo all’emulatore un floppy disk virtuale con Alt-8 e salviamo il programmino come “prova” sul dischetto stesso.
A questo punto, se avete visto il tutorial relativo al cavetto XUM-1541 conoscete il programma CBM Transfer con il suo visualizzatore per file binari. Ora non è fondamentale averlo, vi posto io ciò che risulta aprendo il dischetto virtuale e visualizzando il file PROVA appena ottenuto:
Come si vede bene il file binario inizia da hex 1001 (dec 4097) e i dati contenuti sono esattamente gli stessi visti nel monitor. Se volete vedere bene i due byte iniziali del file che contengono l’indirizzo hex 1001 basta togliere la spunta dalla prima checkbox in alto, e il visualizzatore vi mostra il contenuto del file così com’è:
Quindi riassumiamo un pò:
- I primi due byte di ogni file caricabile indicano a che locazione di memoria verrà caricato (salvo rilocazione, poi lo vedremo), byte basso prima, byte alto dopo.
Chiudiamo e riapriamo VICE per ripulirne la memoria completamente, ri-inseriamo il nostro dischetto virtuale con Alt-8 e poi torniamo al monitor per verificare quanto ho appena affermato (Alt-M per aprire la finestra del monitor).
comando nel monitor:
l “PROVA” 08
l è una “L” minuscola, notare il nome file in MAIUSCOLO (se no non funziona) e 08 che è il numero di device del dischetto che abbiamo associato all’emulatore.
Questo caricamento lo abbiamo fatto dal monitor soltanto perché stiamo imparando e vogliamo capire bene cosa succede. Notiamo infatti che il monitor indica chiaramente che sta caricando a partire dalla locazione esadecimale 1001 alla 100F includendo quindi anche i tre zeri finali post programma BASIC. Tutto quindi corrisponde.
Ora digitiamo X (invio) nel monitor per uscire verso il BASIC e digitiamo LIST (invio):
Voilà, il programma è di nuovo in memoria! Potevamo caricarlo anche usando il normale comando basic
LOAD “PROVA”,8
Semplicemente non avremmo saputo così facilmente a che punto della memoria il programma sarebbe stato caricato e fino a quale locazione.
Riassumiamo:
- Il monitor di VICE tramite il comando Load (L minuscola) carica un file dicendo anche da dove a dove lo ha caricato. Questo ci dà un vantaggio sostanziale rispetto al LOAD del BASIC.
Vedremo fra poco che, se anche il programma fosse stato caricato nella zona di memoria sbagliata, con il monitor integrato in VICE possiamo anche trasferirlo nel posto giusto e risalvarlo correttamente per evitarci fatiche la volta successiva.
Il problema della rilocazione
Il semplice LOAD del basic normalmente fa rilocazione. Ciò significa che il nostro programma PROVA, originariamente alla locazione di memoria 4097, se caricato su VIC con espansione 8K per esempio, che ha il BASIC a 4608 hex 1200) verrà rilocato, ossia riposizionato nell’area basic “giusta” per la configurazione con espansione. Se lo carico sul VIC 8K il programma inizierà quindi dalla locazione 4609 decimale: in questo modo il programma BASIC scritto per inespanso può funzionare anche su VIC 8K.
Questa cosa, apparentemente utile, per un programma in linguaggio macchina è un vero disastro perché i programmi in linguaggio macchina usano spesso indirizzi di memoria assoluti e, se rilocati, non funzionano più.
Per ovviare a questo problema si usa la sintassi di LOAD con il parametro ,1 finale. esempio:
LOAD”PROVA”,8,1
che significa “carica questo programma dal disco (8) all’indirizzo di memoria originale”. Se provate questo comando sul VIC 8k per il nostro programmino di prova noterete un effetto buffo: il programma viene caricato nella memoria video sporcando lo schermo. Nel VIC 8K infatti, la memoria video si trova esattamente dove, nel VIC inespanso, iniziava il BASIC.
Insomma, tutto ruota intorno ai primi due byte che si trovano nel file, che indicano dove il codice verrà caricato (salvo rilocazione, che come abbiamo capito per il linguaggio macchina non è mai desiderabile)
Il fatto che il BASIC non dia la possibilità di rilocare come vogliamo il codice in linguaggio macchina rende assai difficile gestire certi file di programmi (come appunto i file .crt che sono dump di cartucce): se chi le ha dumpate non ha fatto le cose come si deve e l’indirizzo di caricamento che si trova nel file non è quello corretto, sistemare le cose da BASIC non è affatto banale.
La soluzione usando monitor di VICE
In presenza di file in linguaggio macchina (es. file crt) dumpati male la soluzione proposta è a questo punto articolata in pochi punti:
- Caricare tramite monitor di VICE ogni file binario e controllare (il monitor lo dice) dove viene caricato.
- SOLO SE NECESSARIO, spostare con il comando T (Transfer) del monitor il blocco di memoria caricato dal punto sbagliato al punto dove avrebbe dovuto essere
- Salvare il blocco di memoria usando sempre il monitor, che a questo punto salverà nel file l’indirizzo iniziale giusto
- Creare un bel loader BASIC che carichi, tramite delle LOAD con “,1” finale (cioè SENZA rilocazione) i vari file nei punti di memoria preimpostati. Se si tratta di dump da cartuccia, il loader basic potrà alla fine di tutto resettare il VIC con il consueto SYS64802 facendo partire il software della cartuccia.
Caso di studio
Il caso di studio può essere dato dal programma Buck Rogers planet of Zoom, di cui si trova un dump su MyAbandonware a questo indirizzo. Vi sfido a farlo funzionare senza modifiche. Lo ZIP contiene in realtà una varietà di set di dump fatti male, di cui solo uno secondo me è in grado di funzionare. Ma andiamo per ordine.
La cartuccia in questione occupava in origine i blocchi di memoria 3 e 5, quindi un dump corretto dovrebbe includere due file da caricare in queste due zone di memoria (indirizzi in esadecimale):
- 6000 – 7FFF (blocco memoria 3)
- A000 – BFFF (blocco memoria 5)
Aprendo lo ZIP in questione trovate diversi kit di dump organizzati in altrettanti ZIP. Quello che ci interessa è denominato Buck Rogers – Planet of Zoom (1983)(Sega)(NTSC-PAL)[a][6000][A000][multipart].CRT.zip
Notate la [a] contenuta nel file per non confonderlo con gli altri che mi sembrano seriamente buggati. Questo è l’unico ZIP che siamo in grado di far funzionare con la tecnica che illustro qui. Decomprimiamo lo ZIP ottenendo una ulteriore cartellina con due file, che corrispondono ai due blocchi di memoria dumpati che dobbiamo ottenere.
- Buck Rogers – Planet of Zoom (1983)(Sega)(NTSC-PAL)[a][6000][multipart].crt
- Buck Rogers – Planet of Zoom (1983)(Sega)(NTSC-PAL)[a][a000][multipart].crt
Nel sistemare questo dump impareremo qualche nuovo trucco utile.
- Prima di tutto, rinominiamo i file con esplora risorse di windows in maniera che si chiamino rispettivamente:
- buck6.crt
- bucka.crt
- e poi sempre usando esplora risorse di Windos spostiamo i file nella cartella di WinVice dove l’emulatore li può caricare facilmente.
- Avviamo VICE e nelle Impostazioni VIC settiamo come attivi i blocchi di memoria 3 e 5. Nell’esempio qui sotto ho attivo anche il blocco 1 ma non fa alcuna differenza. Diamo OK e resettiamo con Alt-R
- Avendo capito che caricare da BASIC nei casi difficili non ci aiuta, entramo nel monitor con Alt-M
- Carichiamo il primo file, quello che dovrebbe essere caricato nel blocco 3 a partire da hex 6000. Siccome il file si trova sul file system windows, per farglielo trovare diamo nome minuscolo e numero device 00:
l “buck6.crt” 00
- Notate niente di strano? “Loading buck6.crt from A000 to C000″… Il monitor carica il file nel blocco 5, a partire da A000 ma non è assolutamente lì che dovrebbe stare! Abbiamo ora conferma che il blocco di codice che si doveva trovare a hex 6000 è stato caricato nel posto sbagliato, trasferiamo quindi il tutto nel posto giusto con il seguente comando Transfer e poi lo salveremo
t a000 bfff 6000 - Il comando transfer dopo la “t” prevede tre indirizzi: (locazione iniziale) (locazione finale) (locazione di destinazione). Stiamo trasferendo da hex a000 a bfff su 6000 mettendo così il codice a posto.
- Salviamo il primo blocco trasferito con il comando
s “buck6fix.crt” 00 6000 7fff - Carichiamo infine il secondo file, quello che dovrebbe stare a partire da hex A000. Qui l è una L minuscola:
l “bucka.crt” 00
- Notiamo che il secondo file si carica correttamente e cioè a partire dalla locazione hex A000
- digitando x (invio) torniamo al BASIC e resettiamo con Alt-R
- Il gioco parte correttamente, segno che il primo file è stato rilocato correttamente e il secondo andava bene così com’era.
- Ora, se vogliamo evitare tutta la trafila possiamo usare un programmino che carichi i due file in sequenza (usando sempre il ,1 finale mi raccomando!) e che faccia un bel reset con SYS64802 per far partire il gioco. Possiamo usare il programma contenuto in questo ZIP che va messo su dischetto, dove trasferiremo (io ho usato CBM Transfer) anche i due file buck6fix.crt e bucka.crt rinominati rispettivamente BUCKRO.600 e BUCKRO.A00 che sono i nomi che ritroviamo nel programma che li caricherà.
- Volendo un minimo spiegare anche il programma di caricamento, esso semplicemente scrive a schermo i comandi da usare per il caricamento dei due file e la SYS finale, poi mette nel buffer della tastiera le 3 pressioni del tasto INVIO. E’ un automatismo realizzato con un approccio forse un pò rozzo ma efficace.
Conclusioni
Se abbiamo dei file dumpati male o comunque quando abbiamo dubbi su dove venga caricato un file VIC-20, il monitor integrato di VICE si può usare per:
- verificare la zona di memoria in cui codice e dati vengono caricati
- spostare codice e dati in un’altra zona
- risalvare il file in modo che, caricandolo, dati e codice siano stavolta al posto giusto
Ricordiamo di usare sempre il ,1 finale nelle operazioni di LOAD di codice binario.
Se non capiamo perché un programma non funziona può essere utile aprirlo con il viewer HEX di CBM Transfer oppure ancora caricarlo con il monitor di VICE.
Spero questo tutorial sia stato utile, se volete potete postare un commento o condividerlo!
Loading...