[zxspectrum] R: R: Re: R: Re: Fra tanti ZX....
- From: "Simone Voltolini" <simone.voltolini@xxxxxx>
- To: <zxspectrum@xxxxxxxxxxxxx>
- Date: Thu, 28 Jan 2016 16:32:23 +0100
Dimenticavo di aggiungere che
io oltre a cercare le MD originali del
QL
cerco anche quelle dello Speccy
e se avessimo il programma che
DUMPA
preserverei anche quelle
Io ho SUPADRIVE
Tasword 3 originali
MicroMate anche volendo
Ma soprattutto è fondamentale poterle RICREARE inversamente altrimenti
rischiamo poi di perderne lutilizzo su macchina reale.
Comunque intanto le routine che servono ad Enrico sono fondamentali per
cominciare a passare tramite seriale i TAP da un PC alla IF1 su Microdrive.
E qui nessuno ancora cè riuscito
Kora Sistemi Informatici
Via Cavour 1, 46030 San Giorgio di Mantova MN
Tel/Fax +39 0376 371059
P. IVA: 02048930206
Da: Simone Voltolini [mailto:simone.voltolini@xxxxxx] ;
Inviato: giovedì 28 gennaio 2016 16:23
A: 'zxspectrum@xxxxxxxxxxxxx' <zxspectrum@xxxxxxxxxxxxx>
Oggetto: R: [zxspectrum] R: Re: R: Re: Fra tanti ZX....
>Ma abbiamo chi conosce a menadito lL/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:
