A tre anni di distanza, nel 1987 Motorola presenta il 68030, revisione del core introdotto col 68020, similmente a quanto aveva fatto in precedenza col 68000 e il 68010, in quello che sarà un ciclo pari-dispari che contraddistinguerà questa fortunata e apprezzata famiglia di microprocessori.
Revisione può sembrare un termine che sminuisce l’importanza di una CPU, ma non deve avere necessariamente un’accezione negativa. Al solito, bisogna guardare ai fatti e alle novità introdotte, tenendo in debito conto il contesto in cui ciò avviene.
Se gli 84mila transistor del 68010 rappresentano appena il 24% in più dei 68mila utilizzati dal suo predecessore, il 68030 coi suoi 273mila arriva a superare del 44% i 190mila del 68020, lasciando quindi immaginare che “sotto la scocca” un bel po’ di cose saranno state migliorate. Tutto ciò senza nulla togliere ai notevoli e apprezzati miglioramenti sul fronte della virtualizzazione che ha portato il 68010.
Cominciamo col dire che questa CPU è la prima della famiglia a integrare un’architettura (parzialmente) di tipo Harvard, in quanto l’unità centrale è in grado di leggere contemporaneamente le istruzioni dalla cache per il codice e i dati dalla nuova cache per i dati (utilizzando allo scopo, quindi, bus diversi e paralleli).
Infatti ai 256 byte di cache per il codice, il 68030 ne affianca altrettanti per i dati, ed entrambe sono in grado di fornire una longword (32 bit) in un solo ciclo di clock. Inoltre per mantenere coerenza con la memoria, se un dato presente in cache viene (sovra)scritto, la CPU provvede ad aggiornare contemporaneamente sia la cache che la memoria. E’ anche possibile decidere di memorizzare comunque il dato in cache (anche se in precedenza non era in essa presente), settando un apposito bit nel registro CACR (per la gestione della cache) che abilita questa politica di write allocation.
Rispetto al 68020 c’è, comunque, una grossa differenza che riguarda l’organizzazione dei dati nella cache. Mentre prima i 256 byte erano suddivisi in 64 “linee” (con ogni linea che conteneva una longword, un bit di validazione, un diverso indirizzo associato, e veniva indirizzata tramite i bit A7-3 degli indirizzi), adesso ne sono presenti soltanto 16:
Ogni linea indirizza logicamente 4 longword “contigue” (cioè condividono gli stessi 28 bit alti dell’indirizzo, A31-4, e tramite A3-2 si seleziona ognuna delle 4 dalla linea), ma ogni longword viene trattata e utilizzata in maniera indipendente (poiché a essa è associato un apposito bit per marcarne il contenuto come valido o meno). Quindi abbiamo sostanzialmente 16 (macro) indirizzi di memoria “cachabili”.
In teoria si tratta di un peggioramento, perché in precedenza le 64 linee erano completamente indipendenti, poiché potevano contenere 64 indirizzi diversi. In realtà bisogna tener conto della “località” delle istruzioni e dei dati, che generalmente tendono a essere aggregati a indirizzi di memoria “vicini”, per cui c’è più probabilità di leggere codice e/o dati sulla stessa linea da 16 byte, che da 4 linee a indirizzi completamente diversi.
In ogni caso la precedente cache istruzioni era più flessibile, in quanto poteva tranquillamente mappare 4 longword sia a indirizzi contigui, quindi funzionando esattamente come l’attuale, che ad altri completamente diversi, risultando quindi più performante nel casi di codice poco “lineare / locale” (con frequenti salti a indirizzi diversi).
Il motivo di questa scelta da parte di Motorola è semplice: privilegiare i casi più comuni / frequenti, mettendo a disposizione una nuova modalità di accesso alla memoria denominata “burst“, che assieme all’altrettanto nuova modalità sincrona porta a ben tre diverse possibilità di connettersi con la memoria o le periferiche:
- asincrona (la stessa e l’unica disponibile col 68020), che richiede almeno 3 cicli di clock per il completamento dell’operazione, e consente di interfacciarsi con qualunque dispositivo in qualunque configurazione e dimensione delle “porte” (8, 16 o 32 bit), ma soprattutto con frequenza di clock diversa da quella impiegata dal processore
- sincrona, necessita di 2 cicli di clock e la dimensione della porta obbligatoriamente a 32 bit (quindi possono essere trasferite soltanto longword), con allineamento del dato allo stesso tipo (gli indirizzi devono essere multipli di 4 byte)
- burst, simile alla precedente, ma che consente di trasferire fino a 4 longword, impiegando 1 ciclo di clock per ogni longword successiva alla prima (in pratica per i primi due cicli la CPU esegue un accesso sincrono e alla fine del secondo ciclo, se il dispositivo è in grado di fornire un’altra longword, si prosegue sfruttando soltanto il prossimo ciclo; e così via)
Ovviamente nelle due nuove modalità è previsto l’inserimento di appositi cicli di wait per memorie o dispositivi più lenti, in modo da terminare l’operazione in maniera corretta (e soprattutto con dati consistenti).
Si capisce bene, a questo punto, il perché della nuova organizzazione delle cache: grazie al “burst mode” è possibile riempire molto velocemente un’intera linea di cache (4 longword, 16 byte) impiegando soltanto 5 cicli di clock (2 + 1 + 1 + 1), quando in precedenza il 68020, nelle medesime condizioni, ne richiedeva ben 12 (3 * 4).
A far lievitare il numero di transistor ha provveduto anche l’integrazione di una MMU per la paginazione della memoria. Per la precisione si tratta di una versione più economica e con meno funzionalità del 68851 (chip che in precedenza Motorola aveva realizzato per 68010 e 68020), ma con l’aggiunta di qualche utile meccanismo.
Queste le caratteristiche di targa:
- dimensione delle pagine variabile da 256 a 32K byte (per potenze di 2, ovviamente)
- fino a 4 livelli per l’albero di traduzione delle pagine e ogni livello è configurabile per tradurre da 0 (inutilizzato) a 15 bit (32K pagine) dell’indirizzo virtuale, con almeno un livello obbligatoriamente da utilizzare; per confronto, a partire dall’80386 gli x86 hanno messo a disposizione un modello fisso a 2 livelli (di 1024 pagine ognuno) e dimensione fissa delle pagine a 4KB (soltanto più tardi, con alcuni Pentium, è arrivata una modalità con un solo livello e pagine di 2 o 4MB)
- 2 master page table (una per la modalità utente, e una per quella supervisore) per la traduzione degli indirizzi (eventualmente se ne può utilizzare soltanto una condivisa da ambedue le modalità)
- possibilità di definire 2 aree di memoria (con un taglio minimo di 16MB) non soggette alla traduzione degli indirizzi (caratteristica assente nel 68851; utile per mappare aree di memoria che, ad esempio, non devono essere soggette a caching, senza per questo definire per ogni processo delle apposite pagine)
- 22 entry nell’Address Translation Cache (ATC; cache “fully associative” utilizzata per evitare di decodificare un indirizzo virtuale ogni volta, effettuando il caching degli ultimi indirizzi virtuali già tradotti)
Essendo on-chip, i tempi per la decodifica degli indirizzi di memoria sono drasticamente ridotti in quanto quest’operazione viene eseguita in parallelo all’accesso alle due cache e alla memoria esterna. Per essere più chiari, quando al 68030 serve un dato a un certo indirizzo, questo può trovarsi:
- nella cache istruzioni
- nella cache dati
- nella memoria esterna
per cui l’unità centrale si attiva su tutti e tre i fronti (per semplificare), e per quest’ultimo oltre a iniziare un’operazione di accesso col bus esterno attiva anche la ricerca nell’ATC per vedere se l’indirizzo virtuale risulta già tradotto. Alla fine del ciclo (perché tutte e tre le operazioni richiedono un solo ciclo, appunto) è già in grado di sapere come proseguire:
- se ha trovato il dato in una delle cache, abortisce l’accesso alla memoria
- se ha trovato l’indirizzo nell’ATC, prosegue con l’accesso alla memoria se l’indirizzo è valido, altrimenti abortisce l’operazione e solleva un’eccezione
- se non ha trovato l’indirizzo nell’ATC, abortisce l’accesso alla memoria e inizia un ciclo di operazioni per recuperare l’indirizzo fisico partendo dalla master page table, e alla fine se l’indirizzo fisico ottenuto è valido fa partire un nuovo accesso alla memoria (se non è valido, solleva un’eccezione)
Rispetto al 68851 mancano parecchie funzionalità e soltanto poche istruzioni del coprocessore possono essere utilizzate (PFLUSH, PLOAD, PMOVE, e PTEST), ma il modello offerto dal 68030 ritengo sia sufficiente flessibile, col notevole vantaggio dell’integrazione on-chip che permette di velocizzare le operazioni di traduzione quando l’MMU risulta attiva (col 68851 la CPU doveva comunque iniziare un ciclo di lettura, l’MMU doveva poi prelevare l’indirizzo dal bus, effettuare tutti i controlli, e soltanto dopo decidere se e come proseguire).
Contrariamente alle informazioni che si trovano in giro, e in particolare nell’apposita paginetta su Wikipedia, le innovazioni introdotte col 68030 hanno portato a un generale miglioramento delle prestazioni, in particolare grazie al veloce accesso alla memoria, alla presenza della cache dati (per non parlare dell’integrazione della MMU, quando il sistema operativo la utilizza), e a un più efficiente meccanismo di “overlapping” nell’esecuzione delle istruzioni (di cui abbiamo parlato nell’articolo sul 68020).
E’ sufficiente confrontare l’apposito capitolo relativo ai tempi di esecuzione delle istruzioni nei manuali dei rispettivi microprocessori per rendersi conto che, perfino nel caso peggiore, il 68030 offre prestazioni quasi sempre migliori, anche sensibilmente (in particolare per gli accessi alla memoria), rispetto al 68020.
Tra l’altro la stessa Wikipedia si smentisce perché riporta in questa pagina 4 MIPS per il 68020 a 20Mhz, e 11 per il 68030 a 33Mhz. A conti fatti, un ipotetico 68020 a 33Mhz arriverebbe a 6,6MIPS (supponendo un incremento lineare rispetto alla frequenza di clock), che è decisamente inferiore…
Con questa CPU rimangono delusi, invece, i programmatori, in quanto non risulta alcuna nuova istruzione o modalità d’indirizzamento, ma si registra, invece, una defezione (l’eliminazione delle istruzioni relative ai “moduli”, CALLM/RTM). Fatta eccezione ovviamente per l’MMU integrata, che però rimane generalmente appannaggio del sistema operativo e, quindi, inaccessibile alle normali applicazioni.
D’altra parte le migliorie apportate con questo processore sono motivo sufficiente di apprezzamento nei suoi riguardi. Non bisogna neppure dimenticare che un’ISA come quella del 68020 risultava già sufficientemente complicata e colma di istruzioni, e vedremo che, per questo motivo, coi successi modelli la mannaia di Motorola tornerà ad abbattersi eliminando un po’ di “zavorra”…
Mannaggia a IBM che fece quei cavolo di accordi con intel. Sarebbe stato bello avere tale architettura ai giorni d’oggi anzichè stare con gli x86
Articolo molto interessante come sempre.
Ottimo articolo, ho solo un appunto per quanto riguarda le prestazioni rispetto al 68020, ai tempi dell’Amiga ricordo di aver provato sia un 68020 a 28Mhz che un 68030 a 25Mhz, e le prestazioni dei due processori erano pressoché equivalenti.
Considerata la sola differenza di 3Mhz, al tempo supposi anch’io che la differenza in termini di prestazioni tra i due processori fosse minima.
Bisognerebbe vedere che tipo di test erano, se la cache dati era abilitata (per problemi con la chip ram, che non dev’essere cachebile, è possibile che non fosse attiva), se la memoria supportava il burst mode, e c’erano dei wait state a fare da collo di bottiglia.
Se non ricordo male il test era l’applicazione di un filtro ad un immagine con Personal Paint, però in effetti c’è da dire che alcune schede acceleratrici per A1200 non erano esattamente il top in fatto di prestazioni, è probabile che ci fossero dei wait state sulla memoria per una maggiore compatibilità con le SIMM di allora…
In tal caso i vantaggi del 68030 si riducono sensibilmente. Poi se la memoria non è predisposta per il 68020, dubito che riesca utilizzare la modalità sincrona (che sarebbe già un bel passo avanti rispetto a quella asincrona) e, peggio ancora, il burst mode.
Qua’ a fianco del mac c’e’ un A1200 con 68060.. :)
Adoro quell’architettura.
“A1200 con 68060”
Non dirlo ad alta voce che qualcuno potrebbe pensare di organizzare un furtarello attirato da tanto miele ;)
Doh.. non si tocca!!!!.. :) Ricordo che ai tempi avevo fatto dei test sviluppando lo stesso programma in assembly 68060 e x86 su pentium 120Mhz. Ebbene il 68060 a 50Mhz nei calcoli interi aveva le stesse prestazioni…le prendeva sui float ma rimeva comunque un mostro.
Io tutt’ora monto uno ‘030 su un Amiga 600 e riesco anche a navigare in rete :))
030@40 + FPU + MMU su un 1200 con IndivisionAGA.
Le prestazioni si notano piu’ dallo 020 allo 040…
Certamente. Il 68040 è stato un enorme passo in avanti per l’architettura 680×0 (d’altra parte ha il quadruplo dei transistor del 68030 :D).
Visto che gli Amiga tornano sempre nei commenti, sarebbe possibile avere un articoletto dedicato alle espansioni possibili di un 1200 ?
Ad esempio se è possibile mettere sulla stessa macchina schede acceleratrici, schede di rete, scandoubler, lettori cd, controller usb ed ancora, in modo da creare una dream machine ?
E poi, di respiro un po’ più ampio, non sarebbe bello cercare di mettere insieme una serie di speciali del tipo “realizziamo il nostro home computer”, spiegando passo per passo le fasi di progettazione di una macchina simil zx spectrum ?
Troppe volte quando si parla di computer ci si sofferma sulla cpu, la grafica ed il suono come se il tutto ruotasse intorno a tre integrati tre, poi si prende in mano una qualsiasi macchina e si finisce per domandarsi cosa ci fanno tutti gli altri, quale scopo hanno.
Per queste cose non ho competenze, per cui girerò i suggerimenti alla redazione.
In ogni caso penso che si tratti di argomenti molto interessanti e in linea con AD.
Se cerchi nei siti dedicati al retrocomputing, al di fuori dei mondi dorati tradizionali (commodore, sinclair e sistemi completi vari) trovi fior di schedozze che ai tempi venivano vendute in kit e che a grandi linee utilizzavano z80, chip grafici tms e varie altre cose. Se si trovassero le guide di questi sistemi, visto che ai tempi non era tabù parlare di cosa c’era dentro la scatola (con tanto di sorgenti), credo che ci sarebbero moltissimi spunti tecnici
Più che altro bisogna trovare un redattore che abbia le competenze necessarie. Ne stiamo parlando in staff.
In effetti anch’io onestamente non ricordo un grande salto di prestazioni dallo 020 allo 030, MMU e differenze di clock a parte naturalmente.
Altra “caratteristica”, lo 030 era estremamente più lento dello 020 ad accedere alla memoria a 16 bit (ad esempio della fast RAM su Zorro II) – anche qui vado a memoria e andrebbe verificato (forse imputabile all’unità di prefetch?)
BTW i pochi benchmark che si trovano in giro sostanzialmente danno ragione a ReDeX, i dati di wikipedia probabilmente si riferiscono ad un caso estremamente favorevole allo 030.
Dimenticavo:
http://lowendmac.com/benchmarks/speedo4.shtml
http://performance.netlib.org/performance/html/dhrystone.data.col0.html
Il prefetch c’è anche per il 68020, per le istruzioni.
Per i dati non c’è prefetch, ma semplicemente al primo accesso si attiva la cache, che però contiene almeno una longword, quindi a 32 bit. Credo che sia riconducibile a questo il problema: probabilmente per riempire la cache dati, il 68030 esegue due accessi alla fast ram a 16 bit, risultandone ovviamente penalizzato (anche perché non può sfruttare nemmeno la modalità sincrona per il trasferimento di dati).
Per quanto riguarda i benchmark, in giro si trovano informazioni abbastanza variegate, che vanno da valori simili per entrambi i processori, fino alle differenze marcate di cui parlavo. Credo che molto dipenda dall’architettura in cui viene inserito il 68030.
Ottimo articolo, come sempre del resto!
Anch’io sono portatore sano di 1200+060 e non lo mollo manco sotto tortura! ;)
Per quel che riguarda i bench 020 vs. 030, come al solito il riferimento assoluto sono le produzioni della scena demo. C’è un’intera generazione di demo specifiche per 030 che erano semplicemente impensabili sotto 020!
(Fatevi un giretto su http://ada.untergrund.net/)
“68030 esegue due accessi alla fast ram a 16 bit”
Eh si, potrebbe essere proprio questo il motivo. Appena avrò un po’ di tempo cercherò di approfondire.
Il problema sarebbe stato facilmente aggirabile sfruttando i registri di traduzione “trasparente” dell’MMU integrata nel 68030, in modo da marcare l’area “bassa” della memoria (dove risiedono chip ram e fast ram a 16 bit), come non cachabile e, quindi, evitando di attivare la politica di lettura dei due dati a 16 bit.
Purtroppo la fregatura è che questi registri definiscono aree di almeno 16MB, per cui l’accesso a ROM del KickStart, che negli Amiga 3000, 4000 e 1200 era a 32 bit, sarebbe stata fortemente penalizzato.
@jpx: grazie per il link. Appena avrò un po’ di tempo ci farò un giro. :)
Comunque non nascondo che vi invidio molto, non avendo mai posseduto schede acceleratrici per i miei Amiga 2000 e 1200. :(
Ho dato un’occhiata allo User Manual, e il problema sembra effettivamente quello: 2 cicli per il cache filling su bus a 16 bit, 4 cicli in caso di un dato non allineato.
Purtroppo la MMU non è mai stata un equipaggiamento standard su Amiga, preferendo le versioni low cost EC anche per lo 030. La soluzione che dici tu sarebbe stata sicuramente fattibile ed elegante, anche se forse sarebbe stato meglio sbarazzarsi completamente della vecchia RAM a 16 bit (si teneva solo in considerazione di quello che la si aveva pagato xD).
Con una MMU cmq è possibile anche rimappare anche il kickstart in RAM, avendone a disposizione!
Questo avrebbe comportato l’abilitazione dell’MMU però, e quindi si sarebbe dovuta creare una master page table, e avere anche dei miss nella cache dell’ATC.
Mentre coi registri di decodifica “trasparente” l’MMU poteva anche non essere abilitata.
Potendo abilitare l’MMU, il problema era facilmente risolvibile senza toccare nulla: sarebbe bastato mappare le pagine relative a chip ram, fast ram a 16 bit, e dispositivi di I/O come non cachabili (com’è giusto che fossero), lasciando tutto il resto (kickstart e fast ram a 32 bit) cachabile.
Purtroppo, come dici tu, l’MMU è stata merce rara negli Amiga. :(
Ragazzi, riguardo all’Amiga 1200 espanso permettetemi un paio di domande al limite dell’offtopic, ma l’articolo mi ha fatto ritornare “l’amighite” che mi colpisce con cadenza piu’ o meno regolare :)
– quale scheda mi consigliate con 68060?
– qual’e’ un prezzo onesto per quest’ultima (al momento ne trovo solo una su ebay a circa 450 euro, gulp!) e a cosa bisogna stare attenti? (che ne so, rigurdo al tipo di memoria per esempio)
– con una scheda di espansione con 68060, riesco a mettere pure un hard disk dentro al case del 1200?
ho trovato qualche risposta alle domande precedenti cercando un po’ su google ma mi piacerebbe una risposta di chi ha esperienza diretta a riguardo.
su questa domanda non ho trovato granche’ pero’:
– a che risoluzione lavorate normalmente e che monitor utilizzate? io avevo pensato di prendere un monitor che abbia anche un ingresso video visto che per utilizzare l’uscita RGB devo averne uno che accetta refresh orizzontali a 15kHz e non e’ facile trovarne… la qualita’ dell’immagine ne risentirebbe parecchio?
Io principalmente vorrei programmarci in assembly, quindi una buona visibilita’ del testo e’ essenziale.
Purtroppo il prezzo è veramente eccessivo, visto quello che offrono. Lo so che potrà sembrare una bestemmia, ma per programmare in asm 68K su Amiga io userei UAE.
“MMU è stata merce rara negli Amiga. :(”
Sarebbe possibile fare un elenco di errori tecnici che in qualche modo hanno tagliato le gambe all’evoluzione degli amiga considerando i vari tipi di mercato ?
Io metterei tra i primi posti il fatto che il sistema all’avvio poteva bootare direttamente i floppy dei giochi invece di richiedere per prima obbligatoriamente il WB, trasmettendo così l’idea che l’amiga era una console per giocare.
Lo faremo nella serie di articoli previsti che dovrebbero coprire parecchio del mondo Amiga.
Comunque il boot da floppy non era un problema: è stato lo strumento comune a diverse piattaforme per far partire il s.o..
Nel caso dei giochi, la maggior parte provvedevano a uccidere il s.o. e impadronirsi di tutte le risorse del sistema. Ma non era la norma né era obbligatorio: una piccola parte dei giochi funzionavano tranquillamente da AmigaOS. Altri addirittura caricavano il Workbench e dovevi fare il classico doppio click sull’icona per farli partire.
@Marco: con tristezza, concordo.
“la maggior parte provvedevano a uccidere il s.o.”
Non si servivano neanche del kickstart ? Perchè se gli fosse servito, a commodore sarebbe bastato inserire una specie di firma digitale che avrebbe sistematicamente impedito di fare qualcosa al di fuori del so stesso.
Il fatto che i giochi potevano prendersi queste libertà castrava anche l’evoluzione tecnologica del sistema in generale perchè commodore non avrebbe potuto creare una specie di ciclo di aggiornamenti forzati come invece succede adesso. Spesso riguardo all’amiga 1200 ho letto commenti del tipo “che te ne facevi dell’aga se il tutto veniva livellato sul ocs ?”.
Da una parte non era brutta la politica di lasciar scegliere alla gente se proprio aveva bisogno di un upgrade o meno, ma dall’altra non ha portato molto bene. Chi vedeva nell’amiga solo una console non sentiva il bisogno di cambiare il 500 con il 1200, il grosso della base installata non si spostava verso l’alto (tranne particolari gruppi di professionisti) ed alla lunga era logico che il confronto con la piattaforma pc si sarebbe concluso con la sconfitta di questo mondo.
450 euro per una 060 non li caccerei.. Con 600 ti compri una scheda A1 con PPC e AmigaOS4.
@D: no, non serviva nemmeno il kickstart. Nei miei giochi il s.o. era la prima cosa che provvedevo a eliminare per impadronirmi di tutte le risorse, in primis la memoria fino all’ultimo byte.
Di firma digitale all’epoca nemmeno si parlava. I s.o. “consumer” non era assolutamente concepiti sistemi del genere.
Anche così l’evoluzione tecnologica ci sarebbe stata. Il problema, però, era che i programmatori hanno usato i trucchi più sporchi di questo mondo. Basti vedere alla moria di titoli che non funzionavano più già soltanto passando da un classico Amiga 500 o 2000 con 512KB di chip ram e altrettanti di “slow mem”, a uno che aveva 1MB di chip ram e basta.
Nonostante tutto, i giochi per AGA ci sono stati, ed erano apprezzabili. Non ci sono stati quelli per ECS, come ho spiegato nell’apposito articolo.
@Warfox: concordo.
Praticamente da una parte l’obbligo dell’uso del so e quindi delle sue api avrebbe dovuto garantire la compatibilità nel tempo mentre dall’altra tutti se ne strafregavano perchè non c’erano risorse da buttare. Bel dilemma…
Mettiti nei panni dei programmatori di allora, che dovevano tirare fuori qualcosa da una macchina con 7Mhz e 1MB di ram, e vedrai che anche tu l’avresti pensata allo stesso modo. ;)
Che poi ti assicuro che realizzare codice che girava su tutte le macchine era possibile, attenendosi rigorosamente alle linee guida delle Commodore.
Io, ad esempio, ho usato pesantemente anche codice automodificante, ma avevo l’accortezza di chiedere gentilmente al s.o. di disabilitare le cache della CPU prima di ammazzarlo. :D
“7Mhz e 1MB di ram”
Si ma che ingordi sti programmatori. Fino a pochi anni prima dovevano accontentarsi di un 8bit meno di un mhz con 64Kb di ram e ancora non erano contenti :P
In ogni caso è evidente che qualcosa è stato sbagliato se le cose sono finite così
Altrettanto ingordi erano gli utenti, che pretendevano sempre più: grafica spettacolare e sonoro da favola. :D
mi ricordo quando in tempi lontani con un amiga 3000 e un modem ridicolo per gli standard odierni sviluppavo su amix codice c che compilavamo sul server aziendale … quelli si che erano tempi in cui i computer sembravano mostri (ed erano davvero macchine per pochi)…
se ripenso che ho venduto quella macchina mi piange il cuore.. allora quei computer ti davano davvero un vantaggio
Grazie per i consigli, ho deciso per una scheda molto piu’ economica con 68030.
Iva: con quella cifra prendi un notebook-netbook sul quale far girare winuae, con prestazioni velocistiche ben superiori, e il vantaggio di avere una macchina moderna da poter utilizzare anche per altri scopi al bisogno.
Forse non era chiaro ma il setup sul netbook e sul desktop li ho gia’.
Una volta che hai programmato qualcosa sul tuo emulatore devi provare come/se va veramente sulla macchina originale, no?
Comunque principalmente e’ una questione “sentimentale”, avere sotto le dita un’Amiga in carne ed ossa e’ tutta un’altra cosa!
ps la scheda con 68030 a 40/50MHz e 64MB di ram (e a volte 68882) si trovano sui 150/180 euro
Se vuoi solo programmare in asm, ti basta e avanza un A500 o un A1200 liscio ;)