con - Amiga Magazine Online

Diduttica AMIGA MAGAZINE
.*.*.m.m.* .m * ...............................................
non avendo più preoccupazioni di
ambiente o di lunghezza.
Partiamo dal facile e arriviamo al dif-
ficile. Cominciamo quindi ad analiz-
zare Bootlnstall.
Lo scopo del programma è di pren-
dere un programma di nome Booter
dalla directory corrente e di scriver-
lo nei primi due blocchi del drive in-
dicato come argomento. Per com-
prendere il suo funzionamento è pe-
rò necessario un breve excursus in
tre punti.
1 ) Il formato oggetto standard di A-
miga. Un qualunque programma A-
miga, quale ad esempio quello ge-
nerato da un linker, non consiste
semplicemente in una sequenza di
istruzioni e di dati.
Poiché Amiga è una macchina mul-
titask, un programma deve essere
descritto in un formato che conten-
ga le informazioni per posizionarlo
correttamente ovunque nella me-
moria. Se così non fosse, tutti i pro-
grammi dovrebbero essere caricati
a locazioni fisse, rendendo il multi-
task impossibile. Un file oggetto di
Amiga è quindi formato da diversi
"hunk", ovvero blocchi di informa-
zioni per ognuno dei quali viene in-
dicato il tipo di trattamento da effet-
tuare: nessuna rilocazione, riloca-
zione a 16 bit, a 32 bit eccetera. Per
semplificare la situazione, conside-
reremo solo programmi formati da
un singolo hunk. In pratica, dovremo
saltare i primi 32 byte (ovvero 4 pa-
role lunghe) del file oggetto e scar-
tare gli ultimi quattro (ovvero 1 paro-
la lunga), in quanto contenenti dati
descriventi gli hunk, e quindi per noi
di scarso interesse. Il restoè il nostro
programma.
2) 11 formato standard del bootblock.
I primi quattro byte del bootblock
devono contenere necessariamen-
te i caratteri 'D','O','S1,O (non 'O'!),
cioè in pratica la stringa "DOS" in
formato C. I secondi quattro byte
formano una parola lunga che costi-
tuisce il checksum del blocco. I ter-
zi quattro byte formano una parola
lunga che contiene sempre 880, ov-
vero i Kbyte del disco: dopo viene il
nostro programma. La massima at-
tenzione deve essere prestata al fat-
to che il checksum viene calcolato
negando logicamente la somma e-
stesa di tutte le parole lunghe che
formano il blocco, ove somma este-
sastaasignificare che ogni qualvol-
ta c'è un trabocco dell'aritmetica a
32 bit, e quindi un riporto, questo va
pure sommato sotto forma di 1. Inu-
tile dire che "le parole lunghe del
blocco" indica le parole lunghe che
cominciano ad offset multipli di 4
dall'inizio del blocco, e che il "tutte"
esclude la parola lunga di check-
sum.
3) Le tecniche di 110 di Exec. Il DOS
non consente di effettuare 110 a livel-
lo di blocco, bensì solo a livello di fi-
le. Per scrivere quindi nei blocchi O
e 1 dovremo tuffarci nella gestione
delle device di Exec, il controllore
del traffico multitask di Amiga. Per
scrivere dei dati in un punto specifi-
co del disco, occorre:
1) Allocare una struttura di tipo 10-
StdReq;
2) Aprire, mediante OpenDevice(),
la trackdisk.device;
3) Dare il comando di Write;
4) Dare il comando di UpDate, che
fa eseguire fisicamente la scrittura;
5) Fermare il motore del drive.
Torniamo ora a Bootlnstall. Dopo gli
#include necessari (gli utenti Manx
eliminino quelli che cominciano con
protol, poiché I'Aztec C non permet-
te il prototype checking e tantomeno
l'in-line call per le funzioni di libre-
ria), vengono dichiarate le variabili
statiche del caso: il buffer di scrittu-
ra (b[1030]), la porta di comunica-
zione necessaria per fare dellll10
con Exec e la IOStdReq di cui sopra.
Per semplicità, sono stati dati gli
stessi nomi dei tipi alle strutture. Il
programma dovrà essere compilato
con l'opzione che impone il carica-
mento dei dati in CHIP RAM, poiché
è lì che b deve necessariamente ri-
siedere. L'oblio della raccomanda-
zione avrà come conseguenza la
scrittura di "spazzatura" varia nel
bootblock.
Dopo un breve controllo degli argo-
menti che non si presta ad equivoci,
Bootlnstall prova ad aprire Booter.
In caso positivo, salta con una Seek
i primi 32 byte, e ne legge 1017.
101 7 !? Certamente: 101 2 costitui-
scono la lunghezza massima per il
bootblock, 4 formano la parola fina-
le di informazione per lo hunk, e un
byte in più ci serve (nel caso venga
effettivamente letto) per avvisare I'u-
tente del fatto che il file è troppo lun-
go. Una lunghezza di 1016 andreb-
be ancora bene, in quanto l'ultima
parola lunga non ci interessa. Nota-
te come essa non venga cancellata
espressamente, e quindi, se la lun-
ghezza del programma è minore di
101 2, risieda anch'essa nel boot-
block (che fastidio ci dà?).
Eseguita I'inizializzazione dei primi
12 byte (il codice dovrebbe parlare
da solo, dopo le spiegazioni prece-
denti; date un'occhiata al calcolo
del checksum!), Bootlnstall cerca di
aprire la trackdisk.device utilizzan-
do il numero di unità fornito dall'u-
tente. Nel caso tutto vada bene, ini-
zializza la porta di comunicazioni
con Exec (per gli interessati, Exec
non usa WaitPort(Port), bensì
Wait(sigbit), e quindi la mancata al-
locazione del segnale causerebbe
l'arresto a tempo indeterminato del
programma, piantato su una Wait(0)
) ed effettua le operazioni di cui so-
pra. Notate che nella prima opera-
zione di 110 IOStdReq.io-Offset=O
indica che vogliamo scrivere dal
blocco O (se volessimo scrivere dal
blocco 1, comunque, dovremmo
scrivere 512, 1024 per il blocco 2,
eccetera), mentre nella terza 10-
StdReq.io-Length=O indica che vo-
gliamo spegnere il motore del drive
(nel caso volessimo accenderlo, sa-
rebbe l).
Non c'è che da chiudere la
trackdisk.device e stampare un
confortante messaggio.
Proseguendo sulla nostra strada,
andiamo a commentare Loader. Il
simbolo ITEMS deve essere egua-
gliato al numero di programmi che
Booter intendevisualizzare (anche lì
è chiamato ITEMS). PROGNUM-
LOC indica invece la locazione di
memoria mediante la quale Booter e
Loader si scambiano le informazio-
ni. La mia scelta è caduta su $24, in