[zxspectrum] Re: Sempre su MakeTZX
- From: Cesare Falco <wallyweek@xxxxxxxxx>
- To: zxspectrum <zxspectrum@xxxxxxxxxxxxx>
- Date: Mon, 6 Oct 2014 08:47:30 +0200
2014-10-05 12:42 GMT+02:00 Enrico Maria Giordano <e.m.giordano@xxxxxxxxxxxxxxx>:
> Altro strano messaggio:
>
> Block 51 => Bytes: screen$ - Header: Length= 17, Pause=812ms.
> Block 52 => F:255 - Speed: 94% - Start=16384, Length= 6914, Pause=993ms.
>
> Che vuol dire?
- il blocco 51 è stato convertito correttamente (lo capisci dal "-"
prima della scritta "Header") e si tratta di un "Header", quindi lungo
17 byte, di unn blocco di tipo "Byte".
- il blocco 52 è stato convertito correttamente ("-" prima di "Start),
ma con una velocità riconosciuta pari al 94% del loader standard della
rom; il primo byte è 255 (F:255), informazione che MakeTzx restituisce
per i blocchi di dati (diversi dall'header), indipendentemente dalla
velocità (sia standard che turbo). Se hai dimestichezza con
l'assembler, è il valore che va assegnato al registro A prima di
chiamare la routine di load. Spesso per situazioni come queste puoi
provare a forzare il flag di riconoscimento del loader standard della
rom (-ln se mi ricordo bene).
Argomento "CRC".
Più che di un vero CRC si tratta di un "parity byte", secondo la
definizione di "The Complete Spectrum ROM Disassembly". Per ogni byte
da salvare, la routine di save esegue un'operazione di XOR
memorizzando il risultato per usarlo per il byte successivo; salvati
tutti i byte il risultato viene salvato a sua volta e rappresenta
l'ultimo byte del blocco.
La routine di load fa il contrario: di ciascun byte letto esegue lo
XOR e memorizza il risultato per utilizzarlo con il byte successivo;
caricati tutti i byte controlla che l'ultimo letto sia uguale al
risultato finale della "catena" di XOR. Se così non è, viene acceso il
bit di carry e, nel caso di caricamento da basic, la rom emette il
messaggio "R Tape Loading Error".
Questo meccanismo è stato mantenuto in quasi tutti i loader
commerciali (se mi ricordo bene un'eccezione rilevante è l'Alkatraz);
MakeTzx è in grado di utilizzare il medesimo algoritmo per capire se
ha letto tutti i byte correttamente ed espone il risultato delle sue
valutazioni tramite il flag cui accennavo prima (quel "-" prima di
"Header" o "Start" a seconda del tipo di blocco rilevato). Se il flag
vale "-" (meno) o "!" (punto esclamativo) il blocco va bene. Se vale
"F" il parity byte non corrisponde e caricando il blocco in un
emulatore otterrai un errore di caricamento. Il dominio del flag
ammette un altro paio di valori, di cui però non ricordo il
significato. :-(
Una nota aggiuntiva. Nel blocco 52 la lunghezza è pari a 6914: 2 byte
in più della lunghezza reale dei dati, 6912 di una schermata. Questo
perché MakeTzx di solito espone nella lunghezza tutti i byte che ha
effettivamente trovato, inclusi il primo byte e l'ultimo.
Dell'ultimo byte ho già detto, è il parity byte. Come ho accennato
prima, il primo byte deve corrispondere al valore passato nel registro
A prima di chiamare la routine di load. Nel loader standard serve a
distinguere un header (valore 0) da un blocco dati (valore 255); le
primissime protezioni con blocchi headerless usavano valori non
standard per confondere i programmi di copia. Anche questa è una
caratteristica del loader standard mantenuta nella gran parte dei
loader commerciali.
Tornando a MakeTzx, quando riconosce il blocco letto come standard
della rom (header + dati), mi sembra che nel messaggio a video vengano
tolti il primo e l'ultimo byte e venga così segnalata la lunghezza dei
soli dati effettivi (6912 nel caso del blocco di esempio 52).
Perdonate la lunghezza e la spocchia, ma credo fossero entrambe
necessarie per chiarezza. :-)
Cesare
Other related posts:
