Come ho scritto anche nel mio profilo qui su Appunti Digitali, quella dei videogiochi è una grande passione che mi porto dietro da tantissimo tempo (34 anni), ma in tale periodo pochi sono gli eventi che hanno caratterizzato il passaggio alle nuove ere o generazioni.
Da questo punto di vista le console hanno rappresentato una sorta di cartina al tornasole del progresso tecnologico, e l’avvicendamento fra vecchie e nuove ha segnato l’introduzione della successiva generazione a “n bit”…
8, 16, 32, 64 e persino a 128 e 256 bit. Sembra che più o meno a ogni nuova generazione sia corrisposto un “raddoppio” dei “bit” che vengono sistematicamente appioppati loro (anche se ormai sembra essere in disuso questo tipo di nomenclatura; raramente ho sentito parlare di console “a 256 bit”).
Ovviamente si tratta di un’etichettatura che tecnicamente ha ben poco senso, perché significherebbe marchiare un’intera generazione come “a n bit”, in quanto non è detto che tutti gli elementi che ne fanno parte possano essere classificati come tali. A maggior ragione se manca un oggettivo “metro” di paragone…
Qui arriva la prima nota dolonte. Non esiste, infatti, nessuna unità di misura universalmente riconosciuta per indicare che l’architettura di un sistema sia “a n bit”. Le prese di posizione in tal senso sono, quindi, del tutto arbitrarie.
Questo sostanzialmente per due motivi. Il primo è che un sistema è costituito da diversi componenti, che non sono necessariamente etichettabili tutti allo stesso modo. Il secondo è che affibbiare un’etichetta a un singolo componente è, di per sé, abbastanza difficile da realizzare.
Trattando del primo caso e supponendo che a ogni componente sia sempre possibile attribuire una certo “numero di bit”, come si potrebbe arrivare a definire quelli dell’intero sistema? Con una media tradizionale? O una media pesata (dando a ogni componente un grado di “importanza”) e, in questo caso, in che modo si potrebbero definire i pesi? Ancora, scegliendo l’elemento a cui attribuiamo maggior “prestigio”? O altro ancora, perché le possibilità sono innumerevoli.
Se prendiamo un computer moderno o una console, gli elementi che li compongono sono diversi. L’onnipresente CPU (e magari più d’una), il chipset, il bus o collegamento punto-punto che li connette, la GPU (anche più d’una), la memoria centrale e/o quella della GPU, con a sua volta le memorie collegate alla CPU e/o al chipset e/o alla GPU tramite un bus o collegamento punto-punto dedicato, ancora chipset che integrano GPU, tra non molto anche CPU che integrano GPU, e chissà cos’altro ci riserverà il futuro.
Le variabili in gioco sono parecchie, ognuna più o meno “misurabile” in termini di “bit” (avendo prefissato che sia possibile farlo) e, pertanto, è difficile stabilire quali di esse potrebbero concorrere alla definizione dei “bit” dell’intera architettura del sistema, con quale importanza ciascuna, e con quale metodo.
La tendenza che ho riscontrato finora è stata quella di utilizzare la CPU come unico metro di paragone, ma si tratta di una valutazione ampiamente soggettiva, sebbene abbastanza “sensata”, poiché tale scelta si fa risalire sostanzialmente al ruolo che essa svolge nel sistema (e il suo acronimo parla chiaro: Central Processing Unit).
Ma in un sistema realizzato con diverse GPU (o elementi computazionali in generale) e una sola CPU (anche di scarsa “potenza”, poiché avrebbe l’unico compito di coordinarle spartendo loro il lavoro) la sua importanza sarebbe sicuramente relativa e, pertanto, prendendola come misura dell’insieme, questo verrebbe a sua volta “ridimensionato”.
Il primo esempio che mi viene in mente in tal senso è il Jaguar, ultima console della mitica Atari, che è costituita da diversi elementi:
- Motorola 68000 a “16 bit” (citata in tal modo da Atari e dal resto dell’industry dei videogiochi) in qualità di control processor
- DSP RISC a 32 bit per gestire effetti grafici
- DSP RISC a 32 bit per gestire effetti sonori (stessa architettura del precedente)
- RISC dedicato a 64 bit per gestire gli oggetti visuali
- Blitter a 64 bit per l’elaborazione delle scene
- Memory controller a 32 bit (per la gestione degli accessi alla memoria da parte degli elementi che processano la grafica)
- Bus verso la memoria a 64 bit
Atari l’ha pubblicizzata e venduta come console “a 64 bit”, ovviamente sulla base degli elementi classificabili come tali. Puro marketing, insomma (e non gliene si può fare una colpa). In realtà la CPU è rappresentata dal 68000, anche se è stata fatta passare soltanto come processore “di controllo” (quello che coordina tutti gli elementi).
Pertanto se dovessimo prendere la sola CPU come termine di paragone dell’intero sistema, questo dovrebbe essere classificato come “16 bit” (o come “32 bit”, se considerassimo l’ISA, come ho scritto in un articolo a lui dedicato), ma a mio avviso sarebbe riduttivo perché ha diversi altri elementi “significativi”. Viceversa, prendendo però uno di questi coprocessori a “64 bit” si correrebbe il rischio di sopravvalutarlo.
Una situazione diametralmente opposta si presenta col PCEngine di NEC, avente CPU a 8 bit (derivata dal 65SC02) e due chip a 16 bit per gestire la grafica. Dal punto di vista della qualità dei titoli prodotti competeva col SuperNintendo (dotato del 65816 a 16 bit come CPU) e il Genesis/MegaDrive della Sega (che montava un “classico” Motorola 68000). Come per il Jaguar, optare per la CPU o per i coprocessori grafici sminuirebbe o esalterebbe troppo questa console.
Come si può vedere, è veramente difficile etichettare un sistema. Anche togliendo di mezzo CPU e GPU/chip video, i pochi elementi rimasti (bus e/o collegamenti punto-punto, chipset, memorie) non mi sembrano sufficientemente “prestigiosi” da poter essere utilizzati per fornire una qualche misura all’intera piattaforma.
Personalmente penso che la classificazione dell’architettura di un sistema rimarrà ancora uno di quei problemi sui quali non sarà possibile prendere oggettivamente posizione e ciò, purtroppo, contribuirà alla diffusione delle classiche leggende metropolitane, come quelle sulle fantascientifiche console a 128 o più bit…
è chiaro che il numenro di bit sono stati usati per marketing per tutto un periodo, chi era abbastanza grande (o abbastanza piccolo) lo ricorda bene, anche perchè nessuno sapeva cosa comportasse davvero avere bit in più, come molta gente non sa cosa sono le valvole della macchina o altre “diciture”, ma fa fico scrivere sul fianco in rosso che una vettura ha 16 valvole…
è chiaro quindi che erano quelli del marketing a decidere se usare una dicitura piuttosto che un’altra, se anche il solo sistema audio fosse stato a 256bit, non avrebbero esitato a usare la dicitura per attirare l’attenzione, così come per un po’ aumentavano la memoria sulle schede video inutilmente, come specchietto per le allodole.
quando i giochi erano molto semplici, e venivano realizzati con le stesse tecniche da 8 a 16 bit, la differenza era evidente, il Genesis aveva molti più colori di un nes, e il comparto musicale era molto migliore. come parametro ho sempre avuto la modalità schermo di windows, che impostata a 16 o 32 bit cambiava il numero di colori visualizzabili. a quei tempi le palette erano tutto e a 16 bit c’erano molti più colori disponibili.
è chiaro poi che il processore centrale dovrebbe determinare se un sistema lavora a TOT bit, se poi non viene sfruttato allora è una sòla. in caso di una console non trovo scandaloso che venga spacciata a 512bit se anche solo il comparto grafico lavora così, l’importante è che almeno in minima parte possa essere sfruttato.
inutile pensare al nintendo 64, secondo me completamente sbagliato come marketing, perchè accostato al commodore 64… piccola provocazione ;-)
Se mi si concede una battuta, l’articolo è in un certo senso “ricorsivo” :D :D perché discute l’opportunità di etichettare un sistema “a n bit” citando poi come esempi componenti per i quali non è a sua volta chiaro perché siano classificati “a n bit” he he he he he!!!
Mi ricordo il classico esempio, ovvero la diatriba infinita sul 68000… bus dati a 16 bit, ma registri a 32 bit… quindi? Che roba era? Nei giornaletti per smanettoni lo vedevo classificato come CPU a 16/32 bit… Da “amigaro” incallito mi piaceva pensare a questa CPU come un processore a 32 bit, ma come si dice giustamente nell’articolo, è una presa di posizione arbitraria.
Ciao
Filippo
Secondo me si riferiscono ai bit che definiscono la dimensione massima della memoria sulla quale è contenuto il gioco perchè effettivamente le cpu vanno troppo piano mentre le gpu galoppano senza freni.
Per me resteremo ancorati ancora a lungo ai 64bit (eventualmente 64/128, 64/256, 64/512)
Da ignorante ho sempre pensato che il numero di bit agli albori della consolistica rappresentasse la palette colori…:D
Uhmmm…. ho perso i bit, ho perso gli swip, e ho perso i cric!
(Spaceballs)
@mede: giusto una precisazione. Il Genesis aveva nettamente meno colori del SNES sia come palette che come numero di colori per schermi/playfield, e anche dal punto di vista sonoro era messo peggio. In compenso aveva una bellissima CPU. :)
@filippo1974: sì, è un discorso “ricorsivo”, e infatti ne parlavo anche nell’articolo:
“Il primo è che un sistema è costituito da diversi componenti, che non sono necessariamente etichettabili tutti allo stesso modo. Il secondo è che affibbiare un’etichetta a un singolo componente è, di per sé, abbastanza difficile da realizzare.”
E’ chiaro che così il discorso non è chiaro (ROFL :D). Infatti penso di trattare il tema dei “bit” dei singoli componenti (della CPU in particolare) in un prossimo articolo per “chiudere il cerchio” (si fa per dire :D).
@D: sì, spesso viene tirata in ballo la GPU per far “gonfiare” quel numeretto.
@arkanoid: anche i colori sono spesso stati tirati in ballo come elemento di “misura” della “potenza” di una console o computer, ma in questi casi viene quasi sempre citata la quantità totale (256, 32mila, 65mila, ecc.).
@Banjo: da fan di SpaceBalls onestamente non ricordavo questa bellissima battuta. Grazie! :)
Pensate che io ho sempre pensato fosse l’address bus..non so perchè..ma già a 8anni, quando comprai il Sega Master System II (a “8 bit”), pensavo che più bit = più memoria gestibile, e quindi miglior qualità (nel ’90 i bambini non erano informati come ora sulla tecnologia..motivo del ragionamento un po’ farlocco). Dopo un paio d’anni, pensavo si parlasse dell’ampiezza del data bus..8bit = 2 cicli per intero, 16 bit = 1 ciclo, 32bit = 2 interi a ciclo, e via dicendo..secondo la relazione “più dati trasferiti per ciclo = maggior velocità”.. Ma passando alla PS2 (e i 128 bit), ho iniziato a chiedermi a cosa si riferissero espressamente quegli “n bit” (forte degli studi in informatica), senza darmi una risposta esaustiva.. Ora, grazie a Cesare, so che mi sono fatto mille paranoie inutili e che..era tutto marketing! Sigh! Sob!
[…] seguito di questo articolo: 8, 16, 32, 64 bit … le architetture dei sistemi danno i numeri … Articoli correlati: Tema Windows Vista per Xp – free Download […]
@ Cesare Di Mauro
si lo SNES era più potente, io ebbi la fortuna di avere questi tre: nes, megadrive, e snes. purtroppo il mio super nintendo si ruppe quasi subito, io preferivo comunque il megadrive alla fine. diciamo che appartenevano comunque alla stessa generazione e che in mani abili il megadrive non sfigurava poi tanto. la cosa più visibile era quello pseudo-3D di cui era capace lo snes. ma alla fine anche i multipiattaforma non è che fossero così diversi. e io sinceramente ho sempre detestato il controller dello snes (con i tasti laterali). il controller del genesis a 6 tasti era come giocare al bar.
Un buon esempio è anche l’Intellivision, prodotta dalla Mattel, uscita nel 1979, dotata di un processore a 16 bit (http://en.wikipedia.org/wiki/General_Instrument_CP1600), in competizione con la console Atari. Tre anni prima del Commodore 64.
@TheFoggy: non ti preoccupare, perché è esattamente quello che pensavo anch’io.
Poi col tempo ho avuto la fortuna di lavorare per parecchi anni a basso livello, e quindi di comprendere meglio il significato di certi concetti e le implicazioni che si portano dietro.
Nel prossimo articolo parlerò anche dei “128 bit” della PS2. ;)
@mede: non ho detto che il SNES era più potente del Genesis. A mio avviso ognuna delle console aveva punti di forza (e di debolezza), e sostanzialmente sul piano meramente ludico si equivalevano.
@Medicina: per una console dell’epoca quella CPU mi sembra decisamente non appropriata.
Da quel che ho letto gli opcode occupano troppo spazio (consumando la preziosa nonché cara memoria), e le istruzioni impiegavano da 8 a 23 cicli di clock (per cui era anche particolarmente lenta).
Beh, non guardare me: non l’ho progettata io, avevo 6 anni quando il babbo me l’ha portata. :-) All’epoca aveva avuto un discreto successo però.
Comunque, volendo allargare il discorso, anche sulle GPU ce ne sarebbe da “questionare”.
Per esempio, mi sono sempre chiesto (e a tutt’oggi non ho ancora una risposta convincente) cosa volesse dire quella specifica tecnica della mia prima VGA “seria”, la Matrox Millennium (si parla del 1995, che bei tempi…) per la quale si riferiva un pomposo “32-bit VGA core”. Cioè? Ampiezza del bus dati? Dei registri del chip grafico?
Venendo a tempi più recenti, quando era stata presentata la versione aggiornata della GeForce 7800 GTX con 512 MB di memoria si parlava di GPU a 512 bit, salvo poi scoprire che ci si riferiva all’ampiezza del bus di comunicazione tra GPU e memoria video.
Insomma, tanta confusione che aveva come unico scopo quello di trovare il modo di sparare un numero alto… ma serviva poi davvero un bus a 512 bit? I modelli Nvidia successivi sono andati su bus più “stretti” e anche modelli di schede video attualmente di fascia media o medio-alta usano bus ben più “magri” (la mia Radeon HD 4670, che non è propriamente “ferma”, ha un bus a 128 bit).
Ciao
Filippo
Nei computer è l’address bus, in quanto determina la dimensione massima teorica della memoria. Anche il data bus tende ad avere la stessa dimensione, in quanto è necessario sia abbastanza grande per trasportare un indirizzo ma abbastanza piccolo per essere economico (fa parzialmente eccezione l’Intel 8086 in grado di gestire un indirizzamento a 20 bit)
Una console ha l’architettura bloccata e non è molto frequente l’incremnento della memoria: quindi, giustamente, per una console (moderna) è puro marketing.
@AlPa
Ma anche volendo seguire questa regola, allora fa eccezione anche l’Intel 80386SX che dovrebbe essere definito “CPU a 24 bit” (ricordo che questo modello aveva appunto il bus indirizzi “castrato” rispetto al 386DX che invece aveva l’address bus a 32 bit “pieni”).
Stesso dicasi per il 68000 da me già citato, che a seconda di come lo si guarda potrebbe addirittura avere 3 diverse denominazioni: se guardiamo l’ampiezza del bus dati, è una CPU a 16 bit; se invece si prende l’address bus, è una CPU a 24 bit; infine, guardando l’ampiezza dei registri, è una CPU a 32 bit… e qui come la mettiamo? LOL!
bell’articolo, anche se ormai la confusione regna sovrana anche nei pc…
@Medicina: non ce l’avevo mica con te. Anzi, riportando quell’informazione mi hai dato la possibilità di conscere un altro sistema e un’altra CPU. :)
@filippo1974: per quanto riguarda il core della VGA “a 32 bit”, credo si riferisca all’unità di calcolo per l’accelerazione di alcune funzionalità.
Ad esempio, l’Amiga aveva un blitter per eseguire operazioni logiche sui bitplane, che operava a 16 bit.
Successivamente anche le VGA integrarono dei blitter per fare le stesse cose (e anche più avanzate: col tempo si aggiungevano altre funzionalità di accelerazione 2D), per cui è possibile che quei 32 bit si riferiscano a questo tipo di operazioni.
Per le GPU in genere si è usata l’ampiezza del bus dati esterno (con la VRAM, quindi) come “metro”.
@AlPa concordo con filippo1974: utilizzare l’ampiezza del bus indirizzi non è particolarmente significativo come dato. Ne parlerò meglio in un prossimo articolo.
Ma certo… Mi dispiace non poterti dare più dettagli tecnici.
Concordo che non c’è un metro universale e condiviso per definire i bit di un sistema. Ma dai retaggi del primo esame di Architettura degli Elaboratori (correva l’anno 1997…) mi pareva di aver capito che il modo più “giusto” fosse quello di considerare la larghezza in bit del bus che collega la CPU alla memoria. Il motivo è semplice: quando compilato in linguaggio macchina (fatto di 0 e 1) un programma viene suddiviso in tranche di n bit dove n è la larghezza del bus della relativa architettura. Pertanto alla CPU arrivano dalla memoria, attraversando il bus, n bit alla volta da macinare. Tale stringa di n bit può essere un dato, un indirizzo o un’istruzione. In un architettura semplice (senza coprocessore, con frequenza CPU = frequenza BUS, senza pipeline, etc.) è chiaramente evidente che passando da 8 a 16 bit si raddoppia (a parità di frequenza) la quantità di dati che il processore macina nella stessa unità di tempo e quindi il salto di performance è molto evidente. Nel 1997 mi esercitavo proprio con un simulatore per 68000 e funzionava proprio così: ad ogni ciclo di clock corrispondeva una “fetch” dalla memoria di 16 bit, poi internamente la CPU aveva registri a 32 bit che permettevano, tra le altre cose, di sommare o moltiplicare operandi a 16 bit senza andare in overflow o ricorrere a barbatrucchi vari. Ma a livello accademico, nel 1997, il 68000 era considerata una CPU a 16 bit per quanto spiegato sopra.
Personalmente non concordo, e ne parlerò meglio in un prossimo articolo focalizzato proprio sulle CPU in cui vorrei sviscerare tutto ciò che concerne i “bit” per questo importantissimo componente.
Comunque e per dare una parziale risposta, una MOVEQ #100,D0 su un 68000 eseguiva, sì, il fetch dalla memoria di una word a 16 bit per prelevare l’opcode dell’istruzione, ma produceva un risultato a 32 bit… ;)
La differenza la fa l’ISA, non certo la larghezza (tantomeno quella fisica) dei bus.
@lebi77, stando a quel ragionamento come collocheresti CPU tipo il 68008, 386sx o Pentium?
Fammi tirare a indovinare: 8, 16 e 64 bit rispettivamente? O:-)
Comunque le istanze di lebi77 hanno un giusto fondamento, dal punto di vista che ha espresso.
La questione va sicuramente affrontata a 360° perché, come avrete capito, la ragione non ce l’ha nessuno in tasca su quest’argomento. ;)
Beh le architetture si sono fatte via via più complesse e già per il Pentium la cosa cadeva perché aveva sì un bus a 64 bit ma il tutto era organizzato e memorizzato in memoria a quantità di 32 bit. Non ricordo perché il bus fosse il doppio. In tutta sincerità sono passati parecchi anni e non sono più ferratissimo…cmq mi sento di classificare il Pentium come CPU a 32 bit perché internamente manipolava nativamente quantità a 32 bit. Attendo speranzoso un articolo chiarificatore su tutto questo! :)
Sarà fatto, come promesso. :)
P.S. Per il Pentium l’esigenza del bus dati esterno a 64 bit fu quella di poter riempire più velocemente la cache.
[…] un precedente articolo ho parlato di “misura dei bit” dell’architettura di un sistema, e ho […]
[…] precedenti abbiamo trattato il tema della “classificazione”, rispettivamente, di un sistema e di una CPU (o processore in generale) in termini di […]
[…] spesso fuorviante e legata ad operazioni di marketing (e per gli approfondimenti vi rimando all’illuminante articolo di Cesare Di Mauro), quel che è certo è che il progetto divenne “unreleased” per far spazio […]
Ottimo articolo di Cesare , lascio le specifiche tecniche dell’Atari Jaguar , credo siano tra le più complete che ho letto online :
Processors (5 in 3 chips):
– “Tom”
– 750,000 transistors, 208 pins
– Graphics Processing Unit (processor #1)
– 32-bit RISC architecture (32/64 processor)
– 64 registers of 32 bits wide
– Has access to all 64 bits of the system bus
– Can read 64 bits of data in one instruction
– Rated at 26.591 MIPS (million instructions per second)
– Runs at 26.591 MHz
– 4K bytes of zero wait-state internal SRAM
– Performs a wide range of high-speed graphic effects
– Programmable
– Object processor (processor #2)
– 64-bit RISC architecture
– 64-bit wide registers
– Programmable processor that can act as a variety of different video architectures, such as a sprite engine, a pixel-mapped display, a character-mapped system, and others.
– Blitter (processor #3)
– 64-bit RISC architecture
– 64-bit wide registers
– Performs high-speed logical operations
– Hardware support for Z-buffering and Gouraud shading
– DRAM memory controller
– 64 bits
– Accesses the DRAM directly
– “Jerry” – 600,000 transistors, 144 pins
– Digital Signal Processor (processor #4)
– 32 bits (32-bit registers)
– Rated at 26.6 MIPS (million instructions per second)
– Runs at 26.6 MHz
– Same RISC core as the Graphics Processing Unit
– Not limited to sound generation
– 8K bytes of zero wait-state internal SRAM
– CD-quality sound (16-bit stereo)
– Number of sound channels limited by software
– Two DACs (stereo) convert digital data to analog sound signals
– Full stereo capabilities
– Wavetable synthesis, FM synthesis, FM Sample synthesis, and AM synthesis
– A clock control block, incorporating timers, and a UART
– Joystick control
– Motorola 68000 (processor #5)
– Runs at 13.295MHz
– General purpose control processor
Bus bandwith:
106.4 Megabyte per second
Display:
– Programmable screen resolution. Horizontal resolution is dependent on the amount of scanline buffer space given to the “Tom” graphics processor. Maximum vertical resolution varies according to the refresh rate (NTSC or PAL). Reportedly, a stock Jaguar (without additional memory) running NTSC can display up to 576 rows of pixels.
– 24-bit “True Color” display with 16,777,216 colors simultaneously (additional 8 bits of supplimental graphics data support possible).
– Multiple-resolution, multiple-color depth objects (monochrome, 2-bit, 4-bit, 8-bit, 16-bit, 24-bit) can be used simultaneously.
Colors available:
16.8 million
Sound:
16-bit
Ports:
Cartridge slot/expansion port (32 bits)
RF video output
Video edge connector: (video/audio output) (supports NTSC and PAL; provides S-Video, Composite, RGB outputs, accessible by optional add-on connector)
Two controller ports
Digital Signal Processor port (includes high-speed synchronous serial input/output)
Dimensions:
9.5″ x 10″ x 2.5″
Controllers:
Eight-directional joypad
Size 6.25″ x 5″ x 1.6″, cord 7 feet
Three fire buttons (A, B, C)
Pause and Option buttons
12-key keypad (accepts game-specific overlays)
Input/Output:
Cartridge and expansion port, an edge connector
User port, also an edge connector
2 x Joystick ports for digital Atari-style joysticks
TV output (RF modulator, also transmits audio to the TV)
RGB output, including audio and composite video
Serial port for connecting printers and floppy drives
Tape recorder port, yet another edge connector. This is for Commodore’s specialised tape recorder running at 300 bps.
http://www.vgmuseum.com/systems/jaguar/
volevo anche ricordare , non so se lo conoscete , che esiste un sitema arcade dell’Atari che si chiama Cojag , era un ibrido in 2 versioni una con l’hardware del Jaguar a cui è stata innestata la cpu della Psx ( R3000 @ 33 Mhz ) e l’altra ( solo per il gioco Area 51 ) a cui è stato innestato un motorola ( 68EC020 @ 25Mhz ).
HARDWARE DESCRIPTION Atari Cojag :
Main CPU : R3000 @ 33 Mhz (68EC020 @ 25Mhz for Area 51 only)
Graphics Chip : “Tom” @ 26MHz
It has a video controller to generate all the video signals needed. It has an object processor which can render sprites or bitmaps, scaled or straight, in a number of different formats. It also has a blitter which can do complex object manipulations like rotation, scaling, Z buffering and Gouraud shading. Finally, there is a RISC DSP built into Tom, which runs a custom instruction set designed by Atari. The DSP is designed to run in parallel with the main CPU to handle fancy graphics.
Sound – I/O Chip : “Jerry” @ 26 MHz
It has several timers and is connected to a pair of 16-bit DACs. These are controlled by another RISC DSP, related to the one in Tom, that is generally used to play sounds. It is also responsible for all the I/O with controllers and other parts of the system.
Board composition : Main board and Hard Drive (apart from Fishing Frenzy and Freeze), JAMMA harness.
http://www.system16.com/hardware.php?id=778
Qui http://www.youtube.com/watch?v=C3uAaaTXC04 video di Vicious Circle (prototype) un picchiaduro clone di Killer Instinct.
un saluto ancora a Jacopo e Cesare.
Ottimo articolo, tra l’altro hai preso degli esempi perfetti per spiegare come i metri di giudizio fossero a volte fuorvianti per dettagliare la qualità dell’intera architettura (vedi PC engine)