Buongiorno,
espongo qui la quadratura del cerchio del problema.
Non ho risolto ancora, ma almeno ho individuato la questione che scatena il problema.
Riassunto delle puntate precedenti:
abbiamo un A600 con kick ROM originale 2.05 vers. 37.300 + floppy Install2.1 (anche gli altri ovviamente, quindi WB2.1, Locale 2.1 ecc …) + adapter interno IDE-CF, ed una CF SanDisk Ultra tipo 1, 4GB / 30Mbs.
L’obbiettivo è quello di creare 2 partizioni primarie (dell’ordine, ne parliamo fra un attimo), una formattata in FAT32, con ID partizione = 0x0B, e l’altra, con ID partizione = 0x76, da dedicare ad Amiga OS.
La partizione FAT32 servirà ovviamente allo scambio dati fra USB-PC e porta PCMCIA-Amiga, mentre l’altra, dopo essere stata inizializzata, resa bootable e formattata da HDToolBox, dovrà ospitare un’istallazione di WB2.1.
Ho verificato, con l’aiuto di 3 diversi programmi (free) per il partition-managing (giranti su Windows), uno dei quali consente di visualizzare byte per byte i volumi di interesse, quanto segue:
prima di tutto, ho provato due situazioni:
---
1)
Prima partizione primaria = 0x0B/FAT32 = per scambio dati
Seconda partizione primaria = 0x76 = per Amiga OS
2)
Prima partizione primaria = 0x76 = per Amiga OS
Seconda partizione primaria = 0x0B/FAT32 = per scambio dati
---
Entrambe le situazioni portano alla stessa identica conclusione, pertanto da ora in poi mi riferirò alla seconda.
Opero su PC/Windows sulla CF di cui sopra:
dopo aver piallato la CF (cancellazione di tutte le partizioni e riempimento con zeri), faccio quanto segue:
1)
Creo la prima partizione primaria di 2GB, le assegno come ID = 0x76, NON la formatto, poiché tanto ci dovrà pensare Amiga a formattarla, per esempio in FFS (in modalità quick). L’importante è che HDToolBox possa individuare tale partizione, da cui la necessità dell’ID di partizione = 0x76. L’allineamento è già ottimizzato, secondo il programma di partition-managing.
2)
Creo la seconda ed ultima partizione primaria sui restanti 1.73GB, con ID = 0x0B, e la formatto in FAT32. L’allineamento è già ottimizzato, secondo il programma di partition-managing.
3)
Ricostruisco l’MBR.
Senza fare questa operazione ho verificato che posso avere dei problemi: se ad esempio, nel blocco 0, ovvero i primi 512 bytes fisici della CF, mi è rimasto qualche rimasuglio di esperimenti passati, come ad esempio il RDB di Amiga (in passato questa CF ha ospitato solo partizioni 0x76 FFS e OFS per Amiga), allora in tal caso, se non ricostruisco il MBR, ho che Windows non riesce a montare la partizione FAT32, e neppure Amiga ci riesce (se metto la CF in PCMCIA, Amiga mostra la fatidica icona “CF_NDOS”, come è giusto che sia). Insomma, la ricostruzione di un corretto MBR è fondamentale.
Una volta ricostruito, Windows si accorge subito della partizione FAT32, diventa utilizzabile, e anche su PCMCIA/Amiga abbiam un buon comportamento, anche lì la partizione è utilizzabile … fin qui perfetto!
Figura1
4)
Adesso porto la CF su IDE in Amiga.
Avvio A600, che fa boot da DF0, in cui ho messo il floppy Install2.1 con L: FastFileSystem (per inizializzare una o più partizioni DH0, DH1, DH2 ecc … con il FFS, ma a questo punto non ci arriviamo! … adesso vediamo perché).
Bene, adesso avvio HDToolBox 2.22 dal floppy Install2.1.
Abbiamo la lettura di scsi.device, e ottengo questo:
Figura2
Devo pertanto costruire un device che si addica alla mia CF, quindi procedo … ecco il device costruito da me:
Figura3
Notare che, per sicurezza, ho scelto una size di circa 1.5GB anziché 2GB, così da essere sicuro di stare dentro/non avere problemi.
63 e 255 li ho tratti dai feedbacks che mi hanno dato i 3 programmi di partition-managing di cui sopra (tutti e 3 i programmi sono d’accordo su tali parametri), invece i cilindri li ho scelti io per stare dentro i 1.5GB.
Mi appresto adesso a cliccare su “Save changes to drive”:
Figura4
Lo faccio perché vorrei che HDToolBox inizializzasse correttamente la partizione che lui può vedere, ovvero la prima, quella da 2GB, quella con ID = 0x76 (l’unica che lui può vedere), e mi sarei aspettato che il RDB che HDToolBox deve scrivere da qualche parte, venisse NON sovrascritto sull’MBR, cioè nel blocco 0 (i primi 512 bytes della CF): mi sarei aspettato che RDB venisse scritto, per esempio, nel blocco 1, o nel blocco 2.
La teoria dice che l’MBR è “stupido”, nel senso che deve andare sempre e soltanto nel blocco 0, invece RDB è più elastico, nel senso che può essere scritto in uno qualunque dei primi 16 blocchi, così che RDB possa coesistere con MBR, così da avere, in una stessa CF, sia partizioni FAT che partizioni Amiga.
Invece HDToolBox, dopo la pressione del bottone “Save changes to drive”, sovrascrive RDB su MBR:
Figura5
A questo punto la CF può tranquillamente essere “Amigata” (ci posso far tutto, istallare dei WBs, ecc …), ma ho chiaramente perso la possibilità dello scambio dati fra PC e Amiga, poiché l’MBR è stato distrutto, soppiantato dall’RDB.
Qualcuno è in grado di spiegare come risolvere la cosa?
Come insegnare a HDToolBox a lasciar stare l’MBR nel blocco 0 e fare le sue cose (RDB e blocchi PART) nei blocchi successivi al blocco 0?