Buongiorno,
ho di recente ripreso in mano un A1200 fisico.
L’A1200 in questione aveva il seguente materiale a bordo:
Release dello stampato madre: 1.D4
CPU = 68EC020;
Nessuna U0 = FPU 68881 a mordo (pinout presente, chip FPU non montato);
2MB di chip-ram;
Scheda A1208 in botola, quindi 8MB di fast-ram;
CF SanDisk Ultra 30MB/s da 4GB su IDE-44 interno che funge da HDD di sistema, dal quale fare il bootstrap;
DF0, DF1 e DF2 presenti;
Fino a qui abbiamo un A1200 leggermente espanso, ma nulla di chè … si può dire un A1200 di fatto “liscio”, very classic …
I minestroni in Amiga sono pericolosi, tuttavia solo per curiosità ho voluto provare a sostituire il nativo kick 3.0 vers. 39.106 con il nuovo kick 3.2 fisico, vers. 47.96, acquistato (anzi, acquistati, parte High e parte Low) insieme al CD-ROM di OS3.2.
Domanda 1:
nel CD-ROM trovo, ad esempio per A1200, sia il kick.rom di 512KB (credo che sia equivalente al contenuto della parte high sommata a quella low che ho fisicamente nei 2 chip fisici che mi hanno spedito … giusto?) sia i files:
a1200high.bin
a1200low.bin
Cosa sono esattamente questi due files? Che differenza c’è fra questi 2 files.bin, ciascuno di 512KB, ed il singolo file a1200.rom da 512KB? Nell’A1200 emulato che sta per entrare in scena, ho dato come file di ROM-kick proprio il singolo file a1200.rom da 512KB, però mi chiedo il ruolo giocato da a1200high.bin e a1200low.bin …
Su WinUAE (PC/Windows, adattatore USB - CF) mi sono preparato la CF nel seguente modo:
UDH0 – boot priority = 0 – filesystem SFS\00 – OS3.9 + BB1 + BB2
UDH1 – boot priority = -1 – filesystem SFS\00 – OS3.2 + update 3.2.1
UDH2 – boot priority = -2 – filesystem SFS\00 – OS3.1
Su WinUAE tutto funziona alla perfezione, nessun impallamento, mai visto un crash, mai una guru … tutto come da manuale!
Ho in realtà un dubbio anche qui, che riguarda il bootstrap.
Se all’avvio di questo A1200 EMULATO io vado sul boot-manager (Amiga Early StartUp Control) e vado nella sezione “boot”, dopodichè a sinistra, dove abbiamo “select boot device” … ebbene … se qui seleziono UDH0 (ovvero il device bootable di default, per le priorità da me assegnate in fase di preparazione della CF tramite HDToolBox), oppure se qui seleziono UDH2, al riavvio vedo effettivamente che il boot-manager ha lavorato come ci si aspetterebbe, quindi ottengo il boot dall’OS selezionato.
Tra le altre cose, il risultato lo vedo anche quando lancio una cli/shell, dal prompt, che in un caso è UDH0, in un altro UDH2.
Se invece in boot select device seleziono UDH1, invece lì ho dei problemi: ci sono stati giorni in cui ho tranquillamente avuto il boot, come ci si aspetterebbe, dall’OS 3.2, quindi da UDH1, ma ultimamente, nelle ultime prove fatte intendo, NON sono più riuscito a bootare da UDH1, ma riesco solo da UDH0 e UDH1 … adesso non so dire se l’impossibilità di bootare da UDH1/OS3.2 su A1200 emulato su WinUAE sia successiva all’installazione dell’update 3.2.1 … non so se le cose sono correlabili.
Domanda 2:
Come mai questo strano comportamento?
L’A1200 EMULATO (a quello fisico ancora non ci sono arrivato) è, secondo me, equivalente (CPU, RAM, ecc …) a quello fisico, stessa CF (sto testando infatti la CF, prima di portarla su A1200 fisico).
Se qualcuno è interessato ad aiutarmi, posso mandare in PM links a:
-configurazione.uae adottata da me per cercare di emulare il più fedelmente possibile l’A1200 fisico sopra descritto, così potete vedere se le spunte di configurazione vanno bene;
-immagine.hdf della CF in questione.
Ad ogni modo, al di là di questa stranezza, tutto il resto sembra funzionare bene su WinUAE, pertanto mi appresto a portare la CF su A1200 fisico … e qui cominciano i veri problemi!
È difficile e sarebbe lunghissimo riportare tutte le prove fatte, ad ogni modo la sostanza è questa: il sistema sembra MOLTO instabile.
Al primo avvio da freddo, OS3.9 parte, compare correttamente tutto il desktop, compreso il menù in basso con le utilities come Amplifier, ecc …
Inizio a navigare un po' nei drawers, setto le prefs che mi interessano … molto poche, giusto la seriale, l’accelerazione del puntatore, la keymap, i colori in screenmode, che da 4 di default li porto a 128 oppure a 64 per non esagerare (tanto ho visto che il consumo di ram in fast è irrisorio, in chip-ram un po' più rilevante, in quest’ultimo caso infatti passo da 2MB a 1.6MB circa … ma insomma, credo di potermelo permettere), e poi verifico che in:
Sys: RamDisk\Env\Sys
Siano comparsi i data-projects del tipo:
screenmode.prefs
inputs.prefs
locale.prefs
serial.prefs
ecc …
tutti data/projects prodotti dal Tool “Prefs” la cui GUI io ho appena usato per settare quelle poche preferenze di mio interesse, sopra citate.
Domanda 3 (molto meno prioritaria delle altre, ma ormai ci sono e quindi la faccio):
ho notato che in DefaultTool di ciascuna icona di:
screenmode.prefs
inputs.prefs
locale.prefs
serial.prefs
io trovo:
Sistem: Prefs\Pointer
Secondo me non è corretto, poiché il tool “Prefs\Pointer” dovrebbe essere il DefaultTool/il programma che ha generato, editato e salvato il progetto (i dati) chiamato “pointer.prefs”, ma non il DefaultTool anche degli altri data/projects:
il DefaultTool di screenmode.prefs (con il quale ho customizzato la risoluzione, il numero di colori, l’eventuale auto-scrolling ecc …) dovrebbe essere:
Sistem: Prefs\ScreenMode
il DefaultTool di serial.prefs (con il quale ho customizzato il baudrate, l’hand-shaking ecc … della porta Rs232) dovrebbe essere:
Sistem: Prefs\Serial
Ecc …
Invece tutti i data/projects.prefs che poi trovo in:
Sys: Ram\Env\Sys
Hanno come DefaultTool il solito, ovvero:
Sistem: Prefs\Pointer
Secondo me, c’è qualcosa che non va … ditemi voi.