\nuovoarticolo{Paolo Canali}{Tendenze e nuove architetture hardware per la multimedialità}{% Paolo Canali \\ Via P. Roques 1 \\ I-56123 Pisa PI \\ Tel.:~(050)564348 }{}{italian}{\selectlanguage{english} Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS process$\ldots$}{} \sez{Introduzione} Recentemente si è chiaramente definita un'ulteriore funzionalità che i personal computer devono possedere: la capacità di trattare in tempo reale animazioni e suoni digitalizzati, per gestire la cosiddetta ``multimedialità''. Di conseguenza, entro breve tempo tutti i PC avranno due nuovi componenti aggiuntivi, indispensabili come la memoria o un disco fisso: i sottosistemi per il video in movimento e per l'audio digitale. Questa rivoluzione che turba i pensieri degli utenti di altre piattaforme sta passando quasi inosservata per gli utenti \amiga{}, che essendo stato il primo computer multimediale sono da sempre abituati ad avere di serie tutto ciò che occorre. Tuttavia l'esplosione dell'offerta di soluzioni multimediali sta complicando il panorama delle tecnologie e dei prodotti. Entro breve tempo il chip-set dei futuri \amiga{}, per quanto sofisticato possa essere, rappresenterà solo una soluzione di base da personalizzare secondo le proprie esigenze e disponibilità. Ad esempio, ben pochi degli \amiga{} e IBM compatibili attuali sono equipaggiati di una scheda dedicata per la gestione del video digitale in movimento, che rappresenta uno dei cardini della multimedialità. Ci si arrangia con CPU e chip grafico, cosa che ad \amiga{} riesce anche bene, ma a prezzo di uno scadimento delle prestazioni multitasking che si traduce in limiti alla complessità di quello che si può gestire. Un'analisi delle tecnologie per il trattamento di audio e video è utile anche per intuire quali possono essere le strade da percorrere per mantenere \amiga{} nel novero dei computer multimediali per eccellenza. Gli elementi che rendono un computer multimediale (nell'accezione corrente del termine) sono due: la potenza di calcolo e i sottosistemi audio/video (A/V). Dei due fattori, quello più importante è certamente il sottosistema A/V, come \amiga{} insegna. \sez{Chip-set \amiga{}} Per valutare le architetture proposte dai vari produttori di computer e semiconduttori, è utile studiare preventivamente la struttura a basso livello dei chip-set AGA ed ECS. L'architettura del sottosistema A/V di \amiga{} è frutto di un progetto originale che nessun'altro ha imitato. Il chip-set AGA non ha introdotto alcuna modifica architetturale, è solo una diversa implementazione del chip grafico (Lisa), con alcune importanti conseguenze sul controllore DMA (Alice). Come è noto, il sistema è composto da tre chip: un temporizzatore e generatore di indirizzi (Agnus nel chip-set originale e Alice nell'AGA), un chip parzialmente analogico che contiene le interfacce di I/O (Paula), e un generatore di pixel (Denise nel chip set originale e Lisa nell'AGA). Il chip-set originale era costruito con processo NMOS da 3 $\mu$m, quindi è costituito da poche migliaia di transistor, contro le centinaia di migliaia delle soluzioni concorrenti. Lisa e Alice sono invece realizzati con un processo CMOS veloce. I progettisti originari hanno integrato nei chip anche alcune funzioni che non fanno parte del sistema A/V, come l'encoder degli interrupt, i generatori di clock o le porte di ingresso per i joystick. L'incorporazione di questi circuiti nel chip-set (retaggio dell'epoca degli home computer) rende praticamente impossibile posizionare il sistema A/V in una scheda: deve essere integrato sulla motherboard. Questo vincolo dipende solo dalle scelte pratiche dei progettisti e potrebbe essere rimosso. I progetti di sviluppo esposti originariamente da Commodore e poi dai suoi acquirenti concordano sulla necessità di porre il sottosistema A/V su scheda per consentire aggiornamenti; eventualmente sarebbe possibile installare chip-set di terze parti. Gli unici seri problemi sarebbero quello economico (il costo del computer aumenterebbe, quindi la soluzione è improponibile per i modelli base) e quello del controller dei floppy disk: poiché anch'esso è stato integrato nel chip set, non si può garantire la compatibilità hardware separandolo dal sistema A/V. Con un chip set su scheda non funzionerebbero tutti i giochi e demo attuali, che fanno un accesso diretto allo hardware per leggere i dati dal dischetto. In realtà vedremo che con opportune integrazioni al sistema operativo, la necessità di avere un chip-set aggiornabile su scheda diventa poco importante. Il chip principale è Agnus (Alice nel chip-set AGA), che ricava per divisione tutti i segnali di sincronizzazione necessari, partendo da un segnale di clock a 28~MHz. Oltre a questo compito, Agnus esegue il fetch per il video refresh da un banco di RAM dinamica. Il refresh video consiste nella lettura 50 volte al secondo (o anche più spesso, a seconda del modo video scelto) della porzione di Chip RAM che contiene l'immagine da visualizzare, per generare la sequenza di pixel da inviare al monitor. Alice funziona in modo un po' diverso da Agnus. Agnus si serve di un bus a 16 bit e per ogni accesso alla RAM dinamica esegue un ciclo di selezione completo (prima indirizza la riga, poi la pagina del chip di RAM dinamica; dopo l'accesso attende la precarica). Alice usa un bus a 32 bit e può essere programmato per eseguire accessi doppi, in cui dopo un ciclo normale viene lasciata aperta la pagina ed eseguito un accesso ``fast page'' alla locazione successiva. Il tempo necessario per un ciclo di accesso alla RAM è identico per ECS e AGA (e molto lungo per gli standard attuali: 280 ns): però mentre nel caso ECS vengono trasferiti solo 16 bit, nel caso AGA (disponendo i bitplane nella Chip RAM con gli opportuni allineamenti) è possibile trasferire 16, 32 o 64 bit per ciclo. I dati inviati a Denise (Lisa nel chip-set AGA) non rappresentano direttamente i pixel da visualizzare e non vanno direttamente ai convertitori D/A, ma devono essere elaborati disponendoli in opportuni registri. A questo scopo Agnus gestisce una specie di bus indirizzi a 8 bit (bus RGA), che viene campionato assieme al bus dati dagli altri due chip ogni volta che i segnali di clock e selezione (generati da Agnus stesso) soddisfano una particolare espressione logica. Questo accade una volta per ciclo nel caso del chip set ECS e due volte per ciclo nel caso di AGA con modo fast page abilitato, in corrispondenza delle due letture o scritture, quando i dati da o per le RAM sono pronti. Gli otto bit ottenuti dal campionamento del bus RGA vengono portati a un banco di comparatori logici posti dentro i chip, che abilitano il registro selezionato alla comunicazione col bus dati. Questo modo di procedere consente una grande flessibilità: i dati inviati a Denise possono essere indifferentemente sprite, bitplane o pixel in modo HAM (e HAM-8, nel caso di Lisa). Anche interpretarli come ``chunky pixel'' o secondo qualsiasi altro schema (magari di compressione) sarebbe facile e senza problemi. Il fetch dei campioni audio è realizzato dalla stessa circuiteria che genera i pixel video, ma nell'implementazione corrente non viene effettuata una rielaborazione prima della conversione D/A (salvo una banale modulazione del volume). La frequenza di campionamento è perciò strettamente legata alle frequenze del quadro video, a meno di scrivere nei convertitori direttamente con la CPU: una restrizione poco sentita, ma innaturale. Quest'architettura è facilmente scalabile e migliorabile. Una proposta annunciata in passato da Commodore (chip-set AAA) prevedeva un consistente aumento dei punti di campionamento del bus RGA all'interno del ciclo, con conseguente aumento dei bit trasferiti ogni volta. Girare il verso di trasferimento dei pixel per trasformare l'uscita video in un ingresso frame-grabber è altrettanto banale (basta solo che Agnus piloti le RAM in scrittura invece che in lettura), mentre è facile inventarsi schemi di compressione più potenti dello HAM, perfetti per visualizzare animazioni in finestra. Queste caratteristiche del chip-set vengono esaltate dalla particolare architettura dei bus di \amiga{} e soprattutto dalla possibilità della CPU e del Copper di accedere ai registri dei chip custom. Questa peculiarità consente se necessario uno strettissimo accoppiamento tra il software e la generazione del quadro video, con i risultati che si possono ammirare ad esempio in molti ``demo''. Riassumendo, le peculiarità del chip-set di \amiga{} non disponibili altrove sono: \begin{enumerate} \item La presenza di una decodifica dei pixel tra il controller video e i convertitori D/A, con la conseguente necessità di un bus RGA che garantisce una grande flessibilità. \item La possibilità di prelevare da una sorgente video esterna il clock che governa tutto il sistema A/V e i segnali di sincronismo: l'operazione di genlock è immediata. \item Una stretta relazione tra il sistema A/V e il resto del computer, con la CPU che può usare la memoria video come fosse una normale RAM e ha accesso ai particolari interni (registri, copper ecc) del framebuffer; è persino possibile scrivere dallo hard disk nella RAM video direttamente, che è il motivo per cui le animazioni su \amiga{} sono così fluide anche senza hardware aggiuntivo. \item Supporto di schermi multipli a diverse profondità. \item Configurazione dei bus della macchina che consente operazioni concorrenti su tre bus distinti. \end{enumerate} Come punti deboli c'è una bassa disponibilità per la CPU della RAM video, dovuta all'uso di RAM dinamica economica e dal fatto che non sono supportati cicli di accesso fast-page da CPU o slot di espansione verso la Chip RAM: si possono trasferire solo 16 o 32 bit per ciclo. Da ricordare che l'ampiezza del bus che la CPU usa per accedere alla memoria video non ha alcuna relazione con quello che il controller video (Agnus o Alice in questo caso) usa per il fetch dei pixel. Ad esempio, anche se A3000 monta il chip set ECS a 16 bit, l'accesso alla Chip RAM avviene a 32 bit grazie a un sistema di multiplexer. Se si usa un modo video che comporta un elevato traffico per il refresh (i modi dblPAL a 256 colori su A1200/A4000 ad esempio), la CPU è quasi tagliata fuori dalla Chip RAM. Sempre il cattivo uso del modo fast-page (solo due accessi a locazioni consecutive) comporta un numero di bit per ciclo trasferiti a Denise decisamente basso, quindi pesanti limiti sulle frequenze di refresh. Tutti questi difetti dipendono in gran parte dall'implementazione, anche se alcuni limiti non sono superabili per vincoli che sarebbe troppo lungo esporre in questa sede. \sez{Chip S-VGA} L'architettura dei chip S-VGA è rimasta stabile sino al 1993, con una costante e prevedibile richiesta di risoluzioni più elevate, blitter più veloci, disponibilità della RAM video per la CPU più alta (che si traduce in maggiore velocità). Oggi invece la pressione per introdurre funzioni multimediali sta producendo un fermento di proposte che possono avere una ricaduta benefica su \amiga{}, in grado di sfruttarle con più vantaggio. Il concetto di base delle macchine IBM compatibili è che il sistema video non ha una dignità speciale: come le altre periferiche, è un'entità di cui non si conoscono né sono richieste informazioni interne (linea video corrente, ecc.) e con cui si interagisce tramite comandi da scrivere in appositi registri. Il flusso di informazioni è strettamente unidirezionale, da CPU verso il controller S-VGA; i pochi registri leggibili dalla CPU non contengono dati particolarmente utili. Per i limiti dei sistemi operativi disponibili, si può installare una sola scheda video S-VGA. Questo tipo di struttura è chiaramente inadatto a gestire eventi in tempo reale come la gestione di un segnale video trasformato in forma digitale, e difatti è esperienza comune che i personal dell'attuale generazione si limitano a gestire animazioni in finestra. La prima soluzione esplorata consiste nell'overlay analogico di fonti esterne. La funzione è ottenuta tramite una scheda aggiuntiva che funge da scan-converter: digitalizza il segnale applicato agli ingressi, lo pone in una memoria privata e ne esegue il refresh alla frequenza imposta dalla scheda video. Il quadretto generato è sovraimposto sul segnale del controller S-VGA mediante un multiplexer analogico. Il segnale può essere quello di una telecamera oppure il prodotto di un chip che esegue la decompressione MPEG o AVI per via hardware. L'approccio è quindi rovesciato rispetto all'\amiga{}: invece di sincronizzare il sistema video sul segnale esterno, è il segnale esterno a venir risincronizzato. Grazie a questo accorgimento è rimosso il vincolo di usare solo modi video a 15~KHz: ma per generare un segnale videoregistrabile occorre un costoso scan converter. È evidente come questa sia una soluzione arrangistica, per nulla efficiente: oltre a una scheda S-VGA completa, occorre un'altra intera scheda con un'altro controller video e un'altro costoso convertitore D/A, più tutta la circuiteria analogica necessaria per la composizione dei segnali! Tuttavia si integra in modo elementare con l'architettura \amiga{}, perché con una scheda di questo tipo il video a 15~KHz prodotto dagli AGA, eventualmente genloccato con quello esterno, può essere inserito nella finestra di overlay della scheda video senza flicker pur restando disponibile sulla porta a 23 pin. Il sistema audio degli IBM compatibili è sempre separato da quello video. Normalmente non è basato solo sulla sintesi per campionamento, (che si presta a considerazioni simili al sottosistema video), ma anche su altre tecniche. Stranamente, le schede audio attuali tendono sempre più ad assumere la configurazione del sistema video di \amiga{}: un controllore audio preleva da RAM dedicata i campioni del suono, ma non li invia direttamente ai convertitori D/A, bensì a un sottosistema che si occupa di controllo di volume, riverberazione, spazializzazione ecc. \sez{Sistema VideoCache} Moltissimi produttori hanno recentemente appoggiato l'architettura VideoCache brevettata da {\selectlanguage{english}Brooktree}, tutta digitale, di cui il chip OTI-107 (OAK Technologies) e il Video Power Coprocessor da usarsi con il chip Power 9100 (Weitek) sono i primi rappresentanti, con uscita prevista per il dicembre 1994. Anche il sistema A/V di alcune serie \macintosh{} è fatto in questo modo. Il concetto di base consiste nel mantenere separati i flussi di pixel prodotti dal controller S-VGA e dall'unità che tratta il video digitalizzato, effettuando l'overlay direttamente dentro un'apposito convertitore D/A dotato di una pixel port ausiliaria a caricamento asincrono (Brooktree Bt885). In altri termini il video digitalizzato è trasformato in un normalissimo sprite hardware stile \amiga{}. I pixel che lo compongono vengono aggiornati utilizzando un bus ausiliario governato dal ``Multimedia Video Controller" (MVC) della scheda. Naturalmente la dimensione dello sprite è completamente regolabile e può includere l'intero schermo; nel chip OTI-107 l'unica limitazione della pixel port ausiliaria è il clock di ``soli'' 33~MHz (più del doppio dell'AGA). Evitando di caricare i registri dello sprite attraverso la stessa porta usata dal controller S-VGA, si possono ottenere frequenze di rinfresco più alte della soluzione \amiga{} e si resta compatibili con l'architettura ISA, a prezzo di una maggiore rigidità: per avere due sorgenti video sullo schermo occorrerebbe un convertitore con due porte, mentre gli otto sprite di \amiga{} sono praticamente impossibili da ottenere. \sez{MVC} L'MVC è un blocco funzionale presente in tutte le schede per il video digitale. Si compone di un front-end analogico che converte i segnali PAL in ingresso (esempio: telecamera, videoregistratore, sintonizzatore TV) in segnali YUV (cioè segnale di luminanza e i due segnali differenza colore) e li applica ai relativi tre convertitori A/D che li immettono in una memoria di quadro. Si usano i segnali YUV perché si possono quantizzare con meno bit (5, 6 o 7) rispetto agli RGB, e perché molti apparecchi video professionali li hanno già disponibili sulle loro prese di ingresso e uscita. La memoria di quadro è necessaria per eseguire la conversione tra le frequenze dei sincronismi televisivi e quelle usate per pilotare il monitor (generate dal controller S-VGA): come abbiamo visto, è necessario agganciare il video esterno ai sincronismi S-VGA. Un grosso vantaggio dell'OTI-107 é che la memoria di quadro viene ricavata da un banco della memoria video del controller S-VGA stesso, quindi a costo zero. La circuiteria interna all'MVC non fa altro che scrivere nella memoria di quadro i dati YUV a frequenza televisiva; poi li rilegge comandata dal pixel clock del chip S-VGA e li converte in RGB prima di inviarli alla porta asincrona del convertitore D/A. In definitiva il sistema VideoCache rovescia il modo di gestire il video digitale rispetto alle architetture convenzionali (es: \amiga{}, Silicon Graphics Indy). Su \amiga{} un framegrabber digitalizza l'immagine entrante e la copia nella memoria principale, Chip o Fast, dove può essere salvata su hard disk o manipolata. Se copiata in Chip RAM viene visualizzata direttamente (cosa impossibile nell'architettura dei PC o su Silicon Graphics), ma deve essere preventivamente convertita da YUV in bitplane tramite costosi circuiti hardware o un loop software che drena via quasi tutto il tempo macchina. In un sistema VideoCache, il video digitale da visualizzare non disturba minimamente le operazioni del controller grafico. Solo in caso di necessità può essere letto dalla memoria di quadro e copiato su hard disk impegnando la CPU marginalmente, perché la conversione da YUV ad Anim o MPEG può essere fatta o con comodo in un secondo tempo, oppure direttamente via hardware. \amiga{} è adattissimo a ospitare una scheda in tecnologia VideoCache, che avrebbe l'ulteriore vantaggio di consentire la visione del segnale generato dai chip AGA (per ECS ci sono problemi) nella finestra VideoCache della scheda, senza bisogno di commutatori per il monitor. La presenza del chip set a 15~KHz sarebbe la vera ``marcia in più'' di \amiga{} rispetto ai compatibili, perché fornisce una soluzione all'uscita video. Il sistema VideoCache infatti non prevede un'uscita video in standard PAL, che deve essere effettuata con uno scan-converter esterno, estremamente costoso e fonte di degrado del segnale! Su \amiga{} invece si potrebbe usare lo schermo generato dal chip S-VGA per contenere i pannelli e menu del programma e le immagini ferme, mentre il video AGA a 15~KHz finirebbe nella finestra con l'immagine in movimento, agganciato e miscelato con il segnale da manipolare servendosi di un comunissimo genlock. Da notare che la finestra può essere anche full-screen ma è sempre alle alte frequenze di refresh senza flicker scelte dal chip S-VGA: l'editing si fa a 15~KHz ma il controllo lo si ha su uno schermo flicker-free. \sez{Weitek P9100 e Quadra A/V} Apple e Weitek (Video Power Coprocessor per il chip Power9100) propongono una variante del sistema VideoCache con prestazioni migliori. Invece di uno speciale e poco flessibile DAC a doppia porta, il chip S-VGA è realizzato servendosi di due banchi di memoria. L'MVC scrive direttamente in uno di essi, mentre il chip S-VGA nell'altro. Il circuito che si occupa di effettuare il refresh del video (cioè legge i pixel da mandare al convertitore D/A) è comandato da un registro ausiliario che specifica se una o più zone rettangolari dello schermo devono essere prelevate dal primo o dal secondo banco. Chiaramente, quando si sceglie il secondo banco si visualizza una finestra con il video in movimento che può essere posizionata liberamente, come nel caso del chip OAK. Il vantaggio di questa soluzione è che la finestra con il video può essere di qualsiasi dimensione senza limitazioni sul clock, e aumentando il numero di MVC sulla scheda si possono visualizzare facilmente molte finestre (ad esempio, per un montaggio video sarebbero utili due sorgenti e la destinazione). Inoltre, quando non è richiesta la funzione multimediale, il secondo banco può essere utilizzato dal sistema S-VGA per creare animazioni in double-buffering. Nella soluzione Apple c'è la limitazione che per leggere i dati del video in ingresso occorre scambiare il ruolo dei due banchi (c'è un'apposito registro), quindi per registrare su hard disk il video c'è necessità di un continuo saltellare tra i due banchi. Nella soluzione Weitek invece l'MVC contiene un potente post-processore DSP, che esegue in hardware il ricalcolo della palette dell'animazione, la sua scalatura e interpolazione per portarla alla risoluzione desiderata ed eventualmente dithering (se il modo video in uso non è a 24 bit) e la decompressione. Quest'ultima funzione è molto importante perché l'MVC Weitek può essere alimentato direttamente dalla CPU con i dati prelevati da file di animazioni in standard AVI o MPEG. In questo modo non solo è semplificato il trattamento di segnali video esterni, ma anche il playback di file precedentemente registrati. Poiché il numero di persone interessate a fruire di animazioni già pronte è di gran lunga superiore a quello di chi le crea, ci si può aspettare una proliferazione di schede VideoCache con MVC semplificato (senza convertitori A/D) per accettare i dati solo dalla CPU. Per il momento le soluzioni PC e \amiga{} disponibili (es: scheda Full Motion Video di CD32) usano ancora il metodo dell'overlay analogico. \sez{Accelerazione} Il video digitale è solo una delle funzioni che la scheda video multimediale deve supportare, le altre sono racchiuse nel blocco finora indicato come ``controller S-VGA''. Un esame accurato del suo funzionamento è fuori luogo in questa sede, dove ci limitiamo a studiare i miglioramenti significativi introdotti dai chip più recenti. Il chip S-VGA deve generare i sincronismi video e i segnali di sincronizzazione interni alla scheda, consentire alla CPU un accesso senza attese alla memoria video, provvedere alla generazione del flusso di pixel da inviare al convertitore D/A e svolgere operazioni grafiche come il BitBLT. Tutti i controller oggi disponibili si basano sullo sfruttamento estensivo della proprietà delle RAM dinamiche di abbassare considerevolmente il proprio tempo di accesso medio se si accede a locazioni consecutive appartenenti alla stessa pagina. Ne deriva che, se si allineano i dati in memoria in maniera che il primo byte da visualizzare in ogni riga corrisponde all'inizio di una pagina, si possono trasferire al convertitore D/A molti più dati per ciclo rispetto a quanto fa il chip-set \amiga{}. Questo modo di accedere alla RAM video si accoppia molto bene con la struttura a ``chunky pixel'', mentre richiederebbe hardware aggiuntivo (presente nella proposta Commodore ``AAA'') per mantenere una struttura a bitplane. Per superare i limiti dei convenzionali chip di RAM dinamica o VRAM sono stati progettati sottosistemi di memoria ottimizzati per l'uso video, rimasti però per lo più sulla carta. Apple propone una struttura a token-bus chiamata RAMlink. Rambus propone un bus seriale orientato ai byte, con clock superiore al gigahertz, mentre il colosso Samsung (forte della sua tecnologia da 0,5~$\mu$m), propone dei moduli WRAM (Window RAM) che contengono un po' di logica e un'interfaccia bufferizzata, con prestazioni superiori alla VRAM e venduti a prezzo molto più competitivo. Altre tecniche di accesso alla memoria largamente utilizzate sono l'ampliamento del bus dati a 64 bit (P9100 di Weitek, Vision964 di S3, 88800GX di ATI, ecc.), l'uso di banchi interallacciati (Weitek P9000 e P9100) per mascherare i tempi di precarica e così via. Come il chip set AGA dimostra, l'efficienza dell'interfaccia tra memoria video e convertitori D/A (necessaria per l'operazione di refresh) non significa molto se la velocità di accesso della CPU alla RAM video è scarsa. È proprio questo parametro che stabilisce la velocità del sistema video, ed è poco utile avere a disposizione frequenze di refresh alte se poi significano peggiorare la velocità grafica a causa della saturazione del bus della RAM video (modi a 256 colori dblPAL su A4000). E qui sorge un grosso problema, perché mentre gli accessi della circuiteria che esegue il refresh avvengono sempre in locazioni consecutive, quelli della CPU possono essere casuali e distruggono la possibilità di usare il modo fast-page in maniera estensiva. Una soluzione al problema è offerta dall'architettura WINgine di Chips \& Tecnologies (usata su alcune schede BOCA). Questo chip utilizza una banco di memoria aggiuntiva (256~K ogni megabyte) come cache che contiene l'ultimo quadro usato per rinfrescare lo schermo. La circuiteria di refresh effettua letture solo su questo banco, che viene aggiornato dal controller S-VGA durante gli intervalli di rinfresco, mentre la CPU è sempre libera di accedere alla RAM video senza contese. Chiaramente questo si può fare perché nella RAM video, al contrario della chip RAM di \amiga{}, le operazioni di scrittura sono nettamente prevalenti su quelle di lettura. Un'altra soluzione molto usata consiste nell'utilizzare memorie a doppia porta, VRAM o WRAM, che sono fornite sia di un'interfaccia ottimizzata per l'accesso da parte della CPU e dell'acceleratore grafico che di un'interfaccia seriale ad alta velocità per il circuito di refresh video. Anche i banchi di memoria interallacciata (``interleaving'', usata da P9100) alleviano il problema della contesa della RAM video tra CPU e circuiti di refresh. La memoria video è divisa in due banchi, e quindi statisticamente nel 50\% dei casi succederà che la circuiteria video legge dal primo banco mentre la CPU accede contemporaneamente e senza attese al secondo. Se invece entrambi vogliono accedere alla stessa locazione contemporaneamente, la CPU deve aspettare. \sez{Acceleratori} Un altro modo di diminuire la contesa della memoria è ben noto agli amighisti, e consiste nell'aggiungere al controller video un'unità che accetta comandi dalla CPU ed esegue le operazioni grafiche più frequenti nel momento opportuno, in quanto progettata in modo da intercalare perfettamente le sue operazioni all'attività di refresh. Se il sistema operativo è multitasking, la CPU è inoltre subito libera di fare altri compiti. Le funzionalità degli acceleratori grafici implementati sui chip di uso comune sono sempre plasmate sulle necessità del sottosistema grafico di Windows, che Microsoft ha progettato con la stessa proverbiale efficienza, lungimiranza e competenza che contraddistingue il suo sistema operativo. Per questo motivo i prodotti recenti hanno già raggiunto la completa copertura delle funzioni richieste (disegno di linee, bitBLT, operazioni di mascheratura, sprite per il puntatore del mouse) e le differenze di prestazioni tra i chip dipende soprattutto dall'efficienza dei circuiti di refresh. In pratica la velocità del blitter è di gran lunga maggiore di quello \amiga{}, però esegue meno operazioni; l'unico sprite disponibile è di piccole dimensioni e ha una profondità di soli due bit. Anche se sulle Workstation sono di uso comune chip in grado di risparmiare memoria video aprendo finestre con profondità di colore dipendente dalle esigenze dell'applicazione (Silicon Graphics Iris, schede GTX1000 IBM$\ldots$), Windows non supporta questa funzionalità. Di conseguenza i controller S-VGA la prevedono solo in forma limitata, ad esempio rendendo possibili solo un paio di schermi posizionati in locazioni fisse della memoria video (esempio: il primo inizia con la prima locazione del primo banco, e il secondo con la prima del secondo banco). Il supporto ai monitor ``verdi'' in standard ``{\selectlanguage{english}Energy Star}'' consiste semplicemente nell'usare le linee dei sincronismi come un bus seriale su cui trasmettere al monitor i comandi di accensione e spegnimento. \sez{Grafica 3D} L'attuale modello delle librerie grafiche di AmigaDOS, Windows e altri sistemi operativi è di tipo 2D, cioè basato sulla copia di regioni di schermo (caratteri e finestre) e disegno di linee. Le applicazioni 3D sono poche e di solito fornite con driver dedicati per pilotare hardware realizzato su misura per loro: ad esempio Autocad per \msdos{} con schede TIGA o Caligari sugli \amiga{} con schede SAGE. Al contrario, le workstation dispongono ormai da molti anni di sistemi di rendering ben integrati con hardware e software di sistema: le problematiche della grafica 3D con le relative architetture sono state ormai sviscerate nei più minuti particolari da centinaia di pubblicazioni. Le cose stanno rapidamente mutando con la decisione di Silicon Graphics di distribuire su licenza una versione delle sue librerie grafiche opportunamente generalizzata. OpenGL è stata poi istantaneamente supportata da quasi tutti i principali produttori di software (Microsoft inclusa). Questo ha dato il via allo sviluppo di chip economici con acceleratore 3D, tra cui il chip set Mondello di Cirrus Logic (composto dai chip CL-GD5470, 5471 e 5472) e il chip GLiNT di 3DLabs, che si interfacciano al bus PCI. La libreria ha come scopo il rendering sul video di strutture tridimensionali, complete di illuminazione e punto di vista, possibilmente in tempo reale. Il pregio è la struttura stratificata che può essere implementata in hardware a diversi livelli. Questa operazione si può grossolanamente dividere in fasi successive: definizione della geometria, trasformazione secondo il punto di vista, illuminazione, calcolo del colore dei pixel. Il chip GD5470 esegue la parte di rendering: Gourad shading, antialiasing, alpha blending, gestione dello Zbuffer (250\,000 poligoni al secondo). Naturalmente contiene anche un blitter da 66 megapixel al secondo e le consuete accelerazioni 2D. Il chip GD5471 è l'interfaccia con bus PCI o VESA, mentre il 5472 contiene il convertitore A/D, alimentato da un bus a 96 bit; il costo del chip set (già disponibile) è di 100 dollari, che si tramutano in circa 300\,000 lire al pubblico (oltre al costo della RAM video e della scheda). Questo chip-set è il più semplice esempio di accelerazione della libreria OpenGL via hardware, e se la grafica 3D dovesse diventare di interesse generale sicuramente seguiranno altri chip che implementeranno porzioni maggiori. Infatti già anni fa ci fu un tentativo di portare le funzionalità grafiche 3D sui personal come \amiga{} (schede SAGE, ad esempio quelle prodotte da DMI) o IBM compatibili, ma fu accolto con molto disinteresse da parte del pubblico e delle software house. Un possibile impulso allo sviluppo di hardware 3D dedicato sono i videogiochi, visto che i principali produttori del settore hanno messo a punto chip con funzionalità 3D per le proprie console. In realtà per ora si sa poco su questi chip, e ciò lascia spazio al sospetto che la parte 3D sia abbastanza limitata, con quasi tutto il merito della ``magia'' dovuto alla potenza di un economico processore RISC a 32 bit. La grande diffusione dei processori CISC ha infatti fatto dimenticare a molti quanto siano lenti! Un esempio di chip 3D di seconda generazione è il GLiNT, che sarà disponibile nel corso del 1995. È più complesso del chip set Mondello e contiene quasi tutto il sistema di rendering, ma è anche più costoso (150 dollari). La sua architettura interna è abbastanza complessa ed è vagamente simile a quella delle schede Iris di Silicon Graphics; è basata sull'uso estensivo di sistemi connessi in pipeline. Anche questa scheda è dotata di interfaccia per bus PCI. Texas Instruments, il costruttore dei DSP grafici che animavano tutte le schede 3D della passata generazione, non è rimasta con le mani in mano e ha proposto un aggiornamento della sua linea di chip grafici, che però non è diretta al mondo dei personal computer. È stato battezzato MVP (Multimedia Video Processor), e contiene in un solo chip quattro DSP e una CPU RISC che li coordina. Questo chip segue l'altra possibile strada per la grafica 3D su personal computer: l'integrazione nella CPU di funzioni grafiche. Questa via non è percorribile dalle macchine IBM compatibili per problemi di compatibilità, ma resta ampiamente aperta per \amiga{}. Anche in questo caso le soluzioni sono molte. Una possibilità è l'integrazione nel set di istruzioni stesso di funzioni tipiche dei DSP, ovviamente aggiungendo alla CPU le corrispondenti unità hardware in grado di eseguirle in un ciclo di clock. Questa strada è percorsa da alcune CPU RISC, come INTEL i960 o Hewlett-Packard HP-PA7100LC. In ogni caso aumentando sufficientemente la potenza di calcolo generale della CPU si possono tranquillamente eseguire operazioni tipiche di DSP senza modifiche architetturali, come dimostra il chip set R8000 usato delle macchine Silicon Graphics della serie Power Onyx. È da notare che PowerPC, pur essendo il RISC più recente, non solo è privo di istruzioni ottimizzate per usi multimediali, ma è anche l'unico RISC in circolazione che non è passato ai 64 bit, e la sua frequenza di clock massima è attualmente di soli 80~MHz. Pur essendo più veloce dei processori CISC, è uno dei RISC più lenti oggi in commercio. È appoggiato da IBM e Apple, quindi avrà certamente un grande successo, e ciò lascia prevedere che l'approccio di aumentare la potenza di calcolo della CPU con funzioni DSP (per risparmiare sul sottosistema A/V) non è destinato ad avere molto seguito nei personal computer. L'altra possibilità consiste nell'aggiungere un DSP completo sullo stesso chip di una comune CPU. Motorola ha seguito questa via con il chip MC68356, che contiene un comunissimo MC68000 (a 25~MHz) con tutti i relativi pin. In più, mappato in memoria a un indirizzo programmabile con un apposito registro, è connesso uno dei cinque bus di un potente DSP a 24 bit in virgola fissa tipo DSP56002 (a 60~MHz), con una RAM statica veloce interna eventualmente espandibile con chip esterni posti sul suo secondo bus di espansione. MC68356 contiene anche una porta per convertitore A/D o D/A a 16 bit, due porte seriali e un completo controller PCMCIA; è stato studiato per funzionare come CPU di stampanti laser. I segnali disponibili sui suoi pin sono scelti in modo che possa essere facilmente inserito al posto di un MC68000. Naturalmente occorre un adattatore, perché a causa del bus del DSP e dei segnali della porta PCMCIA (che si possono lasciare sconnessi) ha un numero di pin maggiore del normale MC68000: 357. Il package è LBGA, di tipo SMT, mentre il prezzo è di 64,95 dollari. \sez{Conclusioni} L'architettura \amiga{} resta l'unica a proporre una soluzione ottimale e diretta per l'uscita in standard PAL. Al contrario, le tecnologie A/V multimediali sviluppate per il mondo IBM e Apple sono attualmente orientate solo verso la cattura ad alta qualità delle fonti video e alla loro memorizzazione e visualizzazione flicker-free ad alta risoluzione, lasciando a qualche scatoletta l'arduo compito di riportare in qualche modo il risultato nel regno del video PAL. Le nuove tecnologie non sono antagoniste del nostro computer, ma si possono complementare con facilità con AGA consolidando \amiga{} come macchina di riferimento per la produzione videografica. Anche la grafica 3D può essere inserita sotto forma di processore RISC di nuova generazione oppure di scheda 3D. Gli unici, indispensabili requisiti perché \amiga{} possa trarre giovamento dalle prestazioni dei chip più recenti sono la presenza di un bus PCI (surrogabile, ma ad alto costo, con una scheda convertitore di bus) e l'innesto nel sistema operativo della grafica RTG ed eventualmente della libreria 3D OpenGL. Un nuovo chip set che estenda l'architettura attuale, per quanto potente possa essere, da solo non sarebbe sufficiente (e neanche necessario) per mantenere \amiga{} nel novero dei computer multimediali di punta, anche se naturalmente si inserirebbe bene nella strategia seguita da Commodore di fornire il massimo di funzionalità per la cifra spesa. \begin{thebibliography}{0} \bibitem[1]{} Paolo Canali. \newblock {\em Architettura dei computer \amiga{}}. \newblock \amiga{} Magazine n.~34, 35, 36. \bibitem[2]{} Paolo Canali. \newblock {\em Schede video}. \newblock \amiga{} Magazine n.~58, 59. \bibitem[3]{} Paolo Canali. \newblock {\em Come orientarsi nella memoria}. \newblock \amiga{} Magazine n.~37. \bibitem[4]{} Paolo Canali. \newblock {\em Le nuove CPU}. \amiga{} Magazine n.~51. \bibitem[5]{} Commodore Amiga, inc. \newblock {\em Amiga Hardware Reference Manual}. Terza edizione, Addison Wesley, ISBN 0-201-56776-8. \bibitem[6]{} G.~Kane. \newblock {\em Il manuale MC68000}. \newblock McGRAW-HILL, ISBN 88-7700-017-1. \bibitem[7]{} Dimitrios A. Protopapas. \newblock {\em Microcomputer, progettazione hardware}. Gruppo Editoriale Jackson \bibitem[8]{} Toshiba Corp. \newblock {\em MOS Memory (RAM, module) data book 1990}. \end{thebibliography} \finearticolo