A1200 – problemi vari (instabilità) e relative domande

Classic, anche retrogaming

A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 06, 2022 10:42 pm

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

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 06, 2022 10:45 pm

Torniamo alle cose più importanti.

Dicevo che al primo avvio da freddo di A1200 fisico, OS3.9 parte e sembra funzionare discretamente, soprattutto in termini di velocità, nel senso che l’esperienza di navigazione fra i drawers risulta veloce e piacevole, persino con 256 colori, tuttavia succede che ad un certo punto, magari sto per aprire un drawer, apparentemente tranquillo, intendo “Devs”, piuttosto che “Storage”, piuttosto che T: in RAM: … la cosa è stocastica … fatto sta che ad un certo punto della navigazione nel filesystem, A1200 fisico gurizza (ripeto, non gurizza nel lanciare un’applicazione particolarmente pesante, ma aprendo un drawer), e da questo momento in poi diventa praticamente inutilizzabile.

Intendo dire che da questa guru in poi, schiacciando il tasto sinistro del mouse, come richiesto dal messaggio di guru, non si ottiene MAI (questa cosa è sistematica, deterministica) un corretto riavvio da un volume bootable, né da UDH0 (OS3.9), né da UDH1 (OS3.2), né dal più leggero UDH2 (OS3.1).

Per ottenere di nuovo la fruibilità di A1200 fisico, occorre tenerlo spento per minuti e minuti, dopodichè torna ad essere un po' utilizzabile.

Domanda/questione 4:

Ma da quando rigurizza nuovamente, ecco che bisogna ri-attendere questo “tempo di raffreddamento”: scarica di qualche condensatore? … scarica dei condensatorini microelettronici interni a U16, U17, U18, U18, ovvero la DRAM da 2MB sul PCB? Qualche altra motivazione HW? Oppure FW (colpa del nuovo kick3.2)? Non so …

Due anni fa questo A1200 mi venne venduto come ricappato completamente (c’è modo di esserne abbastanza certi, piuttosto che essere sicuri del contrario?).

Vi basti pensare, per esempio, che ieri sera, nonostante io spegnessi, lasciassi riposare A1200 fisico per 20 secondi, 1 minuto, o anche svariati minuti, poi riaccendevo, ma il sistema durava poco, prima di tornare in guru.

Stamattina, quindi dopo una notte di riposo, vedevo un funzionamento che nelle prime fasi/primi smanettamenti sul WB sembrava perfetto … poi ovviamente è andato in guru, e da qui in poi la situazione è peggiorata come descritto sopra.


Domanda/questione 5:

Anche quando l’avvio da freddo porta ad un avvio corretto del device di default, ovvero UDH0/OS3.9, vedo che in realtà ho sempre 2 avvii, ossia:

accendo (do potenza), il led disco/CF lampeggia, poi dopo qualche secondo il led power verde fa un blinking, segno che la CPU viene resettata, abbiamo quindi un secondo avvio (nested nel primo), adesso il led disco/CF torna in attività, ed ecco che parte OS3.9 (quando parte …).

è normale?
La cosa è sistematica.

Un’interpretazione me la sono data, ovvero al primo avvio, dopo il POST (cioè dopo il test anche della chip-ram), i moduli del kick che servono vengono copiati dalla ROM-kick fisica alla DRAM interna (i 2MB di chip-ram), poi il kick stesso, adesso in ram, va a fare bootstrap da UDH0/OS3.9, e da qui prima di tutto preleva i moduli con i quali aggiornare quelli già residenti in ram, provenienti dal kick-ROM fisico, quindi avviene una specie di SetPatch, dopodichè il FW stesso, a patching finita, riavvia (un auto-POR reset, diciamo, come avviene in tanti microcontrollori) il sistema, quindi siamo arrivati al secondo avvio, lanciato automaticamente dal primo, e in questo secondo avvio il sistema trova già in chip-ram dei moduli di kick patchati dal primo avvio (la patch è stata presa da UDH0/OS3.9), pertanto il kick in ram è già a posto, già patchato, è quello che deve essere, quindi adesso il sistema può lanciare definitivamente OS3.9 da UDH0 …

Questo secondo avvio si verifica anche se disabilito in Amiga Early StartUp Control la spunta “Update ROM Modules”.


Domanda 6:

Approfitto per chiedervi dei chiarimenti relativi a queste 3 voci di Amiga Early StartUp Control del kick 3.2:

-Disable CPU caches
-Update ROM Modules
-Failsafe boot

Cosa vogliono dire esattamente?


Domanda/questione 7:

Volevo escludere problemi della CF, quindi ho ripreso un HDD a tracce, un Toshiba da 40GB, 2.5 pollici, porta PATA/IDE33, ovvero l’HDD che trovai nell’A1200 fisico all’acquisto, HDD che ha sempre funzionato perfettamente … ci avevo installato CWB, WB3.0 e altri, e con il nativo kick3.0 il sistema, con questo HDD a tracce, ha sempre funzionato perfettamente, sempre stabilmente, facendoci anche cose un po' più spinte/pesanti, come ad esempio la navigazione online con PLipBOx (MUI3.8, AmiSSL per i certificati per https, AmiTCP per lo stack, IBrowse per navigare).

In questo HDD ho installato quanto segue:

DH0 – boot priority = -1 – filesystem SFS\00 – OS3.2 (SENZA update 3.2.1)
DH1 – boot priority = -2 – filesystem SFS\00 – OS3.1

Non ho previsto di installare al momento OS3.9, in quanto non ho un lettore CD su A1200 fisico e non ho neppure un adattatore IDE-44 da 2.5pollici – USB : avevo pensato, se le cose andavano lisce con OS3.2 su questo HDD classico, di montare la OS39.iso con DiskImageGUI, e da qui tentare un’installazione … ma lasciamo stare tutto per il momento … andiamo avanti con OS3.2.

Ho fatto le stesse prove fatte con la CF di cui sopra anche con questo HDD a tracce … e ho avuto gli stessi problemi osservati con la CF.
In sostanza, molta instabilità.
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 06, 2022 10:49 pm

Alla prima accensione la mattina, iniziamo molto bene, OS3.2 sembra solido, poi apro un drawer, gurizza senza un apparente motivo, da questa prima guru in poi andiamo peggiorando, devo attendere minuti prima di riottenere un pseudo-funzionamento.

Avviando da Amiga Early StartUp Control sia DH0 che DH1, osservo molta instabilità, grande facilità di mandare il sistema in guru.
Faccio notare che anche se disabilito DH0/OS3.2, lascio abilitato quindi solo DH1/OS3.1 e faccio boot da DH1, anche in questo caso dopo l’avvio del WB3.1, basta navigare attraverso pochi drawer per mandare in guru l’A1200 fisico.

Questione 8:

Notare che il “raffreddamento”, che più lungo è e meglio è, è necessario solo per i WBs (3.9, 3.2, 3.1 … ), se invece faccio bootstrap da DF0 con un gioco (ho provato solo Chaos Engine), il boot da floppy funziona sempre e perfettamente, anche senza un riavvio a freddo, ma semplicemente a caldo con CTRL+A+A … non sbaglia mai, non va mai in guru, il gioco funziona sempre, nonostante il kick3.2 …


Domanda/questione 9:

Non sembra funzionare più la lettura delle CF su PCMCIA.
Non funziona più né se faccio boot da DH0/OS3.2, né se faccio boot da DH1/OS3.1.
In entrambi i volumi ho verificato che ho installato da script (IconX) tutto correttamente, ovvero:

in Devs/DosDrivers:

ho l’icona CF0 con DefaultTool: C: Mount

in Devs: ritrovo correttamente :

compactflash.device

in L : ritrovo l’handler per filesystem per Win95/98 (FAT12/16/32):

fat95

insomma … ho tutto, e tutto nel posto giusto … ma fatto sta che ho perso la possibilità di interfacciare A1200 fisico con CF su PCMCIA.
Come mai? È colpa del kick3.2? (mi sembra strano/impossibile …)

Alla fine il “minestrone” non è poi così colorato: il kick3.2 è venduto compatibile con 68EC020 e ho complessivamente 10MB di ram, e l’instabilità si ha sia su una CF che ha sempre funzionato sia con un HDD a tracce che ha sempre funzionato.
Quindi, alla fine, di che minestrone stiamo parlando? È tutta roba classic, che dovrebbe essere compatibile con il mondo A1200.


Questione 10:

Se adesso tolgo il kick3.2 fisico e rimetto il nativo kick3.0, non solo rivedo la CF in PCMCIA, ma non riesco più a mandare in guru A1200 fisico, neppure se mi impegno ... il sistema diventa stabilissimo, quindi l’HW funziona!

Conclusione:

si vede che nel mio A1200 il kick3.2 non si sta comportando bene …

Domanda 11:

C’è qualcosa che posso fare per utilizzare in questo A1200 fisico l’OS3.2? Magari passando ad un kick3.1? è possibile usare OS3.2 con il kick ROM fisico 3.1? Ho già verificato che con kick 3.0 non è possibile (ottengo lo schermo giallo).
C’è qualcosa, a livello magari di prefs oppure di startup-sequence, che posso modificare, per ottenere maggiore stabilità, usando il kick 3.2 + OS3.2?

Nota finale:

se qualcuno ha voglia di cimentarsi, posso fornire ulteriori dettagli e fare altre prove mirate, tempo permettendo …
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMIGASYSTEM » dom feb 06, 2022 11:29 pm

Intanto se dobbiamo risolvere qualche problema parliamo solo di WinUAE, gli Amiga Reali ormai vetusti posso avere mille problemi hardware e causare duemila strani errori dove è davvero difficile individuare la vera causa.

DH0, DH1, DH2 etc... tutti posso avviarsi, se questo non avviene c'è qualche problema nelle partizioni o qualche conflitto fra OS.

Il termine "data-project" non appartine al linguaggio Amiga :felice:

Le icone dei settaggi prefs "non sono reali" hanno tutti settato nel Tooltypes "Sistem:Prefs/Pointer" perchè nel sistema tutti i file con esensione .prefs viene assegnata la medesima icona con un medesimo comando, l'autore ha settato il comando che spetterebbe solo ad una preferenza pointer, quindi le altre sono tutte sbagliate.

Se si vuole renedere le icone reali e magari utilizzare per cambiare i settaggi al volo bisognerà assegnera il giusto tools e salvare, in questo modo l'icona diventa "reale", lo strumento da usare sarà quello predefinito per tipologia, per esempio allo screenmode.prefs lo strumento da assegnare sarà SYS:Prefs/Screenmode.


- Disable CPU caches - > lo dice la parola
- Update ROM Modules -> aggiorna la rom attraverso i moduli se presenti
- Failsafe boot -> una sorta di modalità provvisoria


Riguardo l'avvio di OS 3.2 con Kickstart 3.1 questo è possibbilissimo ma in questo caso dovrai installare anche i "moduli" che permetteranno di aggiornare il Kickstart via software, ma alla fine non cambierà nulla, se guru avevi con il Kickstart Fisico stessa cosa accadrà con la mappatura software, anzi sarà peggio perchè avrai meno RAM disponibile.

In ogni caso se non hai problemi Hardware è possibile che i Guru siano dati da qualche piccolo minestrone software, su OS 3.2 molte librerie o applicazioni degli OS precedenti possono causare crash, cosa che succede su tutti gli OS del Mondo.

Riguardo la CF su PCMCIA potrebbe essere la RAM, leggi il thread allegato dove troverai un chiarimento anche da parte di uno sviluppatore di OS 3.2

https://eab.abime.net/showthread.php?t=107279
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: 5513
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » sab feb 12, 2022 6:27 pm

DH0, DH1, DH2 etc... tutti posso avviarsi, se questo non avviene c'è qualche problema nelle partizioni o qualche conflitto fra OS.


Premetto/confesso tutta la mia ignoranza sull'argomento ... mi scurerete se provo comunque ad emergere dal mio stagno si rane :-)

Le partizioni dovrebbero essere dei compartimenti a tenuta stagna, pertanto se il kick avvia dalla partizione 1, con sopra l'OS1, piuttosto che dalla partizione 2, dove risiede l'OS2, se il bootstrap avvenisse "come ci si aspetterebbe", i due avvii dovrebbero essere ortogonali, ovvero due mondi separati, librerie e moduli vari di sistema dovrebbero essere prelevati e resi residenti in RAM unicamente dalla partizione su cui il sistema ha fatto bootstrap.

L'unica eventualità, che apprendo dai vari forums, in coincidenza della quale le varie partizioni/devices potrebbero essere NON ortogonali, agli occhi del kickstart avviante, è che io utente, in fase di inizializzazione/formattazione, abbia assegnato a queste partizioni lo stesso nome ... supponiamo "pippo".

Nel concreto:

Supponiamo che al device/partizione DH0 io abbia assegnato come etichetta di volume "pippo", e supponiamo che al device/partizione DH1 io abbia assegnato come etichetta di volume "pippo" (DH0 e DH1 sono 2 partizioni del device HDD oppure CF su porta IDE-44 di un A600 oppure di un A1200): il kickstart (solo il 3.2?? oppure tutti?) NON è in grado di tenere separate le due partizioni, in ragione del fatto che le partizioni in questioni condividono lo stesso nome (e se è davvero così, è grave ... dovrebbe contare il nome di partizione/device, non il nome di volume ... no?), la stessa stringa ASCII, pertanto il kick preleva e rende residenti in ram librerie e moduli di OS-0 e di OS-1 in mixing, creando un minestrone dagli esiti imprevedibili/catastrofici.

Purtroppo (sarebbe stato bello il contrario) questo non è il mio caso, dato che da quando mi occupicchio (ogni tanto) di Amiga (dal 2019 ... ho iniziato tardi), ho sempre dato al volume il nome del device, pertanto:

partizione/device: DH0 - nome del volume: DH0
partizione/device: DH1 - nome del volume: DH1

Quindi nel mio caso i due compartimenti del disco sono davvero ortogonali, agli occhi del kick (correggimi se sbaglio ... non sono esperto, cerco solo di capirci qualcosa).

Inoltre, se a livello di Amiga Early Startup Control, io disabilito una partizione sulla quale ho un OS non molto amico del kick attualmente montato, e seleziono come device da avviare la partizione nella quale abbiamo l'OS nativo/best-friend del kick ... beh, questa dovrebbe essere la prova del 9 ...
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » sab feb 12, 2022 7:21 pm

perchè nel sistema tutti i file con estensione .prefs viene assegnata la medesima icona con un medesimo comando


Insomma ... stile Windows!! :-(

Se seleziono con tasto sinistro del mouse un file in Windows, supponiamo un file/progetto (un file di dati = un file progetto = un file editato da un programma che costituisce un ambiente di sviluppo/di editing), ad esempio un file "pippo.txt", e fin qui Amiga è uguale a Windows, poichè entrambi gli OS hanno previsto la selezione con tasto sinistro del mouse (che per la maggior parte di noi prevede l'indice della mano destra) dell'elemento iconografico prescelto, e se con tasto sinistro del mouse scorro un menù a tendina (qui Amiga OS e Windows sono leggermente diversi, poichè in AmigaOS il click del tasto destro del mouse può avvenire in un qualunque punto dello schermo WB, e se lo faccio si riferisce a quell'icona appena selezionata con tasto sinistro, invece in Windows il click con tasto destro deve essere fatto dentro l'icona di interesse ... se viene fatto fuori da questa, viene selezionato il menù a tendina relativo al desktop, non all'icona stessa) ... dicevo ... se scorrendo questo menù a tendina clicco su "proprietà", poi tab "generale", vedo le voci "tipo di file" e "apri con".

Nel mio esempio, a tutti i files con estensione .txt viene assegnata la medesima icona e soprattutto viene assegnato il medesimo comando/programma/DefaultTool, nel mio esempio "BloccoNote" di Windows.

In questo, sembra tutto uguale fra Windows e AmigaOS3.2/icone.prefs ...

Come tu mi insegni, in questo Windows sembra essere inferiore ad AmigaOS, poichè se in Win rinomino "pippo.txt" in "pippo", ecco che Win mostra uno dei suoi talloni di Achille: "pippo" (decurtato della sua estensione .txt) -> proprietà -> generale -> tipo di file = File (indicazione generica) (non più "Documento di testo.txt" ... è bastato eliminare l'estensione .txt dal nome per impedire a Windows di riconoscere il tipo di file, invece qui Amiga è più robusto ... corretto?), descrizione = <nome del file>, dove il campo "descrizione" ha preso il posto del campo "apri con" ... giustamente .... se Win non riconosce più il tipo di file, non può offrire un'opzione di default circa il DefaultTool con cui aprire quel tipo di file ...
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMIGASYSTEM » sab feb 12, 2022 7:23 pm

AMG_Novice_Usr ha scritto:
Le partizioni dovrebbero essere dei compartimenti a tenuta stagna, pertanto se il kick avvia dalla partizione 1, con sopra l'OS1, piuttosto che dalla partizione 2, dove risiede l'OS2, se il bootstrap avvenisse "come ci si aspetterebbe", i due avvii dovrebbero essere ortogonali, ovvero due mondi separati, librerie e moduli vari di sistema dovrebbero essere prelevati e resi residenti in RAM unicamente dalla partizione su cui il sistema ha fatto bootstrap.

Ogni OS ha il suo comportamento e il suo modo di cercare le cose, per esempio su PC se hai un Floppy o un CD con settori/tracce rovinate Windows non ti permetterà di scrivere o copiare niente da questi dispositivi, questo perchè Windows prma di inziare una qualsiasi operazione deve prima controllare tutto il contenuto e in presenza di errori blocca tutto.

Su Amiga questo non succede sia dai Floppy che dai CD riesci a copiare tutto quello che di "sano" si trova nei due dispositivi senza preoccuparsi dei settori/tracce che contengono dati illegibili.

Fatta questa introduzione sul comportamento degli OS, Amiga OS rispetto a Windows, quando avvia il sistema cerca i suoi file nel percoso più "breve", se noi abbiamo due OS su partizioni diverse e questi OS hanno qualcosa in comune come "nome Volume" o "Nome Partizione", AmigaOS prenderà i suoi file dal primo percorso cher gli capita di leggere e quasi sempre leggerà i dati un po' da uno e un po' dall'altro.

Per evitare tutti i problemi da te citati occorrerà rinominare "sia" i Volumi che le Partizioni, in alcuni casi in presenza di una sola somiglianza basterà eliminare l'avviabilità del volume che va in conflitto.
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: 5513
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » sab feb 12, 2022 7:29 pm

Se si vuole rendere le icone reali e magari utilizzare per cambiare i settaggi al volo bisognerà assegnera il giusto tools e salvare, in questo modo l'icona diventa "reale", lo strumento da usare sarà quello predefinito per tipologia, per esempio allo screenmode.prefs lo strumento da assegnare sarà SYS:Prefs/Screenmode.


Ah ok ... ad esempio se cambio il DefautTool associato all'icona fittizia "serial.prefs" da "SYS:Prefs/Pointer" a "SYS:Prefs/Serial" e poi salvo, ecco che l'icona fittizia diventa reale, e soprattutto, all'atto pratico, ottengo una cosa importante: se clicco due volte tasto sinistro su quell'icona, viene lanciato il corretto tool "Prefs/Serial" ...

Appena posso faccio qualche prova ...
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMIGASYSTEM » sab feb 12, 2022 7:40 pm

AMG_Novice_Usr ha scritto:
Ah ok ... ad esempio se cambio il DefautTool associato all'icona fittizia "serial.prefs" da "SYS:Prefs/Pointer" a "SYS:Prefs/Serial" e poi salvo, ecco che l'icona fittizia diventa reale, e soprattutto, all'atto pratico, ottengo una cosa importante: se clicco due volte tasto sinistro su quell'icona, viene lanciato il corretto tool "Prefs/Serial" ...

Appena posso faccio qualche prova ...


Si puoi fare quello che vuoi su una icona, io per esempio su AfA One e AROS One (Finestre, Sfondi, Puntatore, Fonts ec..), mi sono creato dei piccoli script che consentono di eseguire più Preferenze contemporaneamente tali da modificare il tema completo del Workbench, cose quasi impossibili da fare su Windows con solo qualche avvio di preferenza.


AROS One 68k Cambio Tema Workbench
https://www.youtube.com/watch?v=zSXcGjkbMU4

AfA One Cambio Tema Workbench "a caldo"
https://youtu.be/lXyV1PvkNvo?t=245
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: 5513
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » sab feb 12, 2022 7:48 pm

- Disable CPU caches - > lo dice la parola


La memoria ram cache in questione è dentro la CPU 68K ... giusto? Altrimenti avrebbe poco senso chiedersi se abilitala oppure disabilitarla.

E poi, credo che sia una cache che contenga sia dati che istruzioni, poichè le CPU della famiglia 68K sono macchine di tipo (almeno credo) VonNeuman:

https://it.wikipedia.org/wiki/Architett ... on_Neumann

ovvero un unico sistema di bus Ax ... A0 per l'address, Dy ... D0 per il dato da scrivere o leggere, dato che può rappresentare un dato, ovvero un operando di un'operazione, oppure un operatore diciamo, una funzione, un'istruzione ... istruzioni e dati condividono la RAM, in questa architettura.

Nei microcontrollori moderni l'architettura prevalente è quella di Harward, ovvero un sistema di bus per i dati ed un altro, indipendente, per le istruzioni ... ad ogni modo non tutti i micro moderni sono fatti così: ad esempio i core AVR by Atmel, acquistata di recente da Microchip, ovvero CPU modeste a 8 bit, sono ancora realizzate in logica Von Neuman.
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda MacGyverPPC » sab feb 12, 2022 11:35 pm

AMG_Novice_Usr ha scritto:
perchè nel sistema tutti i file con estensione .prefs viene assegnata la medesima icona con un medesimo comando


Insomma ... stile Windows!! :-(

Semmai é winzozz che nato dopo, copia lo stile Amiga :ultralol: :ammicca:
OS4.1.3Immagine+SAM= ImmagineNG c'è!
SAM440EP: OS4.1.4Up4:con USB2.0 UP,RunInUae integrato con Kickstart 3.1,1.3,CD32 originali, MUI migliorato ecc/HD400GbSata/masterizzatore sataDVD/SB Audigy5.1.
AMIGA1200PPC/060(HomeTower):OS4Classic/USB/BlizzardPPC/BVision/Ram128Mb/HD/CD-DVD/RW :rock:
AMIKIT WinUAE:OS3.9/OS4 FE : AMD A8 x64
Advance
Multitask
Integrated
Grafic
Architecture
Avatar utente
MacGyverPPC

Leggenda
 
Messaggi: 10872
Iscritto il: sab set 22, 2007 4:51 pm
Località: Alessandria

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 13, 2022 10:02 am

su PC se hai un Floppy o un CD con settori/tracce rovinate Windows non ti permetterà di scrivere o copiare niente da questi dispositivi,
questo perchè Windows prma di inziare una qualsiasi operazione deve prima controllare tutto il contenuto
e in presenza di errori blocca tutto.


Ho capito.
Solo una domanda (OT):

questa è una caratteristica di Windows, oppure tale comportamento "rigido" è un retaggio ereditato da MS-DOS?
MS-DOS era così esigente nei confronti di HDDs e floppy disks?

Su Amiga questo non succede sia dai Floppy che dai CD riesci a copiare tutto quello che di "sano"
si trova nei due dispositivi senza preoccuparsi dei settori/tracce che contengono dati illegibili.


Ho capito.

Si, Amiga sembra essere più duttile, un sistema più elastico, più smart ... diciamo così.
Effettivamente, di recente ci ho fatto caso (credo di ricordare bene), quando ho usato TS-GUI.
Avevo bisogno di masterizzare su un floppy disk un file.adf.

Questo file aveva un settore (512 bytes) danneggiato: la scrittura dell'adf è andata bene fino a quel settore, dopo di che TS-GUI ha prodotto un requester, un pop-up diciamo, con il quale mi comunicava l'impossibilità di masterizzare su quel blocco, ma mi dava la possibilità di skippare avanti e continuare la scrittura oltre il blocco incriminato.

Fatta questa introduzione sul comportamento degli OS, Amiga OS rispetto a Windows, quando avvia il sistema
cerca i suoi file nel percoso più "breve", se noi abbiamo due OS su partizioni diverse e questi OS hanno qualcosa in comune
come "nome Volume" o "Nome Partizione", AmigaOS prenderà i suoi file dal primo percorso cher gli capita di leggere e quasi sempre
leggerà i dati un po' da uno e un po' dall'altro.


Si, chiaro.

Premesso che nessuna persona sensata, IMHO, creerebbe 2 partizioni aventi lo stesso nome, ed: DH0 e DH0 ... che senso ha?
Giustifico in pieno un kickstart avviante, al quale hai detto, mediante Amiga Early Startup Control, oppure per mero valore numerico della priority di bootstrap (settato in fase di preparazione HDD mediante HDToolBox oppure HDInstTool), di bootstrappare dal primo DH0, piuttosto che dal secondo ... dicevo, giustifico questo kick se poi lui prende roba dalla prima e roba dalla seconda.
Lo giustifico perchè la stringa DH0 della prima partizione e quella della seconda sono identiche, quindi il FW del kick può fare il minestrone.

L'importante è che se i nomi dei devices sono diversi, perfettamente ortogonali, e io li ho sempre scritti così:
esempio:

device/partizione = UDH0, nome del volume = UDH0, OS1, filesystem = X, priority = -1;
device/partizione = UDH1, nome del volume = UDH1, OS2, filesystem = Y, priority = -2;

ecco, l'importante è che, in questo caso di perfetta ortogonalità, il kick faccia il boot esattamente dalla partizione desiderata, e che non vada a cercare nulla nell'altra partizione, piuttosto se gli manca qualcosa (es: icon.library e workbench.library, come nel caso di kick3.2 che tenta di avviare da una partizione con dentro installato OS3.1) preferisco che il requester lo segnali e che il WB non compaia del desktop (che rimane vuoto), piuttosto che un kick che "travalichi" i confini della partizione e vada a cercare roba nell'altra partizione ... questo non deve succedere.

Mi confermi tutto questo?
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 13, 2022 10:34 am

piccolo OT:

https://www.appuntidigitali.it/3838/mot ... -a-32-bit/
https://www.cs.mcgill.ca/~cs573/fall200 ... /lecture8/

se qualcuno fosse interessato ad approfondire il discorso sulla famiglia CPU 68K (appena posso cerco anche io di studiarmeli).

Nel secondo link sono spiegati molto bene i vari passaggi di fetch/decode/execute di un'istruzione dalla ram ad opera del 68K, mediante un diagramma a blocchi abbastanza chiaro, almeno a prima vista.
Avatar utente
AMG_Novice_Usr

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

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMIGASYSTEM » dom feb 13, 2022 10:55 am

AMG_Novice_Usr ha scritto:
Solo una domanda (OT):

questa è una caratteristica di Windows, oppure tale comportamento "rigido" è un retaggio ereditato da MS-DOS?
MS-DOS era così esigente nei confronti di HDDs e floppy disks?


No anche adesso, prova a "bruciare un CD" e poi prova a copiare quel poco che è stato masterizzato, su Amiga potevi, oppure prova a inserire nel lettore floppy un floppy con tracce rovinate o che gli è passato un camion di sopra, Amiga consentirà di copiare il salvato, su Windows non potrai farlo.

In passato con A4000 e un Masterizzatore SCSI ho riparato molti CD bruciati su PC, in molti casi riuscivo a chiudere Sessione o Disco e recuperavo CD cestinati da amici utenti PC.

Premesso che nessuna persona sensata, IMHO, creerebbe 2 partizioni aventi lo stesso nome, ed: DH0 e DH0 ... che senso ha?

Normalmente non capita, ma quando si fa manutenzione a HD o Hardfile ed hai la necessità di montare questi dispositivi sul tuo sistema può capitare, in quel caso per poterci lavorare con il tuo OS devi fare i cambiamenti citati.

Giustifico in pieno un kickstart avviante, al quale hai detto, mediante Amiga Early Startup Control, oppure per mero valore numerico della priority di bootstrap (settato in fase di preparazione HDD mediante HDToolBox oppure HDInstTool),

La priorità gestisce chi deve avviarsi per primo ma non risolve il conflitto se ci sono delle uguaglianze citate.

Lo giustifico perchè la stringa DH0 della prima partizione e quella della seconda sono identiche, quindi il FW del kick può fare il minestrone.

Si solitamete sono le preferenze del sistema i dati che normalmente preleva dal vicino di casa
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: 5513
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: A1200 – problemi vari (instabilità) e relative domande

Messaggioda AMG_Novice_Usr » dom feb 13, 2022 10:55 am

- Update ROM Modules -> aggiorna la rom attraverso i moduli se presenti


Se su un A1200 fisico avessimo un kickROM 3.1, e su HDD oppure su CF avessimo un'unica partizione DH0 (DH0 che prende tutto il disco disponibile, facciamo un esempio semplicissimo), e dentro a questo DH0 abbiamo installato OS3.2.

All'accensione da freddo, dato che l'opzione "Update ROM Modules" è abilitata/spuntata di default, abbiamo che il kick3.1 viene, dopo la fase di POST (in particolare, dopo il test della chip-ram ... e infatti se questo test preliminare fallisce, se chi sono problemi con la ram, abbiamo schermo VERDE + guru 0x80000004), se tutto è ok, allora buona parte (quella che serve) del kick3.1 viene copiato dalle 2 ROM fisiche high e low ed incollato in chip-ram, dopodichè cosa avviene esattamente?

Credo che il FW di kick3.1, adesso caricato in chip-ram, vada a cercare gli "ROM Modules" di cui sopra, li va a cercare in DH0/OS3.2, li trova, poi li porta in chip-ram, sovrascrivendoli su quelli (gli omologhi vecchi) del kick3.1 ... siamo di fronte ad un'azione di patching 3.1 -> 3.2.

A questo punto, ho un dubbio:

il sistema si riavvia da solo (il led verde di power blinka, poi auto-riavvio dell'Amiga), così che al secondo riavvio il kick in chip-ram è già trovato "patchato 3.1 -> 3.2" dalla CPU?

oppure non si verifica questo riavvio automatico?

Io il riavvio l'ho sempre osservato, di recente, quando il kick3.2 fisico sul mio A1200 fisico faceva bootstrap da una partizione UDH0 (la prima delle 3, UDH0, UDH1, UDH2) dove dentro ho installato OS3.9 + BB1 + BB2.
Tale riavvio automatico serve sicuramente per effettuare il patching dei moduli del kickROM in chip-ram 3.2 -> 3.9.

- Failsafe boot -> una sorta di modalità provvisoria


Ah ok, appena posso cerco di provarla.
Quindi il sistema carica dalla partizione DHX/OSX solo lo stretto indispensabile, così per aiutare l'utente a distinguere quali devices, moduli, librerie ecc ... dell'OS fanno funzionare bene il sistema, e quali (se ce ne sono) producono problemi.
Avatar utente
AMG_Novice_Usr

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

Prossimo

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

Chi c’è in linea

Visitano il forum: Nessuno e 4 ospiti

cron