In generale non ha più senso oggi rendere i comandi residenti vista la velocità raggiunta
dalle memoria di massa; era un meccanismo utile quando c'erano ancora i floppy disk e quindi
lasciare un comando in RAM dopo l'esecuzione poteva essere vantaggioso; oggi è sostanzialmente inutile
Certo, ma facciamo un esempio:
se un comando, il cui file (binario, eseguibile) si trova su un floppy, non è reso residente, ogni volta che il sistema necessita
di questo comando, il sistema deve accedere al floppy, con tanto di tempo di rotazione + tempo di avanzamento sulla traccia (0 ... 79) + tempo di prelievo dei bytes ... tempi meccanico/geologici!
Viene prelevato il comando, messo in ram, poi viene utilizzato, poi la ram a lui dedicata viene disallocata, pertanto al successivo
utilizzo di quel comando, il sistema deve ripetere l'accesso al floppy.
Da qui, la ovvia constatazione che rendere residente quel comando è molto meglio per i tempi di esecuzione.
Se però abbiamo che quel comando, il file di quel comando, anzichè risiedere su un floppy disk, magari risiede su una CF, le cose cambiano.
Il concetto è lo stesso del floppy, quindi ogni volta che il sistema necessita di quel comando, il comando va prelevato dalla memoria di
massa, ma essendo tale memoria di massa molto più veloce del floppy disk (la CF è basata su memorie flash, accessibili a banchi, come le flash di una penna USB o di una SD-card ... giusto?), ecco che l'accesso al comando ad ogni suo utilizzo non pesa troppo sulle prestazioni complessive, essendo un indirizzamento puramente elettronico, a stato solido insomma, e non più meccanico, pertanto lasciamo pure il comando su CF, non perdiamo molto in termini di prestazioni, e in più risparmiamo preziosa RAM, che su Amiga reali non espansi/poco espansi non è mai abbastanza ...
A partire dal KickStart 2.x, sia il Comando Resident, CD, Librerie ed altro sono stati inseriti nel Kickstart,
questo a mio avviso è molto meglio che averli su file, prima perchè si trovano al sicuro da corruzioni o infezioni
e secondo perchè a mio avviso velocizzano il sistema e garantiscono stabilità.
Se io ho i comandi sul drawer invisibile (= privo del corrispondente file icona.info) chiamato C, ovvero:
Sys: C
e la finestrella di protezione floppy è aperta, ovvero il floppy è write-protected, posso affermare che anche così stiamo proteggendo i comandi dentro C del floppy da corruzioni o infezioni, giusto? Voglio dire, la protezione non è raggiungibile solo dal fatto che nessun virus può scrivere nella ROM del kick fisico, ma anche la write-protezione del floppy che ospita tali comandi offre la stessa protezione ... è corretto?
La velocizzazione del sistema non è dettata tanto dal fatto che i comandi sono localizzati in kick-ROM, ma dal fatto che questi vengano resi residenti in ram, e quindi fatti girare in ram, tenuti sempre in ram (in stile TSR).
Forse (non sono un esperto in materia) se al posto di una ROM-kick, avessimo una memoria FLASH, quindi un chip di kick-flash, forse la CPU indirizzerebbe i comandi più velocemente in kick-flash piuttosto che in chip-ram, poichè le memorie flash vengono indirizzate a banchi, e non a singoli bytes, ma al tempo c'erano le ROM, e poi le EPROM, e poi le EEPROM, tutte memorie indirizzabili a byte, "byte-wise" in gergo, quindi indirizzamenti lenti, credo più lenti delle SDRAM con cui era fatta la chip-ram (detto meglio, la chip-ram era DRAM), pertanto forse è più veloce indirizzare i comandi in ram piuttosto che direttamente sul chip fisico del kick-ROM, da cui il vantaggio di avere un comando interno "residente", ma la residenza di un comando interno la ottieni gratis, all'accensione, quando cioè il kick-FW viene copiato da ROM a chip-ram (i comandi interni, che sono parte di questo FW, di conseguenza vengono portati in ram, quindi un comando interno all'accensione diventa necessariamente residente).
E' possibile renderlo residente (con "Resident CD", funziona anche su Icaros) ma sia io che lui abbiamo dubbi sul reale
vantaggio di renderlo residente visto che è già un comando interno, occupa poca memoria e la shell gestisce il cambio di directory senza usare il CD.
è un comando interno, e dato che tutto/quasi tutto il kick è stato copiato da ROM a chip-ram, quindi dato che il kick è tutto/quasi tutto residente, di conseguenza anche i comandi interni sono residenti, quindi anche CD è residente.
Rendere residente il CD da file, significherebbe copiare CD da file:
Sys: C/ CD
alla chip-ram.
Ma in chip-ram abbiamo già un CD, proveniente dal kick-ROM (questo CD è parte del kick-ROM-FW), quindi possiamo evitare di scrivere nella startup-sequence:
Resident CD
Riguardo KickStart 1.3 i Comandi residenti si possono utilizzare solo dalla Shell e non con il CLI !
...
inoltre anche il CLI e meno evoluto della Shell, anche qui dal Kick 2.x i due comandi sono stati "unificati".
Che differenza c'è fra Shell e CLI?
Lo domando perchè io tendo a pensare questi 2 oggetti come la stessa cosa, chiamata con 2 sinonimi, ma forse non è così ...
Posso azzardare un pensiero, che tu rettificherai meglio:
MS-DOS (che io non ho mai usato, il mio primo OS su PCx86 è stato Windows XP) era mono-tasking, e alla fine del processo di bootstrap, veniva eseguito/lanciato il processo "command.com", di fatto il cmd.exe che abbiamo anche oggi sulle ultime versioni di Windows, e tale processo di command line interface (CLI) era l'unico processo in running consentito da MS-DOS (correggi ogni virgola, se non dico cose corrette).
Quando io sulla CLI di command.com richiedevo all'OS di lanciare un certo programma/un certo comando, MS-DOS eseguiva il comando, però essendo mono-tasking, il controllo passava a questo comando/programma "figlio", mentre il "padre", ovvero command.com, veniva "congelato", e la sua esecuzione riprendeva solo dopo che il comando/programma figlio ritornava, ovvero terminava definitivamente, quindi solo dopo il "return" di tale comando, command.com riprendeva, fino al lancio del comando successivo ... pertanto non c'era una schedulazione a divisione di tempo che conosciamo oggi, riscontrabile, in quel periodo, solo nei sistemi unix avanzati ... e in Amiga.
Quindi la differenza fra CLI di Amiga (ho parlato della CLI di MS-DOS, ovvero command.com, solo per creare un background, a titolo di spunto per la discussione) e Shell di Amiga, quale è esattamente?
Forse che di CLI ce ne può essere una sola, e di Shell tante? Oppure il contrario?
A pensarci bene però, esistono entrambi i comandi, e sono pure interni a partire dal kick2.04 in poi, ovvero:
NewCLI
NewShell
che aprono un'altra finestra, che è un processo concorrente assolutamente indipendente da quello chiamante, e si vede anche dal numero indicato nel simbolo del prompt:
1>
2>
ecc ...
Anticipo che il kick1.3 non mostra nessun comando residente come preventivato, mostra qualcosa solo dopo aver avviato il sistema,
questo solo grazie ai comandi resi residenti dalla startup.
Probabilmente era anche una questione di spazio.
Fino al kick1.3 avevamo chip di ROM di capienza standard 256KB, e dentro a questa "ridicola" (per gli standards di oggi) memoria, ci stava già uno dei migliori OS del mondo, almeno per quanto attiene agli OS dell'allora nascente mondo degli home-computers (mi sarebbe piaciuto vivere quella fase storica!).
Dicevo, già ci stava dentro Amiga OS (Exec, Intuition a AmigaDOS) ... i comandi non ci entravano (oltre a tanti altri moduli e librerie, patches in generale), pertanto ecco la necessità di avere tutta questa roba esterna e non interna, ovvero su floppy, su files insomma.
A partire dal kick2.04, ecco che abbiamo i primi chip-ROM a 512KB, pertanto diverse cose che prima risiedevano su files, su floppy, poterono essere messe internamente alla ROM del kick.
Ho visto il file del kick1.3 di Carlo, output di Resident, quindi abbiamo capito che nessun comando era interno al kick1.3, tutti i comandi erano su files, su floppy, e potevano eventualmente essere resi residenti in chip-ram importandoli dai rispettivi files immagazzinati, ad esempio, in:
Sys: C
alla fine però sapere come funziona l'avvio dell'Amiga non ti aiuta poi nell'installare o ottimizzare il sistema.
Concentrati di più su cose terra terra come far funzionare i programmi perchè poi tutto il resto diventa solo teoria
e non interessa proprio niente se non sei un ingegnere che deve costruire un clone di un Amiga o un nuovo hardware
basato su questa filosofia.
Da quello che scrivi è chiaro che non sei un principiante, ma un livello conoscitivo molto avanzato,
ma poi ti perdi nell'uso quotidiano di un Amiga e relative periferiche.
Neppure Amiga in realtà mi serve, se è di "utilità" che parliamo, nel senso che non ci lavoro, è solo un'affascinante
hobby/speculazione, che mi concedo (come credo quasi tutti noi) nel pochissimo tempo libero che la vita lavorativa ci concede.
Sono in questo forum per imparare da voi che ne sapete più di me, e poi chissà ... un giorno potrò a mia volta dare una mano a qualcuno, ma non ancora: adesso sono nella fase di apprendimento, che deve durare alcuni anni, per lo meno.