[zxspectrum] R: R: Re: R: Re: Fra tanti ZX....

  • From: "Simone Voltolini" <simone.voltolini@xxxxxx>
  • To: <zxspectrum@xxxxxxxxxxxxx>
  • Date: Thu, 28 Jan 2016 16:22:47 +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  :)”


FERMI TUTTI!!!

Ci dai una mano a scrivere le routine? (Vedi mail di Enrico?)


“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.”
 
Allora sul QL è stato già fatto praticamente tutto: con Daniele Terdina
abbiamo fatto il programma di DUMP dei settori e conosciamo esattamente il
comportamento del MD su QL e come bypassare qualsiasi problemi di DUMPING
(con però anche istruzioni NON documentante).

Per il CONTRARIO invece…Daniele sta studiando come farlo ma tecnicamente è
comunque fattibile in quanto sappiamo benissimo che i settori danneggiati
sono in diverse zone ma sappiamo anche, su QL, come fare in modo di dire a
QDOS di scansarli ;)
 
“

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”
 
Concordo ;) Sistema sicuramente tra i + intriganti di tutti.

I miei test hanno dimostrato che il QL è per il 90% + affidabile dello
Speccy con il Microdrive perché gestisce la scrittura via QDOS molte più
cose ed in maniera + intelligente.




Other related posts: