Il reset non e` frutto di un malfunzionamento accidentale, ma di un bel
RST_0 deliberatamente piazzato in testa al programma.
Dopo un po` di sbattimento per capire come veniva caricato il loader, sono
arrivato al punto in cui l'header da 262 bytes caricato come programma basic
(il primo blocco del tzx) riloca se stesso in una zona di ram in alto (per
la precisione all'indirizzo $F92B) e passa li` in esecuzione.
La prima cosa che fa e` chiamare una subroutine e poi, se il carry ritorna
reset, esegue uno spettacoloso RST 0. Sostituito con un NOP e ricalcolato il
checksum per permettere il caricamento (ho lavorato in formato .tap perche`
lo conosco meglio) il gioco e` diventato perfettamente "compatibile" e sta
girando in questo momento sul badaloc.
A questo punto, appena avro` tempo (non so perche` ma e` sempre ora di
mangiare :-)) dovro` scoprire cosa fa quella subroutine, l'ipotesi iniziale
di Paolo circa l'incompatibilita` con istruzioni non documentate e` ora piu`
che probabile. Non so se sperare che avesse ragione (non risolvibile se non
con una "compatibility-cartridge :-) con sopra uno Z80A) oppure no (cercare
un qualche casino hardware).
Qui http://www.zxbada.bbk.org/Infinity_NO-RST0.zip e` presente lo stato
attuale del "progetto", con il disassemblato dell'header (ho inserito i
commenti dei punti coinvolti) nonche` il file .tap originale (che va in
crash), un eseguibile con sorgente "no_rst0.exe" che genera un nuovo .tap
(modified.tap) nonche` il modified.tap stesso, che funziona perfettamente.
Ciao!
