[zxspectrum] R: Re: R: Re: Fra tanti ZX....
- From: Stefano Bodrato <stefano_bodrato@xxxxxxxxxxx>
- To: "zxspectrum@xxxxxxxxxxxxx" <zxspectrum@xxxxxxxxxxxxx>
- Date: Thu, 28 Jan 2016 15:46:33 +0100
Ma abbiamo chi conosce a menadito l’L/M del Microdrive…che è un po’
lontanuccio da gestire ;)
Ma ci sto pian piano riuscendo ^_^
La questione del Microdrive mi incuriosisce abbastanza..
tempo fa ho studiato (non senza fatica) il kernel del tool "M-Doc: The
Microdrive Doctor", di Ray J. Eckersley in z88dk, e ne ho ricavato delle
funzioni per z88dk, compatibili con qualsiasi versione della Interface 1.
So che EMG si era spinto oltre, controllando direttamente i microdrive senza
usare nemmeno le parti di basso livello della ROM, comunque ecco quel che avevo
dedotto con i miei esperimenti:
- La formattazione del microdrive avviene scrivendo 256 settori numerati in
modo decrescente da 255 a 0 (come sappiamo con i tool opportuni si può cambiare
l'interleave e aumentare leggermente la capacità totale del cartridge).
- In ogni singolo settore viene registrato il nome del cartridge, il proprio
numero d'ordine e i flag di stato .
- Visto che spesso il nastro è più corto del necessario, i settori con numero
più alto verranno sovrascritti al giro successivo (questo significa che i
settori sono salvati in sequenza).
- Nella seconda fase il "Format" verifica i settori e, nel giro successivo ne
aggiorna i flag per distinguere i settori buoni da quelli danneggiati o assenti
(Header Integrity=GOOD).
- Ogni settore può contenere un record, ovvero pezzo di file; il record è a
sua volta numerato progressivamente, ma è sempre possibile (per migliorare le
prestazioni e/o l'affidabilità) salvare più copie dello stesso record in
settori differenti (questo si può fare anche con una semplice POKE, perchè la
ROM è predisposta).
- Le routine di lettura caricano ogni settore che passa davanti alla testina e
confrontano l'header del record in esso contenuto con il nome e tipo di file
cercato (e naturalmente con il numero record)... naturalmente una volta
individuato il settore corretto questo viene dato in pasto al loader.
- L'ultimo record di un file è marcato con un flag EOF.
- Il primo record di tutti i file tranne quelli di tipo "PRINT" contiene un
ulteriore header simile a quello del SAVE che conosciamo, escluso il filename
che è già descritto a livello di record.
- E' possibile leggere, modificare e riscrivere il singolo settore, anche
incasinando le checksum (non ricordo bene cosa faccia la ROM in questo caso,
probabilmente riprova un po' di volte poi da errore, a meno che non trovi una
seconda copia con la checksum a posto.
- CHR$(0) in testa al nome file nasconde il file al comando CAT, ma
sostanzialmente non ha altri effetti.. un CAT potenziato non avrà problemi a
superare questa "protezione"
Le conseguenze logiche di questa situazione:
- Il processo di "ERASE" è lento, perchè viene cercata a tappeto ogni traccia
di qualsiasi record contenente il nome file da cancellare (che può essere anche
doppio o orfano).
- Ho realizzato un RENAME secondo lo stesso principio, ed è ancora più lento.
Il "rename" ufficiale si basa sulla copia del file (MOVE) e successiva
eliminazione del file di origine, il che naturalmente crea problemi in mancanza
di spazio libero.
- Z88DK è in grado di gestire l'accesso casuale a file di grosse dimensioni
utilizzando il numero record. Questo mi ha permesso il funzionamento
dell'interprete per giochi Infocom sul gommoso, copiando con un loop BASIC i
file .DAT originali da seriale.
- Modificando i settori di copie multiple di un programma si possono realizzare
leggere variazioni dipendenti dal settore che ci si trova davanti:
probabilmente usabile osservabile solo con programmini brevi e poco sensato.
- Credo che il nome disco non serva a nulla, se non a CAT per dare un titolo
alla directory.. con un CAT modificato potrebbe essere riutilizzato per
abbozzare dei folder a livello root.
- E' poco conveniente usare il numero di settore per creare un filesystem
alternativo, meglio creare un file di tipo "PRINT" lungo quanto tutto il
cartridge (un qualche linguaggio FORTH o PROLOG lo faceva)..in questo modo si
saltano automaticamente i settori difettosi e per l'accesso casuale si cerca il
numero record.
- Come sopra, nulla vieta di inventarsi un formato di record diverso.
- Non c'è nulla di terribile ad avere il primo settore danneggiato :)
E' inoltre possibile creare un programma che faccia il dump dei settori di un
microdrive ad esempio per spedirli a un emulatore.
Unica difficoltà è distinguere un settore assente da un settore danneggiato:
probabilmente un buon trucco sarebbe di tenere una copia dell'ultimo buffer
caricato e considerare "not found" quando il buffer non cambia.
NON è altrettanto facile riuscire a fare il contrario, perchè ogni cartridge ha
qualche settore danneggiato e quelli del cartridce sorgente potrebbero non
corrispondere.. riformattando tante volte si potrebbe però tentare di marcare
quelli giusti.
Sarebbero state possibili diverse protezioni ad esempio basandosi sulla
presenza di un particolare settore danneggiato.. ma per le note ragioni di
instabilità non sono mai stati utilizzate: già il dato del Microdrive stava su
per miracolo, se ancora ti vietavo la copia...
Stefano
Other related posts:
