WinUAE/OS3.9/HDTB -> CF: MBR + RDB/OS3.2 - successo parziale

Classic, anche retrogaming

WinUAE/OS3.9/HDTB -> CF: MBR + RDB/OS3.2 - successo parziale

Messaggioda AMG_Novice_Usr » ven dic 10, 2021 4:56 pm

Buongiorno,
vorrei spiegarvi l’esperienza che sto portando avanti ultimamente, sperando che qualcuno di voi sia in grado di capire dove si insinua il problema.
Nell’esporre la prendo un tantino larga perché sono i miei primi approcci al mondo WinUAE, pertanto preferisco dirle tutte, per darvi il maggior numero di indizi ed informazioni possibili.

Di WinUAE ho la versione 4.40.
Mi sono procurato l’immagine .iso del CD di OS3.9, con il quale ho aggiornato, su WinUAE, il mio A1200 emulato con Kick3.1. Voglio dire che prima ho creato un System.hdf vuoto, poi dentro a questo HD virtuale ho installato il WB3.1, dopodichè ho applicato, sempre sopra System.hdf + WB3.1, l’aggiornamento OS3.9.
OS3.9 sembra funzionare bene.

//-------------------------------------------------------------------------------------------------------------------------------------

Ho anche aggiornato OS3.9 con BB1 e BB2: quest’ultimo dovrebbe aver portato HDToolBox3.9 alla sua ultima e più avanzata versione.
Il mio interesse per OS3.9 è finalizzato all’utilizzo del suo HDToolBox, poiché in molti mi hanno garantito che HDToolBox3.9 è assai più avanzato degli HDToolBox che ho utilizzato io fino ad ora (HDToolBox2.1, 3.1, 3.2).

Quello che ho cercato di fare, e alla fine credo di esserci riuscito da solo (senza seguire alcuna guida), è di utilizzare HDToolBox3.9 per preparare una CF by SanDisk da 4GB (3.7GB, per l’esattezza), CF in cui abbiamo l’MBR con tanto di tabella delle 4 partizioni primarie, che punta a 2 partizioni che coesistono tranquillamente su questa CF: una prima partizione M in FAT32 di circa 2.4GB, fruibile quindi da un PC/Windows (con questa partizione posso fare lo scambio dati fra PC e Amiga) ed una seconda partizione X di circa 1.3GB, che ho suddiviso in 2 sotto-partizioni, GDH0 e GDH1, entrambe bootable, dove in GDH0 ho installato OS3.2, con GDH0 di priorità superiore rispetto a GHD1 (priorità di GDH0 = 0, priorità di GDH1 = -1).

//-------------------------------------------------------------------------------------------------------------------------------------

Questo lavoro, ovvero preparare una CF in cui abbiamo sia l’MBR sul settore 0, ovvero il primo settore fisico della CF, sia l’RDB su un altro settore, quindi avere una CF visibile sia da un PC/Windows che da Amiga, l’avevo inizialmente tentato con versioni vetuste di HDToolBox, ovvero 2.1 e 3.1.

Creavo, su Windows, con i soliti programmi di partition-management, una prima partizione M con ID = 0x0B, quindi FAT32, poi una seconda partizione non formattata, quindi RAW, con ID = 0x76, poi rigeneravo l’MBR, in modo che l’MBR della CF avesse nei primi 446 bytes una sorta di boot-manager (per me non necessario, dato che non ho intenzione al momento di mettere una versione di Windows, tipo WindowsNT nella partizione M, quindi non ho bisogno di un boot manager che mi consenta di scegliere se caricare un kernel piuttosto che un altro) e nei successivi ed ultimi 64 bytes dell’MBR i descrittori delle 4 partizioni primarie. Fra questi 4 descrittori (tabella delle partizioni) abbiamo il primo che punta alla prima partizione, ovvero quella in FAT32 (ID = 0x0B), mentre il secondo descrittore (il secondo elemento della tabella) punta alla partizione con ID = 0x76, quindi la partizione che vorrei dare in pasto a HDToolBox.

Quando usavo gli HDToolBox vetusti, avevo il problema che questi HDToolBox non selezionavano solo la partizione 0x76 lasciando stare quella 0x0B, bensì sovrascrivevano l’RDB sopra l’MBR, piallando così tutta la CF, che diventava “amigabile”, ma perdendo purtroppo l’MBR la CF non poteva essere più interfacciabile con PC/Windows.

//-------------------------------------------------------------------------------------------------------------------------------------

Questo problema, ovvero l’apparente impossibilità di avere MBR e RDB sulla stessa CF, l’ho risolto con WinUAE + OS3.9:
mentre preparo l’A1200 da emulare, aggiungo con “add hard-disk” il volume X relativo alla partizione 0x76 da “amigare” (partizione da 1.3GB), poi vado sulle proprietà di questo supporto e clicco su “full drive/RDB mode” (questo passaggio è fondamentale per HDToolBox3.9), a questo punto la partizione è pronta per essere gestita da HDToolBox3.9.
Adesso lancio l’A1200 emulato con OS3.9, lancio HDToolBox3.9, poi gli faccio vedere la partizione X da amigare, a questo punto faccio “Install”: se non avessi cliccato in precedenza su “full drive/RDB mode”, Install mi darebbe l’errore “error 7: bad description … …” (eppure la geometria/descrizione dovrebbe essere corretta: è quella auto-rilevata da HDToolBox3.9)

https://drive.google.com/file/d/1IsRvil ... SQb5g/view

//-------------------------------------------------------------------------------------------------------------------------------------

invece da quando ho capito che bisogna cliccare su “full drive/RDB mode” in fase di preparazione degli HD da interfacciare all’Amiga emulato, non ho più avuto quell’errore, pertanto l’installazione va a buon fine, e quindi mi ritrovo correttamente l’RDB (RDSK … ) nel primo settore della partizione X da amigare, che di fatto è già amigata da adesso, e l’MBR nel primo settore della CF non è stato toccato, poiché HDToolBox3.9 è riuscito a lavorare, contrariamente ai suoi antenati, sulla partizione 0x76 e ha fatto tutto lì dentro.
Date un’occhiata a questo prospetto, che riassume il tutto:

https://drive.google.com/file/d/1d3j077 ... FGaUg/view

quindi il bottone Install di HDToolBox3.9 è servito a scrivere l’RDB dentro il settore 0 della partizione con ID = 0x76.

//-------------------------------------------------------------------------------------------------------------------------------------

Adesso che la partizione 0x76 ha il suo RDB, utilizzo sempre HDToolBox3.9, questa volta non come installer di RDB (l’ho già fatto), bensì come partition-editor, pertanto creo dentro quella partizione 2 sotto-partizioni, GDH0 e GDH1, di dimensioni diverse, entrambe bootable, priorità di GDH0 = 0, priorità di GDH1 = -1.
Adesso il mio A1200 emulato con OS3.9 vede sia il supporto M in FAT32, sia GDH0 che GDH1: queste ultime risultano, al momento, come è giusto che sia, not-initialized. Le inizializzo, nel senso che le formatto in modalità quick con FFS. Adesso GDH0 e GDH1 sono pronte.
Adesso in GDH0 installo OS3.2, e tutto sembra andare a buon fine.
L’installazione di OS3.2 la faccio direttamente su WinUAE + OS3.9 (A1200 emulato), avendo a disposizione tutti gli adf di OS3.2.
Ecco la foto conclusiva:

https://drive.google.com/file/d/10w_zlN ... YrLLd/view

come si vede, abbiamo OS3.2 in GDH0.

//-------------------------------------------------------------------------------------------------------------------------------------

Qui voglio segnalare un apparente bug di WinUAE + OS3.9 (sottolineo “apparente”, poiché magari sono io che sbaglio qualcosa).
Se riavvio A1200 emulato, la prima volta, al riavvio appunto, NON vedo le partizioni M (FAT32), GDH0 (con dentro OS3.2) e GDH1 (vuoto, con solo il cestino dentro). Se adesso riavvio nuovamente, al riavvio di A1200 emulato VEDO finalmente M, GDH0 e GDH1. Se riavvio ancora, non le vedo, se poi riavvio nuovamente le vedo, ecc …
In buona sostanza, si va ad intermittenza: ad ogni riavvio, una volta le vedo, la successiva no.
Perché??

//-------------------------------------------------------------------------------------------------------------------------------------

Arrivo adesso al nocciolo della questione.
Adesso che ho installato OS3.2 su GDH0, preparo un A600 emulato su WinUAE, con la configurazione identica a quella di un mio A600 fisico, ovvero 68K + 2MB di chip-ram (1MB nativo + 1MB in trap-door). Come kickstart di questo A600 emulato, gli assegno il kick.rom 3.2 vers. 47.96, ovvero il kick 3.2 by Hyperion, ovvero il nuovo kick che ho messo fisicamente nel mio A600 reale al posto del nativo 37.350.
Una volta preparato questo A600 emulato, prima di lanciarlo gli do in pasto la CF preparata in precedenza: una volta lanciato, vedo che correttamente l’A600 emulato fa bootstrap da GDH0, dove trova OS3.2, il quale, seppur un po' lentamente (a causa del 68K e della poca RAM a disposizione), funziona perfettamente:

https://drive.google.com/file/d/1jIvtzU ... NibI4/view

//-------------------------------------------------------------------------------------------------------------------------------------

Per riprova, adesso rimuovo la partizione amigosa sulla CF, riavvio A600 emulato, e correttamente compare questo:

https://drive.google.com/file/d/1aL9qkV ... nnDzf/view
https://drive.google.com/file/d/1ie2AdO ... SGuOk/view

Segnalo l’apparente bug di WinUAE, precedentemente riportato, anche in questo caso, ovvero A600 emulato con kick 47.96 + 2MB ram + 68K + partizione 1.4GB in CF con dentro OS3.2: riavvio, e la partizione OS3.2 sulla CF viene vista e montata, e infatti OS3.2 parte, poi riavvio, e qualcosa va storto, la partizione OS3.2 non viene vista, quindi compare lo sfondo viola del kick 3.2 v. 47.96, allora riavvio ancora, e questa volta la CF viene vista e OS3.2 viene eseguito, ecc … ad intermittenza.
Perché il boot funziona una volta si ed una volta no?

//-------------------------------------------------------------------------------------------------------------------------------------

Ultima stranezza (la più importante):

seppur una volta si ed una no, WinUAE + A600 emulato hanno dimostrato che la mia CF con coesistenza di MBR e RDB funziona, quindi ho una partizione M in FAT32 e due partizioni GHD0 e GHD1 dentro la partizione X, con dentro l’RDB, ecc …
fin qui, tutto ok.

Adesso prendo la CF e la monto sulla porta IDE-44 del mio A600 reale, che ha la stessa identica configurazione dell’A600 emulato su WinUAE: 68K, 2MB di ram totale, kick 3.2 vers. 47.96. Ebbene:
su A600 reale, il boot di OS3.2 non funziona mai! Eppure sull’analogo A600 emulato, seppur un riavvio si ed uno no, tale boot funziona.
Come mai?
Sull’A600 reale, ad ogni riavvio, vedo sempre lo sfondo viola con schermata del kick 3.2 by Hyperion, segno che la CF ed in particolare la partizione bootable GDH0, con dentro OS3.2, non è stata vista …
L’adapter CF/IDE44 funziona bene, già provato infinite volte.

Ho provato a ripetere l’installazione di OS3.2 su GDH0 sia dando in pasto alla wizard install (dentro Install3.2.adf) il floppy modules_a1200.adf (perché sto operando l’installazione da un A1200 emulato con OS3.9, ma credo qui di aver sbagliato: i modules devono essere quelli del sistema target, non di quello host), sia il floppy modules_a600.adf (credo che sia giusto così, perché il mio target sarà proprio un A600, prima emulato, poi fisico). Il risultato non cambia.

Cosa potrebbe essere??
Avatar utente
AMG_Novice_Usr

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

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

Chi c’è in linea

Visitano il forum: Nessuno e 7 ospiti

cron