Penso che invece di parlare per niente e andare per presupposti, era ora che mi "sporcassi le mani" per vedere un po' quali problemi ci sono nell'usare il codice DASM rilasciato.
Ti premetto che io uso il 64tass, quindi ho dovuto convertire il sorgente in -qualcosa- di compilabile per il mio compilatore.
Ho notato una cosa, che può essere solo un mio problema con il 64tass, perchè NON so come si comporta il DASM.
La seguente porzione di codice del SAVER:
FILEDATA
.WORD $C000, $C118 ; A Freeloader control software
.WORD $0801, $19CF ; B Game
viene compilata dal 64tass come:
$C0, $00, $C1, $18, $08, $01, $19, $CF
ma il codice del SAVER si aspetta l'ordine basso/alto dei bytes, cioè:
$00, $C0, $18, $C1, $01, $08, $CF, $19
quindi verifica l'esattezza di questa cosa, prima di tutto.
Poi, nei miei precedenti esperimenti, avevo usato la versione MULTILOAD che non implementa alcuna automazione per la visualizzazione delle Pictures, per la musica o per lo scrolltext, ma si limita a caricare un file da nastro dato "un numero" che l'identifica.
Anche qui la questione non è chiara: il "numero che identifica" dovrebbe essere il numero del file da caricare partendo da quello attuale.
Esempio veloce: carichiamo il primo file su nastro, lo eseguima e al termine dell'esecuzione dobbiamo caricare il secondo file: specifichiamo sempre 1 come numero del file da caricare... cioè "non saltare" alcun file, ma carica subito.
Ma questo è un altro discorso... che ho fatto per dire che con il "multiloader" riesco a creare TAP funzionanti, mentre con il SINGLE loader (che è quello con lo scrolltext, gli effetti etc... etc... ho qualche problema anch'io).
Un esempio di TAP funzionante è
questo.
Altro dettaglio è la "lunghezza" dei files da salvare su nastro: il valore corretto da usare è quello riportato dalla cartuccia Action Replay (per esempio) e non quello riportato dal compilatore.
Esempio: il mio loader occupa la ram da $C000 a $C117.
Se lo carico con l'ActionReplay, la cart riporta $C000-$C118, mentre il compilatore riporta la prima coppia di indirizzi.
Il saver funziona correttamente solo se gli si "passa" la versione con "un byte in più" della ram realmente occupata dal codice.
Per tornare al LOADER... il codice della versione "mono" è altamente customizzata per qualche tipo di software che l'autore stava sviluppando...
Infatti nel bel mezzo del codice c'è:
;---------------------------------------
; RELOCATE - Relocates code from
; $4000 to $D000
;-------------------
RELOCATE
SEI
LDA #$30
STA $01 ; relocate code
LDY #$00
LDX #$10
TLOP
LDA $4000,Y
TO
STA $D000,Y
INY
BNE TLOP
INC TLOP+$0002
INC TO+$0002
DEX
BNE TLOP
LDA #$35
STA $01
CLI
LDA #$60 ; self modifying CLI to RTS
STA $02D4
JMP $02A7 ; re-initialise the loader
richiamato in questo punto
LOAD_D000
JSR CHECKSTOP
LDX LOAD_FLAG ; $4000 relocating up to $D000
BEQ LOAD_D000
INX
STX LOAD_FLAG
JSR RELOCATE ; relocate code to $D000
ma non è di alcuna utilità in un programma generico...
Poi c'è la parte per rilevare le "expert cartridge" che è pressochè inutile oggi.
Nei miei tests riesco ad eseguire lo scrolltext, caricare le pic, suonare la musica... ma NON ad eseguire correttamente un programma...
L'ultima porzione del caricamento viene gestita da un loader nello stack pointer, cioè quando il loader incontra il "trigger" per il FIRE_UP_STACK, butta nello stack il codice e lo esegue. Questo codice carica ancora almeno un file e poi, dopo alcune operazioni, salta all'indirizzo di partenza specificato in fase di compilazione...
Non riesco a capire se sia più utile studiare la versione "single load" per "rimetterla in funzione" o crearne una nuova usando il "multiloader"...
Confesso che il passaggio DASM -> 64Tass ha creato qualche difficoltà...
Tu sei riuscito ad ottenere risultati migliori?
