AmigaOS 3.5: Gestione dei dischi
di Bernardo Innocenti <bernie@cosmos.it>

ABSTRACT

Questo mese affronteremo un argomento che costituisce uno degli aspetti meno conosciuti del nuovo sistema operativo. Non sono pochi infatti gli utenti che sono rimasti spiazzati dalle numerose differenze nella gestione degli hard disk di AmigaOS 3.5.

NSD vs. TD64

Per introdurre gli argomenti che tratteremo in seguito è propedeutica una digressione su una vicenda che risale a qualche anno fa. Siamo certi che la maggior parte dei lettori abbia già avuto modo di conoscere i dettagli della questione dei due diversi standard per il supporto degli hard disk con dimensioni superiori a 4GB. La polemica che ne derivò fu decisamente accesa e coinvolse molti dei più celebri sviluppatori Amiga.

Lo standard NSD (New Style Device) venne promulgato da Amiga Technologies con un documento apparso per la prima volta sull’Amiga Developer CD 1.1 (Maggio 1996). Lo standard aveva lo scopo di razionalizzare ed estendere l’interfaccia con i device di Exec e definire un set di comandi aggiuntivo per i dispositivi in stile trackdisk, come ad esempio lo scsi.device per garantire l’accesso ai blocchi situati oltre i primi 4GB di una periferica. Difatti, i comandi CMD_READ e CMD_WRITE prevedono che l’utilizzatore (in genere un filesystem) indichi l’offset dei blocchi espresso in byte dall’inizio dell’unità. Questo valore è memorizzato in un campo a 32bit, che consente un offset massimo di 4GB. Per oltrepassare questo limite l’NSD definisce un nuovo set di comandi con offset a 64bit (NSCMD_TD_READ64, NSCMD_TD_WRITE64, e così via). L’estensione a 64bit innalza il limite massimo fino a sedici milioni di Terabyte, che si possono ritenere senza dubbio “sufficienti per chiunque”.

Paradossalmente, sullo stesso CD-ROM era presente in un’altra directory un documento PostScript redatto niente meno che dall’autorevole persona di Ralph Babel. In questo testo viene definito uno standard alternativo che prese il nome di TD64 (trackdisk a 64bit). Pur condividendo le medesime finalità dell’NSD, i dettagli dell’implementazione erano sufficientemente diversi da non consentire l’interoperabilità tra i due standard. Prima del rilascio delle specifiche ufficiali dell’NSD, Ralph Schmidt aveva già adottato lo standard TD64 per i device presenti nelle ROM di tutti i controller SCSI prodotti da Phase 5.

Mentre Heinz Wrobel distribuiva versioni aggiornate dello scsi.device per i controller IDE e SCSI integrati in tutti i modelli di Amiga, gli utenti dei controller Phase 5 dovevano utilizzare per forza di cose il TD64. Ovviamente gli standard a 64bit devono essere supportati anche dai filesystem, in particolar modo il FastFileSystem. Mentre Heinz Wrobel rilasciava sul sito FTP di Amiga Technologies versioni ufficiali del FFS V43 con supporto NSD, era contemporaneamente disponibile il patch TD64 che innalzava il numero di versione del FastFileSystem a V44, pur rimanendo funzionalmente identico alla V40 inclusa nell’OS3.1. Fortunatamente, sia il Professional File System che lo Smart File System funzionano con entrambi gli standard. Se siete stati tra le sfortunate vittime di questo caos, non occorre aggiungere altro.

Oltre i 4GB

L’OS 3.5 include la versione V45 del FastFileSystem realizzata dallo stesso Heinz Wrobel. Questa versione, come la V43, supporta unicamente l’NSD e corregge alcuni dei bug che erano rimasti irrisolti nella V43. Il comando SetPatch, sempre mantenuto da Wrobel, integra le funzionalità del programma NSDPatch. Esso installa su tutti i device presenti nel sistema un patch che li rende conformi allo standard NSD. Con NSDPatch, il FastFileSystem V45 può essere utilizzato sulle unità connesse ai controller Phase 5. Il file di testo “Devs:NSDPatch.cfg” contiene una descrizione di tutti i device conosciuti e indica il modo in cui NSDPatch deve correggerli. Il numero di opzioni è decisamente vasto e la loro modifica richiede una conoscenza approfondita del funzionamento di AmigaOS. Tuttavia, in taluni casi intervenendo su questo file è possibile risolvere dei problemi legati alla propria configurazione (oppure causarne di più gravi). 

Un’altra nuova funzionalità presente in SetPatch è la possibilità di sostituire alcuni moduli del Kickstart con le rispettive versioni aggiornate presenti all’interno del file “Devs:Amiga ROM Update”. Al primo boot, SetPatch determina i moduli corretti per il modello di Amiga che si possiede e li rende residenti in memoria riavviando il sistema.

SetPatch sostituisce la versione del FastFileSystem presente in ROM con la V45, ma le partizioni possono comunque utilizzare una versione diversa memorizzata nell’RDB. L’RDB (Rigid Disk Block) è una struttura dati che occupa i primi blocchi dell’hard disk e ne descrive la geometria e la tavola delle partizioni. HDToolBox consente di memorizzare nell’RDB i filesystem richiesti dalle partizioni di tipo automount, ed è prassi comune inserirvi anche l’ultima versione del FastFileSystem. In questo modo il supporto NSD è disponibile nel filesystem anche al primo boot, condizione necessaria (ma non sufficiente) per poter eseguire il boot da una partizione che oltrepassa i primi 4GB del disco. L’altro requisito indispensabile è possedere un controller il cui firmware implementi nativamente l’NSD. Purtroppo, ad oggi, non ne esistono. Ovviamente SetPatch non può entrare in azione prima del boot a freddo, quindi la partizione che contiene il Workbench deve necessariamente trovarsi entro i primi 4GB dell’hard disk. Se non vuole accettare questo limite, esistono comunque due modi di aggirarlo. Il primo consiste nell’utilizzare un filesystem diverso, come l’SFS o il PFS. Secondo il parere degli utenti che li utilizzano, entrambi sono sufficientemente maturi e stabili da consentirne l’utilizzo al posto del filesystem nativo di Amiga. L’altra possibilità consiste nell’utilizzare la V44 del FastFileSystem, l’unica con il supporto per il TD64. In questo modo si rinuncia ai vantaggi della versione V45, ivi compresi i bug che essa corregge.

Un nuovo HDToolBox

Il nuovo HDToolBox presente nell’OS 3.5 non è un semplice aggiornamento delle versioni precedenti con una veste grafica rinnovata. Si tratta invece di una riscrittura completa basata sulla GUI ReAction e sulla libreria hdwrench.library. Quest’ultima costituisce un layer di astrazione per la gestione dell’RDB e la manipolazione a basso livello delle periferiche IDE e SCSI. Essendo l’RDB uno standard, in linea teorica il nuovo HDToolBox può essere utilizzato con tutti i controller per Amiga. Alcuni beta tester avevano però segnalato dei problemi di compatibilità con le partizioni create con il programma SCSIConfig. Esso fa parte del software fornito a corredo dei controller SCSI di Phase 5 e scritto, indovinate un po’, dal solito Ralph Schmidt. Pare dunque che egli sia la fonte di tutti problemi di compatibilità esistenti su Amiga, ipotesi questa che viene ulteriormente confermata dalla vicenda che riguarda ppc.library e WarpOS.

Anche se il nuovo HDToolBox ha provato di essere un programma affidabile nel corso della fase di beta testing, vi raccomandiamo di tenere a portata di mano una copia della vecchia versione (la V40.4). Il nuovo HDToolBox può essere infatti eseguito solo in un ambiente 3.5 completo e funzionante, condizione che in caso di disastro potrebbe non verificarsi. In ogni caso il disco di emergenza dell’OS 3.5, che senza alcun dubbio avete fatto e state custodendo in un posto sicuro, contiene tutto il necessario per avviare HDToolBox.

Grazie alla hdwrench.library, d’ora in poi sarà possibile scrivere applicazioni che manipolano le partizioni degli hard disk senza doversi preoccupare della struttura dell’RDB, ponendo così fine alla babele di piccole incompatibilità diffuse tra le utility per i dischi. La libreria è documentata nell’ultimo Amiga Developer CD, nel quale è incluso anche un programma di esempio che ne utilizza tutte le funzionalità. Una curiosità: l’autore di questa libreria è una programmatrice statunitense: Joanne Dow.

Conclusioni

Anche in questo caso AmigaOS 3.5 conferma il suo ruolo di integrazione e consolidamento degli standard precedenti, chiudendo una volta per tutte le spaccature che si erano venute a creare nel corso degli anni di anarchia che hanno seguito il fallimento di Commodore. Tutto sommato il limite di 4GB sugli hard disk su Amiga era un problema di poco conto se paragonato all’assurdità dei limiti che ancor oggi affliggono il mondo dei cloni PC. Per non parlare poi della miriade di “soluzioni” che hanno tentato di aggirarli, finendo per aggiungerne di peggiori. Chi possiede un PC con almeno due hard disk sa a cosa mi riferisco. Tutti gli altri possono vivere tranquillamente anche senza conoscere sigle astruse come LBA, FAT32, INT13h, LARGE, MBR, CHS, unità logiche e partizioni estese.

RIQUADRO 1: I moduli presenti in Amiga ROM Update

IDE_scsidisk	43.35	scsi.device per il controller IDE di A600/A1200/A4000
A4000T_scsidisk	43.35	scsi.device per il controller SCSI di A4000T
scsidisk	43.35	scsi.device per il controller SCSI di A3000/A3000T
fs	45.1	FastFileSystem
filesysres	45.2	filesystem.resource
ram-handler	44.13	RAM Disk handler (Boing Bag 2)
console	44.5	console.device (Boing Bag 2)

DIDASCALIE IMMAGINI

Immagine1: L’output di SetPatch mostra i moduli residenti caricati

Immagine2: La finestra gestione delle partizioni di HDToolBox. L’ultima partizione termina oltre i primi 4GB del disco.

Immagine3: La finestra di gestione dei filesystem di HDToolBox (il FastFileSystem è evidenziato).