Newsgroup: it.comp.retrocomputing
Titolo: una vecchia domanda

Classe 1971, vissuto nel pieno boom dei Commodore, dal mitico PET con
la tastiera rossa e blu fino agli ultimi modelli di Amiga.
Con un amico commodore64dipendente come me - da ragazzini - ci si
chiedeva: ma gli incredibili videogiochi per il 64 erano sviluppati
*sul* 64?
In altre parole: "Mission Impossibile" della Epyx o "Maniac Mansion"
della Lucasgames - con tutte quelle animazioni, quella struttura, quei
suoni campionati, venivano sviluppati su quell'affarino con 38K di Ram
a disposizone?
La nostra tesi era che in realtà le software house di metà anni
Ottanta avevano a disposizione ben altre macchine sulle quali
sviluppare e nei cui ambienti "distillavano" un codice macchina che
poi fosse in grado di girare sui processori commodore.
Purtroppo all'epoca non ero così esperto per saper dare anche una
risposta. Oggi neanche, ma magari qui c'è qualcuno che lo sa.
V.

Maniac Mansion (che è l'unico gioco AMIGA che conservo gelosamente in
originale nella sua scatola) era stato sviluppato in SCUMM (Script
Creation Utility for Maniac Mansion) ed è per questo motivo che è
stato facilmente trasportato su PC IBM EGA,  Apple II GS ed Atari ST
(bastava un interprete SCUMM adatto per quella machina e quindi non
era necessario fare il porting di tutto il gioco/musiche/disegni).
In proposito vedi 
http://it.wikipedia.org/wiki/SCUMM
.
All'interno del gioco DoTT (Day of the Tentacle)  puoi trovare un PC
dove giocare a Manic Mansion (il gioco nel gioco ^_^ ).
Confermo che era un gioco meraviglioso.
Mauro


 originale nella sua scatola) era stato sviluppato in SCUMM (...)
Grazie, ma... non hai risposto pienamente alla mia domanda.
Voglio dire: i programmatori della Epyx che hanno sviluppato giochi
come Impossibile Mission o Summergames oppure queli della Melbourne
che hanno edificato il ciclopico The Hobbit come facevano?
Accendevano il loro C64 e in quei 38K ci facevano girare: a) un
ambiente di sviluppo (e debug, inevitabilmente); b) il gioco stesso?
Mi sembra improbabile.
Sono certo quasi al 100% che i migliori giochi per il 64 non sono
stati sviluppati con il Basic "di serie". Esistevano molte extension è
vero (dal celeberrimo Simon's Basic al Toolkit Basic della stessa
Epyx). Tuttavia queste ext lasciavano ben poco spazio disponibile (dai
13K ai 17K se non erro). Dunque escluderei che l'Hobbit, con tutte
quelle schermate, i controlli per la continuity del gioco, il solo
testo, etc. si accontentassero dei soli 15K al netto dell'ambiente di
sviluppo... E' vero che non ha molto senso paragonare i 15K del 64 di
allora ai 15K del nostro Mac, ma insomma...
La mia tesi è sempre stata questa: le grandi software house
utilizzavano macchine più potenti del 64 (ad esempio gli IBM
dell'epoca con doppio drive e dunque possibilità - per quanto
rudimentale - di paging). Su queste macchine loro aveva sviluppato e
installato un emulatore (né più né meno come quello che oggi noi
facciamo girare sui nostri portatili per rigiocare a Pitfall II o a
Ghostbuster...). Forti di questo ambiente e di un bel po' di RAM in
più, sviluppavano (in assembler, non vedo in che altro modo...),
testavano, debuggavano e una volta pronti prendevano il solo "codice
eseguibile" e lo facevano girare sui Commodore 64.
Questa mia tesi, che però sarei curioso di vedere smentita o
dimostrata definitivamente, deriva anche dal fatto che - a partire da
un certo punto in poi - i giochi per il C64 hanno goduto di una
grafica invidiabile e di suoni incredibili (per l'epoca, ça va sans
dire). Dubito che la Epyx (aridaje!) abbia potuto creare i formidabili
movimenti dell'omino di Impossibile Mission ol il tuffo carpiato di
Summergames per quanto forte del suo Toolkit Basic (ma ce li vedete
che renderizzano le animazioni a colpi di ARC, CIRCLE, DOT... etc.? Ma
via, siamo seri!).
Insomma io ritengo che esistavano dei sistemi - chiamiamoli così -
meta-64 dotati di tool bombosi per la grafica, il suono, la
programmazione strutturata, etc. ed erano queste macchine quelle che
usavano i programmatori degli anni Ottanta per produrre i giochi che
poi giravano sui Commodore.
V.



La domanda non è di semplice risposta.
Quel che è sicuro che quasi la totalità dei videogames, per C64 e Spectrum,
erano scritti totalmente in L/M e non in Basic per ovvi motivi di velocità.
Lo confermano riviste dell'epoca che nelle recenzioni "affossavano"
letteralmente i giochi, specie arcade o platform, in cui si riconosceva
l'uso spinto del BASIC o di un compilatore per realizzarne certe parti.
Peraltro, adventure classici come Hobbit sarebbero potuti, anche in parte,
essere scritti in BASIC perché non dovevano richiedere grandi tempi di
elaborazione se non per l'esecuzione degli schermi di accompagnamento (nei
quali era sufficiente utilizzare routine L/M semplici e standard per alcuni
effetti speciali quali il riempimento di figure e così via).
Certo la RAM del C64 o dello Spectrum non consentiva l'inserimento di un kit
di sviluppo (che per i programmatori in Assembler o L/M puro non è peraltro
così necessario), ma se si suppone che il gioco era sempre formato da più
parti disgiunte (l'introduzione, il menù delle opzioni, i vari "quadri"
ecc.) allora si può anche pensare che i programmatori sviluppassero le varie
parti su tanti C64 separati, e quindi la memoria occupata per la parte da
sviluppare diminuisce e aumenta quella per un eventuale kit, dove per "kit",
immaginiamo si parli di librerie di funzioni assembler di uso comune
(movimento sprite, rilevamento collisioni, scrittura punteggio eccetera).
In ogni caso all'epoca c'era chi avvalorava l'ipotesi da te fatta (mai
peraltro confermata da nessuna rivista del settore): che lo sviluppo fosse
fatto realmente su altre piattaforme che emulavano la macchina, ma non si
spiega come un PC dell'epoca fosse in grado di emulare un C64, cosa che
realmente si è riuscita a fare in modo accettabile solo all'epoca dei 386 a
20MHz quando i C64 già erano sul viale del tramonto. C'era chi parlava di
potenti sistemi Unix in cui i giochi venivano scritti in C e post-processati
da librerie che li convertivano in codice macchina per il C64, ma è una
teoria che francamente vedo assai macchinosa anche per i lunghi tempi di
debug che tale cosa avrebbe richiesto, tempi forse incompatibili con quelli
di marketing.
Da tener conto, infine, che le software house riuscivano a sviluppare con
facilità e velocità moltissimi giochi per tutte le piattaforme (C64,
Spectrum, Atari 800, Amstrad, BBC, Apple II, PC ecc.) e questo rimane uno
dei misteri dei programmatori dell'epoca :)
--
SFDR
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 poi giravano sui Commodore.
Penso che molti giochi venissero sviluppati direttamente sulla
macchina su cui giravano, naturalmente equipaggiata al massimo
(drive,stampante, toolkit per il C64 e microdrive e interfacce varie
per lo Spectrum).
Dato che molto spesso i videogiochi erano sviluppati da una/due
persone semplicemente ci si divideva i compiti e....la memoria a
disposizione.
Naturalmente nulla toglie che le parti grafiche (sprite e schermate
statiche) potessero essere sviluppate su dei PC e tradotte nei formati
grafici corrispondenti...ma il codice principale (imho) veniva scritto
e testato direttamente sulle macchine.
Ricordo uno dei primi emulatori (hardware/software) dello Spectrum che
girava sull' A500 distribuito dalla Digimail di milano......

 dei misteri dei programmatori dell'epoca :)
Ecco, la parola "mistero" è appropriata. Esulando dal campo dei
giochi, pensiamo a un applicativo come GEOS. Ma ve lo ricordate? Come
faceva a girare (solo a girare, dico) una cosa come quella su un
banale 64?! E come si fa a sostenere che quel framework operativo sia
stato *sviluppato* (!!!) su un 64?! Altro che mistero, diciamo
chiaramente: stregoneria! :-))))
Scherzi a parte, sarebbe molto interessante leggere interviste e
dichiarazioni "off-the-record" dei protagonisti dell'epoca.
Grazie per la dettagliata risposta, comunque.
V.

 chiaramente: stregoneria! :-))))
Ma nemmeno per idea... GEOS era molto più semplice di un videogame 3D come
"Movie" o "Knight Lore" o a un gioco di calcio come "Match Day". GEOS non
era certo Windows né tantomeno si avvicinava alle problematiche di Windows.
Forse volevi scherzare, ma volendoti prendere sul serio, ho l'impressione -
non me ne volere - che non hai le idee chiare su come si programmi, e si
sviluppi una applicazione.
Ci sarebbe molto di più da discutere, ad esempio, di come i programmatori
dell'epoca riuscivano a ottenere ottimi prodotti con appena 40k di RAM,
spingendo fino all'osso le caratteristiche della macchina (obbligati
altrimenti "ciccia"), mentre oggi un gioco per PC bisogna avere almeno 1Gb
di RAM e una scheda video spaziale altrimenti è tutto lento... nessuno
programma più in LM....


 poi fosse in grado di girare sui processori commodore.
Possibile, ma credo che buona parte dei programmi in LM per le
macchine dell'epoca venisse scritta direttamente sulla macchina. Un
foglio di carta per scrivere il codice, un monitor (mi pare che lo
Zoom per il C64 stesse in 4KiB e faceva assembler, disassembler ed
altre amenità utili) ed un'ottima conoscenza della macchina.
Poi, successivamente con macchine più potenti (e complesse) ci si è
abituati a tante cose belle (debugger, editor ed ambienti di sviluppo
più o meno completi), ma è incredibile vedere cosa sono riusciti a
fare degli appassionati armati solo del proprio cervello, di un foglio
di carta e poco altro.

Io non penso ricorressero ad altre macchine (a parte forse rarissimi casi) e 
sviluppassero direttamente sulla macchina target, in fin dei conti la 
maggior parte dei capolavori sono usciti dalle menti (e dalle dita) di 
singoli programmatori (spesso hobbisti e che comunque non potevano 
permetersi certi investimenti e che il mercato di allora anche per via della 
pirateria poteva permettersi), o al massimo di gruppi di 2 o 3 persone in 
cui uno si occupava della programmazione,uno della grafica e uno del suono 
(sul 64, pechè sullo Spectrum era praticamente inutile); era il tempo dell' 
"one man, one game", l'epoca di geni come i fratelli Stamper.
Al massimo posso pensare che venissero utilizzate macchine diverse solo per 
la grafica o per la musica (come altri ti hanno proposto in alti post), in 
seguito ho letto che alcuni giochi in lavorazione per il QL vennero 
sviluppati su macchine più potenti, ma sempre basate sul 68k, ma ormai 
l'epoca degli home computer era al tramonto.
Leggendo gli altri tuoi post secondo me non hai ben chiaro come si scriveva 
un'applicazione per le macchine di allora e l'aver - probabilmente - 
programmato su macchine più recenti ti ha portato ad un livello di 
astrazione che non ti ha permesso di conoscere la realtà dell'hardware che 
sta sotto al sistema operativo.
Per quanto riguarda il ricorso al BASIC è logico che è improponibile per la 
maggior parte dei giochi per una infinità di motivi tra cui principalmente 
la velocità (secondo me questo fu uno dei principali motivi di insuccesso 
del TI99 che in versione base - 16k aveva solo 256 bytes in cui poteva 
essere caricato un programma LM, il resto andava tutto scritto in BASIC e 
veniva immagazzinato nella RAM del chip video che non era mappata nello 
spazio di indirizzamento della cpu).
Spesso alcuni videogiochi erano composti da rountine in assembler lanciate 
da uno scheletro in BASIC (Ant Attack, era per il 99% in LM, con una 
particina in BASIC per disegnare la parte fissa dello schermo dentro cui si 
sviluppava il mondo 3D del gioco ed aggiornare i punteggi a fine partita).
Qualche successo in BASIC c'è stato (al momento non ricordo il titolo), 
alcuni invece erano in assembler, ma ricorrevano a routine in basic per 
esempio per tracciare primitive grafiche o scrivere testi sullo schermo 
(forse tra questi c'è "The Hobbit", ma non ne sono sicuro, ne ho solo avuto 
l'impressione)
Come esperienza personale nell'85 ho realizzato un videogioco per lo 
Spectrum:
http://users.libero.it/c_altieri/mlol.htm
Per la grafica mi ero scritto un programmino in basic semplice semplice con 
cui disegnare gli pseudo-sprite, per il codice macchina prima assemblavo 
tutto a mano (avevo un manuale della SGS che spiegava come realizzare il 
firmware per una stampante a margherita sullo Z80 e alla fine aveva il 
datasheet del microprocessore con gli op-code), poi quasi subito in edicola 
ho trovato allegato a una rivista CHAMP un fantastico 
assemblatore/monitor/debugger multipiattaforma che occupava solo qualche 
kbyte di memoria, il grande vantaggio fu il non doversi ricalcolare a mano 
tutte le volte i jump relativi (per i quali bisognava tenere conto anche 
della lunghezza degli opcode) anche se ormai avevo raggiunto una certa 
manualità.
Come detto in altri post gli strumenti dei programmatori di allora (e miei 
strumenti) erano il computerino, la propria testa, carta e penna (ho ancora 
il quadernetto a quadretti con tutta la grafica e il codice asm ... mi 
commuovo a rivederlo) e un assemblatore.
Tempo impiegato per svilupparlo? 1 mese compreso il tempo per apprendere 
l'assembler che allora conoscevo pochissimo e in maniera totalmente da 
autodidatta (avevo solo il citato libro della SGS).
Il porting su altre piattaforme? Secondo me veniva fatto tutto da 0 se su 
cpu diverse, riciclando al più la grafica, se sulla stessa cpu buona parte 
del codice poteva essere riutilizzato, al massimo rilocando parti di codice 
e riscrivendo le routine per la grafica, per il suono e per l'input.
Questo il mio contributo, mi sembra incredibile pensare a schiere di 
programmatori che non hanno percorso la mia/nostra stessa strada ... 

 ...
ti sarebbe sicuramente utile leggere qualche "diario del gioco xyz" che
pubblicavano anni addietro su Zzap!, in cui giorno per giorno vedevi nascere
il videogame.
Fai un salto su "progetto zzap! italia" e troverai le scansioni delle
riviste, leggile e capirai tutto.
Per ora hai preso parecchie cantonate. 38KB erano disponibili al *BASIC*, ma
se "sganciavi" il BASIC (disalloccandolo) riuscivi ad ottenere moltissima
piu' ram.
Questo ovviamente significava che se non usavi il BASIC, dovevi per forza
usare il L/M, programmando direttamente con il "programma monitor"
(assembler).
Correttamente come dice Speccyman, ci si divideva i compiti. Della serie:
- aoh quanto ti serve per il gioco?...
- 10K per il codice e 35K per la grafica
- OK quanto mi lasci per la musica?
- 10K
- OK, faccio il possibile, al limite riduco gli effetti sonori o taglio due
musichette
Totale 55K... e considera che spesso i dati venivano COMPRESSI direttamente
dal programma, per cui riuscivi a risparmiare parecchio... e non dirmi che
"10K per le musiche non bastano", perche' un conto e' fare un MP3 o un WAV,
ed un'altra cosa e' programmare col SID! ;-)
...ripeto: leggiti i diari e capirai. :-)
MADrigal
-- 
----------------------------------------------------------------------
Dr. Eng. Luca Antignano                MADrigal's handhelds simulators
find your FREEWARE entertainment at: 
http://www.madrigaldesign.it/sim/
ora anche in italiano:            
http://www.madrigaldesign.it/sim_it/
----------------------------------------------------------------------

 Per ora hai preso parecchie cantonate.
Mah, cantonate. Io non sono un programmatore, né un esperto di
computer, anche se da ragazzino "trafficavo" parecchio e leggevo un
po' di riviste del settore. Avevo postato qui proprio per capire come
stavano effettivamente le cose. E direi che come spesso accade la
verità sta nel mezzo.
Comunque grazie a tutti. E' stata una discussione interessante.
V.

 computer...
Per cantonate mi riferisco al tuo "ma se il C64 ha solo 38 K di RAM, come
faccio a farci stare dentro i programmi in L/M?".  Il fatto e' proprio che
il BASIC non lo usi... e cosi' ti liberi tutta la RAM del suo parser, per
farci stare dentro tutto l'ASM che puoi. :-)
Cmq e' vero, la verita' sta nel mezzo, e la discussione e' stata molto
interessante :-)
Saluti,


 modo mediante magari qualche interfaccia pseudo-midi :-)
Io avevo scritto un programmino in LM (come Carlo, conservo ancora i
fogli di carta su cui lavoravo) che gestiva le tre voci del SID in
maniera indipendente, leggendo il brano da una tabella in RAM. Il
tutto gestito da interrupt, quindi potevi continuare a lavorare in
Basic ed ascoltare la tua creazione :-)
L'occupazione totale non me la ricordo, ma non credo che il programma
superasse i 256 bytes in totale, più la tabella con gli eventi.
Oltretutto, non è difficile riempire la tabella, anche a mano: basta
avere la musica su partitura, si sa che per una croma su un sol ci
vuole un suono 173 di durata 64 (per esempio). In poco più di 1KiB ci
sta un'invenzione a tre voci di Bach...
E comunque, non so voi, ma io ho iniziato su un VIC20, che aveva poco
più di 3KiB liberi. Programmo tuttora dei PIC in assembly con
l'equivalente di 4KiB di spazio libero. Per me 38KiB sono tuttora
TANTI!

 nessuno programma piů in LM....
Vaglielo a dire su comp.lang.asm.x64 e alt.lang.asm, senza contare la scena
c64, spectrum, atari, oric, etcetc ancora vivissime. Io lo faccio ancora,
sia 6502 che x86.
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Se la masturbazione rende ciechi, la fellatio
rende muti, almeno finche' non hai finito. (Anonimo)

 venivano sviluppati su quell'affarino con 38K di Ram a disposizone?
38k a disposizione del basic 2.0, 64k se programmi in asm, ricordatelo.
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
L'uovo ha una forma perfetta, benche' fatto col culo.

 Archivio PAPER Soft 

 sia 6502 che x86.
Per il 6502 posso approvare, ma l' x86 ? specie l' 8086/186/286, come si 
fa a scazzarsi colla peggiore architettura e set di istruzione mai fatta 
? Se ti piace l' assembler 16 bit, buttati sul 68K, va'.....
E non accuso certo la memoria segmentata (anche il 6502 ha la memoria 
segmentata, ma l' architettura e' buona, l' unica cosa che non va e' lo 
stack fisso e troppo piccolo) quanto la rigidita' dei registri, che 
costringe a continui MOV qua e la' per effettuare operazioni che in 
altri proci si fanno più celermente e con più flesibilita'
Saluti,
Dott. Piergiorgio.

 l'impressione)
Non so bene nel caso di "The Hobbit" (a me risulta interamente in LM 
salvo il loader, almeno nella versione spectrum) ma uno degli ultimi 
bastioni ludici del basic erano le avventure testuali (le avventure 
Arscom, per esempio, erano scritte in basic, con una parte in LM 
pilotata dal Basic per la grafica) ove da un lato la velocita' non era 
fondamentale e dall' altro lato c' erano in tutti i dialetti basic 
primitive per la manipolazione delle stringhe, essenziale per i parser 
(la parte degli adventure incaricata di interpretare gli input del 
giocatore).
Altro ridotto del basic erano i wargames e giochi di strategia, tant' e' 
che i wargames SSI ancora nei primi '90 erano in basic compilato, 
difatti si trovano nell' EXE le stinghe identificative del compilatore 
basic e Pirates della Microprose per C64 era in basic interpretato, come 
risulta dalla gabola apparsa su Zzap! a suo tempo.
Saluti,
Dott. Piergiorgio.

 
verde...@hotmail.it
 wrote:
...ma sei dappertutto iAN! Stavo appunto per dire "chiedi a iAN per maggiori
informazioni" ma mi hai preceduto! :-)


 buttati sul 68K, va'
Fatti i fatti tuoi va, decido io cosa deve piacermi ;)
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Blow your mind - smoke gunpowder.

dott.Piergiorgio ha scritto:

Quoto pienamente !
Ho programmato in assembler per anni con gli Z80, 6502, 68K, H8/300, 
H8/S, ma non sono mai riuscito a mettere su un programma decente con i 
micro della Intel. Solo qualche patch per sproteggere i programmi.
Non riesco a capacitarmi di come Linus sia riuscito a mettere su un SO 
con l'assembler di una simile macchina.
Forse la modalita' protetta con la memoria lineare e' piu' facile da 
maneggiare, ma la segmentazione, i puntatori dedicati (per cui per ogni 
istruzione devi ricordarti quale registro puoi o non puoi utilizzare) 
etc., e' una cosa allucinante.
Il fatto poi, di poter scrivere un indirizzo di memoria in non so quante 
varianti (a seconda del registro di pagina) e' una cosa allucinante al 
quadrato.
Per quanto riguarda lo sviluppo di software, non e' escluso che si siano 
utilizzati degli emulatori hardware del micro. In pratica si prende il 
C64, si toglie il microprocessore, si infila il probe dell'emulatore e 
dalla macchina dell'emulatore si comincia a scrivere codice.
In questo modo si puo' far girare il programma come se fosse sul C64 con 
tutte le periferiche attive e la velocita' nativa, ma con il vantaggio 
che sulla macchina emulatore si puo' controllare il flusso del 
programma, si possono inserire break point, si possono vedere le 
variabili e le locazioni di memoria e chi piu' ne ha piu' ne metta.
In cantina ho ancora due emulatori HP64000 con i probe Z80 e 68K.
Ogni tanto li accendo solo per sentirne il rumore, il caratteristico 
boing all'accensione, e il feedback della tastiera (sig, lacrimuccia :) ).
Ciao
Giuseppe

 utilizzati degli emulatori hardware del micro.
Già a questo non avevo pensato ... ma penso che ormai c'erano in giro 
assemblatori e cartucce 'speciali' (peril C64) tanto sofisticati che forse 
potevi fare a meno di un emulatore hardware (che tra l'altro ricordo 
costavano un casino). Non so, l'ultima parola spetta ai programmatori del 
tempo.
Carlo 

Visto che nessuno ne ha parlato, ma molti addirittura hanno tirato
fuori i "monitor" che si allocavano in una zona di memoria e
permettevano di programmare nelle altre (e poi voglio vedervi a
rilocare a manina se dovevate inserire un'istruzione che vi eravate
scordati), vorrei citare un prodotto rilasciato dalla Commodore e che
serviva propio a sviluppare: Il Commodore Macroassembler.
Questo strumento era incredibilmente leggero, e comprendeva una intera
suite di strumenti che consentivano di sviluppare "professionalmente"
in assembly sul C-64.
Pensate che per evitare di occupare la memoria con un editor dedicato,
il macroassembler sfruttava l'editor integrato in ROM (quello del
basic per intenderci) con minime modifiche software.
Il codice prodotto con il macroassembler poteva essere facilmente
compilato per la zona di memora che si desiderava (es. $C000,
$0840....) e il codice oggetto linkato con un apposito tool.
Io ne sono un orgoglioso possessore originale, ma se vi interessa, è
scaricabile dal mio sito: 
http://www.farenga.it/8bit.asp
.
Fabrizio

A questo indirizzo
http://ready64.altervista.org/articoli/categorie.php?id=1
trovi alcune interviste a programmatori di giochi per Commodore 64 che 
possono rispondere alla tua domanda. 

 In cantina ho ancora due emulatori HP64000 con i probe Z80 e 68K.
Può essere che abbia visto una cosa del genere due anni fa a Vicenza
Retro? :?
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.storiediapple.it
 -->
<!-- 
http://www.nezmar.com
 -->

 Retro? :?
Penso proprio di si :)
Non e' che ce ne siano molti in giro!
Ciao
Giuseppe

 Non e' che ce ne siano molti in giro!
Allora complimenti: č un oggetto alieno quanto affascinante. Ti va di
parlarne un po'? :)


 parlarne un po'? :)
Sempre disponibile.
Se intanto vuoi dare un'occhiata qui trovi qualche foto e descrizione:
http://www.webalice.it/gziggio/retrocomputer.htm
Ciao
Giuseppe