\input augs.sty
\input amiga

\author *Sebastiano Vigna*
\netaddress *vigna@ghost.dsi.unimi.it*

% AmigaMail
% Priorità nei RKM
% Acquistare il SAS/C come studenti
% Messaggio velato non comprate da Vito
% UINet!!!


\title *Facciamoci del male, ovvero: lista di indicazioni utili per convivere
con Amiga*

\article

Il titolo di questo articolo (che non vorrei si configurasse già come
semiserio) rappresenta l'inconsa\-pevole stato dell'utente medio di \amiga{} in
Italia. Circondato dalla disinformazione, spesso impossibilitato a prendere
contatto con persone che potrebbero dargli consiglio, anestetizzato dalle
tonnellate di software piratato su cui comunque riesce a mettere le mani,
l'Amigo medio spreca i suoi anni migliori (e quelli della sua macchina) a
chiedersi perché BLAZEMONGER non gira se aggiunge un secondo drive al suo
\amc{} con 1 Mega (di più no, se no BLAZEINSTALLER non va).

Facciamo un piccolo test; nella sequenza di parole: ADSP, Enforcer, PD,
Mungwall, AUISG, FreeWare, RKM, Texinfo, AmigaGuide, Sushi, UUCP, InterNet,
Hirsch \& Wolf, ShareWare, CopyLeft, quante vi risultano note, e cioè di quante
sapreste spiegare il significato e la connessione inscindibile con \amiga{},
esemplificando la vostra dissertazione con disegni verosimili? Se più di cinque
vi risultano ignote, e ancor più se siete programmatori, questo articolo
potrebbe esservi di una qualche utilità. Toccherò una serie di temi importanti
relativi ad \amiga{}, cercando di fornire in poche righe alcune informazioni
essenziali.


\head *Il sistema operativo*

La quantità di informazioni sbagliate e/o tendenziose esistenti su questo
argomento è assolutamente sbalorditiva. Sono noti casi di individui improbabili
recatisi dal negoziante chiedendo di mettere su \amc{} Plus le ROM della
versione 1.3, affermando che con la 2.04 ``i giochi non partono''. Vediamo di
fare luce sull'intera vicenda.

Quando \amiga{} venne alla luce, fu distribuito con una versione del sistema
operativo, la 1.0 o la 1.1, che chiamare definitiva era in effetti un po'
altisonante. Riusciva, è vero, a far funzionare per alcune ore la macchina, ma
niente di più.

Il grosso salto avvenne con la distribuzione della 1.2. Prima di tutto, alcune
funzioni assolutamente necessarie erano state finalmente introdotte (per
esempio, il rinfresco dei singoli gadget). Poi, si poteva---udite
udite!---usare tutto lo schermo PAL.

Rimaneva ancora un problemino: non era possibile effettuare il lancio della
macchina da disco rigido, una rogna disastrosa per una macchina non certo nota
a causa della silenziosità o della velocità dei suoi dischetti. La lacuna venne
colmata con la 1.3, in cui finalmente fu introdotto il nuovo, velocissimo Fast
File System, riservato solamente ai dischi rigidi.

Era però sempre più evidente per tutti che una serie di carenze gravi
affliggevano parecchie parti del sistema operativo. (Sciorinare qui una lista
esaustiva dei buchi da tappare e delle migliorie che era necessario apportare
sarebbe stato decisamente prolisso.)

D'altra parte, è veramente impossibile riuscire a far sentire al lettore
che non abbia seguito con l'intensità di chi scrive quegli anni (sì, perché di
lunghi anni si è trattato!), la quantità di sudore, lacrime, attesa e
disperazione generate dalla scrittura, dal beta-testing e dalla pubblicazione
della Release 2. Furono anni unici (che credo rimarranno irripetibili nella
storia di \amiga{}) durante i quali un manipolo di stakanovisti della Commodore e
la quasi totalità degli sviluppatori si dedicarono a produrre la riscrittura
totale più compatibile del mondo. Anni durante i quali, oltre a generare mezzo
Megabyte di codice ultracompatto e a prova di bomba, vennero testati centinaia
e centinaia di prodotti (soprattutto giochi) affinché le nuove macchine, e
soprattutto gli utenti, non fossero penalizzati dal non poter più utilizzare i
loro vecchi programmi.

Il risultato fu decisamente eccezionale (si provi a paragonarlo con il System 7
della Apple, che ha causato incubi e disturbi psicofisici di entità non lieve a
quasi tutti gli utenti Macintosh). Per dirla con un'espressione rozza, ma
essenzialmente corretta, ``girava tutto''.

Vi starete chiedendo come mai il mitico acquirente dell'\amc{} Plus se ne è
tornato indietro. Forse perché i giochi non funzionavano? Ebbene, NO. Lui forse
poteva crederlo, ma purtroppo il problema è un altro: {\it le sprotezioni
pirata non funzionano!\/} Il 99\% dei problemi riscontrati nel far funzionare
giochi sulla Release 2 deriva dal fatto che chi li ha sprotetti non capisce pressoché
nulla a parte il proprio modello di \amiga{} (che ovviamente conosce fino
all'ultimo cavetto). Peccato che la sua conoscenza sia assolutamente inutile sui
restanti tre milioni di macchine; ma---come si dice?---alla qualità bisogna a
volte sopperire con la quantità.

Il triste, deprimente risultato (peraltro rinforzato dalla politica commerciale
della Commodo\-re) è che quasi nessuno in Italia sa addirittura dell'esistenza
della Release 2. Quando poi ci si impegna per trovarla, si scopre che è necessario
pagarlo cifre folli (perché il montaggio è necessariamente incluso).

D'altra parte, l'Amigo medio italiano è raramente in contatto con il software
distribuibile di altissima qualità che popola le reti informatiche, e quindi
può non sapere che quasi nulla ormai gira sotto 1.3, a parte detti giochi
sprotetti.

Se posso quindi dare un consiglio spassionato: costi quel che costi,
{\it procuratevi la Release 2}. La funzionalità e la stabilità di \amiga{} ne
vengono letteralmente decuplicate.

La storia ovviamente continua con la 2.1, che introduce i nuovi velocissimi
requester e la localizzazione (ovvero il supporto software per la traduzione
dei programmi), e con la 3.01, il software delle nuove macchine, che permette la
gestione dei chip AGA (ed anche altre cosucce molto carine). La base di
compatibilità per il futuro rimane però la 2.04, che è un po' come un paletto
piantato sull'Everest dopo una lunghissima scalata. Il salto 1.3-2.04 è
infatti enormemente più importante di quello 2.04-3.01.


\head *Il software distribuibile*

\amiga{}, grazie al suo folto gruppo di utenti amatoriali, possiede una vastissima
gamma di software distribuibile. Si tratta di programmi che possono essere
liberamente copiati ed utilizzati, senza pagare alcunché (o pagando come
vedremo, cifre molto inferiori a quelle dei programmi commerciali). Su molti
fronti, i programmi distribuibili sono superiori a quelli commerciali: un
esempio tipico è quello dei programmi di comunicazione.

Il problema del software distribuibile è la sua distribuzione: non esistendo
canali commerciali, bisogna affidarsi ai modem (che sono ancora poco diffusi da
noi), agli User Group (ancor meno diffusi), alle collezioni di software
distribuibile, come quella di Fred Fish (neanche a parlarne), o all'accesso di
siti ftp (fantascienza).

Purtroppo, le BBS italiane sono in larghissima parte saturate di pessimo
software piratato, per la maggior parte giochi, che soffoca letteralmente,
peggio di una vera e propria gramigna, l'ottimo software invece reperibile
negli Stati Uniti. Una bella beffa, se si pensa che il miglior software di
questo tipo viene prodotto proprio in Europa.

Vediamo innanzitutto di fare un po' di azzeramento del linguaggio:

\list

\item Software di dominio pubblico (public domain): si tratta di programmi, di
solito distribuiti anche sotto forma di sorgente, dei quali l'autore non
detiene più il Copyright (questo fatto avviene automaticamente qualora l'autore
non si esprima esplicitamente altrimenti, o comunque dichiari il software di
dominio pubblico). Senza dubbio di alto altruismo e levatura morale, questa
metodologia è andata in disuso dopo che alcuni programmi di dominio pubblico
sono stati leggermente modificati e poi venduti a caro prezzo da ditte non
proprio esemplari.

\item Software liberamente distribuibile (freeware): si tratta di programmi di cui
l'autore detiene il Copyright, ma che mette a disposizione degli utenti senza
richiedere nulla in cambio. Il mantenimento del Copyright garantisce
l'impossibilità (almeno teorica) di operazioni losche come quella di cui sopra.

\item Copyleft: si tratta di una speciale ``versione'' del concetto di Copyright
inventata dal gruppo GNU (un gruppo di programmatori che ha prodotto negli
ultimi anni una mole spaventosa di software sotto UNIX, e per riflesso sotto
\amiga{}). In sostanza, i programmi vengono distribuiti insieme al sorgente.
L'utente ha la possibilità di modificare a suo piacimento il pacchetto e
di ridistribuirlo modificato, se gli aggrada, purché gli avvisi di Copyright
rimangano intatti, e tutti i diritti di cui ha goduto l'utente vengano
trasmessi al successivo (possibilità di modificare il codice, etc.). In altre
parole, è una riedizione del dominio pubblico in cui però gli originatori usano
il proprio Copyright al puro scopo di impedire giochetti sporchi.

\item Shareware: si tratta di programmi distribuiti liberamente, ma per i quali
l'autore richiede, in caso di uso effettivo, il pagamento di una (in genere
modesta) cifra. Pochissime persone pagano effettivamente, il che è un vero
peccato.

\endlist

Il termine {\it software commerciale\/} denota invece i programmi che
normalmente vediamo nei negozi, e che vengono distribuiti tramite canali
commerciali standard. In genere, chi scrive e produce programmi commerciali lo
fa per vivere, contrariamente a chi scrive per le altre categorie.

Se si vuole accedere alla manna del software distribuibile, è necessario
armarsi di pazienza e, necessariamente, di un buon modem (ormai i 14400 V32bis
V42bis sono molto sotto il mezzo milione). Il modem apre immediatamente a
chiunque le porte di una comunità molto più vasta di quella in cui è abituato a
muoversi, con tutti i vantaggi del caso. Con un po' di attenzione è possibile
trovare BBS ricche di programmi distribuibili; inoltre, l'unirsi in gruppi di
utenti consente di dividere le spese telefoniche, dato che poi il software
raccolto è comunque replicabile a piacere.

È veramente triste, e non mi stancherò mai di ripeterlo, che proprio la
macchina dotata, per sua fortuna, di una quantità enorme di software gratuito e
ben scritto sia anche maledetta da una comunità telematica di così basso
livello.


\head *Le reti*

Più che di singole BBS, per telematica veramente distribuita si intedono le
grandi reti. Esse sono formate da centinaia, migliaia e anche più nodi, che si
connettono periodicamente (in alcuni casi anche permanentemente) per permettere
lo scambio di posta, conferenze e file.

La posta elettronica è stata giustamente paragonata alla televisione per la
radicale modifica delle abitudini che induce in chi la usa. È pressoché
impossibile anche solo immaginare cosa succederà quando tutta la popolazione
mondiale, e non solo pochi milioni di persone, avranno a disposizione questo
strumento.

Essenzialmente, ogni utente di una rete ha un indirizzo elettronico. Ogni altro
utente può mandare messaggi (di solito testi) ad un altro utente, specificando
il suo indirizzo. La posta elettronica arriva nel giro di minuti (anziché
giorni) e non richiede alcuno sforzo quale l'acquisto delle buste, dei
francobolli, eccetera. Naturalmente, non può neanche darci il piacere di una
carta scelta con gusto, o di una penna che scorre sul foglio, ma le nuove
tecnologie richiedono sempre dei compromessi. Chi scrive non ha mai tollerato
la fatica e la complicazione della posta normale, ma è diventato un fervido
sostenitore della posta elettronica dopo pochissimo tempo. E penso che ben poche
persone possano non condividere questa impressione.

Le conferenze ({\it news}) sono un analogo elettronico di una piazza in cui si
svolge una discussione. Ciascuno può dire la sua, o commentare l'opinione
altrui, in totale libertà. Anche in questo caso siamo accuratamente schermati
dalla fatica (ma anche dal piacere) di doverci spostare, impegnare in un
dibattito e così via. Il grande fascino delle conferenze è che spesso
personaggi di fama mondiale vi descrivono il proprio pensiero, ed è possibile
(nei limiti del buongusto) interpellarli ed ascoltarli.

Il trasferimento dei file è probabilmente la funzionalità più ``fredda'' messa
a disposizione dalle reti, ma è di utilità persino superiore alle precedenti.
Permette a persone sparse geograficamente su tutto il globo di collaborare a
stretto contatto su progetti comuni, e soprattutto fornisce un mezzo di
diffusione capillare ed istantaneo al software distribuibile, che senza le reti
sarebbe relegato sul disco rigido della macchina dell'autore.

Come accedere ad una rete? Ci sono reti amatoriali, tra cui spicca FIDO, a cui
si può accedere a costo zero semplicemente connettendosi mediante un modem ad
una BBS facente parte di esse. Per entrare invece in Internet, la grande rete
mondiale che connette le università ed i centri di ricerca, è necessario essere
studenti o dipendenti di un'università connessa.

L'utente medio \amiga{} ha come prima possibilità quella di collegarsi a FIDO
sfruttando una BBS della propria città. La connessione UUCP è invece
disponibile, ad esempio, diventando sviluppatori certificati presso la
Commodore.

Insisto sul fatto che collegarsi ad una BBS seria apre un mondo di nuove
possibilità. Certamente, nelle conferenze locali della BBS saranno presenti
persone in grado di darvi consigli dettagliati sulle opportunità migliori, che
variano considerevolmente da provincia a provincia.

\head *Programmare su \amiga{}*

Uno degli argomenti più scottanti, e su cui si diventa facilmente religiosi, è
la programmazione di \amiga{}. Fin dagli esordi, si sono formate due schiere
abbastanza compatte: i fanatici delle {\it poke}, che conoscono a memoria ogni
locazione utile, scrivono in esadecimale (Assembler? cos'è un Assembler?) e
misurano i tempi di esecuzione in millimetri di schermo, e i programmatori
cosiddetti ``seri'' che invece utilizzano linguaggi ``ad alto livello'' (leggi
C) e si mantengono scrupolosamente lontani dalla struttura fisica della
macchina.

Mentre il primo approccio poteva funzionare sul Commodore 64, su \amiga{} si è
rivelato assolutamente disastroso. Le numerose, diverse configurazioni hardware
e software disponibili hanno reso pressoché impossibile scrivere codice del
genere sperando di vederlo funzionare altrove che sulla propria macchina.
Migliaia e migliaia di ore/uomo sono state biecamente sacrificate invece di
essere utilizzate produttivamente.

Questo, ovviamente, non significa che con le dovute attenzioni non si possa
prendere il controllo della macchina e farle fare cose particolari. In
particolare, sotto 3.1 la |lowlevel.library| permette di disattivare
selettivamente parti del sistema operativo. E ci sono programmi perfettamente
legali, come |SuperDuper|, che accedono in modo controllato allo hardware per
migliorare le proprie prestazioni.

La sragionevolezza dello smontare il sistema operativo sta nel fatto che Exec è
incredibilmente efficiente. Non fornisce servizi come la protezione della
memoria, o spazi di indirizzamento virtuale separati, ma ha un sovraccarico
assolutamente irrisorio. È pura fantasia pensare di poter fare di meglio. E, se
anche si riuscisse, si costringerebbe il proprio software a restare congelato
nel suo stato presente per sempre, a meno di non dedicarvi ancora energie.

Un tipico esempio è il file requester di sistema: sotto 2.04 era decisamente
lento, ma sotto 2.1 è diventato uno dei migliori. Chi ha avuto la preveggenza e
la costanza di chiamare le funzioni di sistema ne ha ricevuto, a costo zero, un
miglioramento immediato delle prestazioni dei propri programmi. Per non parlare
dell'effetto sugli utenti, che si ritrovano sempre lo stesso file requester, e
non devono imparare trenta volte il significato di bottoni esoterici come
``GetDir''.

Come fare a sfruttare queste informazioni? La parola magica qui è {\it
documentazione}, la bestia nera del programmatore, sempre pronto a provare a
mano se una certa funzione accetta un parametro, o ad indovinare il contenuto
di un registro con qualche scrittura a caso. Non credete a chi vi dice di aver
fatto meraviglie senza aver letto un manuale: è anche possibile che sulla sua
macchina, durante una bella giornata, e con gli eventi astronomici (fasi
della luna, eccetera) favorevoli, il suo software possa funzionare. Ma
programmare non è questo. Un vero programma funziona ora, funzionerà tra dieci
anni. Non solo: tra dieci anni funzionerà {\it meglio}. L'articolo che state
leggendo è stato impaginato da \TeX, un programma scritto da D.E. Knuth nel
1973. Regge bene l'età, non trovate?

La documentazione di \amiga{} è contenuta essenzialmente nei RKM, i famigerati
Rom Kernel Manual, nella loro attuale incarnazione: {\it Libraries}, {\it
Devices}, {\it Includes \& Autodocs}, {\it User Interface Style Guide} e {\it
Hardware Manual}. Sono la base, assolutamente necessaria, per comprendere il
funzionamento delle varie parti del sistema. La loro reperibilità non è
esattamente di chiara fama, ma è possibile ordinarli alla Hoepli di Milano,
alla Clup del Politecnico di Milano, o da Hirsch \& Wolf, il distributore
ufficiale di materiale per \amiga{} della Commodore in Europa (Hirsch \& Wold
oHG, Attn: Hans-Helmut Hirsch, Mittelstr. 33, D-56564 Neuwied 1, Germania;
Tel.:~+49-2631-839-90; FAX:~+49-2631-839931; e\_mail:
|hhhirsch@carla.adsp.sub.org|).

Tra gli RKM è assolutamente necessario procurarsi, nell'ordine, {\it Libraries}
e {\it Devices}. {\it Includes \& Autodocs} è disponibile su disco o CD-ROM in
formato ipertestuale e, in caso di ridotte capacità di acquisto, la {\it User
Inferface Style Guide} può aspettare. Lo {\it Hardware Manual\/} è
essenzialmente inutile per la scrittura del 99\% dei programmi.

Ovviamente, i libri non possono stare dietro allo sviluppo costante del sistema
operativo. {\it AmigaMail}, un periodico pubblicato dalla Commodore, provvede
ad aggiornare continuamente le informazioni degli RKM, ed a fornire esempi
completamente svolti. Gli sviluppatori registrati con la Commodore lo ricevono
periodicamente per via postale, ma è possibile acquistarlo anche attraverso
Hirsch \& Wolf.

Programmare significa anche scegliere un linguaggio adatto. Negli ultimi mesi
sono fioriti diversi ambienti di sviluppo per \amiga{}, che può ormai vantare
eccellenti implementazioni di C, C++, Pascal, Oberon-II e Scheme, nonché
linguaggi specifici dell'architettura come il nuovissimo \amiga{} E. Per molti
di questi linguaggi sono disponibili compilatori o interpreti liberamente
distribuibili (vedi per esempio lo GNU C).

È comunque necessario possedere un sistema di sviluppo di base in C. Il sistema
operativo stesso di \amiga{} è stato scritto in questo linguaggio, ed è quindi
quello da scegliere per applicazioni vicine al sistema (handlers, per esempio).
Una buona conoscenza dell'Assembler 680x0 è però utile, e direi anche
necessaria, se si devono andare a mettere le mani in cose delicate come la
gestione delle interruzioni. Il sistema di sviluppo C ``ufficiale'' (nel senso
che viene usato internamente alla Commodore) è il SAS/C, che contiene ora anche
un compilatore nativo C++, ed è disponibile ad un prezzo modico (circa 400
marchi tedeschi) per gli studenti, previo invio di un FAX con ordine e
fotocopia del libretto universitario alla SAS tedesca
(SAS Institute GmbH, Attn: Ms.~Gerlinde Schuster, Postfach 10 53 40,
D-69043 Heidelberg, Germania; Tel.: +49-6221-4160; FAX: +49-6221-474850; solo
per avere informazioni, e non per ordinare, è possibile mandare posta
elettronica a |eurdoc2@vm.sas.com|).


Quanto al linguaggio di uso comune, è difficile prescindere dal gusto e
dall'esperienza personale. Ogni linguaggio ha la propria schiera di
irriducibili sostenitori, ed è veramente difficile fare delle valutazioni
obiettive. Il miglior consiglio che si possa dare è provare, provare, provare.

Ma programmare è anche, e forse soprattutto, un esercizio di {\it stile}. Il
grande programma è il programma che con {\it nonchalance}, e senza violare una
sola regola del sistema, ottiene risultati eclatanti. I programmi ``legali'' ma
inefficienti, così come gli {\it hack} da un pomeriggio che la mattina dopo
fanno esplodere la macchina, decisamente non inducono nell'utente, o nel
programmatore, alcun sentimento di rispetto. Un grande programma funziona bene
oggi, è pensato per funzionare meglio domani, e soprattutto funzionerà sempre,
e sempre al meglio. Una certa obsolescenza è inevitabile, ma non può sfuggirvi
l'ironia del fatto che |TurboBackup|, un programma scritto nel 1988, che gira
in multitasking e che non usa quasi risorse ancora oggi duplichi dischi più
velocemente di |XCopy|, del quale si grida ``miracolo'' già se riesce a
rientrare nel Workbench senza troppi danni, ma da cui ci si aspetterebbe ben
altro, considerato che ci impedisce di utilizzare il resto della macchina.


\head *ADSP*

Se volete programmare su \amiga{}, anche a livello amatoriale (scrivendo cioè
software distribuibile), potete considerare l'idea di registrarvi come
sviluppatori presso la Commodore. Dettagli sull'Amiga Developer Support Program
sono disponibili negli atti di questo IPISA. Essenzialmente, al costo di una
tassa di iscrizione annuale, la Commodore fornisce assistenza tecnica, sconti
massicci sulle macchine e sulla documentazione, e l'accesso a UUCP e Internet
tramite la connessione di ADSPNet. Se poi state sviluppando software
commerciale, ADSP prevede sconti maggiori, visionamento delle macchine prima
della messa in produzione e così via. Ovviamente, per diventare sviluppatori
commerciali dovete dimostrare di stare sviluppando un prodotto commerciale.


\head *Gli strumenti di sviluppo*

\amiga{} dispone di eccellenti strumenti di sviluppo, tutti o quasi tutti
liberamente distribuibili, o al più shareware.

Il più antico e celebre è certamente |Enforcer| (=poliziotto). Funziona solo su
macchine che possiedono una MMU, e traccia attraverso di essa tutti gli accessi
a zone ``da non toccare'' della memoria. Tipicamente, tutti i tentativi di
utilizzare puntatori nulli producono un |Enforcer| hit, cioè la stampa (sulla
porta seriale, o parallela, o ancora su un file) del punto in cui l'accesso è
avvenuto, il contenuto dei registri è così via.

|Enforcer| collabora con un'altro strumento, |SegTracker|, che fin dalle prime
righe della \discretionary{|startup-|}{|sequence|}{|startup-sequence|} provvede
a tracciare chi possiede le zone di memoria caricate da |LoadSeg()|. In questo
modo, quando il codice produce uno hit è possibile fornire il nome del file
eseguibile, lo hunk e l'offset, rendendo immediato il risalire alla linea di
codice mediante |FindHit|.

Meno noto, ma utilissimo, |Mungwall| offre una serie di servizi di controllo
della memoria: essa viene sporcata prima di essere allocata, quando viene
deallocata, e in generale tutta la RAM libera viene riempita di pattume
riconoscibile come |$C0DEDBAD|, |$DEADBEEF$|, |$ABADCAFE| e così via. Inoltre,
ogni allocazione viene ``circondata'' da due muretti riempiti con caratteri
specifici, in maniera che venga rilevato qualunque ``sfondamento''
dell'allocante al di fuori dell'area allocata. Per finire, la locazione zero
viene sporcata ({\it munged\/}) in maniera da peggiorare in maniera visibile
l'effetto dell'indirezione dei puntatori nulli.

|Sushi|, il recente tool di Carolyn Schnepper, è un toccasana per tutti coloro
che non posseggono un modem o un secondo \amiga{} connesso sulla porta
seriale. Infatti, |Sushi| può catturare l'uscita di |Enforcer| e |Mungwall| e
riportarla in un file o su video.

|Scratch| provvede invece a distruggere metodicamente i contenuti di tutti
registri che non vengono conservati dalle chiamate alle librerie (|d0|,|d1|,|a0|
e |a1|). Può infatti accadere che per un puro effetto collaterale qualche
registro venga preservato, e a causa di ciò un buco di un programma potrebbe
non essere più rilevabile.

|Memoration| provvede a simulare qualunque condizione di mancanza di memoria.
Può infatti far credere a qualunque task che sulla macchina ci sia solo una
certa quantità di memoria, o inibire tutte le allocazioni superiori ad una
certa soglia. |Memoration| è uno strumento essenziale per il controllo di parti
di codice che gestiscono eccezioni verificantisi molto raramente.

Questa lista comprende essenzialmente i tool più importanti, ma moltissimi
altri sono reperibili attraverso i Developer Disk (da Hirsch \& Wolf) o sulle
reti informatiche. È incredibile quanto il rilevamento dei buchi e dei
malfunzionamenti si sia semplificato grazie a questa messe di programmi.

\head *Documentate, documentate, qualche cosa resterà*

La scrittura della documentazione è decisamente la croce del programmatore. Sia
essa pensata per altri programmatori, che per gli utenti finali, rimane un
incubo continuato.

Due soluzioni tecniche hanno preso piede nel mondo Amiga. Nel primo caso
(documentazione per programmatori, in genere per librerie) si può usare
|AutoDoc|, lo strumento utilizzato dai pionieri che progettarono \amiga{} fin
dalle prime fasi del progetto. Essenzialmente, una documentazione essenziale
viene inclusa {\it direttamente nel sorgente}, permettendone così una
manutenzione immediata. Nel momento in cui occorre generare un documento vero e
proprio, |AutoDoc| estrae le parti interessate e le mette in ordine alfabetico.
|AD2AG| provvede poi, se si desidera, a trasformare il tutto in un documento
ipertestuale per AmigaGuide.

Approfittiamo di |AD2AG| per parlare di AmigaGuide, il sistema di
visualizzazione di ipertesti di \amiga. Da pochi mesi, AmigaGuide è
ufficialmente liberamente distribuibile, e questo ha fatto letteralmente
esplodere un fenomeno prima relativamente sommesso, vale a dire la scrittura
della documentazione del software distribuibile e commerciale in forma
ipertestuale.

La strada più seguita fino ad ora dai programmatori è di utilizzare uno
strumento della GNU modificato e adattato ad AmigaGuide da Reinhard Spisser e
me, |makeinfo|. Esso provvede a trasformare un file |Texinfo|, scritto in un
semplice dialetto di \TeX{} particolarmente adatto alla documentazione tecnica,
in un documento ipertestuale AmigaGuide o in un file ASCII. Lo stesso documento
|Texinfo| compilato con \TeX{} si trasforma in un eccellente manuale stampato,
dove i riferimenti ipertestuali diventano riferimenti incrociati.

|Texinfo|, che è stato presentato nella sua prima versione all'IPISA '92,
permette di soddisfare tre esigenze (manualistica stampata, documentazione
ipertestuale, file ASCII) a partire da un solo sorgente. I vantaggi pratici
dovrebbero essere evidenti di per sé.

\head *Comprare all'estero*

Una soluzione relativamente semplice alla mancanza della distribuzione del
software commerciale per \amiga{} in Italia è l'acquisto diretto in altre
nazioni (di solito gli Stati Uniti). Per ottenere un risultato ragionevole è
bene unirsi in gruppi di acquirenti, in modo da ammortizzare al massimo le
spese di spedizione.

Infatti, il modo più semplice e sicuro di fare arrivare merce è tramite un
corriere postale (come DHL o Federal Express), che si preoccupa anche del
disbrigo di tutte le pratiche di sdoganamento, che sono un vero inferno.
Nel caso compriate materiale per posta ordinaria, informatevi attentamente alla
dogana centrale di Milano su che documenti produrre per evitare di essere
considerati acquirenti di giochi, sottoposti ad un'IVA mostruosa (sto,
ovviamente, supponendo che {\it non\/} vi interessi comprare giochi).

La maniera più semplice (in pratica l'unica) per effettuare l'acquisto è
utilizzare una carta di credito. Vorrei far notare a chi non si fosse mai
interessato dell'argomento che ormai la spesa per una VISA/CartaSì è, per uno
studente, dell'ordine delle L.50.000 all'anno, una cifra, a mio avviso, più che
sacrificabile, considerando gli enormi vantaggi che ne derivano. Basta un FAX
ad un rivenditore di software per posta, corredato di numero e fotocopia della
carta di credito, per ottenere nel giro di due settimane il software e
l'hardware richiesto. I nomi di numerosi rivenditori di questo tipo sono
recuperabili sulle riviste specialistiche d'oltreoceano (leggi AmigaWorld).
Molti rivenditori mettono a disposizione una linea verde per gli ordini
dall'Italia (cioè non pagate nulla), purché l'ordine abbia importo superiore ad
una certa cifra. Se vi fidate del vostro inglese, la cosa è molto più semplice,
specie se non avete un FAX. Anche Hirsch \& Wolf accetta ordini tramite carta di
credito.

\head *Pagare lo shareware*

Non canterò in questa sede un peana all'acquisto del software originale,
argomento così ovvio, trito e ritrito da diventare nauseabondo. Vorrei fare
invece un discorso molto più ``forte'' e concreto: {\it pagate lo shareware}.

È infatti diventata una situazione comune, per il programmatore amatoriale di
\amiga{} che vuole guadagnare un piccolo compenso per lo spesso enorme lavoro
fatto, il non ricevere nulla o quasi.

Le ragioni sono tante: mancanza d'attenzione, di denaro... Ma il vero problema
è che sempre più persone abbandonano progetti a causa di questo disinteresse.
Lo shareware è una risorsa preziosissima di \amiga{}, che non possiamo
permetterci di perdere. Se state utilizzando dei programmi shareware, mandate
agli autori quei pochi dollari che vi chiedono (si tratta quasi sempre di cifre
molto modeste). A parte sonni più tranquilli, avrete certamente reso più felice
il programmatore, che essendo di buonumore metterà meno buchi nella versione
successiva.


\head *Siate esigenti*

Concludo questo articolo con un ultimo appello: {\it siate esigenti}. Quanto
comprate o provate un nuovo programma, sia esso commerciale o distribuibile,
non subite passivamente le scelte di implementazione dell'autore. Chiedetevi
sempre se l'interfaccia è standard, se il programma sfrutta bene le risorse
della macchina, se mancano delle funzionalità ovvie. Se poi siete
programmatori, o comunque utenti smaliziati, non date tregua: picchiatelo con
|Enforcer|, |Mungwall|, |Memoration|, |Scratch|, e chi più ne ha più ne metta.
Non è possibile che programmi come |PageStream|, giunto ormai alla versione
3.0, producano ancora |Enforcer| hit. E non è concepibile che programmi pagati
col sudore della nostra fronte si permettano di schiantare la macchina in
condizioni di poca memoria.

Allo stesso modo, non accettate restrizioni arbitrarie sullo hardware che
comprate. Il mercato di schede ed accessori per Amiga è saturato da materiale
di pessima fattura, che spesso non è compatibile con schede perfettamente
progettate. Cercate di aver letto qualche recensione, o (meglio ancora) di aver
visto in funzione per un certo periodo di tempo ed in configurazioni diverse il
tipo di scheda o accessorio che volete comprare: non sempre quello più
economico si rivelerà un buon acquisto.

La comunità \amiga{} è da sempre una delle più esigenti (ad esempio, un utente
\amiga{} non tollererebbe {\it mai\/} di vedere bloccata la macchina durante
una stampa in rete, come avviene per AppleTalk). È una tradizione dovuta alla
grande percentuale di utenti amatoriali, e di programmatori innamorati della
macchina. Questa è, secondo il mio modesto parere, una grande forza, ed è
dovere di tutti trasmettere le buone abitudini ai nuovi utenti.

Ringrazio Stefano Basagni, Marco Menegon, Paolo Silvera, Reinhard Spisser e
Carlo Todeschini per i suggerimenti e le correzioni apportate a questo articolo.

\makesignature

\endarticle