A600 + CF + partizione PFS3AIO + installazione di MI1: error

[AMG_Novice_Usr]

oltre ad eseguire i due eseguibili il sistema deve conoscere anche dove sono posizionati del gioco ......
Detto questo nella startup-sequence devi fare la stessa cosa, vediamo se ci arrivi da solo !

Non ho grosse basi amigose per poter capire cose profonde, ma dal basso della mia ignoranza penserei che:
se batto da cli/shell, piuttosto che (che è la stessa cosa) scrivo nella startup-sequence:

UDH1: Monkey/un_eseguibile

il sistema dovrebbe capire dove è posizionato "un_eseguibile", quindi perchè dover battere su shell/cli, piuttosto che sulla prima riga della startup-sequence:

Monkey

??

(
uguale a:
CD Monkey
)

sembra che il percorso corrente debba essere Monkey, per far funzionare quegli eseguibili, ma credo che questa sia una caratteristica di quegli eseguibili, che mentre girano fanno riferimento alla posizione corrente nel filesystem, che deve essere il drawer del gioco, invece se il path corrente non è il drawer del gioco, gli eseguibili suddetti non trovano ciò di cui necessitano e succede casino ...

Secondo me le cose stanno così, ma non che il sistema non sa dove sono gli eseguibili, se scrivo:

Sys: Monkey/un_eseguibile

il sistema credo che lo sappia, e la risposta è:

Sys: Monkey

[AMIGASYSTEM]

come DefaultTool dell'icona "mio_script.info" ci metto "NotePad", piuttosto che "ED", piuttosto che qualunque editore di testi, così che quando clicco l'icona, l'editor di testo apre lo script, così da poterlo editare. Tutto questo con il flag S NON spuntato.
Quando voglio testare lo script, spunto il flag S, dopodichè riclicco sull'icona "mio_script.info": questa volta il sistema non dovrebbe invocare il tool di default "editor di testo", bensì IconX, che invoca EXECUTE applicato a "mio_script", che viene quindi scriptato, quindi testato.

Si se usi IconX, ma puoi anche non usarlo IconX visto che lo script diventa un eseguibile, siamo su Amiga ! ricorda che Amiga ha più Tipologie di Icone quindi ti basta solo cambiare tipo di icona, inoltre le Icone Amiga possono eseguire un file in base alla tipologia ovvero WB o CLI, esiste anche una terza fuzione chiamata ARexx che serve ad eseguire Script ARexx anche questi hanno bisogno del flag "S"

Da queste info dovresti capire i passaggi, evito la pappa pronta altrimenti non si memorizzano i passaggi e dopo qualche tempo non si ricorano più, io smanettavo 30 anni fa e nonostante i miei 68 anni riscordo ancora quasi tutto, questo grazie alle tante nottate di sperimentazione passate per capire al meglio il sistema Operativo più bello e divertente del Mondo.

[AMIGASYSTEM]

Secondo me le cose stanno così, ma non che il sistema non sa dove sono gli eseguibili, se scrivo:

Sys: Monkey/un_eseguibile

il sistema credo che lo sappia, e la risposta è:

Sys: Monkey

No al contrario, sa dove sono gli eseguibili perchè lo hai impostato, quello che non sa e dove l'eseguibile deve cercare i dati, percorso che tu non hai dato, risultato schermata nera perchè non trova i dati del gioco :)

In pratica nella tua Startup-sequence prima degli eseguibili devi solo aggiungere un piccolo comando .... adesso dovresti arrivarci !

[AMG_Novice_Usr]

ricorda che Amiga ha più Tipologie di Icone

intendi questo argomento qui ? :

https://drive.google.com/file/d/1EAQOYw ... yqF5u/view

qua si vedono 5 tipi di icone, 5 famiglie, diciamo ...

quindi ti basta solo cambiare tipo di icona

Premetto che non ho mai lavorato con le icone di Amiga, nel senso che le ho sempre trovate pronte: mi sono sempre limitato
a lanciarle tramite doppio click del bottone sinistro del mouse, oppure selezionarle, poi A+info, e da qui le proprietà "DefaultTool" e "ToolTypes".

Provo pertanto, e non è detto che ci riesca, ad interpretare quest'ultima tua frase sintetica "ti basta solo cambiare tipo di icona".

Inizio dell'interpretazione:

Supponiamo che io abbia creato uno script "pippo", anzi, diciamo pure "pippo.bat", con EditPad (consentimi il nome alla Windows, con estensione, anche se in Amiga le estensioni non hanno la valenza che hanno in Windows, è solo per capirci meglio), ovvero con questo programma:

Sys: Tools/EditPad

pertanto il file "pippo.bat" è un PROGETTO creato con il programma EditPad, nel senso che ho utilizzato EditPad per editare il file "pippo.bat".

Un pò come un'immagine "figura1.iff", piuttosto che "figura2.ilbm", dipinto creato da me con DeluxePaint e salvato: l'icona figura1.info piuttosto che figura2.info (icona con un triangolino verde raffigurato dentro l'immagine dell'icona) è un PROGETTO, quindi icona "project" (icona "data") in cui il DefaultTool è proprio DeluxePaint.

Torniamo sul binario principale ...

Il file "pippo.bat" è a questo punto, una volta salvato con/in ambiente EditPad, un progetto di EditPad, un progetto realizzato/salvato sotto EditPad, quindi la sua icona appartiene a questo mondo qui, cioè alla quinta famiglia di icone di Amiga che vediamo qui:

https://drive.google.com/file/d/1-X9NZi ... 2qiya/view

Inoltre, al momento, se seleziono l'icona project di "pippo.bat", e poi faccio da menù:

Icon -> Amiga+info

troverò che, come DefaultTool, avrò proprio EditPad.

Veniamo adesso alla frase "ti basta solo cambiare tipo di icona".

Se adesso io cambio il tipo di icona di "pippo.bat", ovvero passo a questa:

https://drive.google.com/file/d/1s0kfmy ... BA_cs/view

nel senso che se faccio in modo (ma adesso non saprei come effettuare in concreto questa operazione) che il file "pippo.info", ovvero l'icona di pippo, passi dal tipo di icona "data" ("project") al tipo di icona "tool" (= "executable" = "application"), dicevo se faccio questa trasformazione, tu stai dicendo che facendo così noi di fatto trasformiamo "pippo.bat" da un progetto editato/salvato con EditPad, ad un eseguibile per AmigaDOS, un'applicazione insomma, anche se pippo.bat non è un binario, un .exe binario come lo intenderemmo comunemente, bensì uno script, un file contenente stringhe ASCII del tipo:

comando 1 \n\r
comando 2 \n\r
ecc...
EOF

che se dato in pasto all'interprete AmigaDOS, oppure al comando EXECUTE, questo lo analizza riga per riga, e lo esegue.

Insomma, la tua frase "ti basta solo cambiare tipo di icona", analizzata parola per parola, si traduce in quello che ho detto: cambiando tipo di icona (come si fa?), passiamo quindi dalla famiglia di icone "projetc" alla famiglia di icone "tool", quindi cambiando la famiglia a cui appartiene l'icona pippo.info, tu stai dicendo che conseguentemente (automaticamente) io ottengo che il file pippo (la cui icona è pippo.info) passa da essere un file di dati, un progetto insomma, ad un file eseguibile, tale per cui se clicco l'icona, che adesso è di tipo "tool", non viene lanciato EditPad, il quale apre il progetto "pippo", ma viene lanciato AmigaDOS oppure EXECUTE, il quale interpreta ed esegue pippo.

inoltre le Icone Amiga possono eseguire un file in base alla tipologia ovvero WB o CLI

Questa frase proprio non riesco ad interpretarla ...

No al contrario, sa dove sono gli eseguibili perchè lo hai impostato,

Si, su questo non avevo dubbi ... se io scrivo su startup-sequence o batto manualmente su shell/cli:

UDH1: Monkey/Monkey_Island

il sistema avvia l'eseguibile (un .exe binario) "Monkey_Island", ed il sistema sa, ovviamente, dove si trova questo eseguibile, dato che gli ho fornito io al sistema il path in cui si trova, ossia:

UDH1: Monkey/

quello che non sa e dove l'eseguibile deve trovare i dati,
percorso che tu non hai dato, risultato schermata nera perchè non trova i dati del gioco :)

Ok, certo, è ragionevole.
Mi stai dicendo che l'eseguibile "Monkey_Island", una volta entrato in esecuzione, si aspetta di trovare "da qualche parte" i files dei dati del gioco, che sono:

sample.dat
music.dat
disk01.lec ... disk04.lec
901.lfl ... 905.lfl
ecc ...

Io non ho insegnato al sistema "dove si trovano questi files di dati", quindi l'eseguibile viene lanciato correttamente, ma non trova i dati, da cui schermo nero perenne.

In pratica nella tua Startup-sequence prima degli eseguibili devi solo aggiungere un piccolo comando .... adesso dovresti arrivarci !

Ma ... io aggiungerei semplicemente, e ho provato che funziona sia su A600 emulato che reale:

Monkey

(oppure "CD Monkey", che è la stessa cosa, se ho portato in UDH1 il drawer C: con dentro il comando CD, e in tal caso nella startup-sequence, come prima riga, dovrei insegnare questo path di sistema ad Amiga, con "Path C: ")

portando quindi la directory corrente sul drawer Monkey di installazione del gioco, l'eseguibile Monkey_Island, una volta lanciato, va a cercare i dati:

sample.dat
music.dat
disk01.lec ... disk04.lec
901.lfl ... 905.lfl

e l'eseguibile sa di suo che li troverà nel drawer corrente, dove mi sono portato prima di lanciare l'eseguibile stesso, ovvero il drawer Monkey in cui ho installato il gioco (drawer in cui ho i dati del gioco, dove cioè l'installer del gioco, una volta lanciato, ha copiato i files di dati dai floppy 1 ... 4 alla CF, nel drawer UDH1: Monkey/ ).

L'ho fatta lunghissima per capire cosa ho capito e cosa no, e rendere più selettive/efficaci eventuali tue correzioni ...

[AMIGASYSTEM]

Bene visto che non hai praticità con le icone ho creato un video partendo da uno script che esegue un eseguibile. Nel video ho simulato i vari errori con il corretto settaggio finale, non far caso al nomignolo "Project" è solo una mia incompatibilità verso un software che sto sperimentando.

Questi i passaggi che ho fatto:

- Creato uno script con EditPad, dentro ho digitato C:HIP (HIP è il programma HippoPlayer)
- Salvato lo Script in RAM con il nome StartHIP
- Eseguito StartHIP da Icona creata dal sistema dove di default è stato associato EditPad

- Primo test fondamentale, convertita l'icona da Progetto a icona Programma (come detto non fare caso che non sia cambiato il nome project)

- Secondo test "simulato errore" nel Tooltype Icona ho impostato "Workbench" (questa opzione serve per lanciare un eseguibile nativo Workbench)
- Terzo passaggio questa volta impostato la giusta voce ovvero "Shell" (questa opzione "chiedi argomento" serve per eseguire uno script o un comando DOS dove è possibile aggiungere dei parametri)

- Quarto test, come sopra, questa volta con la voce "Shell" ma senza il "chiedi argomento" utile quando si vuol eseguire direttamente senza alcuna richiesta.

Concludo descrivendo solo i giusti passaggi per eseguire unoscrip dal Workbench:

- Modificare icona e commutarla in icona "Programma" (Tool)
- Aggiungere il flag "S" all'icona
- Nel TooType impostare "Shell" (facoltativo "chiedi argomento")
- Cambiato immagine Icona (facoltativo, per esempio usare una icona del gioco)

Non finiscono qui gli argomenti, quando si eseguono applicazioni con la "Workbench" il Tooltype (finestra sottoscante) può servire per aggiungere innumerevoli parametri, settaggi e chi più ne ha più ne metta.

Dimenticavo, la commutazione Icona puoi farla dl Workbench da OS 3.5 in su, per i sistemi inferiori occorre usare programmi esterni quando compatibili.

Allego video test:

https://drive.google.com/file/d/1rUvgKy ... sp=sharing




-----------------

Ora passiamo a MI1

Ti dicevo di guardare i passaggi del video, quando ho cliccato UDH1 e come se avessi dato il comando CD UDH1 (nel video il gioco era nella root), ed è questo che fa capire agli eseguibili dove si trovano i dati, nella startu-sequence devi digitare semplicemente questo se il gioco si trova nella cartella Monkey:

CD DH1:Monkey
monkey_patch
monkey_island

[clros]

[...]

nel senso che se faccio in modo (ma adesso non saprei come effettuare in concreto questa operazione) che il file "pippo.info", ovvero l'icona di pippo, passi dal tipo di icona "data" ("project") al tipo di icona "tool" (= "executable" = "application"), dicevo se faccio questa trasformazione, tu stai dicendo che facendo così noi di fatto trasformiamo "pippo.bat" da un progetto editato/salvato con EditPad, ad un eseguibile per AmigaDOS, un'applicazione insomma, anche se pippo.bat non è un binario, un .exe binario come lo intenderemmo comunemente, bensì uno script, un file contenente stringhe ASCII del tipo:
[...]

Ovviamente quello che hai scritto (e che ho evidenziato) è chiaramente impossibile , non puoi trasformare un file , anche se si tratta di uno script AmigaOS, in un binario! (*)
Penso che AmigaSystem intendesse proprio qualcos'altro...


(*) stavo pensando che in effetti sarebbe concettualmente semplice trasformare degli script amigaOS in binari, forse c'erano programmi che lo facevano ai tempi dell'1.3. Ma chiaramente non è cambiando l'icona che si fa, bisognerebbe avere un programma esterno che analizzi lo script e trasformi le chiamate ai programmi in istruzioni Exec/DOS per richiamare quei programmi stessi e si occupi anche di inserirli nelle apposite strutture di controllo definite del file script (IF ELSE, ecc..): Ovviamente il tutto andrebbe compilato prima che possa funzionare. Morale della favola: sarebbe poco conveniente anche perchè la potenza degli script è proprio quella di essere interpretati e quindi anche facilmente modificabili.

[AMIGASYSTEM]

Penso che AmigaSystem intendesse proprio qualcos'altro...

Intendevo che un file di testo può essere lanciato "come se fosse eseguibile", proprio come il .bat su PC.

Se ricordo bene in passato esistevano programmi di conversione testo/binario, io usavo una piccola applicazione che convertiva una immagine in un Exe.

[clros]

Si un file di testo che può essere lanciato "come se fosse eseguibile", proprio come il .bat su PC.

Sono comunque normali script, non sono binari. La funzione degli script di shell (o di qualsiasi altro linguaggio, per esempio Arexx) è proprio quella di essere interpretabili direttamente dalla shell.

Si esistevano inpassato alcuni programmi di conversione testo/binario ora non ricordo, io ne usavo uno che convertiva una immagine in Exe.

Si, anche io ricordo qualcosa del genere. Ma da un certo punto in poi (dal 2.0?) è bastato digitare il nome del file perchè AmigaOS lanciasse il programma associato a quel progetto. Così, se scrivo da shell "pippo.jpg" automaticamente verrà visualizzata l'immagine "pippo.jpg" lanciando il tool associato. MA questo non vuol dire che pippo.jpg sia diventato un eseguibile

Per un bel po' di tempo questa era una caratteristica di Amiga non presente su MS-DOS; adesso questa cosa qui si può fare anche da una qualsiasi shell di Windows.

[AMIGASYSTEM]

Sono comunque normali script, non sono binari. La funzione degli script di shell (o di qualsiasi altro linguaggio, per esempio Arexx) è proprio quella di essere interpretabili direttamente dalla shell.

Non ho mai parlato di file binari, ho sempre parlato di "script" eseguibili, ovvero eseguiti direttamente digitando solo il nome file, senza "digitare davanti execute".

Così, se scrivo da shell "pippo.jpg" automaticamente verrà visualizzata l'immagine "pippo.jpg" lanciando il tool associato. MA questo non vuol dire che pippo.jpg sia diventato un eseguibile

In un sistema standard se scrivi da una shell "pippo.jpg" non si aprirà nessuna immagine se davanti non digiti lo strumento per visualizzarla, con lo script testuale invece è diverso perchè lo strumento execute se lo va a cercare lo script da solo senza che tu lo digiti, per le immagini invece nello script è necessario digitare il viewer.

Parliamo lo stesso linguaggio ma non ci capiamo, diverso invece l'applicazione che citavo per le immagini che non usa nessun programma associato, ovvero una immagine convertita in binario, praticamente l'immagine diventata un vero eseguibile, anche se poi all'interno immagine ci sarà integrato un suo viewer.

Guardando nei miei vecchi appunti ho anche trovato l'applicazione Amiga che converte realmente un testo in binario, si chiama Batch2exe, questa applicazione converte in binario uno script e lo si può eseguire senza che questo abbia bisogno di execute o altre applicazioni esterne.

[clros]

Sono comunque normali script, non sono binari. La funzione degli script di shell (o di qualsiasi altro linguaggio, per esempio Arexx) è proprio quella di essere interpretabili direttamente dalla shell.

Non ho mai parlato di file binari, ho sempre parlato di "script" eseguibili, ovvero eseguiti direttamente digitando solo il nome file, senza "digitare davanti execute".

Si, mi riferivo a quello che scriveva AMG_Novice_Usr

In un sistema standard se scrivi da una shell "pippo.jpg" non si aprirà nessuna immagine se davanti non digiti lo strumento per visualizzarla, con lo script testuale invece è diverso perchè lo strumento execute se lo va a cercare lo script da solo senza che tu lo digiti, per le immagini invece nello script è necessario digitare il viewer.

Hai ragione, ho controllato adesso con Icaros. Non è come dicevo io, ma per qualche motivo mi ricordavo che si potesse fare e ricordavo fosse anche una bella caratteristica di AmigaOS.

Parliamo lo stesso linguaggio ma non ci capiamo, diverso invece l'applicazione che citavo per le immagini che non usa nessun programma associato, ovvero una immagine convertita in binario, praticamente l'immagine diventata un vero eseguibile, anche se poi all'interno immagine ci sarà integrato un suo viewer.

Ma è il file immagine a diventare un eseguibile (perdendo l'immagine originale) o viene creato un eseguibile a partire dai dati dell'immagine (inglobando i dati nell'eseguibile o facendo riferimento all'immagine come path?)
Perchè , nel primo caso, l'immagine di partenza non si potrebbe più aprirla con i tool di disegno o visualizzarla/modificarla in altro modo

[AMIGASYSTEM]

Ma è il file immagine a diventare un eseguibile (perdendo l'immagine originale) o viene creato un eseguibile a partire dai dati dell'immagine (inglobando i dati nell'eseguibile o facendo riferimento all'immagine come path?)
Perchè , nel primo caso, l'immagine di partenza non si potrebbe più aprirla con i tool di disegno o visualizzarla/modificarla in altro modo

Questa applicazione funziona solo con immagini IFF/ILBM (non tutte), e una volta avviata la conversione il file .IFF/ILBM diventa un vero eseguibile, di conseguenza nessun viewer potrà più mostrare l'immagine.

Come tu sai i sistemi operativi in particolare AmigaOS riconosce i file "dall'acronimo inizio file" su cui sono bastati anche i Descrittori Datatypes per il riconoscimento file sul Workbench, bene questa applicazione scrive del codice inizio file quindi l'acronimo in questo caso "ILBMDTHD" non può essere più letto e al suo posto sarà letto il codice che Amiga individua come un exe.

Prova lampante se provi a guardare questo file dal Workbench, noterai che gli verrà assegnata l'icona martello, se forzi l'apertura con Multiview ti dirà che non ha il datatypes per riconoscerlo. Se invece sul sistema hai il Descrittore e l'exe.datatype, Multiview riconoscerà l'eseguibile e fornirà le informazioni su cosa utilizza il file, in questo caso nessuno in altri file exe dirà invece quali librerie, device, font etc.. necessita per essere avviato.

Se provi il mio AROS One x86 noterai che ho creato molti Descrittori Datatypes per il riconoscimento di molti file sia su Dopus4 che dal Workbemch che di default AMiGA OS o AROS o MOS standard non riconoscono. Tutto questo facilita e velocizza quando devi esaminare il contenuto di archivi o file scaricati da internet, dove ogni file oltre ad essere riconosciuto nell'icona avrà l'idoneo strumento per l'apertura file.

[Seiya]

Ho un A600 reale siffatto:

Ciao. Se ti piace giocare ti segnalo un forum che cerca membri: retro-gamers.it.

[AMG_Novice_Usr]

@Carlo
Grazie del video, molto chiaro, appena posso cerco di fare qualche prova per conto mio, e poi ci risentiamo in modo estremamente specifico.

La sintesi finale è comunque questa:

commutazione da icona progetto/icona dati (progetto creato con un editor di testo, dato che uno script si deve scrivere come un qualsiasi documento testuale) a icona tool/eseguibile (icona con cacciavite e/o martello, credo che tale iconografia di default dipenda anche dalla versione di OS e Workbench), poi spunta di S ed assegnazione di "Shell" come ToolType, questo per dire ad Amiga: "appena con doppio click lanciamo l'oggetto associato a questa icona, tu lancia una nuova Shell/CLI, che è un processo concorrente a quelli attualmente in running, che si aggiunge, anche con altre Shell/CLI eventualmente, e questa nuova Shell/CLI deve analizzare lo script per eseguirlo".
Comunque, ci risentiamo nel merito del video appena possibile!

CD DH1:Monkey
monkey_patch
monkey_island

Si, è come ho fatto io, ossia:

Monkey
monkey_patch
monkey_island

Approfitto per discutere di una finezza ... mi sembra attinente (è solo un'estrema finezza).

Il tuo script differisce dal mio solo per la prima riga delle 3 presenti, ovvero tu hai fatto:

CD DH1:Monkey

io invece:

Monkey

sappiamo che è la stessa cosa.

Premetto che non so (sarebbe bello saperlo, qualcuno lo sa?) da quale versione di OS/WB in poi, nei sistemi Amiga è possibile omettere l'invocazione da Shell/CLI attuale del comando di sistema CD per cambiare il path/directory corrente in cui la shell stessa si trova.
Io infatti prima battevo sempre CD <path di destinazione> per spostarmi appunto in quel path/quel drawer, ma da OS2.x in poi sicuramente non ce n'è più bisogno, si può omettere CD ... chissà se nei primi sistemi OS/WB1.x la chiamata a CD era mandatoria, oppure Amiga, ovvero a partire da Amiga1000, è già nato con la possibilità di omettere CD.

Ad ogni modo, la mia domanda/questione è un'altra, adesso ci arrivo:

dicevo, io ho omesso CD, e il mio script funziona come il tuo.
Questo vuol dire che dentro il kickstart, nel mio caso kick3.2, abbiamo già il comando CD, o qualcosa di simile/analogo, funzionalmente equivalente, ovvero quando il 68K, all'accensione, carica da ROM-kick a chip-ram i circa 512KB del FW/bios chiamato "kick3.2", in questo FW che viene caricato da ROM a RAM abbiamo già alcuni comandi/programmi di sistema, fra i quali un equivalente del CD che invece troveremmo in Sys: C ... è corretto?

Pertanto, è meglio usare questa riga:

Monkey

piuttosto che questa qui:

CD DH1:Monkey

primo perchè dovrei portare da UDH0 (dove ho installato OS3.2) a UDH1 (partizione vuota, c'è solo l'installazione del gioco MI1) il comando CD, e invece un analogo di CD lo abbiamo già residente in ram in quel momento, preso dal kick fisico 3.2 in ROM, e secondo perchè se magari decidiamo di rendere residente in ram il comando CD:

Resident CD PURE

(
magari potremmo scrivere:
Path C: // in C abbiamo messo CD
Resident CD PURE
CD DH1:Monkey
)

abbiamo un secondo programma di Change Directory che ci occupa RAM, occupazione inutile, seppur piccola, dato che in kick3.2 avevamo già un programma/comando di Change Directory funzionante.

è solo un sofismo questo, ma mi interessava avere un parere tecnico.

[AMG_Novice_Usr]

Ciao. Se ti piace giocare ti segnalo un forum che cerca membri: retro-gamers.it.

Interessante! E anche molto carino (ho già letto la retro-recensione di MI2) ... grazie per la segnalazione!
Appena riesco mi inscrivo sicuramente!

[AMIGASYSTEM]

Ho eliminato i post doppioni, è capitato anche a me quell'errore ma poi il post è stato salvato.

Ad ogni modo, la mia domanda/questione è un'altra, adesso ci arrivo:

dicevo, io ho omesso CD, e il mio script funziona come il tuo.

Questo vuol dire che dentro il kickstart, nel mio caso kick3.2, abbiamo già il comando CD, o qualcosa di simile/analogo, funzionalmente equivalente, ovvero quando il 68K, all'accensione, carica da ROM-kick a chip-ram i circa 512KB del FW/bios chiamato "kick3.2", in questo FW che viene caricato da ROM a RAM abbiamo già alcuni comandi/programmi di sistema, fra i quali un equivalente del CD che invece troveremmo in Sys: C ... è corretto?

Pertanto, è meglio usare questa riga:

Monkey

piuttosto che questa qui:

CD DH1:Monkey

Quello è un comando standard, funziona lo stesso omettere CD, ma se quello script lo utilizzi su OS 1.x non funzionerà, inoltre su OS 1.x dovrai avere anche il Comando CD su file, prima di os 2.x il comando CD non era residente nel Kickstart.