\articolo{La preparazione di un CD-ROM per Amiga}{Luca Danelon e Matteo
Forniz}%© 1996, Interactive di Luca Danelon
\index{Danelon!articolo di}

\paragrafo{Premessa}
Questo testo non vuole assolutamente essere una ``guida pratica alla
produzione di CD su \A'', ma proporre invece alcune piccole riflessioni
sui problemi generati da una tale attività e sul miglior modo per
risolverli.

\paragrafo{Introduzione}
Il presente intervento nasce dalla nostra personale esperienza nei mesi
passati a creare il CD ``Amy Resource\index{Amy Resource}'',
edito da Interactive. La parola ``creare'' è veramente molto generica
nell'ambito del discorso ora iniziato, in quanto ad alcuni può far credere
si tratti solo di una semplice operazione di
masterizzazione\index{masterizzazione}, oppure ancora la sola e semplice
realizzazione dei contenuti del CD-ROM\index{CD-ROM}. In realtà, abbiamo
utilizzato volontariamente questa parola proprio perché il CD-ROM che
Interactive produce e distribuisce è interamente realizzato sui nostri
Amiga 4000 e 1200. Quindi non vi è solo la fase di preparazione dei
contenuti (che tra l'altro è la fase più dispendiosa in termini di tempo),
ma anche la masterizzazione del gold disk\index{Gold disk}, cioè della
prima copia del CD, la preparazione delle copertine e della sovrastampa del
CD stesso. Questo intervento non vuole però avere la pretesa di insegnare
tutti questi passaggi, ma solamente di svelare alcuni piccoli trucchi che
hanno permesso di rendere più agevole il lavoro e soprattutto che si sono
dimostrati utili per realizzare un prodotto completamente dedicato ad \A.

\paragrafo{I sistemi utilizzati}
Il computer utilizzato per tutti i passaggi della produzione è stato un
Amiga 4000/040, dotato di 18 Mb di memoria, HD IDE da 1,7 Gb, HD SCSI da 1
Gb, controller SCSI DKB RapidFire, scheda grafica CyberVision64 con 2 Mb,
masterizzatore Yamaha CDR-102 più vari supporti di memorizzazione (Iomega
Zip, Syquest 270, CD-ROM ed i classici floppy DD e HD), utilizzati
soprattutto per l'interscambio di dati con i collaboratori e con i service
utilizzati. Il mio collaboratore invece ha utilizzato un Amiga 1200 con
Blizzard II 68EC030 50Mhz, 68882 50Mhz e 24Mb di memoria Fast, controller
Squirrel SCSI, Iomega Zip per studiare una bozza delle copertine e
soprattutto per raccogliere e preparare la gran parte del materiale grafico
inserito su CD-ROM.

\paragrafo{La masterizzazione}
La masterizzazione è quel passaggio che permette di memorizzare dei dati
generici (in formato digitale) su supporto CD. Il Compact Disc, come è
ormai noto, è un supporto a sola lettura: questa limitazione è dovuta alla
stessa costituzione fisica del supporto, che permette una sua manipolazione
in lettura/scrittura solo tramite un raggio laser proiettato sulla
superficie lucida del CD, che contiene delle tracce circolari simili a
quelle dei vecchi dischi in vinile. Anche nel CD infatti sono presenti
delle micro-incisioni che generano, nel caso dei dati in digitale, un
cambiamento del numero binario; al contrario però dei lettori di dischi al
vinile, che generavano un suono basandosi sui {\bf diversi} rilievi
presenti sui dischi stessi, i lettori CD si basano su tecnologia digitale,
e quindi bastano due sole posizioni per segnalare un cambiamento binario,
come risulta dalla figura seguente:
%
\begin{center}
\includegraphics[width=\columnwidth]{danelon/pics/immagine1.eps}
\end{center}
%
Il CD è fisicamente costituito da un disco di plastica di 12 cm di diametro
e di altezza pari a 1,2\unit{mm}, con una superficie argentata che
riflette il raggio laser utilizzato per leggerlo. Il CD è costituito da
diversi strati: il primo, di plastica trasparente, con funzione protettiva.
Il secondo è invece un sottilissimo foglio di alluminio che contiene i
microsolchi, che viene appoggiato ad un terzo strato con la funzione di
matenere rigido il foglio di alluminio (figura \ref{struttura}).
%
\begin{figure}
\centering
\includegraphics[width=\columnwidth]{danelon/pics/immagine2.eps}
\caption{Struttura di un CD.} \label{struttura}
\end{figure}
%
Lo standard per masterizzare questo tipo di supporti è chiamato ISO
9660\index{ISO 9660}, e ne esistono due ``livelli'': il primo, più
restrittivo, è quello dedicato alla piattaforma PC e comprende limitazioni
nel nome dei file (8 caratteri, un punto e tre caratteri di estensione,
tutti rigorosamente maiuscoli e con severe limitazioni sui possibili
caratteri da utilizzare), nella struttura (al massimo 8 ramificazioni) ed
anche nel nome utilizzato come titolo (undici caratteri).

Il secondo livello è invece pensato per i nuovi sistemi operativi o
piattaforme quali Mac e \A, e permette nomi di file a 32 caratteri,
presentando inoltre in generale minori restrizioni rispetto al primo
livello.

Nonostante questo, l'ISO 9660 ha ancora alcune limitazioni che il
file-system \A, nonostante i diversi anni d'età, supera senza problemi.
Ecco quindi il primo problema, risolvibile analizzando il target a cui si
rivolge il CD: scegliere infatti di masterizzare il CD seguendo ciecamente
le specifiche ISO 9660 oppure trasgredire questo standard in vista di una
maggiore personalizzazione del prodotto per la piattaforma per cui è stato
creato.

La scelta è ricaduta su quest'ultima possibilità, anche pensando 
proprio ai contenuti del CD: creare infatti un prodotto dedicato 
alla nostra piattaforma, ma che presenti limitazioni proprie 
solamente di altre piattaforme è parso assurdo, e per questo 
sono stati utilizzati particolari accorgimenti che rendono il 
CD perfettamente godibile {\em senza limitazioni} su \A, a scapito 
della perdita di una rigorosa compatibilità con lo standard ISO 9660.

Alcune di queste scelte includono la possibilità di avere più di 
8 ramificazioni (e questo lo si può vedere anche nel ``volume zero'',
in cui è stata inserita, in una serie di cassetti nascosti 
al Workbench, una simpatica animazione) o la possibilità di 
includere anche nomi dei file con particolari caratteri 
riservati (precisamente, \verb+~+ e \verb+#+).

La masterizzazione pratica di un CD è stata poi separata in due parti:
creazione dell'immagine del CD e suo riversamento sul supporto. Questi due
passaggi si sono resi necessari in quanto riportare i dati presenti su HD
direttamente su CD era impossibile se non possedendo un velocissimo hard
disk in grado di erogare un flusso continuo di dati senza pause e/o
variazioni per oltre mezz'ora di tempo (tempo necessario alla
masterizzazione di un CD con un masterizzatore 2x).

Anche se su \A esiste MasterISO\index{MasterISO}, programma capace di
generare immagini ISO e poi riversarle su CD, è stato scelto di utilizzare
per la prima parte del processo un programma separato, ed esattamente
\c{mkisofs}, che si può trovare nelle raccolte edite da Fred Fish.
Questo perché quest'ottimo programma (frutto di un porting da Unix)
permette una personalizzazione maggiore dell'immagine da creare rispetto al
prodotto commerciale della AsimWare: MasterISO infatti, forse per volersi
adattare allo standard ISO 9660 di cui prima, non presenta opzioni
rilevanti di personalizzazione dell'immagine.

Per la seconda fase della masterizzazione, cioè il passaggio 
dei dati da HD a CD, è stato invece utilizzato proprio 
quest'ultimo software, che comunque mostra ancora 
alcuni problemi o incompatibilità.

Il consiglio forse più importante da dare a chiunque debba operare la
masterizzazione su \A è quello di dotarsi di diversi Mb di memoria, per
permettere così all'HD da cui si preleva i dati un po' di ``respiro''
(creando dei buffer da cui il masterizzatore si copia le informazioni), e
soprattutto per non permettere a MasterISO di bruciare diversi CD prima di
giungere allo scopo.


\paragrafo{Le copertine}
Le copertine sono state create direttamente su \A, tramite i noti programmi
di grafica Photogenics 2.0, ImageFX e l'immancabile Personal Paint 6.4.
Senza entrare nel merito delle creazioni artistiche che potete ammirare
sulle copertine (e per cui ringraziamo il noto disegnatore
{\selectlanguage{english}Eric Schwartz}), presentiamo solo qualche
annotazione: ad esempio il fatto di aver utilizzato molte volte il Personal
Paint, accanto a Photogenics 2.0, per ritoccare dei dettagli o per
preparare gran parte delle scritte che compaiono sulle copertine. Per
ragioni di tempo e di esperienza, siamo stati portati infatti a scegliere
un programma di grafica pittorica (i succitati ImageFX o Photogenics) anche
per le parti testuali delle copertine, piuttosto che ricorrere ad un
programma di impaginazione quale PageStream o Final Writer. La ragione
principale alla base di questa scelta, oltre alle già citate variabili
tempo ed esperienza, è stata l'incerta compatibilità del formato EPS
salvato dai programmi \A con i package utilizzati dal service tipografico.
Per non rischiare quindi di dilatare ulteriormente i tempi d'uscita del
nostro prodotto, è stata compiuta questa scelta sicuramente limitante la
qualità finale delle parti testuali: per cercare di ovviare comunque alla
perdita di qualità abbiamo optato per quei caratteri utilizzanti la
tecnologia AGFA Intellifont. Questi infatti sono ormai da tempo supportati
da AmigaOS e quasi tutti i maggiori programmi di grafica e DTP ne
interpretano il formato (direttamente oppure tramite la loro immagine
bitmap).

Giova ricordare come i caratteri di tipo Intellifont\index{Intellifont} si
discostino da quelli bitmap in quanto le differenti grandezze sono create
non più operando banali operazioni di rescaling, quanto invece ricalcolando
funzioni matematiche descrittive del set di caratteri prescelto. \`E questo
per sommi capi il medesimo principio che anima le tecnologie TrueType e
Adobe.

\`E bene determinare in maniera positiva anche l'aspect ratio associato 
alla modalità video con la quale ci si trova a lavorare.

In questa maniera è possibile avvicinarsi ad un ambiente 
WYSIWYG (``What You See Is What You Get''), dove cioè tutto quello che 
appare ``a video'' ha all'incirca la medesima qualità di come apparirebbe su 
di un'altra periferica (tipicamente una stampante).

Un esempio chiarificatore può essere l'esercizio di realizzare un quadrato 
di 100 pixel di lato su due modi video differenti. Operando in modalità 
Pal LowRes ogni pixel ha un aspect ratio di 44/44 (cioè la larghezza è pari 
all'altezza); ciò fa si che il quadrato sopra citato sia effettivamente 
composto da 10.000 pixel. Ma passando ad esempio alla modalità Ntsc 
LowRes accade che l'aspect ratio di un pixel sia pari a 44/52.

Ne consegue che un quadrato che presenti il medesimo ``ingombro visivo'' in
questo frangente sarà in realtà un rettangolo con dimensioni 100$\times$85
pixel. Questo ragionamento introduttivo (ripreso da vecchi paper tecnici
Commodore), può essere ripreso anche per i font ComputerGraphic.

Tali famiglie di caratteri hanno infatti già determinato al loro interno i 
valori (in DPI), relativi all'asse $X$ ed a quello $Y$. Questi sono valori
{\em reali}, riflettono cioè una effettiva impostazione di stampa espressa
in punti per pollice. Quando però si accede ad un font, si pone il medesimo
problema accennato poc'anzi: ottenere una non distorta rappresentazione ``a
video''.

Qualora non sia l'applicazione stessa ad impostare un aspect 
ratio corretto, questo deve essere comunicato in qualche modo dall'utente. 
In questa maniera la diskfont.library è in grado di scalare opportunamente il 
font prescelto.

Nella sostanza l'applicazione ottiene un carattere con il medesimo 
\c{YDPI} (già impostato permanentemente nel font), ma con un nuovo \c{XDPI} 
calcolato sulla scorta del valore YDPI di cui sopra e dell'aspect 
ratio fornito. Questo avviene in quanto nell'ambiente \A la grandezza 
di un font (size), viene considerata come la sua altezza (calcolata in pixel).

L'utente può comunicare al sistema operativo l'aspect ratio più consono 
modificando (o creando) la variabile ambiente
\spath{SYS:Prefs/Env-Archive/DiskFont}.

Si tratta di un file ASCII contenente le seguenti informazioni:
\begin{center}
\c{XDPI {\em xxx} YDPI {\em yyy} XDOPT {\em xxx} YDOPT {\em yyy}}
\end{center}
I valori espressi devono essere numerici e qualora il file non esista il
sistema operativo procederà con dei valori di default.

Una volta impostato un parametro (\c{DPI} o \c{DOPT}), bisogna assegnare un
valore anche al corrispondente valore in \c{X} o \c{Y}.

XYDPI rappresenta appunto l'aspect ratio, mentre \c{XYDOPT} inerisce lo
spazio riempito da un punto in relazione alla risoluzione dello schermo.

Come citato nel manuale utente del WorkBench 3.0, occorrono valori 
molto grandi o piccoli di \c{XYDOPT} per notare qualche differenza.

Seguono a scopo informativo alcuni aspect ratio desunti da differenti modi
e risoluzioni video.
%
\input{danelon/tabella1.tex}
%
%(Tabella 1)
%
\noindent Le copertine sono state realizzate alla reale dimensione
richiesta dal tipografo, e quindi il solo picture disc aveva un diametro
ben superiore ai 1500 pixel. Se poi si considera che le parti del booklet
devono essere preparate già affiancate per la stampa, si deduce ben presto
che le risoluzioni sono veramente elevate. Abbiamo preferito lavorare
subito a queste risoluzioni, anche se con tempi di lavoro un po' più
lunghi, dovuti ad estenuanti attese per il caricamento o la memorizzazione
delle immagini, per ottenere la massima qualità possibile. Per questo, la
principale caratteristica sfruttata di Photogenics è stata la ``memoria
virtuale'', un particolare sistema interno che permette di caricare
immagini di qualunque dimensione e profondità senza doversi dotare di
decine di Mb di memoria. Questo perché l'immagine non viene caricata in
memoria, ma in un file in formato IFF DEEP\index{Iff deep} residente su
hard disk: questo passaggio permette di occupare solamente la memoria
necessaria alla visualizzazione dell'immagine nella finestra di preview di
Photogenics, a scapito di un ristretto numero di operazioni da compiere
sull'intera immagine. Questo però non ha rappresentato un grosso problema,
anche perché, come si diceva poc'anzi, il lavoro di creazione della
copertina è stato suddiviso in parti e quindi si lavorava solamente su una
piccola parte dell'immagine caricata.

Questa comoda opzione di Photogenics ci porta ad affrontare alcune 
considerazioni sulla memoria virtuale, tutt'altro che oziose, sebbene 
in quest'ultimo anno il prezzo delle SIMM (banchi di memoria) 
sia drasticamente diminuito.

Innanzitutto bisogna richiamare l'attenzione sul fatto che il 
paradigma ``memoria virtuale = MMU'' sta andando vieppiù 
scomparendo. Quasi tutti i programmi di un certo ``peso'' adottano infatti 
tecniche proprietarie per alleviare l'utilizzo di RAM reale 
appogiandosi ad operazioni di lettura e scrittura di file.

In secondo luogo la produzione di immagini tipografiche di alta 
qualità è un processo che richiede veramente molta memoria, più di 
quanta forse un utente medio (oppure disinteressato all'argomento), possa sospettare.

Ma in ultima analisi, è di fondamentale importanza ricordare come gli \A 
della classe 1200 si trovino ad affrontare la seguente situazione: la 
totalità delle schede acceleratrici più recenti, prevedono 
un solo slot per le SIMM (delegando il secondo in genere ad un 
controller SCSI da acquistare separatamente).

Se è vero che la complessità di un processo creativo cresce generalmente 
molto più velocemente della dotazione hardware posseduta, sarà molto 
comune essere in difetto nella propria configurazione all'inizio di un 
progetto mai affrontato. Ecco quindi come un'efficiente implementazione 
delle routine di gestione della memoria virtuale non sia affatto di secondo piano.

Quello che segue è un piccolo test compiuto su di una texture IFF a 
24 bit con risoluzione 640$\times$480 (la cui dimensione in kilobyte è
911.232).

L'operazione svolta dai programmi impiegati è un ``banale'' resizing a 
1280$\times$960, abilitando la migliore qualità possibile di questa opzione.

\input{danelon/tabella2.tex}
%(Tabella 2)

\noindent Sebbene confronti incrociati tra i programmi sopracitati siano
francamente azzardati (a causa della non uniformità delle condizioni della
prova ed anche a causa del diverso trattamento dei dati utilizzato da ogni
software), è molto interessante osservare la differenza tra le operazioni
compiute in memoria Fast con quelle utilizzanti la memoria virtuale
(associata ad uno Iomega Zip collegato ad una interfaccia non DMA quale è
la Surf Squirrel). Quello che qui si vuole notare è l'attenzione spesa
nell'implementare questa utile funzione: è stupefacente riscontrare
l'attenzione che i programmatori del secondo e del terzo pacchetto
(rispettivamente shareware e freeware), hanno portato nella gestione della
memoria virtuale.

Auspicando che i risultati ottenuti siano quantomeno tendenziali, si può
capire immediatamente come trattando le illustrazioni con effetti più
complessi, una superficiale (o mancante),implementazione di questa feature
possa esasperare anche gli utenti più ascetici.

%
% I programmi citati sono copyright dei rispettivi proprietari.
% MasterISO Copyright © 1993-1996 Asimware Innovations Inc.
% Photogenics Copyright © 1994-1996 Almathera Systems Ltd.
% Personal Paint Copyright © 1992-1995 Cloanto Italia Srl
% MKISOFS Copyright Yggdrasil Computing, Inc.
%         AmigaDOS porting by Frank Munkert

%\paragrafo{Bibliografia}
Informazioni sulla tecnica di funzionamento del supporto CD si possono
trovare all'indirizzo \path|http://www-us.philips.com/sv/newtech/cd.html|
oppure anche su vari articoli di Amiga Magazine, periodico mensile edito
dal Gruppo Editoriale Jackson.

\autore{Luca Danelon\\
Via Bolzano, 2\\
33010 Feletto Umberto (UD)\\
e-mail: \c{danelon@interlandsrl.it}}{}


\citazione{\selectlanguage{english}The reasonable man adapts himself to the
world; the unreasonable man persists in trying to adapt the world to
himself. Therefore, all progress depends on the unreasonable man}{George
Bernard Shaw}