interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Classic, anche retrogaming

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMG_Novice_Usr » dom dic 19, 2021 8:32 pm

Ho esaminato il tuo Video e la una Immagine CF e credo sia normale che le partizioni non siano state
riconosciute dal Workbench, hai impostato con HDToolBox un Custon Filesystem Alieno, sconosciuto a me
ma anche ad Amiga ovvero "CFS" con un identificatore 0x43465300 che apparteneva ad una vecchia versione di SFS,
ecco perchè le vedeva solo HDToolBox "il creatore"


Aspetta, qui ci sono diverse cose che non mi tornano.

Prima di tutto, tu dici "Custon Filesystem Alieno, sconosciuto a me ma anche ad Amiga".

Non è un Filesystem aliano/speciale, è semplicemente il FFS che ho trovato nel drawer L: del floppy Install3.2, non l'ho preso da chissà quale supporto esotico ...

L'identificatore "CFS\0", o se vogliamo più semplicemente "CFS0", non l'ho conferito io, ne l'ho customizzato io, quello è l'ID che HDToolBox3.9 su OS3.9/A1200 emulato su WinUAE ha letto nel momento in cui gli ho dato in pasto quel Filesystem sul floppy Install3.2.

L'intero a 4 bytes "0x43465300" altro non è che la label "CFS0" nella tabella ASCII:

0x43 - carattere 'C'
0x46 - carattere 'F'
0x53 - carattere 'S'
0x00 - carattere di terminazione stringa '\0'

quindi il numero 0x43465300 non può essere l'ID di nessuna versione di SFS.

l'ID di una qualunque versione di SFS sarà sicuramente fatto così:

esempio:

SFS0 (questo l'ho effettivamente usato una volta su un A1200 reale)

l'ID era:

0x53465300

in quanto, sempre secondo la tabella ASCII:

0x53 - carattere 'S'
0x46 - carattere 'F'
0x53 - carattere 'S'
0x00 - carattere di terminazione stringa '\0'


ecco perchè le vedeva solo HDToolBox "il creatore"


No, non solo HDToolBox3.2 (il loro creatore) vedeva le partizioni UDH0 e UDH1 / CFS0, ma anche il boot-manager "Amiga Early Startup Control" riesce a vederle correttamente, come mostrato chiaramente nel mio video. Allego qui uno screenshot tratto da quel video, a titolo di prova:

https://drive.google.com/file/d/1gWS0Tw ... oWCs-/view

Amiga Early Startup Control è il boot-manager del kick 3.2, quindi il FW del kickstart 3.2 di A600 fisico ha riconosciuto le partizioni,
il filesystem CFS0, l'interfaccia scsi.device ... tutte le informazioni sono corrette, pertanto nessun filesystem alieno ...


Domanda, hai provato a fare il contrario, ovvero rendere la CF vergine (nessuna partizione e nessuna inizializzazione) praticamente la devi ripulire tutto da PC, poi inizializzare e formattare direttamente da A600, magari anche installare un mini sistema.
Se tutto funziona allora ti sposti su WinUAE e installi il sistema completo !


Questo processo inverso non l'ho provato, ma proverò e ti farò sapere.
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 271
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMIGASYSTEM » dom dic 19, 2021 8:55 pm

No hai creato tu il filesystem Alieno perchè hai fatto la procedura inversa e quindi in base all'identificatore presente è scaturita l'acronimo Alieno.

In pratica tu devi prima cliccare su Aggiungi/Aggiorna e una volta inserito l'identificatore in "Cambia" troverai l'acronimo del Filesystem Standard o il nuovo creato SFS\00, PFS\00, etc.. Clicca QUI per un mio vecchio video che mostra la procedura citata.

Parlavo di un vecchio SFS che magari aveva altro nome ora non ricordo, quell'identificatore gironzolava in quel periodo probabilmente se lo cerchi in rete qualcuno lo confermerà.

Adesso se vuoi sistemare quelle partizioni, modifica l'identificatore utilizzando FFS, al riavvio troverai sul Workbench le icone delle due partizioni da formattare.

Se riesci a inizializzare da Amiga è tutto di guadagnato è la massima compatibilità
Immagine - AROS One Home Site - AfA One - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 5509
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMG_Novice_Usr » sab dic 25, 2021 8:55 pm

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!!
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 271
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMIGASYSTEM » sab dic 25, 2021 9:47 pm

Ok, sono contento che sei riuscito nell'impresa, comunque SFS oltre a richiedere un 68020 ha anche bisogno di un OS 3.0. o superiore

Battere il tasto Enter in molti casi su Amiga è necessario, in pratica è una sorta di invio del comando o del cambiamento di stato di un file o percorso.

PFS2/3 è supportato amche da OS 1.3, io usavo PFS2/3 sul mio A4000 ma adesso preferisco SFS per tanti motivi, uno tra questi è il tempo di scrittura, con PFS se riavvi subito dopo aver copiato qualcosa, al riavvio i file copiati non li ritroverai, anche una stringa scritta su un file di testo scompare se riavvii senza aspettare il giusto tempo e la lucetta lampeggiare che conferma il termine della copiature o di un salvataggio.

Aggiungo che se riavvii o hai un crash mentre stai ciopiando tanti file, per sicurezza dovrai ricopiarli tutti perchè gli ultimi file specialmente "quelli più grossi" saranno tutti corrotti perchèè stato copiato solo parte del file.

Di buono, ma questo è presente anche su SFS, a differenza di OFS e FFS puoi recuperare un file cancellato anche più volte attraverso una Shell o meglio da un Filemanager, per fare questo basta richiamare il nome della "cartella cestino" nascosta !
Immagine - AROS One Home Site - AfA One - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 5509
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMG_Novice_Usr » dom dic 26, 2021 12:18 pm

comunque SFS oltre a richiedere un 68020 ha anche bisogno di un OS 3.0 o superiore


Come detto, nel mio A600 fisico ho un kick3.2 vers. 47.96, quindi stiamo parlando della base FW (bios) dell'OS3.2.
L'unico requisito non soddisfatto, per poter usare SFS\00, rimane a questo punto la CPU: ho un 68000, non 68EC020.
Ad ogni modo, l'interrogativo evidenziato da me in grasseto, nel mio post precedente, rimane un mistero ...

...preferisco SFS per tanti motivi, uno tra questi è il tempo di scrittura, con PFS se riavvi subito dopo aver copiato qualcosa,
al riavvio i file copiati non li ritroverai, anche una stringa scritta su un file di testo scompare se riavvii senza aspettare
il giusto tempo e la lucetta lampeggiare che conferma il termine della copiature o di un salvataggio.


Facciamo un esempio:
abbiamo 2 A1200 identici, stesso HW insomma (stessa CPU 68020, stesso kick3.1), e su ciascun A1200 abbiamo lo stesso OS, supponiamo OS3.1.
Insomma, due macchine identiche.
Sulla prima A1200 abbiamo il filesystem PFS3AIO (con il quale abbiamo inizializzato e formattato l'unica partizione bootable DH0, nella quale è installato OS3.1), sulla seconda A1200 abbiamo il filesystem SFS\00 (con il quale abbiamo inizializzato e formattato l'unica partizione bootable DH0, nella quale è installato OS3.1).
Supponiamo adesso che su entrambe le A1200 noi ci accingiamo a scrivere lo stesso identico file su CF, un file di testo, con Notepad per esempio.
Ebbene, mi stai dicendo che la prima A1200 ci mette più tempo a compiere fisicamente tale scrittura, a causa della lentezza di PFS3AIO, invece la seconda A1200, essendo SFS\00 più veloce nell'accedere R/W al disco, è più veloce, quindi meno immune a mancate scritture, se riavvio il sistema appena dopo la scrittura.

Ti dico la verità, io a sentimento avrei detto il contrario, poichè è noto che PFS3AIO non è journaled, mentre invece SFS\00 lo è.

SFS\00, essendo journaled, ha il vantaggio di essere abbastanza immune alla corruzione del filesystem stesso, in quanto i metadati dei files gestiti su disco godono del supporto del file di rollback, file speciale dove il sistema, prima di effettuare un'operazione di scrittura su un file su disco, registra questa "dichiarazione di intenti" sul file di rollback, dopo di chè effettivamente compie la scrittura. Alla fine della scrittura, il sistema registra su file di rollback che l'operazione di scrittura è andata a buon fine, ovvero che la precedente "dichiarazione di intenti" ha avuto felice seguito/esito.

Se dopo la dichiarazione di intenti su rollback, abbiamo un repentino riavvio (o spegnimento, o qualsiasi problema sul disco), la scrittura effettiva su disco fallisce, e quando il sistema si riavvia, valuta il file di rollback, vede che c'è una dichiarazione di intenti non seguita dalla dichiarazione "operazione OK", pertanto il sistema può ripristinare l'integrità del filesystem.

Il journaling appena esposto è bello perchè preserva l'integrità del filesystem, e credo quindi del disco stesso, insomma il sistema con SFS\00 montato non dovrebbe sputtanarsi facilmente (confermami se ho capito le cose), ma la gestione del journaling stesso richiede sicuramente un delta_tempo aggiuntivo non trascurabile, ovvero ogni volta che scriviamo un file su disco, dobbiamo mettere in conto un dt = qualche ms in più rispetto ad un filesystem privo di journaling, come ad esempio PFS3AIO.
Dico pochi ms, poichè SFS\00 applica il journaling solo sui metadati, non sui dati (c'è solo un caso in cui il journaling è applicato anche ai dati, ovvero durante la deframmentazione automatica che il sistema compie autonomamente in background).

Insomma, SFS\00 è molto sicuro, in quanto journaled, ma "lento".

PFS3AIO non è sicuro, in quanto NON journaled, quindi più esposto a corruzioni, però più veloce a leggere da/scrivere su disco.

Di buono, ma questo è presente anche su SFS, a differenza di OFS e FFS puoi recuperare un file cancellato anche più
volte attraverso una Shell o meglio da un Filemanager, per fare questo basta richiamare il nome della "cartella cestino" nascosta !


Qui non ho capito.
Stai dicendo che con PFS3AIO o SFS\00, se io batto da shell/cli:
DELETE mio_file.txt
mio_file.txt non è perso per sempre, ma è possibile recuperarlo in qualche modo?

richiamare il nome della "cartella cestino" nascosta !


Puoi chiarire meglio? Non ho capito ...
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 271
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMIGASYSTEM » dom dic 26, 2021 1:38 pm

AMG_Novice_Usr ha scritto:Come detto, nel mio A600 fisico ho un kick3.2 vers. 47.96, quindi stiamo parlando della base FW (bios) dell'OS3.2.
L'unico requisito non soddisfatto, per poter usare SFS\00, rimane a questo punto la CPU: ho un 68000, non 68EC020.
Ad ogni modo, l'interrogativo evidenziato da me in grasseto, nel mio post precedente, rimane un mistero ...

Il solo Kick 3.2 non dice niente, occorre installare un OS 3.x altrimenti il Filesystem SFS non è riconosciuto, nessun mistero anche Windows va in panico o addirittura in Blocco quando forzi di leggere un Floppy formattato Amiga o di altra piattaforma, va in blocco anche quando il Floppy è illegibile o vergine se tenti di aprirlo cose che Invece Amiga legge e da un codice errore come è successo a te con la partizione non supportata.

Ebbene, mi stai dicendo che la prima A1200 ci mette più tempo a compiere fisicamente tale scrittura, a causa della lentezza di PFS3AIO, invece la seconda A1200, essendo SFS\00 più veloce nell'accedere R/W al disco, è più veloce, quindi meno immune a mancate scritture, se riavvio il sistema appena dopo la scrittura.

Riguardo la velocità è l'esatto contrario PFS è più veloce di SFS e supeeeer veloce se lo utilizzi per i floppy (che non saranno bootable), il problema da me citato è dato dal fatto che PFS proprio per velocizzare usa una sorta di buffer di scrittura nella cache e che poi scrive entro una decina di secondi, fai qualche prova e poi magari ti renderai conto di quello che dico.

Ti dico la verità, io a sentimento avrei detto il contrario, poichè è noto che PFS3AIO non è journaled, mentre invece SFS\00 lo è.

Infatti come detto è il più veloce dei Filesystem Amiga

SFS\00, essendo journaled, ha il vantaggio di essere abbastanza immune alla corruzione del filesystem stesso, in quanto i metadati dei files gestiti su disco godono del supporto del file di rollback

Si rarissimamente si invalida e quando lo fa difficilmente recuperi perchè non ci sono strumenti per fixare o recuterare i dati PFS invece ha questi strumenti.

Riguardo SFS aggiungo che per AROS in questi ultimi tempi è uscito un software per intervenire qualora accadesse qualcosa su partizioni SFS, il software si chiama arSFSDoctor

Il journaling appena esposto è bello perchè preserva l'integrità del filesystem, e credo quindi del disco stesso, insomma il sistema con SFS\00 montato non dovrebbe sputtanarsi facilmente (confermami se ho capito le cose)

Su WinUAE uso da più di 20 anni SFS su tutti i miei sistemi è non ho mai avuto una invalidazione, quindi direi che è molto difficile che possa accadere, con PFS2 sul mio a 4000/060 capitava ogni tanto ma un piccolo comando PFS che avevo in testa alla startup-sequence fixava al volo riavviando il sistema senza più alcun problema.

Insomma, SFS\00 è molto sicuro, in quanto journaled, ma "lento".

Si ma di poco, io come detto lo preferisco su tutti !

PFS3AIO non è sicuro, in quanto NON journaled, quindi più esposto a corruzioni, però più veloce a leggere da/scrivere su disco.


Qui non ho capito.
Stai dicendo che con PFS3AIO o SFS\00, se io batto da shell/cli:
DELETE mio_file.txt
mio_file.txt non è perso per sempre, ma è possibile recuperarlo in qualche modo?

No ancora meglio, non un solo file, ma tutti gli ultimi file eliminat, è una directory di una certa grandezza che si aggiorna automaticamente aggiungendo i nuovi file cancellati eliminando i più vecchi.

Qui SFS ha un punto in più rispetto a PFS, in pratica può eliminare definitivamente i file recuperati da questa cartella, PFS non può eliminarli perchè protetti da scrittura, l'utente non può modificare il flag di sola lettura

Poi chiarire meglio? Non ho capito ...

Sapevo che ti saresti incuriosito, si tratta di due parloline magiche che hanno un nome diverso per i due Filesystem, allego uno screenshot dove su AfA One (SFS) mostro i file della .deldir mentre su ARS One 68k (PFS) mostro i file nella .recycled

Su PFS devi rinominare i file eliminando l'estensione aggiunta, su SFS invece il nome file è uguale a quello eliminato
Allegati
SFS-Undelete.jpg
PFS-Undelete.jpg
Immagine - AROS One Home Site - AfA One - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 5509
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMG_Novice_Usr » lun dic 27, 2021 6:09 pm

Il solo Kick 3.2 non dice niente, occorre installare un OS 3.x altrimenti il Filesystem SFS non è riconosciuto


Ho anche provato ad installare OS3.2 sulla partizione UDH1, inizializzata e formattata in SFS\00 anzichè con PFS3AIO, ma su A600 reale basico ottengo lo stesso risultato, ovvero impallamento di Amiga, che si offende se le esponi una partizione bootable a bassa priorità, con un filesystem non compatibile (incompatibile con la CPU), quando poi però le esponi anche una partizione bootable ad alta priorità e con PFS3AIO, quindi un filesystem supportato ... vabbene ... ogni sistema ha i suoi giusti limiti, nessun problema ... pertanto è appurato che il problema è la CPU, 68000 e non 68EC020.

Il limite comunque c'è: se avessi scritto io il FW del kick3.2, come caratteristica fondamentale avrei previsto/implementato il seguente principio generale:

se abbiamo una partizione/volume dove ci sono problemi di visibilità, es: filesystem non supportato, magari con l'ausilio di un timer di watchdog, se entro un certo timeout il sistema non riesce a risolvere e montare la partizione, questa viene disabilitata (esattamente lo stesso procedimento che invece funziona, se passiamo attraverso il boot-manager "Amiga Early Startup Control"), dunque procediamo a tentare il bootstrap da una partizione, se esiste, bootable e con filesystem noto, cosa che nel mio caso c'è, ovvero UDH0, ad alta priorità, e con PFS3AIO.

PFS proprio per velocizzare usa una sorta di buffer di scrittura nella cache e che poi scrive entro una decina di secondi


è possibile imporre a PFS3AIO un comportamento stile "sync", o per meglio dire "fflush"?
O per lo meno diminuire la size di questo buffer di cache, così da migliorare/costringere le prestazioni realtime di effettiva scrittura su disco ...
Voglio dire, possiamo rinunciare a questo buffer di cache, che inganna l'utente?

Preferisco aspettare qualche secondo, ma avere la certezza che dopo quei N secondi (pochi), l'informazione è stata compiutamente scritta sulla memoria di massa in questione ...

(PFS) mostro i file nella .recycled


Appena posso faccio qualche prova e ti faccio sapere!
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 271
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: interfacciare OS3.9/HDToolBox con partizione 0x76 su CF

Messaggioda AMIGASYSTEM » lun dic 27, 2021 6:46 pm

AMG_Novice_Usr ha scritto:
è possibile imporre a PFS3AIO un comportamento stile "sync", o per meglio dire "fflush"?
O per lo meno diminuire la size di questo buffer di cache, così da migliorare/costringere le prestazioni realtime di effettiva scrittura su disco ...
Voglio dire, possiamo rinunciare a questo buffer di cache, che inganna l'utente?

PFS era un software Commerciale poi diventato software libero, PFS3AIO è la versione aggiornata ancora in sviluppo da parte di Toni Willen autore di WinUAE, potresti chiedere a lui, nel link allegato trovi la sua ultima recensione con tanti interventi interessanti su questo File System.

https://eab.abime.net/showthread.php?t=90778


P.S. i floppy IPF non possono essere copiati in nessun modo salvo tu non abbia una attrezzatura adeguata, uno dei motivi e che i file contenuti richiedono un floppy di molto superiore ad una capacità che normalmente abbiamo su un floppy ! a questo aggiungi protezioni fisiche o software !
Immagine - AROS One Home Site - AfA One - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 5509
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Precedente

Torna a Amiga OS Classic (1.x-3.x)

Chi c’è in linea

Visitano il forum: Nessuno e 1 ospite

cron