Prima di tutto buon Natale!
e una volta inserito l'identificatore in "Cambia" troverai l'acronimo del Filesystem Standard o il nuovo creato SFS\00, PFS\00
Si, adesso mi funziona tutto.
L'unica vera accortezza non scontatissima è stata quella, dopo aver inserito il DOS-Type opportuno, di battere il tasto Enter.
All'inizio non battevo Enter, semplicemente inserivo l'esadecimale del DOS-Type del filesystem che volevo aggiungere ad HDToolBox,
dopodichè cliccavo sul bottone OK. Così non avevo il risultato atteso.
Invece ho scoperto che bisogna, dopo aver battuto, nel campo di edit a sinistra, il DOS-Type, bisogna dicevo battere Enter: in tal modo si vede subito che HDToolBox3.9 riconosce il DOS-Type e produce lui, mostrandolo sulla destra, l'acronimo corretto.
Clicca QUI per un mio vecchio video che mostra la procedura citata.
L'ho visto, grazie. è stato importante per capire meglio la procedura.
Adesso se vuoi sistemare quelle partizioni, modifica l'identificatore utilizzando FFS
Ho sistemato UDH0 e UDH1 nella CF utilizzando PFS3AIO, e tutto funziona da manuale, sia su Amiga emulato che su Amiga fisico ...
perfetto!!
Ovviamente su A600 reale, con 68K, Kick 3.2 vers. 47.96, con soli 2MB di ram (1MB nativo + 1MB in trap-door), effettivamente OS3.2
su UDH0 in CF funziona, ma l'esperienza utente non è soddisfacente: molto lento, poco fruibile.
Proverò a fare le stesse cose sul mio A1200 reale, dove anche lì ho il kick 3.2: mi aspetto delle prestazioni superiori.
Ultime due note:
1)
ho provato a fare questo esperimento:
sulla CF (inserita in IDE-44 su A600 reale) ho modificato la seconda partizione, UDH1, passando, solo per questa partizione, da PFS3AIO a SFS0, pertanto la situazione attuale è la seguente:
UDH0, priorità = -1, FS = PFS3AIO, OS = OS3.2 installato da PC/Win - WinUAE;
UDH1, priorità = -2, FS = SFS\00, OS = nessuno;
Se accendo A600 fisico, il sistema va in guru!
Se accendendo, vado subito in Amiga Early Startup Controller, e da lì disabilito UDH1, dopodichè avvio, in questo modo A600 riesce a fare correttamente bootstrap da UDH0.
So bene che SFS\00 è supportato da 68EC020 in poi, mentre invece il mio A600, in quanto quasi genuino/nativo, dispone del 68000, pertanto non mi aspettavo che tentando di fare bootstrap da una partizione UDH1 formattata con SFS\00, il sistema potesse riuscire ad avviarsi ...
2)
... però non mi torna molto che A600+68000+kick3.2, una volta che il FW del kick viene copiato in RAM ed eseguito, si impalli a causa di una partizione (UDH1) formattata con un filesystem (SFS\00) ignoto, incompatibile con il 68000.
Io mi sarei aspettato il seguente comportamento logico:
appena do potenza ad A600 fisico, il FW scritto nella ROM del chip fisico kick3.2 viene copiato dalla ROM stessa ed incollato in RAM (complessivamente 2MB, 1MB su scheda madre di A600, 1MB su scheda di espansione in botola), dopodichè, a fine copiaggio, il 68K (la CPU) inizia a fetchare le istruzioni del kick dalla RAM, ovvero ad eseguire il "BIOS" di A600.
L'esecuzione di questo BIOS determina, dopo l'autodiagnosi dell'HW corrente (quello che nel mondo IBM-like si chiamerebbe "POST"), la ricerca di un supporto (di almeno un supporto) di memoria di massa (floppy, HDD, CF, ecc ...), in base alle priorità, dal quale fare bootstrap.
Pertanto il "BIOS" (FW di kick3.2, nel mio caso) dovrebbe accorgersi delle partizioni UDH0 e UDH1, entrambe bootable (rese tali da me, in fase di HDToolBox3.9 su WinUAE/OS3.9), e dovrebbe chiedersi "da quale di queste 2 partizioni posso avviare un OS valido?", quindi andare a vedere il settore di avvio RDB (@RDSK ... ) della CF, da cui le informazioni richieste.
Da qui il kick3.2 dovrebbe capire che abbiamo, sulla CF attuale, la partizione UDH0, con priorità maggiore di UDH1, e che in UDH0 abbiamo un filesystem valido, ovvero il PFS3AIO (valido = riconoscibile da CPU 68000), con installato un OS3.2 valido, pertanto A600 dovrebbe già fermarsi qui e fare bootstrap su UDH0.
Il sistema potrebbe, "per ligiosità", investigare anche la natura di UDH1, ovvero la partizione a priorità inferiore, per vedere però che il filesystem di UDH1 è ignoto (SFS\00), e senza un OS installato, ad ogni modo già per il fatto che abbiamo SFS0, filesystem ignoto ad A600+68K, già solo questo dovrebbe indurre il FW di kick3.2 ad ignorare quella partizione, a non preoccuparsene, anche perchè il sistema dispone di una partizione UDH0 a priorità maggiore, con un filesystem noto PFS3AIO, con un OS noto/compatibile con 68K, pertanto il sistema dovrebbe bootare da UDH0.
Poi mi torna perfettamente che, una volta fatto il boot su UDH0, e una volta regimato l'OS3.2 su UDH0, sul desktop di OS3.2 non devo vedere la partizione UDH1, poichè UDH1 è inizializzato e formattatato con SFS\00, filesystem ignoto al 68K.
Quello che non mi torna è che in fase di valutazione, dopo il POST, delle eventuali partizioni bootable sulla CF dalle quale tentare un avvio, il FW del bios Kick3.2 veda UDH1 con SFS\00 non compatibile, si "offenda" molto per questo, e vada in guru ...
Come ti spieghi questa cosa??
Ultimissimo punto:
per concludere, il prossimo obbiettivo è quello di tentare di creare una CF 3.7GB "mixed", ovvero non un'unica partizione RAW - 3.7GB not formatted - ID = 0x76 (oppure ID = 0x04), con l'RDB come primo blocco, al posto dell'MBR, con due partizioni create da HDToolBox3.9 su OS3.9/A1200 emulato su WinUAE, funzionanti su A600 fisico (la CF attuale, insomma).
Il prossimo task sarà quello di creare una CF con 2 partizioni, M e X, un MBR come primo settore, M come prima partizione primaria (la prima delle 4 possibili con l'MBR) formattata in FAT32, X come seconda partizione primaria, con ID = 0x76 oppure 0x04, con dentro due sotto-partizioni amigose, UDH0 e UDH1, magari entrambe in PFS3AIO.
Non ho dubbi che su WinUAE/OS3.9, sul quale preparerò tale CF, tutto funzionerà come da teoria: voglio solo vedere se l'A600 fisico sopra descritto riuscirà a vedere tale CF ... ti faccio sapere appena possibile!!
