Confronto fra i486 e Motorola 68000

[fek]

Dalle News:
http://www.hwupgrade.it/forum/showthread.php?t=948317&page=5

Il processore in questione e' si un 32bit ma con un bus esterno a 16 bit ed un data bus a 24. almeno cosi' era in TUTTI i computer che lo usavano al tempo.
Che poi sia piu' flessibile dun un x86 e possa diventare un 32 full non vuol dire che lo fosse..
Il fatto che il 486 permettesse di eseguire le istruzioni in un solo ciclo di clk lo sanno piu' o meno tutti.. bisogna poi vedere la potenza di esse e l'efficacia.

http://www.cpu-world.com/CPUs/68000/

Per quanto riguarda tutto il resto non mi pare il caso di discutere riguardo le istruzioni e l'efficienza di esse (inquanto ho parlato anche di architetture), il punto sta nel fatto che i programmi li giravano molto piu' rapidamente.
Il cubase dava i numeri, non azzeccava una nota nemmeno su un 1000mhz!! tutt'oggi un un porcessore come il mio (un 64bit a 2,7ghz) ha degli scompensi quando si verivica un accesso "eccessivo" alle periferiche ide o quando si legge un floppy (per non parlare di quando e' rovinato!!).
Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP, poteva semplicemente accelerare i calcoli relativi alle elaborazioni audio. La parte midi era portata direttamente dal "vecchio" cubase per ST e nulla c'entrava con il DSP.

Il primo masterizzatore che comprammo fu uno 0,5X e montato su un "portentoso" 486 mi bruciava un disco ogni 2 e quando muovevi il mouse (anche con masterizzatori migliori usciti molto dopo) falliva all'istante. (ovviamente non parlo di masterizzatori moderni in grado di sospendere la masterizzazione). Al mio falcon che monta un "misero" 68030, ho attaccato un mast 4x (perche' quresto ho trovato scsi) e non mi ha mai sbagliato un disco, mentre faccio tutto cio' che voglio.
Con tutto che non ho mai portato simpatia eccessiva per l'architettura amiga (da te citata), ti invito ad immaginarti un'evoluzione tecnologica a queste frequenze di quella macchina (ed una conseguente evoluzione della famiglia 68k).. poi dimmi se sencondo te, avrebbe bisogno di una scheda video separata per far girare un giocho 3d decentemente..
In ogni caso non riesco a vedere come tu possa volermi paragonare un 68000 con un 486 uscito anni ed anni dopo.. paragoniamo le architetture o meglio i risultati. Se proprio vogliamo, paragoniamolo ad un 68060, gia' mi sembra piu' equo.

In fine direi che se un moderatore debba dire qualcosa a qualcuno, lo debba fare a te, vista la tua correzione "deltutto personale" punto punto. Per quanto mi riguarda la discussione finisce qui.

[MadRat]

Grazie per l'apertura.. ma non e' mai stato un confronto tra un 68000 ed nu 486.. ma tra architetture.. una vecchia 25 anni piu' dell'latra..
Comuqnue rimanesse convinto delle proprie idee, poco mi cambia.
Io sostenevo solamente che l'architetura dei "pc compatibili, x86" sia solo un limite prestazionale (da qui il semplice esempio portato da me dei computer basati su 68000) del quale non soffriranno le nuove console e dunque a parita' di gpu/cpu saranno considerevolmente piu' potenti di questi cassoni vincolati a concetti di 50 e passa anni fa.

Per chi volesse sapere di che si stia parlando..
http://www.hwupgrade.it/forum/showthread.php?p=8599237#post8599237

[cdimauro]

Il processore in questione e' si un 32bit ma con un bus esterno a 16 bit ed un data bus a 24. almeno cosi' era in TUTTI i computer che lo usavano al tempo.
Se parli del 68000, sì, e tra l'altro l'avevo già scritto nel mio messaggio.

Il 68008, che internamente aveva la stessa architettura, era però più limitato, perché aveva 20 bit per il bus indirizzi e 8 bit per quello dei dati: secondo il tuo criterio avrei dovuto definirlo come processore a 8 bit? Oppure a 8 / 32 bit?
Che poi sia piu' flessibile dun un x86 e possa diventare un 32 full non vuol dire che lo fosse..
"Full 32 bit": ti ho già chiesto in base a quale criterio (oggettivo) classifichi un processore come "full x bit" o "non full x bit".

Quanto alla flessibilità, non so a cosa ti riferisci: dovresti essere più chiaro.
Il fatto che il 486 permettesse di eseguire le istruzioni in un solo ciclo di clk lo sanno piu' o meno tutti.. bisogna poi vedere la potenza di esse e l'efficacia.
Ti ricordo che tu hai confrontato un 68000 a 8 Mhz con un 486 a 66Mhz.
Ti ho fatto notare che un 68000, per eseguire una NOP (che è un'istruzione che non fa nulla), impiega ben 4 cicli di clock.
Ti ho fatto notare che un 486 esegue la maggior parte delle istruzioni (quindi anche ben più complicate di una NOP) in un solo ciclo di clock.
Questo avrebbe dovuto farti dedurre che la disparità fra la "potenza di calcolo / efficacia" (qualunque cosa tu intendi con questi termini) è MOSTRUOSAMENTE a favore di quest'ultimo.

Hai mai visto girare la prima versione di UAE (l'emulatore Amiga più conosciuto / diffuso / preciso / usabile) su un 486 (a 50Mhz)? Se lo ritieni così inefficiente / poco potente, mi spieghi come faceva ad emulare un 68000 a 7,09Mhz, con tanto di chip custom, discretamente?

Ovviamente l'emulazione dei chip custom era primordiale, ma in questo contesto m'interessa puntualizzare la capacità del 486 di emulare il 68000: in base a quanto hai scritto, come potrebbe un 486 emulare un processore che tu hai definito come "suo pari", un 68000 a 8Mhz?
http://www.cpu-world.com/CPUs/68000/
Questo perché l'hai postato? A me non serviva e non vedo cosa c'entri col resto del discorso.
Per quanto riguarda tutto il resto non mi pare il caso di discutere riguardo le istruzioni e l'efficienza di esse (inquanto ho parlato anche di architetture),
Anch'io ho parlato di architetture, e le ho messe in relazione in base a quel che erano in grado di fare (tipo di operazioni) e a come lo facevano (tempo di esecuzione), per dimostrare che il tuo confronto non era (e non è) assolutamente realistico.
il punto sta nel fatto che i programmi li giravano molto piu' rapidamente.
Ti ho già scritto che bisogna vedere in che modo sono stati realizzati i programmi / conversioni: non puoi giudicare soltanto in base all'apparenza.
Il cubase dava i numeri, non azzeccava una nota nemmeno su un 1000mhz!! tutt'oggi un un porcessore come il mio (un 64bit a 2,7ghz) ha degli scompensi quando si verivica un accesso "eccessivo" alle periferiche ide o quando si legge un floppy (per non parlare di quando e' rovinato!!).
Idem come sopra: non puoi effettuare dei confronti senza avere in mano dati chiari su come sono stati realizzati i programmi per le due architetture.

Esempio: Halo è un gioco per X-Box e per PC, ma è stato scritto e funziona in maniera diversa. Non hanno preso il programma così com'era, e semplicemente ricompilato (e anche qui bisognerebbe vedere come, ma tralascio questo dettaglio perché complicherebbe ulteriormente il discorso).
Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP,
Sono informato, ed è perfettamente in grado di farlo. Puoi dirmi che non è ciò per cui è stato pensato e realizzato, ma questo è UN ALTRO DISCORSO.
poteva semplicemente accelerare i calcoli relativi alle elaborazioni audio.
Vedi sopra: questo è il motivo per cui è stato integrato nel Falcon, ma non vuol dire che non lo si possa usare anche per altro (anche nel campo dell'elaborazione grafica avrebbe delle buone prestazioni).
La parte midi era portata direttamente dal "vecchio" cubase per ST e nulla c'entrava con il DSP.
Atari ST e Falcon hanno la stessa interfaccia MIDI, che altri non è se non una seriale che "viaggia" a circa 31000 baud: gestire una seriale a velocità così basse è capace di farlo anche il 6502 a 1Mhz del Vic20.

Il problema, come ti ho già detto, è che bisogna vedere IN CHE MODO è stato realizzato il programma che la usa.
Il primo masterizzatore che comprammo fu uno 0,5X e montato su un "portentoso" 486 mi bruciava un disco ogni 2 e quando muovevi il mouse (anche con masterizzatori migliori usciti molto dopo) falliva all'istante. (ovviamente non parlo di masterizzatori moderni in grado di sospendere la masterizzazione). Al mio falcon che monta un "misero" 68030, ho attaccato un mast 4x (perche' quresto ho trovato scsi) e non mi ha mai sbagliato un disco, mentre faccio tutto cio' che voglio.
Stai mischiando capra e cavoli: parli di sistemi completamente diversi, che usano programmi completamente diversi.
Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD. Chissà perché...
Con tutto che non ho mai portato simpatia eccessiva per l'architettura amiga (da te citata),
La mia, ai tempi, era più che una simpatia. D'altra parte un Amiga permetteva di emulare tranquillamente anche un Mac o un Atari ST, ma il viceversa non è mai stato possibile...
ti invito ad immaginarti un'evoluzione tecnologica a queste frequenze di quella macchina (ed una conseguente evoluzione della famiglia 68k)..
Sono anni che ci penso, e penso che Motorola abbia avuto le sue buone ragioni per abbandonare quest'architettura. Anche se era molto "bella" (ti parlo come programmatore assembly), a livello di implementazione era estremamente complicata.

Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Anche ipotizzando l'adozione di un "core RISC", come oggi avviene per la famiglia x86 (e i PowerPC di IBM), il lavoro sarebbe enorme. Per l'esempio di cui sopra, sarebbero necessarie almeno 5 microistruzioni per portare a termine l'operazione (una "semplice" MOVE), e i due accessi in memoria metterebbero sotto stress sia le cache dati sia la cache TLB.

Poi non parliamo nemmeno del decoder delle istruzioni, che risulterebbe MOSTRUOSAMENTE più complicato, rispetto a quello degli x86.

Quindi, in definitiva e per rispondere a quanto chiedevi, mi sembra alquanto difficile già soltanto pensare di implementare un'architettura come quella dei 68000 "secondo i canoni attuali", e sicuramente sarebbe impossibile raggiungere frequenze di lavoro comparabili, a parità di tecnologia produttiva utilizzata.
poi dimmi se sencondo te, avrebbe bisogno di una scheda video separata per far girare un giocho 3d decentemente..
Anche questo è un altro discorso, e non c'entra niente col confronto che hai tirato in ballo.
In ogni caso non riesco a vedere come tu possa volermi paragonare un 68000 con un 486 uscito anni ed anni dopo..
Ti ricordo che il paragone l'hai fatto tu: io non me lo sarei mai sognato.
paragoniamo le architetture o meglio i risultati.
Le architetture le possiamo anche paragonare, ma non ne salterebbe nulla di utile (che te ne fai?)

Per i risultati, bisognerebbe prima decidere il tipo di applicazioni da usare, e poi, simulatori alla mano (a meno che tu non abbia a disposizione i processori oggetto del confronto), verificare quanti cicli di clock sono necessari per portare a termine un ben preciso lavoro.
Se proprio vogliamo, paragoniamolo ad un 68060, gia' mi sembra piu' equo.
E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486... ;)
In fine direi che se un moderatore debba dire qualcosa a qualcuno, lo debba fare a te, vista la tua correzione "deltutto personale" punto punto.
Non potevi capire: è un discorso che è stato affrontato in un altro thread.
Per quanto mi riguarda la discussione finisce qui.
Se volevi che finisse, ti sarebbe bastata una riga per farlo, non un romanzo in cui rispondevi a quanto ho scritto. Comodo uscirtene fuori così, sottraendoti al confronto dopo aver detto la tua.

[cdimauro]

Grazie per l'apertura.. ma non e' mai stato un confronto tra un 68000 ed nu 486.. ma tra architetture.. una vecchia 25 anni piu' dell'latra..
Questo:

(un motorola 68000 a 16 bit a 8mhz ha il potenziale di un 486 a 32bit a 66mhz),

l'hai scritto tu, o sbaglio?
Comuqnue rimanesse convinto delle proprie idee, poco mi cambia.
Io sostenevo solamente che l'architetura dei "pc compatibili, x86" sia solo un limite prestazionale (da qui il semplice esempio portato da me dei computer basati su 68000) del quale non soffriranno le nuove console e dunque a parita' di gpu/cpu saranno considerevolmente piu' potenti di questi cassoni vincolati a concetti di 50 e passa anni fa.
E ti ho risposto che non sono d'accordo, argomentando.

Puoi anche rimanere con le tue idee, e non ci sarebbe alcun problema, ma se lo fai pubblicamente devi anche sostenerle con qualcosa di più delle tue opinioni personali.

[MadRat]

Se parli del 68000, sì, e tra l'altro l'avevo già scritto nel mio messaggio.
Il 68008, che internamente aveva la stessa architettura, era però più limitato, perché aveva 20 bit per il bus indirizzi e 8 bit per quello dei dati: secondo il tuo criterio avrei dovuto definirlo come processore a 8 bit? Oppure a 8 / 32 bit?
Quanto alla flessibilità, non so a cosa ti riferisci: dovresti essere più chiaro.

The 68000 architecture was much more flexible than other CPU familes (z80, 80x86, z80000, etc) as it could be very easily expanded to support full 32-bit data and address.
Questo viene dal link che non cpisci perche' io abbia postato..


"Full 32 bit": ti ho già chiesto in base a quale criterio (oggettivo) classifichi un processore come "full x bit" o "non full x bit".
In base alle non restrizioni dei bus a bittaggi inferiori-



Ti ricordo che tu hai confrontato un 68000 a 8 Mhz con un 486 a 66Mhz.

Hai mai visto girare la prima versione di UAE (l'emulatore Amiga più conosciuto / diffuso / preciso / usabile) su un 486 (a 50Mhz)? Se lo ritieni così inefficiente / poco potente, mi spieghi come faceva ad emulare un 68000 a 7,09Mhz, con tanto di chip custom, discretamente?

Ovviamente l'emulazione dei chip custom era primordiale, ma in questo contesto m'interessa puntualizzare la capacità del 486 di emulare il 68000: in base a quanto hai scritto, come potrebbe un 486 emulare un processore che tu hai definito come "suo pari", un 68000 a 8Mhz?"

Secondo me si dovrebbe far distinzione tra "emulare" ed "imitare", un 486 fa girare molto male l'emulatore amiga e per emulare un 68000 ha bisogno di frequenze spropositatamente superiori.
Se prendi un normalissimo 520st, e' in grado di far girare il 30% piu' velocemente (con lo spectre) un mac di pari frequrenza.
In oltre l'emulatore ST dell'amiga era pietoso, girava al 10% delle possibilita' di un vero st, era inusabile, poi, come provavi a lanciare un software entrava nella crisi piu' totale. Era si e no in grado di emulare il descktop con lentezza esasperante, assolutamente non in grado di eseguire tutte le operazioni assegnate al dma, un st poteva formattare un floppy in backgrund senza rallentare il computer in alcuna maniera e se cubase si impallava e tornava al desk, la song continuava a suonare senza sbagliare un 64esimo nemmeno durante la fase di crash.
Dunque mi sembra assurdo parlare d'emulatore st su amiga. (lo ho ed ho ancora diversi amiga assieme al loro software ed una bella collezione di retrocomputing a partire dal vectrex passando per l'archimedes e finendo al giorno d'oggi..) Tenendo presente che anche gli emulatori attuali non sono in grado di visualizzare ad esempio le demo che rappresentino raster in overscreen, riducendoli nei colori pesantemente. Non sono nemmeno in grado di far girare in cubase con la precisione dell'originale.


Anch'io ho parlato di architetture, e le ho messe in relazione in base a quel che erano in grado di fare (tipo di operazioni) e a come lo facevano (tempo di esecuzione), per dimostrare che il tuo confronto non era (e non è) assolutamente realistico.

Ti ho già scritto che bisogna vedere in che modo sono stati realizzati i programmi / conversioni: non puoi giudicare soltanto in base all'apparenza.

Idem come sopra: non puoi effettuare dei confronti senza avere in mano dati chiari su come sono stati realizzati i programmi per le due architetture.

Bene, secondo questo tuo assunto, tutti i difetti sono riconducibili alla mala programmazione e pessimi porting.. sempre che di porting si tratti..
All'atto pratico TUTTI i software presenti su entrambe le piattaforme giravano meglio (infinitamente meglio a parita di cpu, frequenze e memoria impiegata) su sistemi 68000 based.
Sara' stata tuta incompetenza dei programmatori.. mah!!


Esempio: Halo è un gioco per X-Box e per PC, ma è stato scritto e funziona in maniera diversa. Non hanno preso il programma così com'era, e semplicemente ricompilato (e anche qui bisognerebbe vedere come, ma tralascio questo dettaglio perché complicherebbe ulteriormente il discorso).


Riguardo Halo non sono informato, ma mi parrebbe strano leggere di queste grandi differenze, vista la similarita' (identicita', piu' che altro) delle piattaforme in questione. Se hai qualcosa postalo.


Sono informato, ed è perfettamente in grado di farlo. Puoi dirmi che non è ciò per cui è stato pensato e realizzato, ma questo è UN ALTRO DISCORSO.

Vedi sopra: questo è il motivo per cui è stato integrato nel Falcon, ma non vuol dire che non lo si possa usare anche per altro (anche nel campo dell'elaborazione grafica avrebbe delle buone prestazioni).


Non mi risulta che il DSP 56001 sia quest'asso nelle istruzioni "General Purpose"
;) (ci rifacciamo al discorso degli pseudo-dsp del cell). Che poi possa essere usato per la gestione grafica anziché audio o quant'altro risulta ovvio.. accade anche oggi con alcuni software per pc che sfrutano le schede 3d per elaborare l'audio.
Cio' non toglie che la gestione di 160 ch midi (tramite un'interfaccia PASSIVA esterna e porta lan (di derivazione mac) in aggiunta a quelle di serie), non comporti minimamente l'utilizzo del dsp. Un 486 non e' assolutamente in grado di gestire 16ch midi con precisione. Molti miei amici musicisti fino al 2ghz e passa si sono disperati per questo motivo. E' anche il motivo per il quale alla fine io non ho ancora cambiato, anche se prima o poi accadra'. Tutt'oggi un pc per avere una vera prestazione midi/hdr, necessita di una costosa scheda dedicata. Ma tanto tu sostieni che si tratti di malaprogrammazione.



Atari ST e Falcon hanno la stessa interfaccia MIDI, che altri non è se non una seriale che "viaggia" a circa 31000 baud: gestire una seriale a velocità così basse è capace di farlo anche il 6502 a 1Mhz del Vic20.

Come no.. si e' visto.. puo' farlo un vic venti ma non un 486.. nemmeno un athlon 1000..
Forse non si tratta solo di trasferire dati.. che ne dici??


Il problema, come ti ho già detto, è che bisogna vedere IN CHE MODO è stato realizzato il programma che la usa.


E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)


Stai mischiando capra e cavoli: parli di sistemi completamente diversi, che usano programmi completamente diversi.
Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD. Chissà perché...


Ma tu vivi nel mio studio?? Il primo masterizzatore comprato tantissimi anni fa era SOLO scsi e costava circa 13milioni di lire e mi sprecava CD del valore di 90mila.


La mia, ai tempi, era più che una simpatia. D'altra parte un Amiga permetteva di emulare tranquillamente anche un Mac o un Atari ST, ma il viceversa non è mai stato possibile...

A questo ho risposto ampiamente sopra. Poi se vuoi ti racocnto bene come nacquero l'amiga e l'ST.


Sono anni che ci penso, e penso che Motorola abbia avuto le sue buone ragioni per abbandonare quest'architettura. Anche se era molto "bella" (ti parlo come programmatore assembly), a livello di implementazione era estremamente complicata.


La motorola lo abbandonò perche' schiacciata dal mercato. Le schede a 256 colori a basso costo di produzione orientale fecero diffondere il pc in modo assurdo e rapido. Se ci fosse stata una pari evoluzione degli altri due sistemi, ora saremmo decisamente su un altro piano.
Il 680x0 aveva solo il limite di essere cisc, specialemnte nelle ultime versioni, possedeva potenza da vendere (060), ma un risc era sicuramente piu' efficace. (specialmente in ambito di malaprogrammazioneo o programmazione "facile"..)


Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.


Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.


Anche ipotizzando l'adozione di un "core RISC", come oggi avviene per la famiglia x86 (e i PowerPC di IBM), il lavoro sarebbe enorme. Per l'esempio di cui sopra, sarebbero necessarie almeno 5 microistruzioni per portare a termine l'operazione (una "semplice" MOVE), e i due accessi in memoria metterebbero sotto stress sia le cache dati sia la cache TLB.


A me il 680x0 piace perche' non e' risc.
anche se oggi non ha senso parlare di risc e cisc, i processori sono cosi' complessi da non poter essere piu' distinti in questo modo. Piu' che altro si adattano nell'evoluzione al tipo di istruzioni piu' richiesto.


Poi non parliamo nemmeno del decoder delle istruzioni, che risulterebbe MOSTRUOSAMENTE più complicato, rispetto a quello degli x86.


Come sopra, a te piacicono le cose semplici, ma non e' una regola applicabile a tutti.


Quindi, in definitiva e per rispondere a quanto chiedevi, mi sembra alquanto difficile già soltanto pensare di implementare un'architettura come quella dei 68000 "secondo i canoni attuali", e sicuramente sarebbe impossibile raggiungere frequenze di lavoro comparabili, a parità di tecnologia produttiva utilizzata.


Sarebbe possibilissimo iplementare le attuali tecnologie ad un'altra architettura.
Il discorso e' molto piu' complesso,in primis perche' oggi si richiede comuqnue un aggiornamento (politica del consumismo) continuo, che con certe architetture risulta piu' ostico (ma meno necessario).
C'e' da considerare anche che la tecnologia attuale e' cresciuta con i pc compatibili e dunque su misura per loro. Qualora fosse stata sviluppata su altre piattaforme, avrebbe sicuramente preso altre direzioni (quelle piu' opportune alle altre piattaforme, appunto). Sicuramente non ci sarebbe stata questa folle rincorsa alle frequenze, dalla quale per fortuna, AMD si sta (solo in parte) dissociando.


Anche questo è un altro discorso, e non c'entra niente col confronto che hai tirato in ballo.

C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.


Le architetture le possiamo anche paragonare, ma non ne salterebbe nulla di utile (che te ne fai?)

Ne abbiam gia' parlato


Per i risultati, bisognerebbe prima decidere il tipo di applicazioni da usare, e poi, simulatori alla mano (a meno che tu non abbia a disposizione i processori oggetto del confronto), verificare quanti cicli di clock sono necessari per portare a termine un ben preciso lavoro.


Forse non hai mai usato tutte le istruzioni di un 680x0, non essendo risc richiede una programmazione piu' complessa e "fantasiosa", ma queste cose le sai.


E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486... ;)


No, non e' uno scherzo, dovremmo vedere le date di produzione, comunque regge il paragone con un pentim senza problemi.. direi.


Non potevi capire: è un discorso che è stato affrontato in un altro thread.


Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.
Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.
Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno ;) )


Se volevi che finisse, ti sarebbe bastata una riga per farlo, non un romanzo in cui rispondevi a quanto ho scritto. Comodo uscirtene fuori così, sottraendoti al confronto dopo aver detto la tua.

Non ero d'accordo ed esistendo il diritto di replica (me lo concedi no??) deve finire chi ha parlato per secondo. Almeno cosi' si fa in democrazia.

Per quanto riguarda l'altro post, direi che le mie convinzioni riguardo l'indecenza dell'architettura di questi cassoni sia palesata ed anche la convinzione (mia e non solo mia) che le potenzialita' di macchine basate su 68000 siano maggiori di quelle basate su x86, sia altrettanto palesata.
Convengo con te riguardo la difficolta' di programmazine, che oggi come oggi sarebbe un gran limite, vista la frenesia del mercato, ma questo e' un altro discorso ancora.

Insomma, per ora il mio falcon non mi sbaglia una nota di un 128esimo, un pc senza schede costosissime fa slittare note di 16esimi anche solo se si legge un cd e scrive una cache su hd.

[fek]

E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)

Ma questo e' semplicemente falso, basta sapere come e' fatto un PC all'interno. E' una totale evoluzione di quell'architettura, che ormai non condivide piu' nulla se non il fatto di avere una CPU e della memoria.

E' come dire che una Ferrari e' un grosso accrocco costruito con molte toppe perche' deriva dalle carrozze a cavallo e condivide con loro quattro ruote.

Mi citi una limitazione dell'architettura del PC di oggi dovuta ai PC ad 8bit e 640kb?


Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.
Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.
Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno )

I PC di oggi non sono compatibili con quelli di ieri infatti. E' possibile far girare alcune applicazioni in emulazione, ma questo non li rende compatibili piu' di quanto un PC sia compatibile con una Amiga perche' e' in grado di emularlo.


C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.

Lo credo bene, e' un'architettura general purpose. Tu hai citato il Cell come processore in grado di strapazzare le CPU Intel/AMD, ma hai ignorato il fatto che il Cell entra in crisi proprio in applicazioni general purpose, mentre e' molto veloce in applicazioni di calcolo su stream di vettori, che rappresentano una stretta minoranza delle applicazioni di computing.


Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.

Ma guidare una macchina non e' progettare software o hardware: in questo campo vince la semplicita'. Essere "complicato" da usare ma piu' veloce se usato bene e' uno svantaggio, non un vantaggio.

[MadRat]

Ma questo e' semplicemente falso, basta sapere come e' fatto un PC all'interno. E' una totale evoluzione di quell'architettura, che ormai non condivide piu' nulla se non il fatto di avere una CPU e della memoria.

E' come dire che una Ferrari e' un grosso accrocco costruito con molte toppe perche' deriva dalle carrozze a cavallo e condivide con loro quattro ruote.


No, assolutamente. E come dire che se oggi si proggettasse una macchina da zero, verrebbe reinventato il motore endotermico. Sicuramente si creerebbe un mezzo esponenzialmente piu' efficace, silenzioso, non inquinante e sicuro.

Fermo restando che una TVR con banalissimo motore a scoppio va a 388kmh e poco ha a che vedere con una topolino.. Una Ferrari (preferisco Lambo ;) ) sara' un ottimo prodotto, altamente prestante, ma sempre uno sfregio alla tecnologia attuale resta. Cosi' come lo sono questi pc.



Mi citi una limitazione dell'architettura del PC di oggi dovuta ai PC ad 8bit e 640kb?
I PC di oggi non sono compatibili con quelli di ieri infatti. E' possibile far girare alcune applicazioni in emulazione, ma questo non li rende compatibili piu' di quanto un PC sia compatibile con una Amiga perche' e' in grado di emularlo.


Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..


Lo credo bene, e' un'architettura general purpose. Tu hai citato il Cell come processore in grado di strapazzare le CPU Intel/AMD, ma hai ignorato il fatto che il Cell entra in crisi proprio in applicazioni general purpose, mentre e' molto veloce in applicazioni di calcolo su stream di vettori, che rappresentano una stretta minoranza delle applicazioni di computing.


Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te.. Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.
Poi puo' pure essere finto quel demo, ma credo in quel progetto.


Ma guidare una macchina non e' progettare software o hardware: in questo campo vince la semplicita'. Essere "complicato" da usare ma piu' veloce se usato bene e' uno svantaggio, non un vantaggio.

Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.

[homero]

scusate il motorola 68000 e' un progetto dei primi anni 80 montato su personal computer MAC, AMIGA, ATARI dal 1984 in poi....
di fatto era una versione base di una famiglia di processori che vedeva il punto di riferimento nel 68020+68881+MMU(adesso non ricordo la cifra che indica questo chip).
laprima era ULA+INTEGER 32bit/32bit la seconda era un FLOATING POINT UNIT e la aterza e' lA memory menagement unit.
il 486 non e' il processore piu' adatto al confronto.
piuttosto lo e' il 386+387 intel.
questo e' tutto.
appartiene alla storia....niente di piu'
ne esistono decine di emulatori che permettono di testarne le qualità dalpunto di vista della programmazione, molto facile da programmare in assembler...

[MadRat]

scusate il motorola 68000 e' un progetto dei primi anni 80 montato su personal computer MAC, AMIGA, ATARI dal 1984 in poi....
di fatto era una versione base di una famiglia di processori che vedeva il punto di riferimento nel 68020+68881+MMU(adesso non ricordo la cifra che indica questo chip).
laprima era ULA+INTEGER 32bit/32bit la seconda era un FLOATING POINT UNIT e la aterza e' lA memory menagement unit.
il 486 non e' il processore piu' adatto al confronto.
piuttosto lo e' il 386+387 intel.
questo e' tutto.
appartiene alla storia....niente di piu'
ne esistono decine di emulatori che permettono di testarne le qualità dalpunto di vista della programmazione, molto facile da programmare in assembler...

Beh, sicuramente sarebbe piu' appropriato, ma sarebbe ancor piu' logico il paragone tra il 68020 (e non il 68000) con il 386, meglio ancora sarebbe il 68030. Anche se differiscono troppo per date d'uscita ed architetture, per trovare un paragone corretto.

In ogni caso e' iniziato tutto (questo discorso) sostenendo non tanto la potenza su carta delle cpu, ma l'efficacia in azione dei sistemi basati su architetture x86, che io, tutt'oggi, trovo ridicola, vista anche la tecnologia che esse implementano allo stato attuale..
Per renderti conto di cio' che dico ti basta prendere una suonblaster economica o usare le porte onboard di un pc odierno, che sia anche a 3-4 ghz, caricarci un cubase e sentirai come non sia assolutamente in grado di mantenere un tempo preciso.. sempre che ti intenda di musica ed abbia un orecchio allenato all'intendere queste cose. :)
Un atari lo faceva con 512kb di ram, 8mhz e 16bit di bus; il tutto nell' 85.. Ora sono passati 20 lunghissimi anni.. per un uomo sono tanti, ma per il campo informatico sono un era.. ed ancora non ci siamo. Gli esempi ovviamente non si limitano a questo. Se ne hai voglia rileggi tutte le discussioni!! :p hehe
Questo concetto e' scaturito da una mia considerazione nella quale vedevo come vantaggio non da poco, la non derivazione delle nuove console dall'architettura x86/pc-compatibili di mezzo secolo fa.

[fantoibed]

Ti ho fatto notare che un 68000, per eseguire una NOP (che è un'istruzione che non fa nulla), impiega ben 4 cicli di clock.
Ti ho fatto notare che un 486 esegue la maggior parte delle istruzioni (quindi anche ben più complicate di una NOP) in un solo ciclo di clock.
Questo avrebbe dovuto farti dedurre che la disparità fra la "potenza di calcolo / efficacia" (qualunque cosa tu intendi con questi termini) è MOSTRUOSAMENTE a favore di quest'ultimo.

Che vantaggio ci sarebbe nell'eseguire un'istruzione che non fa' nulla in meno cicli di clock? ...Per la serie "non fa' nulla ma lo fa' più rapidamente..." ? (scherzo, eh!)

Riporto come supporto alla discussione 2 link in cui sono riportati i timings delle istruzioni generiche+ALU (nel primo) e FPU (nel secondo) sui 486:
http://fux0r.phathookups.com/programming-tutorials/Assembly/opcode.html
http://fux0r.phathookups.com/programming-tutorials/Assembly/fpuopcode.html

Qui, invece, ci sono i timings delle istruzioni FPU sul 68881:
http://hysteria.sk/~mikro/Coding/Atari/Maggie/FPU.TXT

Se trovo i timings dei 68030 faccio un edit....

[cdimauro]

The 68000 architecture was much more flexible than other CPU familes (z80, 80x86, z80000, etc) as it could be very easily expanded to support full 32-bit data and address.
Questo viene dal link che non cpisci perche' io abbia postato..
Che conferma quello che ho detto sul 68000 e sul 68008: che l'architettura è a 32 bit, non a 16 né a 16/32 bit, come sostenevi tu.
In base alle non restrizioni dei bus a bittaggi inferiori-
E' una TUA considerazione, non un criterio OGGETTIVO.
Secondo me si dovrebbe far distinzione tra "emulare" ed "imitare", un 486 fa girare molto male l'emulatore amiga e per emulare un 68000 ha bisogno di frequenze spropositatamente superiori.
Infatti ho parlato di emulazione per farti capire che il 486 le potenzialità le ha tutte, visto che riesce a emulare il 68000 con cui TU l'hai messo a confronto.
Solo che emulare un 68000 vuol dire fargli fare lo STESSO IDENTICO lavoro, ma in maniera MOLTO più inefficiente: immagina cosa sarebbe in grado di fare "nativamente".
Se prendi un normalissimo 520st, e' in grado di far girare il 30% piu' velocemente (con lo spectre) un mac di pari frequrenza.
Questi dati dove li hai presi?
In oltre l'emulatore ST dell'amiga era pietoso, girava al 10% delle possibilita' di un vero st, era inusabile, poi, come provavi a lanciare un software entrava nella crisi piu' totale.
Mi sembra ovvio: le applicazioni che accedevano direttamente all'hardware non trovavano nulla dell'ST.
Era si e no in grado di emulare il descktop con lentezza esasperante, assolutamente non in grado di eseguire tutte le operazioni assegnate al dma, un st poteva formattare un floppy in backgrund senza rallentare il computer in alcuna maniera e se cubase si impallava e tornava al desk, la song continuava a suonare senza sbagliare un 64esimo nemmeno durante la fase di crash.
Le applicazioni "canoniche" (che non sfruttavano l'hardware direttamente) giravano bene. Poi è chiaro che per certe operazioni non era particolarmente versatile.

Ad esempio, l'Amiga non aveva un controller per il floppy a cui diceva: "prendi questi 512 byte e infilali nel settore 7 della traccia 123". Doveva prima codificare in MFM l'INTERA TRACCIA, effettuare il seek per posizionarsi sulla traccia giusta, selezionare la testina, e soltanto dopo spedire i dati col DMA.
Dunque mi sembra assurdo parlare d'emulatore st su amiga.
Infatti non l'ho fatto in questo contesto, ma ne ho parlato dopo (in un altro): qui parlavo di un PC con 486 che emula un Amiga con 68000 a 7Mhz.
(lo ho ed ho ancora diversi amiga assieme al loro software ed una bella collezione di retrocomputing a partire dal vectrex passando per l'archimedes e finendo al giorno d'oggi..)
Idem. Ma questo non c'entra niente col discorso... ;)
Tenendo presente che anche gli emulatori attuali non sono in grado di visualizzare ad esempio le demo che rappresentino raster in overscreen, riducendoli nei colori pesantemente. Non sono nemmeno in grado di far girare in cubase con la precisione dell'originale.
Non vuol dire che non saranno in grado di farlo.

L'Amiga ha un hardware custom MOLTO più complicato da emulare rispetto a quello dell'ST: eppure WinUAE è quasi perfetto e permette di emulare un Amiga (1000, 500, 1200, 3000, 4000, ecc.) in maniera fedele, fino al ciclo di clock se necessario.

Allo stesso modo, esistono emulatori C64 molto fedeli, in grado di emulare perfino la pipeline interna del 6510.

Il problema è di avere persone qualificate che siano in grado di realizzare emulatori di questa levatura (presupponendo di avere tutta la documentazione disponibile, ovviamente).
Bene, secondo questo tuo assunto, tutti i difetti sono riconducibili alla mala programmazione e pessimi porting.. sempre che di porting si tratti..
All'atto pratico TUTTI i software presenti su entrambe le piattaforme giravano meglio (infinitamente meglio a parita di cpu, frequenze e memoria impiegata) su sistemi 68000 based.
Sara' stata tuta incompetenza dei programmatori.. mah!!
E' difficile trarre giudizi senza avere sotto mano i sorgenti dei programmi in questione e analizzarli.

Per quanto mi riguarda, conoscendo discretamente entrambe le architetture, penso che a un 486 non manca certo la potenza di calcolo per far girare bene le applicazioni di cui parli.

D'altra parte non hai detto anche tu che i 68000 bisogna saperli programmare per spremerli bene? Lo stesso vale per i 486... ;)
Riguardo Halo non sono informato, ma mi parrebbe strano leggere di queste grandi differenze, vista la similarita' (identicita', piu' che altro) delle piattaforme in questione. Se hai qualcosa postalo.
Su google trovi un sacco di informazioni. Qui http://www.multiplayer.it/articolo.php?id=9935&lang=it ne trovi una recensione in cui parlano anche della conversione e dei suoi problemi. Ti riporto uno stralcio delle conclusioni:

"[...]Ma la conversione presenta non vari problemi (non è comprensibile che un titolo che girava bene su un Xbox, ossia un Pentium III 733 con 128 kbyte di cache L2 e una Geforce 3 con la sola aggiunta di un’unità di Vertex Shader rispetto alla Geforce 3 originale, giri con difficoltà su macchine molto più aggiornate). Ed è per questo che il voto di Halo rimane quello di un titolo che, per quanto bello, subisce il peso di una realizzazione non eccezionale.[...]"
Non mi risulta che il DSP 56001 sia quest'asso nelle istruzioni "General Purpose"
Che già è MOLTO DIVERSO da quel che avevi affermato prima:

"Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP,"

Non puoi dire prima una cosa (per di più per te era "ovvio"), e poi un'altra diversa, altrimenti dimostri di non avere adeguate conoscenze o di non avere un'idea precisa di ciò di cui stai parlando.
Cio' non toglie che la gestione di 160 ch midi (tramite un'interfaccia PASSIVA esterna e porta lan (di derivazione mac) in aggiunta a quelle di serie), non comporti minimamente l'utilizzo del dsp.
Infatti ho separato i discorsi: gestione dei canali MIDI -> seriale a 31000 baud, manipolazione audio e effetti speciali -> DSP 56001.
Un 486 non e' assolutamente in grado di gestire 16ch midi con precisione. Molti miei amici musicisti fino al 2ghz e passa si sono disperati per questo motivo. E' anche il motivo per il quale alla fine io non ho ancora cambiato, anche se prima o poi accadra'. Tutt'oggi un pc per avere una vera prestazione midi/hdr, necessita di una costosa scheda dedicata. Ma tanto tu sostieni che si tratti di malaprogrammazione.
Il tuo problema è che tu mischi processori e hardware in un gran calderone, tentando di forzare dei confronti senza alcuna base consistente.
Se parli di un 486, è una cosa. Se parli di hardware per fare musica, è un'altra cosa.

Se vogliamo testare le capacità di un 486 in campo audio, avrebbe senso farlo a parità di dotazione hardware, non credi?
Altrimenti potrei anche dirti che l'8086 a 4Mhz disintegra un 68060 a 50Mhz soltanto perché la NASA l'ha usato per lo Shuttle...
Come no.. si e' visto.. puo' farlo un vic venti ma non un 486.. nemmeno un athlon 1000..
Forse non si tratta solo di trasferire dati.. che ne dici??
Esatto, ma questo l'avevo già ampiamente affermato prima...

Per chiarire il discorso, visto che la battuta non è stata colta, volevo dire questo: l'interfaccia MIDI è una banalissima seriale a 31000 baud che può pilotare tranquillamente anche un VIC20 con un 6502 a 1Mhz. Poi bisogna vedere come lo si fa, appunto: con quale programma.

In questo caso rientra il fatto di vedere come è stato realizzato il porting delle applicazioni che usano la MIDI. Se, quindi, ha avuto la stessa "cura".
Perché può essere molto comodo comodo confrontare un programma scritto in assembly 68000 (o quanto meno nelle parti critiche) che si interfaccia direttamente ai registri (hardware) alla seriale/MIDI, con uno scritto in C (o altro) e che fa uso delle API di Windows per comunicare con la seriale/MIDI.

Spero che adesso sia chiaro il concetto.
E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)
Hai mai programmato un PC con 386 in vita tua? E' un TANTINO DIVERSO da quello di cui conservi un cattivo ricordo... :p
Ma tu vivi nel mio studio?? Il primo masterizzatore comprato tantissimi anni fa era SOLO scsi e costava circa 13milioni di lire e mi sprecava CD del valore di 90mila.
Hai letto bene quello che ho scritto? Te lo riporto:

"Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD."

Parlavo dello stesso masterizzatore che usavi (o che usi ancora) col Falcon.

Inoltre non abbiamo considerato i controller SCSI, che sicuramente saranno diversi, come pure i loro driver e i software per masterizzare.
A questo ho risposto ampiamente sopra. Poi se vuoi ti racocnto bene come nacquero l'amiga e l'ST.
Idem. Quanto alla loro storia non ne ho bisogno, grazie: la conosco molto bene.
La motorola lo abbandonò perche' schiacciata dal mercato. Le schede a 256 colori a basso costo di produzione orientale fecero diffondere il pc in modo assurdo e rapido.
Si parla di processori e te ne vai alle schede video: lo vedi che metti assieme delle cose diverse, mischiando tutto? Io quando ho parlato di processori ho confrontato solo loro e le caratteristiche che avevano. Non ho infilato in mezzo il DSP 56001 per l'audio o la Tseng ET6000 per la grafica.
Se ci fosse stata una pari evoluzione degli altri due sistemi, ora saremmo decisamente su un altro piano.
Coi se e i ma non si va da nessuna parte...

E' stata Motorola ad abbandonare la sua famiglia più famosa e su chi ha costruito molta della sua fortuna: non pensi che avrà avuto i suoi buoni motivi per farlo? S'è resa conto che con l'enorme competizione a cui era soggetto il mercato dei processori, i limiti strutturali dei suoi 680x0 l'avrebbero portata prima o poi a un vicolo cieco.
Il 680x0 aveva solo il limite di essere cisc,
Anche gli x86 sono CISC.
specialemnte nelle ultime versioni, possedeva potenza da vendere (060),
Questo nessuno l'ha mai negato.
ma un risc era sicuramente piu' efficace.
Sicuramente no, ai tempi. Sicuramente un RISC più moderno sì, perché è stato più facile scalare in frequenza.
(specialmente in ambito di malaprogrammazioneo o programmazione "facile"..)
I RISC non si programmano in assembly, ma con linguaggi ad alto livello.
Quanto alla "malaprogrammazione", non dipende dall'architettura ma dai programmatori.
Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.
Non si pone neppure il problema: la Panda è il 68000 e la Lamborghini è il 486 (in base al confronto che hai fatto). :p

Comunque io parlavo d'altro: delle difficoltà che un ingegnere ha nell'implementare una determinata architettura. Difficoltà che sono notevoli per i 680x0, ed era questo che volevo rimarcare. Il confronto Panda <-> Lamborghini qui non c'entra assolutamente nulla.
A me il 680x0 piace perche' non e' risc.
Idem. E lo stesso vale per gli x86 (con x >= 3).
anche se oggi non ha senso parlare di risc e cisc, i processori sono cosi' complessi da non poter essere piu' distinti in questo modo. Piu' che altro si adattano nell'evoluzione al tipo di istruzioni piu' richiesto.
Più che altro le istruzioni vengon aggiunte.
Comunque la distizione fra RISC e CISC c'è ancora.

Inoltre quello che hai scritto non c'entra niente con la parte che hai quotato.
Come sopra, a te piacicono le cose semplici, ma non e' una regola applicabile a tutti.
Non parlavo di tutto, ma di una cosa BEN PRECISA: il decoder delle istruzioni di un processore.

Ho detto che quello per un 68020+ sarebbe MOLTO più complicato da realizzare, e ti ho spiegato anche il perché.

Se c'è qualcosa di non chiaro, non hai che da dirlo: non ho problemi a farti altri esempi.
Se non sei d'accordo con ciò che ho detto, non hai che da fornire un contro-esempio.
Sarebbe possibilissimo iplementare le attuali tecnologie ad un'altra architettura.
Il discorso e' molto piu' complesso,in primis perche' oggi si richiede comuqnue un aggiornamento (politica del consumismo) continuo, che con certe architetture risulta piu' ostico (ma meno necessario).
Ma infatti io non ho detto che non si potrebbe fare: ho illustrato alcune problematiche su cui ci si scontrebbe nella realizzazione.

Non c'entra niente il consumismo: è una questione PURAMENTE TECNICA. Attieniti a questo nelle tue valutazioni.
C'e' da considerare anche che la tecnologia attuale e' cresciuta con i pc compatibili e dunque su misura per loro. Qualora fosse stata sviluppata su altre piattaforme, avrebbe sicuramente preso altre direzioni (quelle piu' opportune alle altre piattaforme, appunto).
Sono motivazioni che non reggono: la stessa tecnologia è usata da IBM con la sua famiglia Power (RISC), che con gli x86 ha ben poco a che spartire.
Sicuramente non ci sarebbe stata questa folle rincorsa alle frequenze, dalla quale per fortuna, AMD si sta (solo in parte) dissociando.
AMD non si è affatta dissociata: infatti continua a sfornare processori a frequenze più elevata. Tra poco arriverà l'FX a 2,8Ghz.
Allo stesso modo, anche IBM coi Power, e adesso con Cell e il processore dell'X-Box360, ha puntato molto sulla frequenza di lavoro. E anche qui, le architetture che ho elencato non hanno nulla a che vedere con gli x86.

Comunque, ripeto quanto scritto: io ho fatto delle considerazioni di natura strettamente tecnica in merito al fatto di vedere implementata l'architettura 680x0 con le tecnologie disponibili ai giorni nostri.
Puoi non essere d'accordo, e in tal caso ti pregherei di portare altrettanti argomenti tecnici, ma non puoi spostare il discorso verso altri lidi.
C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.
Un Falcon senza l'hardware dedicato è ridicolo, entra in crisi in molti segmenti.
Ne abbiam gia' parlato
Appunto. E tecnicamente non sei stato molto convincente sull'intrinseca superiorità dell'architettura 680x0 su quella x86 (in particolare, ti ricordo il 68000 a 8Mhz e il 486 a 66Mhz).
Forse non hai mai usato tutte le istruzioni di un 680x0,
Direi proprio di no: ho una discreta conoscenza sia dei 680x0 che degli x86... ;)

Tu invece cosa, cosa mi racconti di bello? C'hai mai lavorato (a basso livello intendo), o ti sei limitato soltanto a usarli (i computer che li montavano)?
non essendo risc richiede una programmazione piu' complessa e "fantasiosa", ma queste cose le sai.
Al contrario: proprio perché lo so come si programmano, visto che l'ho fatto per parecchi anni e non mi sono certo limitato al classico "Hello, world!", so che un 68000 era piuttosto semplice da programmare rispetto a tanti RISC, tant'è che l'assembly era molto usato come linguaggio, perfino per scrivere i comandi DOS.
No, non e' uno scherzo, dovremmo vedere le date di produzione, comunque regge il paragone con un pentim senza problemi.. direi.
Non ho mai detto che non sarebbe paragonabile, anzi (propendo più il 68060, se non si fosse capito ;)). Ho soltanto detto che non potevi confrontare un 486 con un 68060, ma che quest'ultimo andava paragonato con il suo "naturale antagonista", il pentium.

Quanto alle date di produzione, 80486 e Pentium sono arrivati prima dei "rispettivi" 68040 e 68060.
Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.
Diciamo che ne sono meno affette, proprio perché sono "nuove".

Ma il tuo problema è che non riesci a capire / vedere che l'architettura di mezzo secolo fa è soltanto un vago ricordo, e che gli x86 di oggi sono ALQUANTO DIVERSI.
Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.
Ovvio: potendo progettare tutto da zero, si potrebbe utilizzare meglio il silicio.

Ma tu parlavi di un 68000 costruito con le tecnologie attuali, che invece si porterebbe dietro tutti i problemi della sua architettura.
Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno ;) )
Non ho iniziato nessun dibattito: quel che ho scritto era un piccolo e semplice messaggio di precisazione.
Non ero d'accordo ed esistendo il diritto di replica (me lo concedi no??) deve finire chi ha parlato per secondo. Almeno cosi' si fa in democrazia.
Questo è un forum libero: limitatamente al regolamento, hai piena libertà di dire ciò che vuoi, e questo nessuno l'ha negato.

Ho soltanto detto che è troppo comodo pontificare e poi fuggire dicendo che il discorso si chiude qua.

Se ti vuoi confrontare, accomodati pure: per me non c'è problema.
Per quanto riguarda l'altro post, direi che le mie convinzioni riguardo l'indecenza dell'architettura di questi cassoni sia palesata ed anche la convinzione (mia e non solo mia) che le potenzialita' di macchine basate su 68000 siano maggiori di quelle basate su x86, sia altrettanto palesata.
A me sembra, invece, che sia l'esatto contrario, e ho scritto anche il perché. Dovresti "palesare" meglio il tuo pensiero, magari intavolando una discussione tecnica, senza mischiare processori e hardware in un gran calderone, e portando argomenti tecnici a sostegno delle tue tesi, perché finora non hai fatto altro che riportare le tue convizioni.
Convengo con te riguardo la difficolta' di programmazine, che oggi come oggi sarebbe un gran limite, vista la frenesia del mercato, ma questo e' un altro discorso ancora.
Sì, ma è pure sbagliato, come ho già detto: i 680x0 sono fra i processori più semplici da programmare (lasciando perdere i dettagli specifici, che comunque si ritrovano in tutte le architetture), e proprio per questo chi ha avuto modo di lavorarci ne conserva ancora un gran bel ricordo.
Insomma, per ora il mio falcon non mi sbaglia una nota di un 128esimo, un pc senza schede costosissime fa slittare note di 16esimi anche solo se si legge un cd e scrive una cache su hd.
Vedi sopra.

Comunque se qualcuno si passerà il capriccio di emulare il Falcon su questi schifosissimi PC, magari potrai finalmente metterlo da parte e continuare a non sbagliare una nota di un 128esimo... :p

[cdimauro]

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..
Puoi spiegarti meglio? Con l'Amiga e l'ST si potevano leggere tranquillamente i floppy dei PC (da 720KB), e con gli appositi emulatori far girare i programmi (limitatamente al PC emulato).
Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te..
Non in tutti i mainframe: solo in quelli per cui il Cell è particolarmente orientato a livello di calcoli.
Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.
Poi puo' pure essere finto quel demo, ma credo in quel progetto.
Appunto, e hai fatto l'esempio giusto: per QUELLE COSE il Cell va bene (e neanche tanto: per l'IA non è ben predisposto).

Per i calcoli general purpose, però, già i PC di oggi sono molto più potenti.
Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.
Sì, ma sempre per ciò per cui è stato pensato e progettato: il calcolo massicciamente parallelo / distribuito.

Sulla tua risposta a homero non mi pronuncio, visto che ho trattato gli stessi argomenti nel messaggio precedente.

[cdimauro]

Che vantaggio ci sarebbe nell'eseguire un'istruzione che non fa' nulla in meno cicli di clock? ...Per la serie "non fa' nulla ma lo fa' più rapidamente..." ? (scherzo, eh!)
Era soltanto un esempio. Il discorso è partito da qui http://www.hwupgrade.it/forum/showthread.php?t=948317&page=5 e in particolare da questa frase:

"(un motorola 68000 a 16 bit a 8mhz ha il potenziale di un 486 a 32bit a 66mhz)"

di MadRat.

Ti consiglio di leggere il thread dall'inizio, così ti sarà tutto più chiaro.
Riporto come supporto alla discussione 2 link in cui sono riportati i timings delle istruzioni generiche+ALU (nel primo) e FPU (nel secondo) sui 486:
http://fux0r.phathookups.com/programming-tutorials/Assembly/opcode.html
http://fux0r.phathookups.com/programming-tutorials/Assembly/fpuopcode.html

Qui, invece, ci sono i timings delle istruzioni FPU sul 68881:
http://hysteria.sk/~mikro/Coding/Atari/Maggie/FPU.TXT

Se trovo i timings dei 68030 faccio un edit....
Non ho trovato niente in giro...

Proprio l'altro ieri ho buttato un listato con i timing precisi del 68030. :muro:
Vediamo se nel week-end trovo il file da cui era stato stampato, ed eventualmente ne riporto qualche stralcio, se interessa (o tutto: non erano molto lungo l'elenco).

[cdimauro]

Scusate per gli strafalcioni grammaticali: non ho tempo né voglia di correggerli, anche perché comunque si capisce tutto... :p

[Spectrum7glr]

Scusate per gli strafalcioni grammaticali: non ho tempo né voglia di correggerli, anche perché comunque si capisce tutto... :p

non ti preoccupare: da quello che scrivi si capisce che hai studiato...e non poco ;)

[fek]

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..

Anche se metti quel floppy dentro un Mac o un'Amiga, viene letto. Non mi risulta che un Mac sia cosi' simile ad PC degli anni '80 :)

Fai un altro esempio :)


Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te..


Ne sanno molto piu' di me, infatti il Cell e' uno streaming processor, non un processore General Purpose.

Non ci vuole chissa' quale preparazione per capire che un processore con esecuzione in order e core semplificato (il PPE) va molto piu' piano su codice general purpose di un processore con esecuzione out of order e svariati transistor spesi in cose come branch pradiction et simili (P4 o AMD) a frequenze paragonabili.


Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.

Il Cell non e' in grado di fare rasterizzazione, tanto e' vero che gli hanno affiancato una GPU nella PS3. Su su su non portiamo techdemo da marketing ad esempio.


Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.

E' esattamente il contrario. Proprio perche' hanno tolto tutta una serie di facility come l'esecuzione out of order, il multithreading nelle SPE, le cache sostituite con memoria privata da programmare esplicitamente, il Cell ha un paradigma di programmazione molto piu' complicato di una CPU general purpose. Infatti e' uno stream processor.

[Hal2001]

Masterizzatore 0,5X :rotfl:

[fantoibed]

Non ci vuole chissa' quale preparazione per capire che un processore con esecuzione in order e core semplificato (il PPE) va molto piu' piano su codice general purpose di un processore con esecuzione out of order e svariati transistor spesi in cose come branch pradiction et simili (P4 o AMD) a frequenze paragonabili.

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera porti sicuramente ad un peggioramento delle prestazioni. D'altra parte tutti quei milioni di transistor risparmiati per l'assenza di queste tecnologie in hardware possono essere sfruttati per poter inserire più unità di calcolo o una cache più grande, ecc...

La maggiore complessità per il programmatore potrebbe essere relativa, nel senso che sistemi di code morphing e API ad alto livello potrebbero spostare la parte "rognosa" di codice a kernel level!

Tu che programmi videogiochi, suppongo che scriverai codice ad alto livello interfacciandoti a qualche libreria apposita per la gestione della scena 3D, tipo OpenGL o DirectX e non ti tocca molto da vicino il fatto che l'ISA di questa o quella GPU sia "rognosa" da programmare in assembly: questo problema casomai sarà di chi sviluppa i drivers, non di chi scrive i giochi.

Analogamente, se realizzassero una virtual machine di alto livello (cosa che va sempre più di moda, vedasi Java prima, .Net poi e via dicendo) non sarebbe difficile scrivere software per la macchina virtuale. Il problema dell'ISA ostica verrebbe affrontato una volta per tutte da chi sviluppa la virtual machine....

....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?

[fek]

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera porti sicuramente ad un peggioramento delle prestazioni. D'altra parte tutti quei milioni di transistor risparmiati per l'assenza di queste tecnologie in hardware possono essere sfruttati per poter inserire più unità di calcolo o una cache più grande, ecc...

Purtroppo non abbiamo la controprova perche' questi tool e questi compilatori non sono stati ancora scritti. Per quello che ne sappiamo ora, allo stato attuale delle cose, una CPU con esecuzione in-order e con cache limitata come il PPE va piu' piano sul codice general purpose. Poi, se ci saranno i tool, se i compilatori saranno in grado di fare il lavoro che oggi fa la CPU, se la cache minore non sara' un problema (cosa che non credo), allora se tutte queste condizioni saranno vere potremmo fare considerazione differenti. Al momento queste condizioni non sono ne' vere ne' dimostrati tali, anzi, ci sono fortissimi dubbi che i compilatori saranno in grado staticamente di fare quello che la CPU fa dinamicamente in base alle condizioni di esecuzione. Lo stesso codice, ad esempio, puo' avere profili prestazionali di esecuzione totalmente differenti a seconda di quando e' eseguito e dopo che cosa e' eseguito, ed e' una cosa che un compilatore non sara' mai in grado di prevedere per ovvi motivi.

Tu che programmi videogiochi, suppongo che scriverai codice ad alto livello interfacciandoti a qualche libreria apposita per la gestione della scena 3D, tipo OpenGL o DirectX e non ti tocca molto da vicino il fatto che l'ISA di questa o quella GPU sia "rognosa" da programmare in assembly: questo problema casomai sarà di chi sviluppa i drivers, non di chi scrive i giochi.

Il discorso sul Cell facile o difficile da programmare non e' sull'ISA, ma sul modello di programmazione inerentemente complicato al di la' del set di istruzioni e questo non puo' essere nascosto ne' dalla libreria' ne' dai tool. Il Cell si programmera' in maniera totalmente diversa da una CPU classica, bisognera' suddividere il problema in maniera che si adatti ad un'architettura che lavora in streaming, senza cache e la stragrande maggioranza dei problemi non si adatta a queste condizioni. Ad esempio, ricerche in grafi, rasterizzazione di poligoni, IA sono tutti problemi che non sono agevoli da trattare come un "flusso di dati sul quale esegui operazioni". Qui non c'e' tool di sviluppo o compilatore o code morphing che tenga: il Cell si inchioda perche' non e' progettato per fare quelle cose.

Avevo fatto una volta l'esempio dell'idraulico: se gli chiedi di aggiustarti un rubinetto e' un missile, se gli chiedi di tagliarti l'erba magari ci riesce anche, ma un giardiniere e' piu' veloce.

Usare OGL o D3D non toglie che se voglio far andare le cose veloci devo sapere come e' fatta all'interno la GPU anche in minimi particolari, altrimenti quello che scrivo va... ma piano. Quando si tratta di fare andare le cose veloci e' necessario sapere come l'hardware e' implementato all'interno e il suo design detta le ottimizzazioni e gli algoritmi.

Un esempio: l'API per usare una Texture3D e' la medesima in OpenGL e D3D su NVIDIA e ATI. Ma se non so che su ATI un pattern di accesso ad una Texture3D che segue solo l'asse z e' lento, mi trovo lo stesso codice che va 10 volte piu' lento su un R4X0 rispetto ad un NV4X.

....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?

Ci sono molte informazioni sul Cell, la sua architettura non e' piu' un mistero ormai.

[fantoibed]

... ci sono fortissimi dubbi che i compilatori saranno in grado staticamente di fare quello che la CPU fa dinamicamente in base alle condizioni di esecuzione.

Infatti dovrebbe farlo dinamicamente il sistema operativo (o la virtual machine) e non staticamente il compilatore...

Ci sono molte informazioni sul Cell, la sua architettura non e' piu' un mistero ormai.

Sull'architettura no, ma sul software (vm, api, os, compilatori, ecc...) sì...

[fek]

Infatti dovrebbe farlo dinamicamente il sistema operativo (o la virtual machine) e non staticamente il compilatore...


Ma questo e' improponibile, come fa il sistema operativo ad analizzare tutto il codice che dev'essere eseguito mentre viene eseguito e riordinare le istruzioni per evitare gli stalli? Dovrebbe avere accesso alla CPU, in pratica dovrebbe fare la CPU, tanto vale che lo faccia la CPU.

[Correx]

Masterizzatore 0,5X :rotfl:

:D


il mio primo masterizzatore SCSI fu il glorioso (ho dei cd che durano ancora oggi) Philips CDD2000, che già era 2x, non ricordo gli 1X sul mercato , italiano almeno....

[Hal2001]

il mio primo masterizzatore SCSI fu il glorioso (ho dei cd che durano ancora oggi) Philips CDD2000, che già era 2x, non ricordo gli 1X sul mercato , italiano almeno....

Il mio primo.. se mio si può definire ( :D ) fu invece un plextor 4X sempre scsi, 1.200.000 :muro:

Ma avevamo bisogno di velocità :ciapet:

Fine OT

[fantoibed]

Ma questo e' improponibile, come fa il sistema operativo ad analizzare tutto il codice che dev'essere eseguito mentre viene eseguito e riordinare le istruzioni per evitare gli stalli? Dovrebbe avere accesso alla CPU, in pratica dovrebbe fare la CPU, tanto vale che lo faccia la CPU.

Invece è proprio questo che intendono fare, almeno stando a quanto si dice su arstechnica:
http://arstechnica.com/articles/paedia/cpu/cell-1.ars

Back to the future, or, what do IBM and Transmeta have in common?

It seems like aeons ago that I first covered Transmeta's unvieling of their VLIW Crusoe processor. The idea that David Ditzel and the other Transmeta cofounders had was to try and re-do the "RISC revolution" by simplifying processor microarchitecture and moving complexity into software. Ditzel thought that out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream had increased processors' microarchitectural complexity to the point where way too much die real-estate was being spent on control functions and too little was being spent on actual execution hardware. Transmeta wanted to move register renaming, instruction reordering and the like into software, thereby simplifying the hardware and making it run faster.

I have no doubt that Ditzel and Co. intended to produce a high-performance processor based on these principles. However, moving core processor functionality into software meant moving it into main memory, and this move put Transmeta's designs on the wrong side of the ever-widening latency gap between the execution units and RAM. TM was notoriously unable to deliver on the intitial performance expectations, but a look at IBM's CELL design shows that Ditzel had the right idea, even if TM's execution was off.

IBM's Cell embodies many of the "RISC redivivus" principles outlined above, but it comes at these concepts from a completely different angle. Like TM, IBM started out with the intention of increasing microprocessor performance, but unlike TM, simplifying processor control logic wasn't the magic ingredient that would make this happen. Instead, IBM attacked from the very outset the problem that TM ran headlong into: the memory latency gap. IBM's solution to the memory latency problem is at once both simple and complex. In its most basic form IBM's Cell does what computer architects have been doing since the first cache was invented — Cell moves a small bit of memory closer to the execution units, and lets the processor store frequently-used code and data in that local memory. The actual implementation of this idea is a bit more complicated, but it's still fairly easy to grasp.

[fek]

Invece è proprio questo che intendono fare, almeno stando a quanto si dice su arstechnica:
http://arstechnica.com/articles/paedia/cpu/cell-1.ars

Quello che e' scritto in quell'articolo e' molto diverso dall'analizzare ogni singola istruzione mentre viene eseguita per allocarla nel punto giusto del flusso e nascondere le latenze, che e' cio' che fa una CPU out-of-order.

Anzi, non dice proprio nulla a riguardo. Parla semplicemente delle memorie private degli SPE, che devono essere programmate a manina e non dal Sistema Operativo: il loro uso dipende fortemente dall'algoritmo ed e' quindi in mano al programmatore.

[fantoibed]

Quello che e' scritto in quell'articolo e' molto diverso dall'analizzare ogni singola istruzione mentre viene eseguita per allocarla nel punto giusto del flusso e nascondere le latenze, che e' cio' che fa una CPU out-of-order.

Anzi, non dice proprio nulla a riguardo. Parla semplicemente delle memorie private degli SPE, che devono essere programmate a manina e non dal Sistema Operativo: il loro uso dipende fortemente dall'algoritmo ed e' quindi in mano al programmatore.

Leggi tutto. Ho messo in grassetto un passaggio fondamentale.
In pratica dice che le nelle attuali architetture CISC, l'out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream ha aumentato a dismisura la complessità dell'hardware tanto che una parte troppo grande del die viene sprecata per le funzioni di controllo rispetto a quella che si occupa dell'esecuzione delle istruzioni.
L'idea che sta alla base dell'architettura dei processori Transmeta e TheCell è quella che conviene spostare queste funzioni dall'hardware al software.
L'errore che è stato fatto con le CPU Transmeta e che ha compromesso le prestazioni dei loro processori è stato quello di ospitare questa parte software (core processor functionality) in RAM con tutti i problemi di latenza elevata che ne derivano.
TheCell riprende il concetto di base, ma intende risolvere il problema prestazionale legato alla latenza della RAM con lo stesso principio che ha portato anni fa' all'introduzione della cache nei processori, ovvero spostare una piccola parte di memoria più vicino alle unità di esecuzione in modo da consentire al processore di memorizzare codice e dati più usati in quella memoria locale. L'implementazione vera e propria è più sofisticata, ma la spiegazione rende l'idea.

A questo aggiungo una riflessione. Dato che il software che viene eseguito (codice+dati) non è altro che un flusso di informazioni e dato che TheCell è impareggiabile come stream processor, vuoi vedere che, se opportunamente programmato, riesce ad eseguire le funzioni di controllo in software più efficientemente di quanto una GP-CPU classica riesca a fare via hardware?

Edit: Aggiungo da questo paper (ma consiglio di leggere il documento per intero che è molto interessante):
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf

4.4. Software branch prediction
Whereas modern hardware branch prediction structures do not do well on performance per transistor, software branch prediction tends to be an inexpensive means to gain a substantial performance improvement. In order to support high-frequency deeply pipelined designs efficiently, a branch hint instruction, present in the code well before the actual branch instruction allows for “just in time” prefetching of the instructions at the branch target. In combination with loop unrolling and interleaving, compilers can achieve near optimal performance even on deeply pipelined high-frequency processors.

[fek]

L'idea che sta alla base dell'architettura dei processori Transmeta e TheCell è quella che conviene spostare queste funzioni dall'hardware al software.
L'errore che è stato fatto con le CPU Transmeta e che ha compromesso le prestazioni dei loro processori è stato quello di ospitare questa parte software (core processor functionality) in RAM con tutti i problemi di latenza elevata che ne derivano.

Leggi meglio, il testo che hai quotato non dice quello che hai scritto ma dice che e' secondo quella filosofia e' meglio spostare quei transistor in ulteriori unita' parallele d'esecuzione, che nel caso del Cell sono unita' dedicate all'elaborazione in streaming non in general purpose.

ovvero spostare una piccola parte di memoria più vicino alle unità di esecuzione in modo da consentire al processore di memorizzare codice e dati più usati in quella memoria locale.

Che e' l'idea alla base delle cache da decine di anni a questa parte, non c'e' nulla di nuovo, se non l'interessante discorso sul fatto che non essendo una cache la memoria privata va caricata a mano dall'applicazione (non dal sistema operativo), pero' questo consente alle SPE di avere un modello di latenze perfettamente prevedibile che aiuta il compilatore (non il sistema operativo) a schedulare le istruzioni in maniera efficiente.


A questo aggiungo una riflessione. Dato che il software che viene eseguito (codice+dati) non è altro che un flusso di informazioni e dato che TheCell è impareggiabile come stream processor, vuoi vedere che, se opportunamente programmato, riesce ad eseguire le funzioni di controllo in software più efficientemente di quanto una GP-CPU classica riesca a fare via hardware?

Il codice e' un flusso, i dati non sempre, anzi, nella stragrande maggioranza delle operazione non lo e'. Le applicazioni general purpose sono soprattutto ricerche e gestione di strutture dati con pattern di accesso casuale in un largo working set (ordini di grandezza maggiore della memoria privata di un SPE); in una situazione simile l'applicazione (e non il Sistema Operativo) si trovera' a dover caricare e scaricare l'intera memoria privata potenzialmente ad ogni accesso alla memoria, perche' questo accesso non sara' potenzialmente vicino al precedente ma in una zona random del working set. Esempi di algoritmi di questo tipo: gestione del grafo di una scena 3d, rasterizzazione di poligoni texturizzati, Intelligenza Artificiale, qualunque tipo di database, compilatori, filesystem. Esempi di applicazioni in streaming: codifica/decodifica audiovideo.

Edit: Aggiungo da questo paper (ma consiglio di leggere il documento per intero che è molto interessante):
http://www.hpcaconf.org/hpca11/papers/25_hofstee-cellprocessor_final.pdf

Questo paper conferma quello che ho scritto: l'idea e' di spostare la schedulazione delle istruzioni a livello del compilatore (non del Sistema Operativo) sfruttando il modello di latenze fisso della memoria privata. Quest'idea e' ottima per le applicazioni in streaming, e' molto meno buona per applicazioni general purpose non in streaming dove il codice ha figure prestazionali diverse a seconda di quando e' eseguito e dei pattern d'accesso dei dati su cui e' eseguito, cosa che un compilatore non puo' ovviamente ottimizzare.


. In combination with loop unrolling and interleaving, compilers can achieve near optimal performance even on deeply pipelined high-frequency processors.

Compilatori, non il Sistema Operativo che non e' mai citato eseguire alcun tipo di analisi dinamica del flusso di istruzioni per riordinarne l'esecuzione. Sarebbe pura fantascienza, oltre che incredibilmente lento.

[fantoibed]

Leggi meglio, il testo che hai quotato non dice quello che hai scritto ma dice che e' secondo quella filosofia e' meglio spostare quei transistor in ulteriori unita' parallele d'esecuzione, che nel caso del Cell sono unita' dedicate all'elaborazione in streaming non in general purpose.

No. Rileggi.

Che e' l'idea alla base delle cache da decine di anni a questa parte, non c'e' nulla di nuovo, se non l'interessante discorso sul fatto che non essendo una cache la memoria privata va caricata a mano dall'applicazione (non dal sistema operativo), pero' questo consente alle SPE di avere un modello di latenze perfettamente prevedibile che aiuta il compilatore (non il sistema operativo) a schedulare le istruzioni in maniera efficiente.

No. Viene fatta dal software, non dall'applicazione. Prendi i Transmeta (società a cui Sony ha rilevato 100 ingegneri su 208 totali). Sui Crusoe ed Efficeon tale software (code morphing) è ad un livello inferiore a quello del Bios e del sistema operativo.

Il codice e' un flusso, i dati non sempre, anzi, nella stragrande maggioranza delle operazione non lo e'. Le applicazioni general purpose sono soprattutto ricerche e gestione di strutture dati con pattern di accesso casuale in un largo working set (ordini di grandezza maggiore della memoria privata di un SPE); in una situazione simile l'applicazione (e non il Sistema Operativo) si trovera' a dover caricare e scaricare l'intera memoria privata potenzialmente ad ogni accesso alla memoria, perche' questo accesso non sara' potenzialmente vicino al precedente ma in una zona random del working set. Esempi di algoritmi di questo tipo: gestione del grafo di una scena 3d, rasterizzazione di poligoni texturizzati, Intelligenza Artificiale, qualunque tipo di database, compilatori, filesystem. Esempi di applicazioni in streaming: codifica/decodifica audiovideo.

Ripeto. Le funzioni di reordering, register renaming, latency hiding, ecc.. vengono eseguite dal layer di code morphing sui Transmeta e probabilmente avverrà qualcosa di analogo sui Cell. L'architettura logica vista dai processori sarà probabilmente diversa da quella fisica...


Questo paper conferma quello che ho scritto: l'idea e' di spostare la schedulazione delle istruzioni a livello del compilatore (non del Sistema Operativo) sfruttando il modello di latenze fisso della memoria privata. Quest'idea e' ottima per le applicazioni in streaming, e' molto meno buona per applicazioni general purpose non in streaming dove il codice ha figure prestazionali diverse a seconda di quando e' eseguito e dei pattern d'accesso dei dati su cui e' eseguito, cosa che un compilatore non puo' ovviamente ottimizzare.
Compilatori, non il Sistema Operativo che non e' mai citato eseguire alcun tipo di analisi dinamica del flusso di istruzioni per riordinarne l'esecuzione. Sarebbe pura fantascienza, oltre che incredibilmente lento.

Si riferisce a compilatori "just in time", però, che saranno integrati nel sistema operativo oppure ad un layer ancor più basso come nei Transmeta.

Per ora si sa che le applicazioni non avranno accesso diretto alle SPE ma sarà il kernel linux a mettere a disposizione un layer di astrazione attraverso device drivers e system calls:
http://www.linuxtag.org/typo3site/freecongress-details.html?talkid=156

[fek]

No. Rileggi.

Si', ho riletto. Dice esattamente quello che ho detto io, non parla di code morphing o nulla di analogo (ovviamente perche' chi ha scritto quell'articolo e' molto preparato e non lo scriverebbe mai).


No. Viene fatta dal software, non dall'applicazione. Prendi i Transmeta (società a cui Sony ha rilevato 100 ingegneri su 208 totali). Sui Crusoe ed Efficeon tale software (code morphing) è ad un livello inferiore a quello del Bios e del sistema operativo.

Scusami, no. Gli algoritmi per scaricare e ricaricare la memoria privata dipendono dall'applicazione. Un filtro digitale carica il kernel del filtro e blocchi di dati, un compilatore caricherebbe una parte del sorgente e la tabella dei simboli, un grafo caricherebbe i nodi adiacenti. Dipende dall'applicazione.
Hai mai programmato qualcosa di analogo ad uno stream processor?


Ripeto. Le funzioni di reordering, register renaming, latency hiding, ecc.. vengono eseguite dal layer di code morphing sui Transmeta e probabilmente avverrà qualcosa di analogo sui Cell. L'architettura logica vista dai processori sarà probabilmente diversa da quella fisica...


E' tutto un probabilmente, sono piu' speranza che realta', al momento non e' neppure previsto nulla di simile. Pura fantascienza, per quanto ne so avrebbe la stessa valenza dire che l'analisi del codice verra' fatta da un alieno per via telepatica.
E come spiego dopo analizzare il codice mentre viene eseguito richiede istruzioni e tempo e sarebbe altamente inefficiente.


Si riferisce a compilatori "just in time", però, che saranno integrati nel sistema operativo oppure ad un layer ancor più basso come nei Transmeta.

No. Si sta riferendo ai compilatori, la parola just in time non appare in tutto il testo. Neppure il termine code morphing. Sono interpretazioni tue (sbagliate).

Per altro, anche se fosse just in time (che non e' un compilatore ma e' un traduttore), la traduzione del metodo viene effettuata ovviamente alla sua prima esecuzione, non ad ogni sua esecuzione, cosa che sarebbe oltremodo inefficiente.



Per ora si sa che le applicazioni non avranno accesso diretto alle SPE ma sarà il kernel linux a mettere a disposizione un layer di astrazione attraverso device drivers e system calls:
http://www.linuxtag.org/typo3site/f...html?talkid=156

Ho delle pre-release dell'SDK della PS3 e l'accesso diretto alle SPE e' garantito sia in assembly sia in un linguaggio ad alto livello.

Infatti il link che hai postato conferma esattamente quello che ho detto io fino ad ora:

The most important functions of the user interface including loading a program binary into an SPU, transferring memory between an SPU program and a Linux user space application and synchronizing the execution. Other challenges are the integration of SPU program execution into existing tools like gdb or oprofile.

Traduco: "Le funzioni piu' importanti dell'interfaccia verso l'utente includono il caricamento di un programma binario nella SPU, il trasferimento della memoria fra un programma nella SPU e lo spazio utente di Linux e la sincronizzazione dell'esecuzione".

Conferma quindi che queste funzioni sono a carico dell'utente e non del sistema operativo, come ho detto: dipendono dall'applicazione e non dal sistema operativo.

Da notare infine il paragrafo finale che toglie ogni dubbio sulla questione:

A model has been proposed to provide an interface that attempts to integrate well into the existing set of Linux system calls and enable software authors to easily integrate the use of SPUs into their own libraries and applications.

... che permettono agli autori del software di integrare l'uso delle SPE (SPU) nelle loro librerire e applicazioni, perche' evidentemente non puo' essere a solo carico del Sistema Operativo. Come ho detto fin dall'inizio: le SPU non vengono nascoste all'utente come affermi tu, ma vengono esposte all'utente per poterle utilizzare attraverso le system calls.

Direi che non c'e' altro da aggiungere a riguardo.

[jappilas]

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..
forse lui si riferiva al fatto che si riesce ad avviare il DOS anche su un P4 o athlon attuale, e che il dos stesso non distingua la macchina dall' AT su cui veniva usato già negli anni 80...

ma in realtà questo accade perchè il p4: da un lato emula le istruzioni x86 a 16 bit, dall' altro la modalità reale
inoltre, cosa fondamentale, i bios moderni continuano a supportare il sistema a memoria base/estesa/espansa, lasciano come opzionale l' attivazione del gate a20, emulato nel chipset o via SW...
chipset che dal canto suo, va secondo me pensato come l' implementazione della "piattaforma" con il suo modello I/O, gli IRQ, eccetera...e la piattaforma che appunto costituisce, allo stato attuale è tutto sommato elegante (praticamente tutti i nuovi chipset di intel via, sis, sono "legacy free" basati su architetture crossbar...) e poco (magari l' interrupt controller e l' 8042 per la tastiera) ha a che vedere con gli antichi AT e le limitazioni ad esso imposte
in pratica, se MadRat volesse una piattaforma "nuova" e "fresca" gli basterebbe prendere un pc normale e installargli un firmware di tipo EFI: di suo questo è sostanzialmente legacy free essendo stato progettato da zero con l' obiettivo , tra l' altro, del cross-platforming (ia32, itanium, arm)... nella versione x86 è previsto un modulo di retrocompatibilità che implementi le chiamate del BIOS classico: non installando tale modulo ci lascia alle spalle la compatibilità DOS (ed anche la VGA col suo bios, infatti le specifiche EFI includono anche quelle per un nuovo tipo di firmware destinato alle schede di espansione come schede grafiche, controller scsi/raid, rete ecc)

Hai mai programmato qualcosa di analogo ad uno stream processor?

io no, in effetti non ho idea di cosa implichi e sono estremamente curioso :)

[fantoibed]

Si', ho riletto. Dice esattamente quello che ho detto io, non parla di code morphing o nulla di analogo (ovviamente perche' chi ha scritto quell'articolo e' molto preparato e non lo scriverebbe mai).

Io ho parlato di code morphing riferendomi a Transmeta non a Cell.

Scusami, no. Gli algoritmi per scaricare e ricaricare la memoria privata dipendono dall'applicazione. Un filtro digitale carica il kernel del filtro e blocchi di dati, un compilatore caricherebbe una parte del sorgente e la tabella dei simboli, un grafo caricherebbe i nodi adiacenti. Dipende dall'applicazione.
Hai mai programmato qualcosa di analogo ad uno stream processor?

In effetti no.

E' tutto un probabilmente, sono piu' speranza che realta', al momento non e' neppure previsto nulla di simile. Pura fantascienza, per quanto ne so avrebbe la stessa valenza dire che l'analisi del codice verra' fatta da un alieno per via telepatica.
E come spiego dopo analizzare il codice mentre viene eseguito richiede istruzioni e tempo e sarebbe altamente inefficiente.

E' una congettura, ma l'alleanza Sony/Transmeta e le similitudini di fondo tra le due tipologie di CPU (entrambe basate su in-order VLIW core) lascia ampio spazio a queste idee.
http://arstechnica.com/news.ars/post/20050401-4765.html
D'altra parte pare ormai certa l'implementazione di LongRun2 (parte integrante del layer di code morphing degli Efficeon)

No. Si sta riferendo ai compilatori, la parola just in time non appare in tutto il testo.

Se non è riferito ai compilatori, il “just in time” prefetching a chi sarebbe riferito?

Neppure il termine code morphing. Sono interpretazioni tue (sbagliate).

Non ho mai parlato di "code morphing" sui Cell, solo sui Transmeta. Casomai ho detto "qualcosa di analogo"...

Per altro, anche se fosse just in time (che non e' un compilatore ma e' un traduttore), la traduzione del metodo viene effettuata ovviamente alla sua prima esecuzione, non ad ogni sua esecuzione, cosa che sarebbe oltremodo inefficiente.

Perché la traduzione dovrebbe essere effettuata solo alla prima esecuzione?
Nei Transmeta non mi pare sia così...

Ho delle pre-release dell'SDK della PS3 e l'accesso diretto alle SPE e' garantito sia in assembly sia in un linguaggio ad alto livello.

Non ho a disposizione tali sdk quindi non posso che credere sulla parola.

Infatti il link che hai postato conferma esattamente quello che ho detto io fino ad ora:

Traduco: "Le funzioni piu' importanti dell'interfaccia verso l'utente includono il caricamento di un programma binario nella SPU, il trasferimento della memoria fra un programma nella SPU e lo spazio utente di Linux e la sincronizzazione dell'esecuzione".

Conferma quindi che queste funzioni sono a carico dell'utente e non del sistema operativo, come ho detto: dipendono dall'applicazione e non dal sistema operativo.

Hai tradotto giusto ma parafrasato male. L'interfaccia verso l'utente (come lo sono le API di windows) è una parte del sistema operativo e si prende carico lei del caricamento..., del trasferimento della memoria ... e della sincronizzazione dell'esecuzione. Se tutto ciò dovesse essere fatto dall'utente perché avrebbero creato un'interfaccia apposita?

Da notare infine il paragrafo finale che toglie ogni dubbio sulla questione:

... che permettono agli autori del software di integrare l'uso delle SPE (SPU) nelle loro librerire e applicazioni, perche' evidentemente non puo' essere a solo carico del Sistema Operativo. Come ho detto fin dall'inizio: le SPU non vengono nascoste all'utente come affermi tu, ma vengono esposte all'utente per poterle utilizzare attraverso le system calls.

Direi che non c'e' altro da aggiungere a riguardo.

Sì, ma non hanno certo scritto, come affermi tu, che tutte le singole operazioni sulle SPE devono essere effettuate "a manina". Esiste un'interfaccia dell'OS verso l'utente, esistono delle syscalls, ecc... Il fatto che il programmatore possa integrare l'uso delle SPE nel suo software in modo indiretto (basandosi sulle interfacce (API) del sistema operativo) o in modo diretto (programmandosele in asm) non cambia le carte in tavola...

[fek]

Se non è riferito ai compilatori, il “just in time” prefetching a chi sarebbe riferito?

E' riferito al fatto che tutti gli accessi a memoria avvengono da e verso una memoria privata che ha latenze di prefetching dei dati fisse, mentre le latenze di una cache dipendono dal fatto che il dato sia in cache o meno. Questo permette al compilatore di avere una buona idea delle latenze al momento della compilazione del codice e puo' fare un buon lavoro (non ottimo) di schedulazione delle istruzioni.



Non ho mai parlato di "code morphing" sui Cell, solo sui Transmeta. Casomai ho detto "qualcosa di analogo"...

E qualcosa di analogo al code morphing che cos'e'?



Perché la traduzione dovrebbe essere effettuata solo alla prima esecuzione?
Nei Transmeta non mi pare sia così...

Perche' i JIT compiler funzionano cosi'.



Hai tradotto giusto ma parafrasato male. L'interfaccia verso l'utente (come lo sono le API di windows) è una parte del sistema operativo e si prende carico lei del caricamento..., del trasferimento della memoria ... e della sincronizzazione dell'esecuzione. Se tutto ciò dovesse essere fatto dall'utente perché avrebbero creato un'interfaccia apposita?

No, l'API si prende carico di esporre il caricamento e la sincronizzazione al programmatore, non decide che cosa caricare e quando caricare al posto del programmatore. Sarebbe come dire che le D3D esponendo l'API per renderizzare i triangoli si prende carico anche di decidere quali triangoli renderizzare e quando.
Il testo e' piuttosto chiaro su questo punto, impossibile fraintenderlo (se non volutamente).

Lo riquoto:

A model has been proposed to provide an interface that attempts to integrate well into the existing set of Linux system calls and enable software authors to easily integrate the use of SPUs into their own libraries and applications.

Il termine interfaccia e' piuttosto chiaro ed impossibile da fraintendere per chiunque ha programmato. API = Application Programming Interface.

Sì, ma non hanno certo scritto, come affermi tu, che tutte le singole operazioni sulle SPE devono essere effettuate "a manina".

Non ho mai affermato una cosa simile.
Ho affermato che il modello di programmazione del Cell prevede che il programmatore decide e programma a manina che cosa e quando caricare in memoria privata ed eseguire, un modello che funziona bene per calcoli in streaming, e non e' trasparente come il funzionamento di una cache che decide quando e che cosa caricare in memoria veloce in maniera del tutto trasparente al programmatore, cosa che funziona bene per applicazioni general purpose, ma non per applicazioni in streaming.

Mai affermato nulla di diverso da questo.

Come ti ho detto, il testo quotato e' conclusivo sull'argomento, non ci sarebbe bisogno di aggiungere altro sarebbe solo noioso spaccare il capello e rendere questa discussione totalmente illeggibile. Possiamo muoverci su un altro punto piu' interessante.

[fek]

io no, in effetti non ho idea di cosa implichi e sono estremamente curioso :)

L'idea e' avere un flusso di dati in entrata, eseguire una qualche trasformazione su di esso e scrivere un flusso di dati in uscita. In una situazione di questo tipo una cache e' perfettamente inutile perche' si basa sul principio di localita' degli accessi alla memoria (se ho letto in una zona X della memoria, presumibilmente continuero' a leggere quella zona anche in futuro).

Se entra un flusso di dati, se ho letto in una zona X, in futuro leggero' presumibilmente in una zona X + 1, poi X + 2, X + n e cosi' via. Una cache continuerebbe a caricare in memoria porzioni di memoria che non verranno mai usate.

In questa situazione e' piu' conveniente dividere il flusso in ingresso in blocchi, caricare il blocco di dati A in memoria privata, iniziare l'esecuzione del programma sul blocco di dati e in contemporanea caricare il blocco A + 1 in memoria parallelamente. In questa situazione lavori sempre su un blocco mentre carichi in memoria il successivo su cui lavorerai dopo. Il Cell aiuta il compilatore per il fatto che questa memoria privata sulla quale ogni SPE lavora ha una latenza di accesso fissa che non cambia (mi sembra 3 cicli), quindi come ho detto il compilatore e' in grado di usare le latenze per schedulare altre istruzioni non legate a quell'accesso a memoria.

[fantoibed]

E' riferito al fatto che tutti gli accessi a memoria avvengono da e verso una memoria privata che ha latenze di prefetching dei dati fisse, mentre le latenze di una cache dipendono dal fatto che il dato sia in cache o meno. Questo permette al compilatore di avere una buona idea delle latenze al momento della compilazione del codice e puo' fare un buon lavoro (non ottimo) di schedulazione delle istruzioni.

Ok. Ora mi è un po' più chiaro.

E qualcosa di analogo al code morphing che cos'e'?

Un layer software che si frapponga tra l'hardware e le applicazioni.

No, l'API si prende carico di esporre il caricamento e la sincronizzazione al programmatore, non decide che cosa caricare e quando caricare al posto del programmatore. Sarebbe come dire che le D3D esponendo l'API per renderizzare i triangoli si prende carico anche di decidere quali triangoli renderizzare e quando.

ok.

Ho affermato che il modello di programmazione del Cell prevede che il programmatore decide e programma a manina che cosa e quando caricare in memoria privata ed eseguire, un modello che funziona bene per calcoli in streaming, e non e' trasparente come il funzionamento di una cache che decide quando e che cosa caricare in memoria veloce in maniera del tutto trasparente al programmatore, cosa che funziona bene per applicazioni general purpose, ma non per applicazioni in streaming.

Ok. Ma a prescidere dalle congetture sulla possibile scelta o meno da parte di Sony/IBM/Toshiba di creare un layer di emulazione software, non pensi che creandolo si potrebbe emulare un'architettura diversa in modo efficiente con Cell? D'altra parte è il principio cardine dei processori Transmeta che sono anch'essi VLIW in-order core! Certamente le prestazioni dei transmeta non sono mai state esaltanti, ma si è già parlato dei limiti dovuti alla scelta di tenere in RAM il codice che implementa le funzioni di controllo a cui conseguono problemi di latenza, e poi le prestazioni non sono mai state l'obiettivo primario di Transmeta, visto che ha puntato tutto sulla riduzione dei consumi.
La similitudine con le cpu transmeta nell'idea di fondo e l'elevatissimo numero di istruzioni che Cell è in grado di eseguire per ogni ciclo di clock su registri SIMD mi fa pensare a Cell come una cpu in grado di rendere il massimo come emulatore di una CPU general purpouse.

Possiamo muoverci su un altro punto piu' interessante.

Ok, proponi. Mi hai già chiarito diversi dubbi e la discussione è già interessante così anche se non c'entra molto con 486 e motorola...

[fek]

Un layer software che si frapponga tra l'hardware e le applicazioni.


E questo layer che cosa dovrebbe fare? Analizzare continuamente il flusso di istruzioni e riordinarlo, il lavoro che fa un'architettura OOO e la cosa ovviamente consuma cicli di clock, tanto vale farlo in software per applicazioni general purpose. Mentre per uno streaming processor e' giustissimo non farlo proprio, perche' non serve.


Ok. Ma a prescidere dalle congetture sulla possibile scelta o meno da parte di Sony/IBM/Toshiba di creare un layer di emulazione software, non pensi che creandolo si potrebbe emulare un'architettura diversa in modo efficiente con Cell?


No. Credo sarebbe altamente inefficiente.

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

[fantoibed]

E questo layer che cosa dovrebbe fare? Analizzare continuamente il flusso di istruzioni e riordinarlo, il lavoro che fa un'architettura OOO e la cosa ovviamente consuma cicli di clock, tanto vale farlo in software per applicazioni general purpose. Mentre per uno streaming processor e' giustissimo non farlo proprio, perche' non serve.

In un'architettura come quella di Cell il rischio è quello di sprecare unità di esecuzione non cicli di clock. Quel layer potrebbe preoccuparsi di parallelizzare threads e istruzioni, rinominare i registri, ecc... Con 8 unità di esecuzione il problema è quello di sfruttarle tutte, non di sprecare qualche ciclo di clock su una delle 8...

D'altra parte il minikernel contenuto nelle SPE potrebbe occuparsi anche di questo...
http://research.scea.com/research/html/CellGDC05/26.html ..e seguenti

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

Boh, probabilmente hai ragione, ma non sono molto convinto...
Per ora si sa che la ps3 supporterà i giochi della ps1 e ps2 e che la stessa Sony parla di Virtual Machine (JIT) all'interno delle SPE:
http://research.scea.com/research/html/CellGDC05/51.html

[fek]

In un'architettura come quella di Cell il rischio è quello di sprecare unità di esecuzione non cicli di clock. Quel layer potrebbe preoccuparsi di parallelizzare threads e istruzioni, rinominare i registri, ecc... Con 8 unità di esecuzione il problema è quello di sfruttarle tutte, non di sprecare qualche ciclo di clock su una delle 8...

Ma c'e' solo un'unita' che agisce da coordinate ed e' su quella che esegui le applicazione general purpose ed e' su quella che non devi sprecare cicli di clock perche' e' gia' lenta di suo.

A meno che tu non voglia implementare un algoritmo di ricerca in un grafo su una SPE caricando e scaricando parti del grafo dalla memoria privata ad ogni accesso. Oddio, e' teoricamente possibile, quando esce provaci e soprattutto prova a farlo andare veloce :)

Il problema non e' farcelo girare un algoritmo, il problema e' farcelo girare velocemente, o meglio altrettanto velocemente di come girerebbe su una CPU OOO a parti numero di transistor. Teoricamente una GPU e' perfettamente in grado di compilare un programma in C++. Prova a implementarlo pero'.

Sony parla di Virtual Machine (JIT) all'interno delle SPE:
http://research.scea.com/research/html/CellGDC05/51.html

"Will be". Sony parlava anche di far girare Toy Story in tempo reale sulla PS2. Finche' parlano...

[fantoibed]

Ma c'e' solo un'unita' che agisce da coordinate ed e' su quella che esegui le applicazione general purpose ed e' su quella che non devi sprecare cicli di clock perche' e' gia' lenta di suo.

Sono le SPE che caricano dalla memoria i propri job, li eseguono e salvano l'output in memoria ed eseguono il load/store molto più velocemente di quanto non possa fare la PPU.

A meno che tu non voglia implementare un algoritmo di ricerca in un grafo su una SPE caricando e scaricando parti del grafo dalla memoria privata ad ogni accesso. Oddio, e' teoricamente possibile, quando esce provaci e soprattutto prova a farlo andare veloce :)

Non è necessario. Le SPE possono accedere direttamente alla RAM.

Il problema non e' farcelo girare un algoritmo, il problema e' farcelo girare velocemente, o meglio altrettanto velocemente di come girerebbe su una CPU OOO a parti numero di transistor. Teoricamente una GPU e' perfettamente in grado di compilare un programma in C++. Prova a implementarlo pero'.

Esistono tecniche apposite per la gestione dei grafi sfruttando architetture parallele e SIMD.
http://citeseer.ist.psu.edu/hsu95implementation.html
http://portal.acm.org/citation.cfm?id=131274
http://portal.acm.org/citation.cfm?id=148046
http://ad.informatik.uni-freiburg.de/lehre/ss02/paa/vorlesung-uebungen/download/
....

[fek]

Sono le SPE che caricano dalla memoria i propri job, li eseguono e salvano l'output in memoria ed eseguono il load/store molto più velocemente di quanto non possa fare la PPU.


Ma i job devono essere coordinati dalla PPU.


Non è necessario. Le SPE possono accedere direttamente alla RAM.

Molto lentamente e non e' piu' possibile sfruttare le latenze fisse.


Esistono tecniche apposite per la gestione dei grafi sfruttando architetture parallele e SIMD.


Esistono anche tecniche per implementare query di un database nella GPU.

Il problema non e' l'esistenza o meno delle tecniche, esistono; il problema e' inerente all'accedere casualmente un largo working set, cosa che le SPE non fanno in maniera efficiente. Ne parlammo gia' tempo fa.

[TNR Staff]

C'ho capito pochetto :D,ma per quel che è la mia esperienza,vado particolarmente a braccetto con fek.

Quando ho letto un annetto fa che qualcuno voleva far eseguire ad una GPU delle applicazioni general purpose,mi è venuto da ridere :rolleyes:

Quando poi ho letto i commenti degli utenti mi sono proprio capottato,è impensabile far eseguire un lavoro del genere ad una GPU,avrebbe prestazioni ridicole.

La stessa cosa imho vale per il Cell,è stato pensato per altri scopi,cercare di mettere delle "vie di mezzo" rallenta solo le cose (soprattutto quando le "vie di mezzo" sono software),anche perchè alla fine qualcuno deve pur elaborarle,a quel punto tanto vale affiancarci un altro processore,no? ;)

Mi ricordo che già all'uscita delle istruzioni MMX nei Pentium si parlava di miracoli,miracoli che non ho visto (si parlava di spendere centinaia di migliaia di lire per un mmx,che sarebbe stato usato per "emulare" (male) una scheda audio da 30.000 lire)

Imho l'unica è aspettare,come ha detto fek secondo quanto disse la Sony,la ps2 doveva far girare Toy Story....l'unico Toy Story che gira su ps2 è il film,e quello gira pure su un cessoso lettore dvd :D

[fek]

Riporto un post interessante di un tipo che lavora all'Activision e sta studiando il Cell su dei prototipi speditigli da Sony, a quanto ho capito.


When a decision is made in a processor (an if statement) the PC (Program counter) often has to jump to a separate section of the code returning later to the commmon code. This interupts the caching of the instructions as the processor does NOT know where the code is going to jump as this is more often than not data dependant. Modern CPU's have a method they use the predict which branch will be taken. Branch prediction is extremely complex and I won't even try to explain it here BUT I can say that it often hides the caching issues I mentioned. A branch miss results in ALL the instruction cache being flushed and the cpu then starts reading from its new location... X360 HAS branch prediction on ALL its cores thus ofimes it avoids this flush. Ps3 has it only on the PPE - the spe's have ZERO branch prediction but CAN be given hints by the programmer as to which branch might be taken... this is NOT as fast as full branch prediction AND it takes longer to program. Code can be designed around this problem and no doubt it WILL be .... but it takes longer.

Futher - the spe's rely upon a LOCAL area of memory (256Kb) to store both the data they use during calculations AND the resuts of said calculations. This data is streamed in by DMA as and when needed and thus needs to be controlled either by itself or the main CPU the DMA is HEAVILY relied upon but AFAIK can only process one request at a time albeit at a VERY fast rate. Now... the DMA reads from a memory address a set number of bytes, each addres+numbytes is a single request.... consider accessing 1,000 vertices... they would normally be stored linearly in memory thus a SINGLE dma request would be used. If you're following me then you know where I'm going... consider the SPE accessing data from 100 different memory addresses in a NON linear fashion; random. Each access would represent a NEW dma, more DMA requests == further delays for ALL spe's.

There is an area of memory that is shared between the SPE's so the above example IS a worst case scenario... but like many things on the cell.. this shared memory is non-trivial and is small thus requiring manangement;more programming.

3. Cell is VERY good with large datasets requiring linear access and having a relatively simple code pathway - lighting, vertex transform, A* pathing (if designed properly), Character skinning, texture processing, animation. However to get the most out of it each will require its own specific handling and design around the SPE limitations and DMA request optimisation.

4. Information on RSX is sketchy at best... they have said 100B shader ops but haven't told us much else. It will be fast, it will be able to run most if not all the things that the ATI part in X360 will run. It DOES NOT use the same language - more work required.

5 X360's CPU == 240 Gflop with 1 thread per core, Ps3 CPU == 218 Gflop - TOTAL when you ADD the 2 threads running on the PPE... if we take the same standpoint as sony.... X360's CPU is 480Gflops... thats >2XPs3.... we just need the numbers on the GFX Cards."

"
note - "IF we take the same standpoint as Sony" in that - Sony in their comments regarding the STATS on the cell HAVE ADDED THE NUMBERS across the board in order to reach the 2.18 TFLop, they have added 2 threads on the ppe and dual issue on teh spe's.... it was MEANT to show people what the x360 numbers come out to WHEN we use the same "technique" as sony.

and - you say that it shouldn't be much more difficult than ps2 - hmm.. that puts MOST things at around 5x programming time over x360 - thanks for backing me up.

regarding branch prediction NOT being an issue - go to the cell docs IF you have them (anyone else who has them can back me up here)

/cell/0_3_0/documents/hardware/BE-Overview_e.pdf
in that pdf go to SPE->SPU Performance Characteristics and READ the section on BRANCH PREDICITION AND WHY ITS IMPORTANT.


Dice piu' o meno le stesse cose che ho detto, ma in maniera decisamente piu' corretta ed approfondita di quanto ho fatto io.

[jappilas]

MOLTO interessante... e mi ha tolto una perplessità su cui stavo per chiederti lumi...:)

[fantoibed]

Io trovo più interessante questi:
http://www.research.ibm.com/people/m/mikeg/papers/2002_wced.pdf
http://www.research.ibm.com/people/m/mikeg/papers/2001_tc.pdf
http://www.research.ibm.com/vliw/isca31/Advances%20and%20future%20challenges%20in%20binary%20translation%20and%20optimization.pdf

...Dove vengono mostrati i vantaggi di una traduzione e ottimizzazione dinamica via software su architetture in-order rispetto ad un branch prediction hardware su architetture OOO.

L'autore non è un tizio dell'Activision ma:
http://www.research.ibm.com/people/m/mikeg/
Dr. Gschwind is one of the originators of the STI CELL Broadband Processor Architecture and was a member of the joint architecture exploration and definition team. He was also the leading architect of the SPU architecture and the instigator of its compiled code SIMD focus. Dr. Gschwind was the developer of the first compiler targeting the BPA. His leadership and technical contributions to the S/T/I project were recognized as IBM Research Achievement Award.

Dr. Gschwind has also been a leading contributor to future PowerPC enhancements used by a Microsoft and a variety of IBM OEM customers and one of the lead architects for the BOA Binary Translation and Optimzation Architecture, an IBM PowerPC implementation based on advanced dynamic compilation techniques.

[MadRat]

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera...............


....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?


Concordo con te in quasi tutto.. L'unica cosa che non ritengo logica e' l'apertura di un thread dedicato al cell.. perche'?? perche' sono d'accordo con te su cio' che hai detto!! e dunque ritengo che ci siano troppe poche informazioni al suo riguardo e troppi inutili thread gia' aperti.

[MadRat]

E questo layer che cosa dovrebbe fare? Analizzare

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

Il cell non e' mai stato dichiarato come streaming processor. Almeno non mi risulta. Forse qualcuno (forse pazzo) lo considera anche in grado di operazioni GP, magari con un'implemetazione software simile a quella ipotizzata da fantoibed.
Chi vivra' vedra'.

[fantoibed]

Concordo con te in quasi tutto.. L'unica cosa che non ritengo logica e' l'apertura di un thread dedicato al cell.. perche'?? perche' sono d'accordo con te su cio' che hai detto!! e dunque ritengo che ci siano troppe poche informazioni al suo riguardo e troppi inutili thread gia' aperti.

Riguardo al fatto che la discussione su Cell non è inerente il topic hai ragione al 100%, ma ormai la frittata è fatta....

Riguardo al sostegno morale a chi sostiene l'una o l'altra tesi (non sto accusando te, ma parlo in generale), trovo più stimolante confrontarmi con uno che la pensa diversamente da me piuttosto con chi mi da ragione. Solo con un confronto (purché sia una discussione civile come questa senza provocazioni, battutine, offese, ecc...) vengono alla luce gli errori o le imperfezioni dell'una e dell'altra tesi e solo così si sviscera l'argomento.

[MadRat]

Ora volessero perdonarmi lor signori, ma io riprenderei momentaneamente alcune argomentazioni relative al thread!! :p Poi parliamo anche di pizza, non ho problemi!! (a me piace come la fanno a napoli. :D)

Anche se metti quel floppy dentro un Mac o un'Amiga, viene letto. Non mi risulta che un Mac sia cosi' simile ad PC degli anni '80 :)

Fai un altro esempio :)



Ad un ST non succedeva nemmeno nell'85. con adeguati software o SO multitasking, l'accesso al floppy era completamente trasparente.
_________________________________-


Che conferma quello che ho detto sul 68000 e sul 68008: che l'architettura è a 32 bit, non a 16 né a 16/32 bit, come sostenevi tu.

E' una TUA considerazione, non un criterio OGGETTIVO.
.......

Sì, ma è pure sbagliato, come ho già detto: i 680x0 sono fra i processori più semplici da programmare (lasciando perdere i dettagli specifici, che comunque si ritrovano in tutte le architetture), e proprio per questo chi ha avuto modo di lavorarci ne conserva ancora un gran bel ricordo.

Vedi sopra.

Comunque se qualcuno si passerà il capriccio di emulare il Falcon su questi schifosissimi PC, magari potrai finalmente metterlo da parte e continuare a non sbagliare una nota di un 128esimo... :p

Decisamente ora non ho tutto il tempo necessario a risponderti passo passo. Tuttavia voglio precisare che hai travisato molte cose..

In primo luogo, l'idea che i computer basati su 68000 fossero considerato dei 16 bit (e da alcuni 16/32) e' cosi' mia e personale che il nome ST vuol dire proprio 16/32, (come TT significa 32/32) e le riviste del tempo che li trattavano, portavano come sottotitolo riferimenti al mondo informatico a 16bit..
Ti risparmio decine e decine di siti nei quali si parli di 68000, ST, Amiga, Mac e storia dei computer e processori, nei quali si parla di generazione di computer a 16bit. Poi se ci tieni proprio ti do un po' di link, ma puoi anche cercare da solo su google.


L'emulatore dell'ST su amiga, era un simulatore di desktop limitato nelle funzioni ed incapace anche di far scorrere un mouse con fluidita'. L'hardware dell'amiga era piu' massiccio, non piu' complesso. Molto meno armonioso e bilanciato di quello ST.. Del resto sono nati dalle stesse mani e sono solo due interpretazioni differenti di comuter simili.

Che l'emulatore mac su st girasse a quella velocita' e' risaputo da chi ha usato quelle macchine, addirittura fecero pure un'interfaccia esterna contenente le rom del mac e vendettero (vendemmo, visto che eravamo centro atari ed l'assistenza ufficiale assieme alla sede di milano e torino) molti atari a tutti coloro i quali fossero indecisi tra uno (mac) e l'altro, inquanto la compatibilita' era totale, la velocita' superiore e la risoluzione video anche. Questo e' indice di spueriorita'. Nel caso dell'amiga io parlerei di diversita'.

Seguiti a parlarmi di velocita' di trasmissione della midi.. Il 68000 dell'st programmava solamente l'hardware dedicato alla gestione dma dell'interfaccia midi.. Hai le idee un po' confuse al riguardo, e' ovvio che una simile velocita' di trasmissione sia gestibile con poche risorse. Forse non si tratta solo di quello ;). E NESSUN programma midi per quelle macchine soffriva di scarsa precisione o rallentamenti, non credo proprio che fossero tutti in assembler!!

Poi mi dici che un falcon senza l'hardware dedicato non saprebbe fare nulla.. IL FALCON SENZA HW DEDICATO NON ESISTE. E' nato superiore/migliore, come se nascesse oggi un computer nuovo, sarebbe superiore/migliore anche (e soprattutto) concettualmente a qualunue architettura gia' inventata.

Seguiti a sostenere che io ritenga i pc odierni simili ad un 386.. non e' vero, so che hanno poco e nulla a che spartire con loro. Ritengo solamente che siano partiti dalla piu' sbagliata delle basi informatiche.

Se non capisci perche' abbia parlato di schede video, te lo rispiego in una riga.
Perche' hanno portato i giochi a 256 colori al grande pubblico, diventando cosi' commerciali e soppiantanto amiga ed st. (grazie a taiwan e non certo alla superiorita' del mondo pc-comp).

Oggi un 68000 farebbe ridere come architettura quanto un 2/386.. Un evoluzione di questo (68000) sarebbe notevole e porterebbe con se i propri "difetti, nella stessa misura rilevata con gli x86.
Come capisci bene e ci tieni a precisare, che i processori di oggi poco c'entrino con un 386, dovresti intuire che la stessa qualita' evolutiva avrebbe coinvolto qualunque altra cpu al posto delle x86, ma come giustamente dici tu, sono solo dei se.

Metto un'ultima piccola aggiunta riguardo ad Halo..
Questo non dimostra cio' che sostieni tu, dimostra soltanto che (come sostengo da sempre) un hw dedicato e non soggetto a cambiamenti sia piu' "spremibile" ed a parita' di HW una console rispetto ad un pc e' piu' efficiente. Da qui i problemi a far girare Halo decentemente su pc di faccia bassa.. molto bassa direi.Per non parlare di doom3!!. Politica per altro anticonsumistica, perche' credo che comuqnue piu' o meno TUTTI i giochi principali per pc, potrebbero girare meglio se affinati nella programmazine.
Poco tempo fa lessi un commento di non ricordo chi, che analizzava il codice di unreal (e o di far cry), mostrando la quantita' di righe inuliti e pesanti presenti.

Comunque se non erro prima sostenevi che il 68000 manderebbe al manicomio chiunque ed ora sostieni che sia piu' semplice di un x86. Forse mi e' sfuggito qualcosa.
Non puoi dire prima una cosa e poi un'altra diversa, altrimenti dimostri di non avere adeguate conoscenze o di non avere un'idea precisa di ciò di cui stai parlando. (questa frase l'ho gia' sentita..)


Dici che il dsp 56001 sia in grado di eseguire instruzioni gp.. non piu' di un qualunque altro dsp (cell docet).

Per quanto riguarda la corsa alle frequenze di AMD, vorrei farti notare come sia rimasta intorno ai 2ghz per quasi due anni.

P.S.
Fallo tu un emulatore del Falcon se pensi sia possibile. :) Per ora non ci riesce nessuno ed in ogni caso avrebbe gli stessi rallentamenti del vst in fase di forti carichi ide.
Comuqnue non sarebbe una soluzione per me, perche' il cubase audio non e' mai stato sprotetto bene, le versioni pirata crashano che e' una bellezza ed il mio ha la chiave di protezione hardware!! :doh: :cry:

[MadRat]

Riguardo al fatto che la discussione su Cell non è inerente il topic hai ragione al 100%, ma ormai la frittata è fatta....

Riguardo al sostegno morale a chi sostiene l'una o l'altra tesi (non sto accusando te, ma parlo in generale), trovo più stimolante confrontarmi con uno che la pensa diversamente da me piuttosto con chi mi da ragione. Solo con un confronto (purché sia una discussione civile come questa senza provocazioni, battutine, offese, ecc...) vengono alla luce gli errori o le imperfezioni dell'una e dell'altra tesi e solo così si sviscera l'argomento.

Ragionissima.. Ma per me qui si puo' parlare tranquillamente anche di cell.. ovviamente tenendo presente che nessuno dei sottoscritti abbia ancora mai avuto l'onore di programmarlo e/o utilizzarlo. Insomma, mi irrita un po' l'arroganza di chi sostiene con estrema fermezza delle tesi riguardanti l'efficacia di un qualcosa che non ha mai provato.

Se ne puo' parlare facendo ipotesi, illazioni.. non le si puo', pero', porre come punti fissi e pretendere che gli altri ragionino basandosi su di essi.

A parer mio il Cell, se ben programmato distruggera' il trialcore del 360 anche in GP.
Continuo a sostenere che quanto ipotizzato da fantoibed (17-06-2005, 22:09 ) nell'ultima parte del post, sia alquanto probabile, magari e' proprio in base a questo che Sony dichiara grandi capacita' di GP per il Cell.

C'e' da considerare anche, quanto veramente servira' l'utilizzo degli altri core in qualita' di GP-cpu ed ancora non possiamo saperlo.

[fek]

Il cell non e' mai stato dichiarato come streaming processor. Almeno non mi risulta. Forse qualcuno (forse pazzo) lo considera anche in grado di operazioni GP, magari con un'implemetazione software simile a quella ipotizzata da fantoibed.
Chi vivra' vedra'.

Sicuro?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Direttamente dal sito IBM:
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/372E2BE9229AC34987256FC00074A13A

[fek]

L'autore non è un tizio dell'Activision ma:
http://www.research.ibm.com/people/m/mikeg/

E' il tizio che lo ha disegnato, ti pare che avrebbe detto: "No guardate, ho progettato un'architettura in-order che va piu' piano nel general purpose di una out-of-order"? :)

Almeno le parole che ho riportato sono di qualcuno che ha messo le mani sull'hardware e sembra avere un po' di esperienza di programmazione a riguardo.

[fek]

Io trovo più interessante questi:
http://www.research.ibm.com/people/m/mikeg/papers/2002_wced.pdf
http://www.research.ibm.com/people/m/mikeg/papers/2001_tc.pdf
http://www.research.ibm.com/vliw/isca31/Advances%20and%20future%20challenges%20in%20binary%20translation%20and%20optimization.pdf

...Dove vengono mostrati i vantaggi di una traduzione e ottimizzazione dinamica via software su architetture in-order rispetto ad un branch prediction hardware su architetture OOO.


Quegli articoli parlano di compilazione Just In Time, e riportano esplicitamente che la traduzione viene effettuata al momento della prima esecuzione e poi conservata per ammortizzarne il costo. Nessuno nega che sia una buona idea in generale (.NET si basa proprio su quel principio), ma ancora non e' stato dimostrato sul campo che sia piu' efficiente mentre e' dimostrato che lo e' meno. .NET viaggia a circa il 90% dell'efficienza di codice precompilato, perche' soffre dei problemi di cui abbiamo gia' parlato, il fatto che il profilo di esecuzione del codice dipende non solo dal codice eseguito, ma da quando e' eseguito e dai dati sui quali e' eseguito, cosa che nessun compilatore JIT e' in grado di prevedere, ma che solo un'architettura OOO e' in grado di analizzare fino ad un certo punto.

Inoltre non riportano alcun dato pratico, parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare :)

Tanto e' vero che AMD e Intel dicono l'esatto contrario ed esaltano le architetture OOO e fino a questo punto hanno ragione loro, perche' nel campo delle prestazioni General Purpose a parita' di transistor sono al top e si sono lasciati indietro i Power PC. All'atto pratico non c'e' alcuna architettura in-order in circolazione veloce come le architetture out-of-order a parita' di transistor e questo e' l'unico dato che conta.

Ripeto, parlo di applicazioni GP qui

[fek]

A parer mio il Cell, se ben programmato distruggera' il trialcore del 360 anche in GP.

Questo e' decisamene fuori da ogni logica visto che si parla di un solo core GP nel Cell contro 3 core GP nel 360. Per quanto possa pilotare bene Schumacher con una Fiat Punto non andra' mai piu' veloce di un pilota su una Ferrari. E nel GP la differenza fra le due CPU non e' tanto lontana da quella fra una Punto ed una Ferrari.

[fek]

Ok, il paragone Cell/X360 e Punto/Ferrari e' un po' esagerato, ma rende l'idea :)

C'e' un consenso abbastanza diffuso fra gli sviluppatori sul fatto che il Cell abbia un deciso vantaggio sui calcoli in floating point e l'X360 nei calcoli GP.

[fantoibed]

Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III

Inoltre non riportano alcun dato pratico, parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare :)

...Questo è la tua traduzione della parte sopra?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

riportano esplicitamente che la traduzione viene effettuata al momento della prima esecuzione e poi conservata per ammortizzarne il costo...

Con questo di riferisci all'ottimizzatore dinamico?

[fek]

...Questo è la tua traduzione della parte sopra?


Non letterale. Il concetto e' comunque chiaro.


Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Ovviamente una memoria locale non puo' essere un processore.

Con questo di riferisci all'ottimizzatore dinamico?

No, al JIT.

[fantoibed]

Non letterale. Il concetto e' comunque chiaro.

Non è letterale e non è nemmeno una traduzione, direi piuttosto una mistificazione... Chi ha scritto il paper non si è preso la responsabilità di un simile paragone, ma si dice "Transmeta claimed..." e poi "about the same" non significa "va più piano". Se il Pentium-III 500 andasse molto più veloce del Crusoe 667 l'errore sarebbe di Transmeta e non di chi ha scritto quel paper. Dico "se", perché ci sono benchmark che dimostrano che tale affermazione non è poi così campata in aria come vorresti far credere:
http://www.geocities.com/crusoeVpentium3/Comparisons.htm

Ovviamente una memoria locale non puo' essere un processore.

...E soprattutto che si stanno parlando del SPE e non di Cell, quindi nella frase che hai riportato è il SPE ad essere definito "stream processor", non il Cell.

No, al JIT.

Chi se ne frega del jit? Parliamo dell'ottimizzatore/traduttore dinamico!

[fek]

Non è letterale e non è nemmeno una traduzione, direi piuttosto una mistificazione...

Quando ci si mette a sindacare parola per parola per il solo gusto di farlo, per me la discussione finisce. Il concetto era chiaro, nessuna mistificazione.


...E soprattutto che si stanno parlando del SPE e non di Cell, quindi nella frase che hai riportato è il SPE ad essere definito "stream processor", non il Cell.

Le SPE usano l'80% dei transistor del Cell. Anche qui si vuole sindicare parola per parola quando il concetto e' chiaro.


Chi se ne frega del jit? Parliamo dell'ottimizzatore/traduttore dinamico!

No, perche' non esiste. Quei paper parlano solo di JIT. Stai parlando di fantomatica ottimizzazione dinamica da tre pagine, ma e' solo una tua invenzione/speranza della quale non parla nessun altro, si parla sempre e solo di JIT.

Stiamo girando in tondo, per me il discorso e' chiuso. Sicuramente non ne sei convinto, ma a quanto ho capito la tua e' piu' che altro solo una speranza non fondata su alcun dato tecnico visto che hai piu' volte travisato anche cio' che tu stesso hai postato e mi sembra tu stia andando avanti piu' per il gusto di contraddirmi anche sui singoli termini che per vero interesse.

Penso di aver dimostrato i miei punti al di la' di ogni ragionevole dubbio, e tutto quello che hai postato li ha confermati, chiunque laovora ne settore conferma piu' o meno quello che ho scritto, non ritengo necessario aggiungere altro.

Ti lascio l'ultima parola.

[fantoibed]

Quando ci si mette a sindacare parola per parola per il solo gusto di farlo, per me la discussione finisce. Il concetto era chiaro, nessuna mistificazione.

La tua traduzione dice qualcosa di completamente diverso da quello che viene detto nel testo originale. E' proprio il senso del discorso ad essere storpiato e lo sai benissimo.

Le SPE usano l'80% dei transistor del Cell. Anche qui si vuole sindicare parola per parola quando il concetto e' chiaro.

Quindi la mia macchina è solo una scocca con un motore perché questi 2 elementi pesano l'80% del peso complessivo della macchina?

Il Cell dovrebbe avere circa 250milioni di transistor (o giù di lì). Ogni SPE ha 7 milioni di transistor + 14 milioni per la sram locale e anche se fossero di più non è corretto attribuire ad un processore una frase in cui si parla solo di un componente di tale processore.

No, perche' non esiste. Quei paper parlano solo di JIT. Stai parlando di fantomatica ottimizzazione dinamica da tre pagine, ma e' solo una tua invenzione/speranza della quale non parla nessun altro, si parla sempre e solo di JIT.

Certo il titolo del primo documento è "Inherently Lower Complexity Architectures using Dynamic Optimization". Già il titolo è eloquente.
Nelle pagina di "Michael Karl Gschwind" http://www.research.ibm.com/people/m/mikeg/ riportano:
Dynamic compilation. Michael Gschwind is a member of the DAISY group which performed ground-breaking work in the field of binary translation and dynamic optimization. Michael Gschwind has been a leading contributor to BOA, the Binary translation and Optimization Architecture, which was a joint project with IBM Server group.

[MadRat]

Ok, il paragone Cell/X360 e Punto/Ferrari e' un po' esagerato, ma rende l'idea :)

C'e' un consenso abbastanza diffuso fra gli sviluppatori sul fatto che il Cell abbia un deciso vantaggio sui calcoli in floating point e l'X360 nei calcoli GP.


Io non vedo l'ora di vederli all'opera.. c'e' da dire che SICURAMENTE, se non coadiuvato da qualche formula d'utilizzo (tipo quelle ipotizzate qui in precedenza), il Cell perdera' dal punto di vista GP. Vincendo in atri segmenti (FP).
Quello che intendo dire pero', e' che il divario tra la potenza GP del processore del 360 e quella del Cell e' sì notevole, ma assolutamente non si paragona alla differenza che possono fare gli altri core del Cell nei loro segmenti di calcolo. Per tanto a parer mio, le due cpu "quasi" si equivalgano, anche se alle fine direi che siano semplicemente "differenti".
Ritengo che le possibilita' del Cell, previa buona programmazione, potrebbero essere decisamente piu' alte. Mi riferisco al fatto che, se da una parte e' ipotizzabile l'utilizzo GP dei core del Cell, non lo e' altrettanto un eventuale utilizzo efficace del trialcore come DSP.
Spero di esser stato chiaro.
Insomma, credo che il Cell sia piu' legato ad un buon sotware, ma decisamente piu' flessibile e potente.

[MadRat]

Sicuro?

A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Direttamente dal sito IBM:
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/372E2BE9229AC34987256FC00074A13A

Questo dimostra solo che il cel sia un ottimo stream processor.. Non vedo dichiarazioni cosi' palesi.
Io non ho mai detto che non sia un potente stream processor.

[^TiGeRShArK^]

Questo dimostra solo che il cel sia un ottimo stream processor.. Non vedo dichiarazioni cosi' palesi.
Io non ho mai detto che non sia un potente stream processor.
credo si riferisse al fatto ke dicevi ke il cell non è uno stream processor....

[^TiGeRShArK^]

x quanto riguarda il crusoe e il code-morphing:

The Crusoe chips that were announced yesterday translate x86 instructions into 128-bit Very Long Instruction Word (VLIW) instructions that can be run directly on the Crusoe chip. This translation is handled by software called "Code Morphing" software. Transmeta estimates that the Code Morphing software is 3/4 of the logic behind the Crusoe, with the other 1/4 being the hardware chip itself.

The Crusoe chips can go without any register renamers, reorder buffers, and stack arithmetic units since the Code Morphing software takes care of all of this stuff. Without this excess baggage, the chips themselves can be smaller, feature less transistors, and run cooler than traditional mobile chips such as the Intel mobile Pentium II and Pentium III. As you would guess, the Crusoe processors are aimed specifically at mobile applications. One flavor is aimed at Internet appliances, and the other is aimed at mini-notebooks.

So, that's all well and good, but what is the meaning of "software?" I mean, we all know what software is: code that runs on a processor. What Transmeta didn't make a big point of is that the Crusoe chips require a bootable ROM chip on the motherboard. This ROM chip holds the Code Morphing software. When you turn on your laptop or other device with a Crusoe chip in it, the ROM chip loads up the Code Morphing software into memory and Crusoe runs it before doing anything else. Then, whenever a call is made to the processor, the software intercepts it and translates it into code that runs natively on the Crusoe. The native Crusoe instructions are stored in a 16MB cache that the x86 OS is forbidden from accessing. So, if the proper ROM chip is in place for running x86 instructions, you can install Linux, Windows, BeOS, or whatever OS you want on a Crusoe-based system.

Il "software" x il code morphing è dunque contenuto nella ROM.
Non mi risulta ke nel CELL sia stato utilizzato un qualsiasi sistema anke lontanamente paragonabile a quello utilizzato nel Crusoe x la traduzione al volo del codice x86 in codice VLIW.

[Athlon]

Messa in rilievo perche' a mio parere si tratta di una bella discussione di quelle che non si vedono molto di frequente ai giorni nostri.


P.S. per un attimo mi e' sembrato di essere tornato negli anni 90 :cry: :cry: :cry: :cry:

[fantoibed]

Il "software" x il code morphing è dunque contenuto nella ROM.
Non mi risulta ke nel CELL sia stato utilizzato un qualsiasi sistema anke lontanamente paragonabile a quello utilizzato nel Crusoe x la traduzione al volo del codice x86 in codice VLIW.

E' più probabile che venga implementato un sistema analogo ma con con traduzione di codice PowerPC-to-PowerPC come avviene nei processori sperimentali della IBM "BOA" e "DAISY" sviluppati dallo stesso team che sta sviluppando Cell. Da http://www.research.ibm.com/people/m/mikeg/papers/2002_wced.pdf

[...]While BOA uses special-purpose hardware support in the form of the checkpointing and rollback facilities for the architecting of precise exceptions, the DAISY uses in-order software-managed commit operations. This allows to take exceptions without rolling back the processor state to the previous checkpoint by determining the corresponding original program point for any optimized trace fragment.
To ensure correct correspondence of the program state between the optimized code fragments and the original program, DAISY has to compute the entire state and commit it in original program order. Because DAISY was targeted at wide high-performance VLIW architectures [27], this did not result in performance degradation. Later work extends this approach to allow for the elimination of dead state during the optimization of trace fragments [28, 29], and thus allows to perform more aggressive optimization of trace fragments on architectures with more limited issue bandwidth, such as for PowerPC-to-PowerPC dynamic optimization.
The present approach is different from the DIF approach of Nair and Hopkins [30], and trace processors [31]. By choosing to implement the trace formation and scheduling in software, BOA can generate perform more extensive profiling to determine which trace paths are frequently executed, assemble longer traces, perform more aggressive optimizations and generate better schedules. Also, the underlying hardware only has to support a single execution mode whereas DIF and trace processors require almost three machines: a frontend processor used when executing normal code which has not been collected and preprocessed, a system for preparing, cracking and pre-scheduling the traces to be stored in the trace cache, and the execution engine optimized for executing code from the trace cache.
Our trace-based dynamic optimization is related to the idea of optimizing for the most likely execution path described by Fisher [32]. Trace scheduling requires to estimate the likelihood of a given path being executed and thus requires information about the runtime behavior of programs. Modern compilation systems attempt to address this issue by collecting execution profiles to be used by the compiler. Alas, this profile-directed feedback approach does not allow to optimize the program for different execution profiles according to specific workloads, or for phased program behavior. Unlike the static compilation techniques assumed in this work, dynamic optimization profits from the ability to collect and process profile information at runtime and to react to execution profile changes.

Ho citato il Transmeta perché è sicuramente più conosciuto come processore VLIW rispetto al DAISY. D'altra parte mi vien difficile pensare che S/T/I sviluppino una CPU simile al DAISY come concezione di fondo e decidano di non utilizzare un software di ottimizzazione dinamica già scritto per il DAISY...

[MadRat]

credo si riferisse al fatto ke dicevi ke il cell non è uno stream processor....

Ma chi lo ha mai detto.. ho detto che nessuno lo ha mai dichiarato tale. Potrebbe rivelarsi molto piu' flessibile di quanto non sembri in prim'analisi.

[cdimauro]

Intel Itanium ed Efficeon Transmeta sono gli esempi più noti di architetture "in order", e testimoniano il fatto che spostare il problema del miglioramento delle prestazioni dall'hardware (transistor per implementare unità out-of-order, predizione dei salti, ecc.) al software (compilatori) non paga, anche mettendo a disposizione parecchie altre risorse (Efficeon, in particolare, esegue bundle di ben 8 istruzioni ed è dotato di parecchie unità di esecuzione).

La motivazione principale l'ha portata fek: soltanto nel momento stesso dell'esecuzione è possibile conoscere le condizioni in cui si trova il processore, e scegliere in che modo è possibile sfruttare al meglio le risorse disponibili.

In particolare, per cercare di risolvere questo problema, il CodeMorph di Transmeta era in grado di ricompilare i blocchi di codice (già compilati) nel caso in cui il profiling della precedente esecuzione mettesse in evidenza la possibilità di ottenere qualche guadagno prestazionale rilevante.

Nonostante tutto, nonostante Efficeon avesse anche delle caratteristiche appositamente pensate per facilitare la traduzione del codice, il profiling e per intercettare e gestire il più velocemente possibile le eccezioni sollevate dall'ISA emulato, le prestazioni sono sempre rimaste piuttosto scarse (e la cache del processore fa un lavoro decisamente migliore rispetto al DMA di Cell, per questo particolare tipo di compito).
I benchmark postati sono molto vecchi, bisogna vedere effettivamente come viene generato il workload, e mi sembra alquanto strano che in tre test i risultati dei due processori siano ESATTAMENTE identici, in due differiscono di pochissimo, e soltanto uno è molto diverso (a favore di Transmeta, ovviamente): numeri così non si vedono neppure fra processori x86 con caratteristiche simili...

Se ciò non basta a dimostrare che quest'approccio non è una buona soluzione, certamente non gli fa una buona pubblicità e scoraggia chi avesse intenzione di riabbracciarla.

Quanto a Cell, le prestazioni nell'ambito del calcolo general purpose e dell'emulazione in particolare non possono che essere ben peggiori (almeno Efficeon possiede dell'hardware dedicato che ne facilita il compito).

Innanzitutto c'è da dire che, non solo sono unità in ordine, ma le SPE sono sostanzialmente delle unità SIMD con l'aggiunta di qualche caratteristica all'ISA per renderle "indipendenti", per cui sanno fare (molto) bene ciò per cui sono state progettate: calcolo massicciamente parallelo (di tipo streaming).
Basta prendere un problema "classico" (ordinamento, hash table, ricerca in un albero binario, cammino minimo di un grafo, ecc. ecc.) per capire che, a parte la notevole difficoltà implementativa (immaginate di implementare le stesse cose con le MMX/SSE o Altivec), le prestazioni sarebbero veramente troppo scarse.
Immagino già una SPE che prova a emulare il 6510 a 1Mhz del Commodore 64: chissà che fatica, anche se lei gira a 3,2Ghz... :asd:

L'unica per cui ha senso e che rimane in grado di eseguire calcoli general purpose è quindi l'unità PPE, anch'essa in-order, ma che proprio per questo motivo risulta abbastanza scarsa (anche se enormemente meglio delle SPE), per tutto ciò che già è stato detto. A ciò aggiungiamo anche il fatto che è dotata di poche unità di esecuzione (condivise da entrambi i thread) molto specializzate, e il quadro diventa decisamente desolante...

Certo, rispetto a un Efficeon Cell ha la possibilità di utilizzare il DMA per caricare velocemente dei blocchi di dati nella memoria locale, e accedervi poi molto velocemente, ma è un vantaggio apparente: il codice general purpose non è sequenziale (quindi richiederebbe frequenti "cambi di blocco"), e peggio ancora è l'accesso ai dati (non locale -> continui caricamenti di blocchi di dati -> il DMA che perde parecchio del suo tempo e della sua efficienza a recuperare i pochi dati che realmente servono in un preciso momento).

Visto che si parlava di emulazione, basterebbe dare un'occhiata al codice di un emulatore, anche dotato di un compilatore Just in Time, per rendersi conto che proprio questo tipo di problema è fra quelli che in assoluto mettono in ginocchio già un processore particolarmente orientato al calcolo general purpose: un'architettura in-order è quanto di peggio si possa desiderare, per quanta buona volontà ci si possa mettere nell'implementazione.

Anzi, possiamo anche prendere un qualunque emulatore, prelevare a caso il sorgente di alcune istruzioni dell'ISA emulata, e analizzare il codice: si vedrà molto facilmente che esistono delle dipendenze assolutamente ineliminabili già per un processore ooo, e che per un'architettura in order sarebbero fatali (dovrebbe forzatamente aspettare il completamento dell'istruzione che crea la dipendeza prima di proseguire).

I miracoli non esistono: se tutte le CPU general purpose continuano, DA ANNI, a integrare logica out-of-order, branch prediction, register rename, ecc., non lo fanno certo per sport o perché gli ingegneri conoscono soltanto certe tecnologie, ma perché è evidente che in questo campo sono quelle che garantiscono le migliori prestazioni.

D'altra parte Intel con Itanium c'ha provato: tolta la cache L3 da questo, anche un Duron con 192KB di cache L2 (Itanium ne ha 256KB) è in grado di competergli (e ad avere prestazioni mediamente migliori) nel calcolo general purpose, a parità di clock.

Adesso veniamo al link riportato da cui è possibile prelevare un PDF del 18 luglio 2000 con le informazioni su DAISY (Dynamic Binary Translation and Optimization) di IBM, e di cui ho riportato degli stralci:

The DAISY architecture defines execution primitives similar to the PowerPC architecture in both semantics and scope. However, not all PowerPC operations have an equivalent DAISY primitive. Complex PowerPC operations (such as "Load Multiple Registers") are intended to be layered, i.e., implemented as a sequence of simpler DAISY primitives to enable an aggressive high-frequency implementation. To this end, instruction semantics and data formats in the DAISY architecture are similar to the PowerPC architecture to eliminate data representation issues which could necessitate potentially expensive data format conversion operations.

The DAISY architecture provides extra machine registers to support efficient code scheduling and aggressive speculation using register renaming.
Data are stored in one of 64 integer registers, 64 floating point registers, and 16 condition code registers. This represents a twofold increase over the architected resources available in the PowerPC architecture. The architecture supports renaming of the carry and overflow bits in conjunction with the general purpose register. Thus, each register has extra bits to contain carry and overflow. This rename capability enables changes to global state (such as the carry and cumulative overflow information) to be renamed in conjunction with the speculative destination register until the point where the state change would occur in the original in-order PowerPC program.

The DAISY VLIW also has the usual support for speculative execution in the form of non-excepting instructions which propagate and defer exception information with renamed registers [6][17][13][14][18]. Each register of the VLIW has an additional exception tag bit, indicating that the register contains the result of an operation that caused an error.

The DAISY VLIW supports a memory hierarchy which is very similar to the emulated PowerPC architecture. This choice reduces the cost of implementing operations accessing the memory. Our experience indicates that if memory operations have to be implemented using a sequence of operations to emulate the memory management structure of the base architecture, severe performance degradation can result. If multiple platforms are to be supported by a common core, then this core must provide an efficient way of emulating the memory management structure of all supported base architectures appropriately. In particular, it is important to ensure that frequently executed memory operations do not incur emulation burden, whereas updates to the memory map (such as changes to the page tables, segment registers, etc.) might require additional logic to update the DAISY VLIW core's native memory management system.

The DAISY VLIW processor contains hardware support for profiling in the form of an 8K entry 8-way set associative (hardware) array of cached counters indexed by the exit point id of a tree region. These counters are automatically incremented upon exit from a tree region and can be inspected to see which tips are consuming the most time. They oer the additional advantages of not disrupting the data cache and being reasonably accurate.

However, some older architectures, e.g., Intel x86 require automatic synchronization between data and instruction caches. Efficient implementation of such architecture requires some hardware support. To solve this, we add a new read-only bit to each "unit" of base architecture physical memory, which is not accessible to the base architecture. (The unit size is > 2 bytes for S/390 and > 1 byte for x86, but it could also be chosen at a coarser granularity, e.g., a cache line.) Whenever the VMM translates any code in a memory unit, it sets its read only bit. Whenever a store occurs to a memory unit that is marked as read-only (by this or another processor, or I/O) an interrupt occurs to the VMM, which invalidates the translation group(s) containing the unit.
E la tabella delle cache utilizzate:
Cache | Size / Entries | Line Size | Assoc | Latency
L1-I | 32K | 1K | 8 | 1
L2-I | 1M | 2K | 8 | 3
L1-D | 32K | 256 | 4 | 2
L2-D | 512K | 256 | 8 | 4
L3 | 32M | 2048 | 8 | 42
Memory | | | | 150
DTLB1 | 128 entries | | 2 | 2
DTLB2 | 1K entries | | 8 | 4
DTLB3 | 8K entries | | 8 | 10
Page Table | | | | 90
E' interessante analizzare bene tutte le parti che ho evidenziato.

In definitiva non si tratta di un semplice sistema in-order, ma di un'architettura VLIW appositamente studiata e realizzata (via software per le simulazioni) per emulare un'architettura, quella dei PowerPC, con cui CONDIVIDE PARECCHIE CARATTERISTICHE.
E' un lavoro che riesce a fare molto bene proprio per questo motivo (leggere meglio sopra. Meglio ancora il documento), e inoltre grazie a una dotazione delle varie cache non proprio alla portata di tutti (stiamo parlando del 2000, non di oggi: all'epoca esistevano soltanto i Power4 e Pentium 3 a 0,18u come riferimento) e con una massiccia dotazione di altre caratteristiche.
Da notare i 1024 byte di linea di cache istruzioni L1 e 2048 di cache istruzioni L2: un valore ENORME, necessario per "sfamare" il core. A ciò aggiungiamo anche latenze di accesso eccezionali: UN solo ciclo per la L1 istruzioni e addirittura soltanto TRE cicli per la cache istruzioni L2.
Anche gli altri dati si commentano da soli.

Beh, se devo spostare transistor da una parte all'altra, per lo meno mi aspetterei un CONSISTENTE risparmio nel farlo, non addirittura un IMPROPONIBILE AUMENTO... :p

Sarà per questo che, a cinque anni da quella pubblicazione, IBM continua a produrre i suoi processori Power come ha sempre fatto, e come ha continuato a fare col core dell'X-Box360 (che è di derivazione Power). ;)

Il core di Cell non fa testo, perché le SPE non sono assimilabili a processori VLIW, e inoltre il PPE è semplicemente una versione castrata dell'architettura Power, messo lì per fare da microcontroller per le SPE. Checché se ne dica, AGLI EFFETTI Cell è uno Stream Processor: le definizioni lasciano il tempo che trovano, contano i fatti (un Cell senza SPE e con la sola PPE non vale assolutamente niente: viene surclassato in tutti i campi dalle architetture esistenti).

P.S. LongRun2 è una tecnologia sviluppata da Transmeta per il controllo (hardware e software) di frequenza, voltaggio e correnti di leakage del processore, e che quindi non aiuta il compito dell'emulazione (per questo è l'architettura stessa che presenta delle interessanti caratteristiche).

[cdimauro]

Decisamente ora non ho tutto il tempo necessario a risponderti passo passo.
OK, aspetterò le tue risposte agli altri punti che hai lasciato in sospeso. In mancanza, assumerò che non hai avuto argomenti per smentirli.
Tuttavia voglio precisare che hai travisato molte cose..
Non è un po' presto per tirare delle conclusioni? Vedremo chi dei due ha "travisato"...
In primo luogo, l'idea che i computer basati su 68000 fossero considerato dei 16 bit (e da alcuni 16/32) e' cosi' mia e personale che il nome ST vuol dire proprio 16/32, (come TT significa 32/32) e le riviste del tempo che li trattavano, portavano come sottotitolo riferimenti al mondo informatico a 16bit..

Ti risparmio decine e decine di siti nei quali si parli di 68000, ST, Amiga, Mac e storia dei computer e processori, nei quali si parla di generazione di computer a 16bit. Poi se ci tieni proprio ti do un po' di link, ma puoi anche cercare da solo su google.
Non c'è bisogno: so anch'io che molti hanno classificato e classificano ancora il 68000 come processore a 16 bit.

Io ti ho dimostrato che internamente l'architettura è a 32 bit, con tanto di registri dati/indirizzi a 32 bit e bus dati interno e indirizzi a 32 bit, e che soltanto il bus dati esterno è a 16 bit e quello indirizzi a 24 bit.
PERSONALMENTE (notare il maiuscolo) la ritengo, quindi, un'architettura a 32 bit.

Adesso rinnovo la domanda: mi porti un CRITERIO OGGETTIVO per definire un'architettura a "n bit"? Bada bene: non un link a una rivista, ma uno studio che mi dia una DEFINIZIONE FORMALE di architettura a "n bit" e che mi consenta quindi di classificare in maniera precisa, univoca e oggettiva una determinata architettura in base alle sue caratteristiche.

Inoltre ti faccio nuovamente notare che il 68008 ha la STESSA ARCHITETTURA INTERNA di un 68000, ma il bus dati esterno è a 8 bit (indirizzi a 20): lo classificheresti come processore a 8 bit soltanto per questo?
L'emulatore dell'ST su amiga, era un simulatore di desktop limitato nelle funzioni ed incapace anche di far scorrere un mouse con fluidita'.
Era discretamente fluido, dai miei ricordi. Purtroppo non ho sotto mano un Amiga, ma appena posso lancio WinUAE, lo configuro come un Amiga 500 con emulazione perfetta (al ciclo di clock, quindi né più lento né più veloce sulle mie macchine), e lo riprovo.
L'hardware dell'amiga era piu' massiccio, non piu' complesso. Molto meno armonioso e bilanciato di quello ST..
Del resto sono nati dalle stesse mani e sono solo due interpretazioni differenti di comuter simili.
Hai un ricordo molto confuso e poco attinente alla realtà. Ecco qua: http://it.wikipedia.org/wiki/Amiga e qua: http://it.wikipedia.org/wiki/Atari_ST

Riporto qualche stralcio, giusto per farti prendere coscienza dell'erroneità delle tue informazioni.
Partiamo dall'Amiga 1000 (il primo modello) e dalle sue caratteristiche tecniche:
Processore principale:
Motorola MC68000
Bus Interno a 32 Bit
Bus dati a 16 Bit
Frequenza di clock 7.16 MHz

Chip custom
Agnus
Denise
Paula

Memoria
RAM 256 Kilobyte, espandibile internamente a 512 KB ed esternamente fino ad 8 MB
ROM 8 Kilobyte, il Kickstart non risiede nella ROM ma viene caricato al momento dell'accensione nella RAM

Sistema operativo
AmigaOS 1.0

GUI
Interfaccia utente a finestre denominata "Intuition"

Disk drive
1 floppy disk drive capace di leggere dischi da 3,5" a doppia densità (880kb)

Mouse
1 Mouse a due tasti

Input/Output
1 porta video RGB analogico
1 modulatore video RF per connessione alla televisione
1 porta video NTSC composito
2 porte controller (per mouse, joystick, paddle, penna ottica ecc.)
1 porta esterna floppy disk
1 porta RS232
1 porta parallela "Centronics"
1 connettore di espansione laterale di tipo Zorro I dotato di tecnologia AutoConfig
1 connettore di espansione RAM
1 connettore tastiera

Per quanto riguarda i chip custom:

Denise: era il chip responsabile di generare il segnale video (15KHz). I dati gli erano forniti da Agnus via DMA. Conteneva una palette di 32 colori da 4096, eccezionale per l'epoca. Disponeva di una modalità a bassa risoluzione (320x256) ed una ad alta risoluzione (640x256). Gestiva nativamente l'interlacciamento per arrivare fino a 320x512 o 640x512. Le temporizzazioni video erano parzialmente programmabili e si poteva dunque ottenere risoluzioni prive di bordi (overscan). Denise poteva segnalare sul connettore video se stava visualizzando il colore di background o meno. Questo permetteva di realizzare dei genlock in chroma key economici. Interlacciamento, overscan e genlock resero Amiga la macchina di riferimento per le produzioni video a basso costo.

Agnus: era il responsabile dei 25 canali DMA a disposizione della macchina e del refresh della DRAM (detta Chip ram). Agnus conteneva:
Copper: era un processore dotato di 3 istruzioni (MOVE, WAIT, SKIP). Permetteva di cambiare i registri hardware in sincronia con il pennello video, liberando la CPU da questo onere. Questa tecnica permetteva ad esempio di cambiare modalità video nel mezzo dello schermo, visualizzare più colori e più sprites. AmigaOS traeva vantaggio del Copper per implementare il concetto di "Schermo". Il Copper non era una novità, Jay Miner aveva già realizzato qualcosa di molto simile sugli Atari a 8 bit con le display list di ANTIC. Per capire le capacità del Copper e la flessibilità dell'hardware si consideri che in un gioco (Battle Squadron) gli sprite invece di essere 'alimentati' dal DMA, come d'uso, venivano alimentati dal Copper arrivando a creare dei nuovi sprites a 2 colori e più di 8 sprites per linea.
Blitter: anche questa fu una rivoluzione, prima di Amiga solo alcune costose workstation grafiche disponevano di Blitters. Era un coprocessore che implementava alcune primitive grafiche in hardware. Elaborando un bitplane alla volta poteva combinare tre zone rettangolari (A, B e C) copiandole in una quarta zona rettangolare (D). I cosidetti BLOB (BLitter OBject)) erano oggetti grafici mobili realizzati avendo come A e D il frame buffer, come B l'immagine del BLOB e come C la maschera del BLOB. Il Blitter implementava un'altra primitiva grafica: il disegno di una linea, durante il disegno di essa poteva effettuare anche un fill.

Paula: controllava le porte (seriale, parallela, ecc...) ed il floppy drive ma sopratutto l'audio. Forniva 4 DAC PCM 8bit, 2 sul canale destro, 2 sul sinistro. Ogni canale aveva un volume a 6bit ed un controllo di periodo. Un canale poteva modulare l'altro in periodo o volume (da cui 8+6 = 14bit). I campioni audio potevano essere forniti via DMA o via CPU. Con il DMA la frequenza di campionamento, relata alle temporizzazoni video, era programmabile fino a circa 29Khz. Era possibile applicare un filtro passa basso sull'uscita audio. I 4 canali audio vennero col tempo ritenuti insufficienti e si svilupparono mixer software (trackers) capaci di spingere Paula ai suoi limiti. Alcuni mixer software erano abbastanza efficienti da essere utilizzati nei videogames. Dunque una hardware audio di tutto rispetto, tuttavia la mancanza di una economica porta MIDI integrata fece preferire gli Atari ST ai musicisti.

Ed ecco quelle dell'ST:
Le seguenti specifiche si riferiscono all'originario 520 ST:
CPU: Motorola 68000 @ 8Mhz
RAM: 512 KByte
Suono: Yamaha YM2149
Drive: floppy disk drive 3½" a singola faccia
Porte: TV out (nei modelli FM), MIDI In/Out, RS-232, Stampante, Monitor (RGB e monocromatico, porta per Disk drive aggiuntivo, porte Joystick e Mouse
Sistema operativo: TOS (Tramiel Operating System) dotato di interfaccia grafica GEM (Graphical Environment Manager)
Modalità video: 320×200 (16 colori), 640×200 (4 colori), 640×400 (monocromatico), palette di 512 colori

Proprio la stessa cosa, vero? E non ho riportato informazioni su tante altre caratteristiche... ;)
Mi limito a riportare qualche commento:
A differenza dell'Amiga, l'Atari ST non disponeva di chip custom progettati per l'accelerazione delle funzioni grafiche tipicamente usate nei videogiochi, programmi di grafica e montaggio video, né disponeva di chip audio avanzati (la qualità audio di un Atari ST era grossomodo equivalente a quella di un Commodore 64). Tuttavia, la sua maggiore economicità, la frequenza del processore leggermente più elevata rispetto a quella dell'Amiga e la presenza di porte MIDI incorporate, lo resero un computer di successo nell'ambito musicale professionale e amatoriale.
Un bel computer, non c'è che dire... :asd:

Quanto alle mani che li hanno creati, non sono certo le stesse, come vorresti far credere: basta leggere i link che ho riportato. E qui: http://en.wikipedia.org/wiki/Jay_Miner la storia del progettista dell'Amiga.

Come vedi, l'unica cosa che ha sviluppato per l'Atari è il chip video per la console Atari 2600...
Che l'emulatore mac su st girasse a quella velocita' e' risaputo da chi ha usato quelle macchine,
Risaputo... Allora doveva essere un fatto noto: com'è che nelle riviste dell'epoca, in cui è stato recensito, non trasparivano questi dati?
addirittura fecero pure un'interfaccia esterna contenente le rom del mac e vendettero (vendemmo, visto che eravamo centro atari ed l'assistenza ufficiale assieme alla sede di milano e torino) molti atari a tutti coloro i quali fossero indecisi tra uno (mac) e l'altro, inquanto la compatibilita' era totale, la velocita' superiore e la risoluzione video anche. Questo e' indice di spueriorita'. Nel caso dell'amiga io parlerei di diversita'.
Anche per l'Amiga valeva lo stesso, e tra l'altro non era necessario avere un'interfaccia esterna per la rom.
La risoluzione video era maggiore di quella offerta dall'ST(640x400 per NTSC e 640x512 PAL, e inoltre erano disponibili le modelità overscan con A-Max: 704x480 NTSC e 704x576 PAL).
Inoltre grazie all'uso del Blitter tutta la parte grafica del Mac veniva scaricata su questo processore, e le prestazioni erano superiori al Mac Plus a col 68000 a 8Mhz (nell'ST, come nel Mac, doveva essere il 68000 a gestirle; gli ST col Blitter sono arrivati dopo, con l'STE, e sono state poche le applicazioni ad usarlo).
Seguiti a parlarmi di velocita' di trasmissione della midi.. Il 68000 dell'st programmava solamente l'hardware dedicato alla gestione dma dell'interfaccia midi.. Hai le idee un po' confuse al riguardo, e' ovvio che una simile velocita' di trasmissione sia gestibile con poche risorse.
Le idee confuse le hai tu, invece. Guarda qui: http://www.emuita.it/emu.php?cat=Atari%20ST e in particolare

"CPU audio: AY-3-8910 ed interfaccia MIDI (la cui gestione era a carico della CPU)"

Come accadeva con tutti gli altri computer dell'epoca: veniva generato un interrupt quando c'era un byte disponibile da leggere, ed era possibile generare un interrupt quando il buffer di invio poteva accettare un altro byte da spedire.
Forse non si tratta solo di quello ;). E NESSUN programma midi per quelle macchine soffriva di scarsa precisione o rallentamenti, non credo proprio che fossero tutti in assembler!!
Assembly (il linguaggio), non assembler (il compilatore).

Non li ho fatti io né ho i sorgenti a disposizione per poter controllare. Comunque, come ti dicevo prima, l'assembly era un linguaggio molto usato per scrivere applicazioni, grazie alla semplicità dell'architettura 68000.
Quasi tutti i programmi che ho scritto io per Amiga, anche dotati di GUI e con programmazione a oggetti, erano in assembly.
Poi mi dici che un falcon senza l'hardware dedicato non saprebbe fare nulla.. IL FALCON SENZA HW DEDICATO NON ESISTE. E' nato superiore/migliore, come se nascesse oggi un computer nuovo, sarebbe superiore/migliore anche (e soprattutto) concettualmente a qualunue architettura gia' inventata.
Anche qui hai le idee un po' confuse. Sempre dal link di cui sopra che parla dell'Atari ST:
Altri modelli
TT 030 - nuove macchine basate sul processore Motorola 68030 con frequenza di 32 Mhz, in un nuovo case con tastiera separata.
Atari Falcon 030 - un'altra macchina basata sul 68030, come il TT, ma in un case estremamente simile a quello della serie 1040, con degli ulteriori miglioramenti al comparto grafico e sonoro, un processore Motorola 56000 dedicato al DSP (elaborazione digitale dei segnali), un sistema operativo multitasking (su disco) ed una porta LocalTalk per le connessioni di rete.
Le origini sono sempre le stesse... Con un po' di lifting... :p
Seguiti a sostenere che io ritenga i pc odierni simili ad un 386.. non e' vero, so che hanno poco e nulla a che spartire con loro. Ritengo solamente che siano partiti dalla piu' sbagliata delle basi informatiche.
No, hanno molto in comune coi 386, invece. Hanno tagliato i ponti con l'8086 e il 286 (anche se non è del tutto vero: è sempre possibile eseguire codice 8086 e 286, ma ciò non comporta alcun handicap per tutto il resto dell'architettura), ma il 386 è stato sostanzialmente il progenitore di tutte le architetture x86 moderne.
Quindi, anche se "partita male" (a me non è mai piaciuto né l'8086 né il 286), col 386 si è messa sulla giusta strada.
Se non capisci perche' abbia parlato di schede video, te lo rispiego in una riga.
Perche' hanno portato i giochi a 256 colori al grande pubblico, diventando cosi' commerciali e soppiantanto amiga ed st. (grazie a taiwan e non certo alla superiorita' del mondo pc-comp).
E qual è il problema? Le schede grafiche dei PC, dopo la VGA, erano diventate molto efficienti e competitive, mentre l'hardware dell'Amiga rimaneva sostanzialmente fermo (l'ST navigava in acque peggiori).

Questo cosa c'entra con l'abbandono dei 680x0 da parte di Motorola? Nulla.

L'Amiga fino al 1996 è rimasta la piattaforma d'elezione per i giochi, ed esistevano già da parecchi anni le schede SuperVGA: poi la Commodore è morta e così il mercato dei giochi si è definitivamente spostato sui PC (gli ST, come al solito, non erano molto considerati).

Ripeto: schede video e bontà del processore sono due cose completamente diverse che vanno valutate separatamente.
Oggi un 68000 farebbe ridere come architettura quanto un 2/386..
A me non fa ridere: continuo a ritenerla un'ottima architettura. Con tutti i suoi limiti, ovviamente. E un 386 fa tutt'altro che ridere...
Un evoluzione di questo (68000) sarebbe notevole e porterebbe con se i propri "difetti, nella stessa misura rilevata con gli x86.
Non è così e te l'ho già spiegato quando ti ho mostrato le difficoltà intrinseche della realizzazione di un 680x0 utilizzando le tecnologie attuali.

Ti avevo già detto che se avevi bisogno di ulteriori chiarimenti, ero disponibile a fornirteli: non hai né capito né chiesto spiegazioni.
Come capisci bene e ci tieni a precisare, che i processori di oggi poco c'entrino con un 386,
Non mettermi in bocca parole che non ho detto. Tu hai detto questo:

"E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)"

e io ho risposto con questo:

"Hai mai programmato un PC con 386 in vita tua? E' un TANTINO DIVERSO da quello di cui conservi un cattivo ricordo..."

8 bit e 640KB -> 8086. Io, invece, ti ho messo di fronte un PC CON UN 386. Quindi è logico che lo ritenga (decisamente) superiore a quello che tu hai citato (un 8086).
dovresti intuire che la stessa qualita' evolutiva avrebbe coinvolto qualunque altra cpu al posto delle x86, ma come giustamente dici tu, sono solo dei se.
Idem come sopra: non mettermi in bocca parole che non ho mai detto...

Non ho negato il fatto che altre architetture potessero far uso delle medesime tecnologie (e infatti è ciò che fa IBM con la famiglia Power, che sono dei RISC), ma ho anche detto che bisogna valutare le PROBLEMATICHE INTRINSECHE che si portano dietro.

Ti ho fatto anche l'esempio di cosa vorrebbe dire implementare l'ISA di un 68020+ con le stesse tecnologie, e delle notevoli difficoltà per farlo.
Metto un'ultima piccola aggiunta riguardo ad Halo..
Questo non dimostra cio' che sostieni tu, dimostra soltanto che (come sostengo da sempre) un hw dedicato e non soggetto a cambiamenti sia piu' "spremibile" ed a parita' di HW una console rispetto ad un pc e' piu' efficiente. Da qui i problemi a far girare Halo decentemente su pc di faccia bassa.. molto bassa direi.
Invece dimostra esattamente ciò che ho detto: che la conversione ha subito delle modifiche consistenti (e ciò traspare anche da quella recensione, e da tutte le altre) che hanno appesantito molto il gioco, elevando i requisiti per poter godere di una giocabilità equivalente a quella dell'X-Box.
Per non parlare di doom3!!. Politica per altro anticonsumistica, perche' credo che comuqnue piu' o meno TUTTI i giochi principali per pc, potrebbero girare meglio se affinati nella programmazine.
Poco tempo fa lessi un commento di non ricordo chi, che analizzava il codice di unreal (e o di far cry), mostrando la quantita' di righe inuliti e pesanti presenti.
Ne abbiamo già AMPIAMENTE parlato nella sezione News e anche in questa: non è affatto come dici tu.
Evidentemente le politiche che portano alla realizzazione di un gioco sono a te assolutamente estranee (e da quelle che dici non sembri aver mai programmato in vita tua, tanto meno dei giochi).
Fatti una ricerca, e se hai voglia di continuare a parlarne, riapri i thread oggetto della discussione.
Comunque se non erro prima sostenevi che il 68000 manderebbe al manicomio chiunque ed ora sostieni che sia piu' semplice di un x86. Forse mi e' sfuggito qualcosa.
Non puoi dire prima una cosa e poi un'altra diversa, altrimenti dimostri di non avere adeguate conoscenze o di non avere un'idea precisa di ciò di cui stai parlando. (questa frase l'ho gia' sentita..)
Idem come prima: non puoi mettermi in bocca cose che non ho assolutamente detto. Prima di dare giudizi affrettati dovresti quanto meno leggere e cercare di capire meglio quel che scrivono gli altri, altrimenti rischi di prendere delle clamorose cantonate...
Ti risparmio la fatica e ti riporto quel che ho detto, spiegandoti anche il significato.

(relativamente al decoder delle istruzioni) "Ho detto che quello per un 68020+ sarebbe MOLTO più complicato da realizzare, e ti ho spiegato anche il perché."

"so che un 68000 era piuttosto semplice da programmare rispetto a tanti RISC, tant'è che l'assembly era molto usato come linguaggio, perfino per scrivere i comandi DOS."

La prima frase è relativa all'IMPLEMENTAZIONE DELL'ARCHITETTURA. In parole molto povere: di come gli ingegneri devono mettere assieme i transistor per realizzare e far funzionare un processore.

La seconda frase riguarda la PROGRAMMAZIONE DELL'ARCHITETTURA. In parole molto povere: di come i programmatori devono mettere assieme le istruzioni che rende disponibili per far funzionare i programmi.

L'unica cosa che lega le due frasi è la parola ARCHITETTURA.
Dici che il dsp 56001 sia in grado di eseguire instruzioni gp.. non piu' di un qualunque altro dsp (cell docet).
Appunto. Mentre prima tu prima hai COMPLETAMENTE NEGATO questa possibilità.
Per quanto riguarda la corsa alle frequenze di AMD, vorrei farti notare come sia rimasta intorno ai 2ghz per quasi due anni.
Se l'intorno lo prendi con lo scarto di 1Ghz, sono d'accordo con te. Ma mi sembra un po' troppo...
P.S.
Fallo tu un emulatore del Falcon se pensi sia possibile. :)
Non è che lo penso: E' possibile.
Per ora non ci riesce nessuno
Non è esatto: per adesso non ci si è messo nessuno...
MAME e MESS emulano già sistemi molto più complessi del Falcon. Perfino il Jaguar, che ha un hardware superiore e più complicato di quello del Falcon, viene già emulato dal MESS a piena velocità (ho due Athlon64 2800+ a casa).
ed in ogni caso avrebbe gli stessi rallentamenti del vst in fase di forti carichi ide.
Non credo proprio. Non solo l'IDE, ma anche lo SCSI viene già emulato tranquillamente da MAME e MESS e non presenta i problemi di cui parli.
Comuqnue non sarebbe una soluzione per me, perche' il cubase audio non e' mai stato sprotetto bene, le versioni pirata crashano che e' una bellezza ed il mio ha la chiave di protezione hardware!! :doh: :cry:
Non c'è problema: se la chiave hardware è collegata alla porta seriale o parallela, che vengono già emulate perfettamente, ti basterebbe attaccarla e lasciarle credere che sta girando su un vero computer...

[fantoibed]

[...] soltanto nel momento stesso dell'esecuzione è possibile conoscere le condizioni in cui si trova il processore, e scegliere in che modo è possibile sfruttare al meglio le risorse disponibili. [...]

Su questo non c'è dubbio, ma considera che il branch prediction hardware su CPU OOO non è infallibile, soprattutto nei videogiochi in cui è difficile prevedere le azioni di tutti i giocatori, delle AI, ecc...

Qui:http://www.research.ibm.com/people/m/mikeg/papers/2004_msp.pdf vengono stimate su un PPC970 ed un FPS: sono circa il 10%. Teniamo conto, poi, che in un'architettura OOO con pipeline lunga le latenze sono elevate e una misprediction fa' perdere moltissimi cicli di clock.

In un'architettura a pipeline molto corta come quella del Cell, una misprediction crea un danno molto ma molto minore, anche pensando che le unità di esecuzione sono molte e se una stalla le altre mandano comunque avanti i thread.

Qui http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf stimano una perdita di 8 cicli per la PPU e 18 per una SPE:
A mispredicted branch in the Power core has an eight-cycle penalty, and a load has a fourcycle data-cache access time.When one thread is stalled, possibly by a mispredicted branch or a cache miss, the second thread often can execute to fill the execution stall. This leads to greater architectural efficiency and higher utilization of processor resources.
Edit: inoltre vorrei far notare che, stando a quando dice Jon "Hannibal" Stokes di ArsTechnica, anche Xenon (il triple-core di Xbox360) come Cell richiede un'ottimizzazione statica per ILP e TLP: From ILP to TLP, from the processor to the programmer (http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/2) e soprattutto, stando a quanto dicono quelli di ArsTechnica, utilizzerà un'architettura in-order proprio come quella di Cell: http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/3
Io non so se ha preso un granchio anche Hannibal, di sicuro se avesse ragione i sostenitori di Xbox360 dovrebbero trovare un'altra motivazione per celebrare la superiorità della console Microsoft non valendo più il OOO vs IOO...

I benchmark postati sono molto vecchi, bisogna vedere effettivamente come viene generato il workload, e mi sembra alquanto strano che in tre test i risultati dei due processori siano ESATTAMENTE identici, in due differiscono di pochissimo, e soltanto uno è molto diverso (a favore di Transmeta, ovviamente): numeri così non si vedono neppure fra processori x86 con caratteristiche simili...

Nel testo viene spiegato come vengono generati i workloads e comunque le prestazioni sono allineate su quasi tutti i test tranne uno (MS-Office2000), dove è PentiumIII-650 a prevalere sul Crusoe-533 e non il contrario come dici tu, visto che il workload viene eseguito in un tempo inferiore (=prestazione migliore). D'altra parte fek contestava il fatto che il Crusoe-667 potesse avere prestazioni simili al PentiumIII-500, mentre nella fattispecie il confronto viene fatto con un Crusoe a frequenza più bassa rispetto a quella del PentiumIII.

Il punto, comunque, non era se fosse più veloce il Crusoe o il PentiumIII quanto se fosse una traduzione obiettiva o no
"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"
=
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

[fek]

Il punto, comunque, non era se fosse più veloce il Crusoe o il PentiumIII quanto se fosse una traduzione obiettiva o no
"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"
=
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.

Mi quoti di preciso dove attorno alla sequente frase "parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare" ho scritto che e' una traduzione letterale e accurata del testo inglese? Grazie.

Poi mi quoti dove ho "contestato che potesse avere prestazioni simili"?

Visto che fai il precisino invece, ti faccio notare che:
""Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"

Sono "circa le stesse", non "le stesse" e neppure "poco superiori", quindi anche se di poco inferiori, quindi il mio "piu' piano di" e' un'interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione.

Infatti ho scritto:
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Il "genericamente" non e' casuale, ma tu lo hai volutamente ignorato. Come volevasi dimostrare.

Riguardo al discorso sullo Stream Processor, cidimauro ha posto gia' la parola fine per me. Il Cell e' uno Stream Processor come affermato anche da IBM. Mentre tu hai confuso una memoria locale con un processore, che sono due concetti un po' diversi.

[fantoibed]

Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.

Ho fatto copia e incolla, vedi tu.

Mi quoti di preciso dove attorno alla sequente frase "parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare" ho scritto che e' una traduzione letterale e accurata del testo inglese? Grazie.

Hai detto che era una traduzione libera e che rende l'idea.
E' chiaro che hai preso quella frase (che è del tutto marginale nel discorso) e l'hai modificata a tuo uso e consumo solo per cercare di rendere inattendibile quella fonte.

Poi mi quoti dove ho "contestato che potesse avere prestazioni simili"?

Lo smile indicava quello, è evidente!


Visto che fai il precisino invece, ti faccio notare che:"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"

Sono "circa le stesse", non "le stesse" e neppure "poco superiori", quindi anche se di poco inferiori, quindi il mio "piu' piano di" e' un'interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione.

Quindi era un caso il fatto che tu abbia scelto "piu' piano di" invece che "piu' veloce di" per la tua "interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione" ?

E poi, che cos'altro intendevi con "come volevasi dimostrare" se non tentare di screditare le fonti?

Infatti ho scritto:
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Il "genericamente" non e' casuale, ma tu lo hai volutamente ignorato. Come volevasi dimostrare.

L'ho ignorato perché lo consideravo corretto. Non è il "genericamente" ad essere errato, è tutto il resto della frase.

Mentre tu hai confuso una memoria locale con un processore, che sono due concetti un po' diversi.

Non è vero e lo sai. E' un'altra chiara ed evidente mistificazione e chi segue il thread se ne può rendere conto facilmente.
Come volevasi dimostrare [cit.]

Riporto quel pezzo:
A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a Cell Processor

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Dove avrei confuso una memoria locale con un processore lo sai solo tu.

E' evidente che stai solo cercando di screditare chi la pensa diversamente da te attribuendogli frasi mai dette. Ti cito: Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.. E con tale frase, vinci anche una segnalazione ai moderatori.

Tieni presente che io non ho mai contestato il fatto che Cell sia uno "stream processor", contesto solo il fatto che nella frase che hai riportato si riferiscono ad una singola SPU quando dicono "stream processor" e non all'intero Cell!

[fek]

Ho fatto copia e incolla, vedi tu.

Hai detto che era una traduzione libera e che rende l'idea.
E' chiaro che hai preso quella frase (che è del tutto marginale nel discorso) e l'hai modificata a tuo uso e consumo solo per cercare di rendere inattendibile quella fonte.

Questa e' una tua illazione e come tale non ha valore, ed e' oltretutto offensiva.

Ho detto che e' una traduzione libera, dopo che tu mi hai domandato se fosse una traduzione esatta. Con me non cambi le carte in tavola.


Lo smile indicava quello, è evidente!

E' evidente solo per te. Mi quoti dove avrei scritto quello che mi hai attribuito?

Mi metti in bocca cose che non ho scritto solo per screditarmi e dopo che ho detto che non avrei piu' affrontato l'argomento. Comportamento infantile.


Quindi era un caso il fatto che tu abbia scelto "piu' piano di" invece che "piu' veloce di" per la tua "interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione" ?

In inglese "it's about the same", significa "e' quasi lo stesso".
Come "it's about to come", significa "sta quasi arrivando".

http://dictionary.reference.com/search?q=about
a·bout Audio pronunciation of "about" ( P ) Pronunciation Key (-bout)
adv.

1. Approximately; nearly: The interview lasted about an hour.
2. Almost: The job is about done.
\
La mia traduzione "piu' piano" e' fedele al testo originale tradotto letteralmente "e' quasi (inferiore) lo stesso", grammatica inglese alla mano. Ripassa l'inglese.
E noto con piacere che anche attaccandoti alle singole parole non stai ricavando molto se non una brutta figura.

Lo ripeto per tua utilita':
Il documento conferma che una CPU in-order di clock superiore va piu' piano ("about the same", quasi come) una CPU a clock inferore.

Avresti dovuto leggere con piu' attenzione prima di imbarcarti nel fare illazioni, dare epiteti e nello screditarmi. Sara' per la prossima volta.


E poi, che cos'altro intendevi con "come volevasi dimostrare" se non tentare di screditare le fonti?

Intendevo dire che la fonte conferma quello che andavo dicendo e che tu non volevi accettare. Il fato volle che per l'ennesima volta tu mi abbia portato fonti che confermano quello che stavo dicendo.


L'ho ignorato perché lo consideravo corretto. Non è il "genericamente" ad essere errato, è tutto il resto della frase.

Il resto della frase e' corretta, grammatica inglese alla mano.


Non è vero e lo sai. E' un'altra chiara ed evidente mistificazione e chi segue il thread se ne può rendere conto facilmente.


E' vero e lo so. Con questa tua politica di screditare quello che dico attaccandoti (e sbagliando anche) alle piccolezze non sta sortendo grandi risultati.


Dove avrei confuso una memoria locale con un processore lo sai solo tu.

Lo sanno anche tutti quelli che hanno letto. Qui:


Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Oppure, in italiano, vuole dire uno "oppure" l'altro. Visto che tu credi abbastanza ingenuamente che il Cell non sia uno stream processor, nella tua frase rimane solo la seconda opzione.


E' evidente che stai solo cercando di screditare chi la pensa diversamente da te attribuendogli frasi mai dette. Ti cito: Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.. E con tale frase, vinci anche una segnalazione ai moderatori.

Segnalami pure, visto che non ti resta altro che buttarla sul personale per "vincere" questa discussione che ti vede dalla parte di chi non sa di che cosa si parla e cerca affannosamente su google, quotando testi che ti danno torto :)

Io non ho screditato nessuno, e posso quotare con dovizia i tuoi "rileggi meglio", e le tue errate traduzioni.

Sono stanco del tuo atteggiamento nei confronti di diversi utenti e non solo il solo al quale stai dando addosso. Il caso di cdimauro nelle News e' ancora plateale.

Il tuo mettermi in bocca frasi che non ho scritto dopo che avevo abbandonato la discussione e' stata una vigliaccata che non mi aspettavo.

E gia' che ci sei quota dove ti ho messo in bocca quello che non hai detto. Grammatica alla mano tu hai scritto che se IBM non si riferiva al Cell allora si riferiva alla memoria locale. Se poi non sei in grado di scrivere quello che realmente pensi, diventa un problema di comunicazione tuo e non mio.

Tieni presente che io non ho mai contestato il fatto che Cell sia uno "stream processor", contesto solo il fatto che nella frase che hai riportato si riferiscono ad una singola SPU quando dicono "stream processor" e non all'intero Cell!

Si riferiscono all'intero Cell infatti, come in quattro ti abbiamo fatto notare.

Ora, vuoi rinormalizzare il discorso oppure vuoi continuare sullo scontro dove hai buttato la discussione? Nel primo caso sarei felicissimo, e pretenderei delle scuse, nel secondo caso rischi una figuraccia peggiore di quella che hai gia' fatto. Non sono l'ultimo arrivato.

[fantoibed]

Questa e' una tua illazione e come tale non ha valore, ed e' oltretutto offensiva.

Ho detto che e' una traduzione libera, dopo che tu mi hai domandato se fosse una traduzione esatta. Con me non cambi le carte in tavola.



E' evidente solo per te. Mi quoti dove avrei scritto quello che mi hai attribuito?

Mi metti in bocca cose che non ho scritto solo per screditarmi e dopo che ho detto che non avrei piu' affrontato l'argomento. Comportamento infantile.



In inglese "it's about the same", significa "e' quasi lo stesso".
Come "it's about to come", significa "sta quasi arrivando".

http://dictionary.reference.com/search?q=about
a·bout Audio pronunciation of "about" ( P ) Pronunciation Key (-bout)
adv.

1. Approximately; nearly: The interview lasted about an hour.
2. Almost: The job is about done.
\
La mia traduzione "piu' piano" e' fedele al testo originale tradotto letteralmente "e' quasi (inferiore) lo stesso", grammatica inglese alla mano. Ripassa l'inglese.
E noto con piacere che anche attaccandoti alle singole parole non stai ricavando molto se non una brutta figura.

Lo ripeto per tua utilita':
Il documento conferma che una CPU in-order di clock superiore va piu' piano ("about the same", quasi come) una CPU a clock inferore.

Avresti dovuto leggere con piu' attenzione prima di imbarcarti nel fare illazioni, dare epiteti e nello screditarmi. Sara' per la prossima volta.



Intendevo dire che la fonte conferma quello che andavo dicendo e che tu non volevi accettare. Il fato volle che per l'ennesima volta tu mi abbia portato fonti che confermano quello che stavo dicendo.



Il resto della frase e' corretta, grammatica inglese alla mano.



E' vero e lo so. Con questa tua politica di screditare quello che dico attaccandoti (e sbagliando anche) alle piccolezze non sta sortendo grandi risultati.



Lo sanno anche tutti quelli che hanno letto. Qui:



Oppure, in italiano, vuole dire uno "oppure" l'altro. Visto che tu credi abbastanza ingenuamente che il Cell non sia uno stream processor, nella tua frase rimane solo la seconda opzione.



Segnalami pure, visto che non ti resta altro che buttarla sul personale per "vincere" questa discussione che ti vede dalla parte di chi non sa di che cosa si parla e cerca affannosamente su google, quotando testi che ti danno torto :)

Io non ho screditato nessuno, e posso quotare con dovizia i tuoi "rileggi meglio", e le tue errate traduzioni.

Sono stanco del tuo atteggiamento nei confronti di diversi utenti e non solo il solo al quale stai dando addosso. Il caso di cdimauro nelle News e' ancora plateale.

Il tuo mettermi in bocca frasi che non ho scritto dopo che avevo abbandonato la discussione e' stata una vigliaccata che non mi aspettavo.

E gia' che ci sei quota dove ti ho messo in bocca quello che non hai detto. Grammatica alla mano tu hai scritto che se IBM non si riferiva al Cell allora si riferiva alla memoria locale. Se poi non sei in grado di scrivere quello che realmente pensi, diventa un problema di comunicazione tuo e non mio.



Si riferiscono all'intero Cell infatti, come in quattro ti abbiamo fatto notare.

Ora, vuoi rinormalizzare il discorso oppure vuoi continuare sullo scontro dove hai buttato la discussione? Nel primo caso sarei felicissimo, e pretenderei delle scuse, nel secondo caso rischi una figuraccia peggiore di quella che hai gia' fatto. Non sono l'ultimo arrivato.

Tieniti pure la ragione, se la vuoi. Non mi abbasso ad un livello tanto infantile.

[fek]

http://www.research.ibm.com/cell/

Exploring realtime multimedia content creation in video games
6th Workshop on Media and Streaming Processors in conjunction with MICRO 36, December 2004. (B. Matthews, J.D. Wellman, M. Gschwind)

The Microarchitecture of the Streaming Processor for a CELL Processor
ISSCC 2005, February 2005. (B. Flachs et al.)

Ovviamente adesso si mettera' magari a sindacare sul cavillo che Stream e Streaming non sono la stessa cosa.

http://www.blachford.info/computer/Cells/Cell2.html

Stream Processing

A big difference in Cells from normal CPUs is the ability of the APUs in a Cell to be chained together to act as a stream processor [Stream]. A stream processor takes data and processes it in a series of steps. Each of these steps can be performed by one or more APUs.

Oppure si mettera' a sindacare sul fatto che "l'essere configurabile per agire da stream processor" non vuol dire essere uno stream processor.

Per altro anche questo articolo ripete esattamente le stesse cose che ho detto fino ad ora e non menziona alcuna traduzione di codice dinamica.

Oppure si mettera' a sindacare che un processore formato da 9 core di cui 8 lavorano preferibilmente su dati in streaming non e' uno stream processor.

[fek]

Tieniti pure la ragione, se la vuoi. Non mi abbasso ad un livello tanto infantile.

A giudicare da questo direi il contrario, ti sei gia' abbassato a livelli molto piu' infantili; ho smesso di fare lo specchio riflesso alle elementari. Io non mi prendo la ragione, su questo argomento ho ragione come ampiamente dimostrato in lungo e in largo con dovizia di particolari.

Fattene una ragione :)

[fantoibed]

Io non mi prendo la ragione, su questo argomento ho ragione come ampiamente dimostrato in lungo e in largo con dovizia di particolari.

Fattene una ragione :)

Complimenti, allora!

[fek]

Complimenti, allora!

Niente per cui ricevere complimenti, a me basta che sia stata evitata della cattiva informazione anche se ci sono volute quattro pagine :)

[fantoibed]

Niente per cui ricevere complimenti, a me basta che sia stata evitata della cattiva informazione anche se ci sono volute quattro pagine :)

Hai ragione. Hai ragione perché non si può discutere con te.
A certe persone è meglio dare ragione anche quando dicono che la Luna è fatta di formaggio.

[lowenz]

Io voglio il parere di repne scasb :ave: :D

[fek]

Hai ragione. Hai ragione perché non si può discutere con te.
A certe persone è meglio dare ragione anche quando dicono che la Luna è fatta di formaggio.

http://www.bbc.co.uk/parenting/images/300/baby_crying_closeup.jpg

Con me si puo' discutere, e me lo dicono tutti a parte te. Ci sara' un perche' :)
E quando si parla di processori, gpu e programmazione, so di che cosa sto parlando, non mi invento che una memoria locale e' un processore.

Ora devi continuare a metterla sul personale oppure la smetti con questa pagliacciata? E' la terza volta che te lo chiedo. Se non ti piace come mi comporto puoi sempre comunicarmelo in PM.

[fantoibed]

http://www.bbc.co.uk/parenting/images/300/baby_crying_closeup.jpg

Con me si puo' discutere, e me lo dicono tutti a parte te. Ci sara' un perche' :)
E quando si parla di processori, gpu e programmazione, so di che cosa sto parlando, non mi invento che una memoria locale e' un processore.

Ora devi continuare a metterla sul personale oppure la smetti con questa pagliacciata? E' la terza volta che te lo chiedo. Se non ti piace come mi comporto puoi sempre comunicarmelo in PM.

Io non sto facendo proprio nulla. Assisto solo sbalordito ai tuoi comportamenti.
Chi sa leggere si rende conto del mio atteggiamento e del tuo, e sa valutare le mistificazioni...

[jappilas]

Io voglio il parere di repne scasb :ave: :D
un po' in effetti mancano, quei suoi post privi (gli ultimi a parte) di emozione, ma ricchi di assembly... :(

[DioBrando]

Io voglio il parere di repne scasb :ave: :D

scusate l'OT...cmq è un peccato che non partecipi + :(

sicuramente ci sn altre teste con quel livello di preparazione tecnica cmq una in + male n faceva...

Fine OT


continuo a seguire con interesse il thread e complimenti a tutti cmq per le nozioni sviscerate :)

[fek]

Io non sto facendo proprio nulla. Assisto solo sbalordito ai tuoi comportamenti.
Chi sa leggere si rende conto del mio atteggiamento e del tuo, e sa valutare le mistificazioni...

Esatto. E a quanto pare chi ha letto mi ha gia' dato ampiamente ragione. Ti ripeto che se i miei comportamenti non ti aggradano puoi comunicarmelo in PM. Ma non sembra che a te interessino i miei comportamenti, sei piu' interessato a farmi una member war dopo essere rimasto scottato dall'andamento della discussione.

Continua a piagnucolare da solo adesso...

[fantoibed]

Esatto. E a quanto pare chi ha letto mi ha gia' dato ampiamente ragione. Ti ripeto che se i miei comportamenti non ti aggradano puoi comunicarmelo in PM. Ma non sembra che a te interessino i miei comportamenti, sei piu' interessato a farmi una member war dopo essere rimasto scottato dall'andamento della discussione.

Continua a piagnucolare da solo adesso...

Continua così che vai forte!

[jappilas]

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo :(

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro :ave:

[fantoibed]

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo :(

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro :ave:

Infatti sto cercando di evitare di rispondere alle provocazioni di fek.
Aspetto di vedere se i moderatori prenderanno provvedimenti oppure no.

[MadRat]

Non c'è bisogno: so anch'io che molti hanno classificato e classificano ancora il 68000 come processore a 16 bit.
Io ti ho dimostrato che internamente l'architettura è a 32 bit, con tanto di registri dati/indirizzi a 32 bit e bus dati interno e indirizzi a 32 bit, e che soltanto il bus dati esterno è a 16 bit e quello indirizzi a 24 bit.
PERSONALMENTE (notare il maiuscolo) la ritengo, quindi, un'architettura a 32 bit.
Adesso rinnovo la domanda: mi porti un CRITERIO OGGETTIVO per definire un'architettura a "n bit"? Bada bene: non un link a una rivista, ma uno studio che mi dia una DEFINIZIONE FORMALE di architettura a "n bit" e che mi consenta quindi di classificare in maniera precisa, univoca e oggettiva una determinata architettura in base alle sue caratteristiche.
Inoltre ti faccio nuovamente notare che il 68008 ha la STESSA ARCHITETTURA INTERNA di un 68000, ma il bus dati esterno è a 8 bit (indirizzi a 20): lo classificheresti come processore a 8 bit soltanto per questo?


Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.


Era discretamente fluido, dai miei ricordi. Purtroppo non ho sotto mano un Amiga, ma appena posso lancio WinUAE, lo configuro come un Amiga 500 con emulazione perfetta (al ciclo di clock, quindi né più lento né più veloce sulle mie macchine), e lo riprovo.


I tuoi ricordi sono offuscati, non girerebbe fluido come un st nemmeno su un A4000.
Quasi quasi me lo ricarico su un amiga vero e non emulato.


Hai un ricordo molto confuso e poco attinente alla realtà.

Riporto qualche stralcio, giusto per farti prendere coscienza dell'erroneità delle tue informazioni.
Partiamo dall'Amiga 1000 (il primo modello) e dalle sue caratteristiche tecniche:

Ed ecco quelle dell'ST:


Proprio la stessa cosa, vero? E non ho riportato informazioni su tante altre caratteristiche... ;)
Mi limito a riportare qualche commento:

Un bel computer, non c'è che dire... :asd:


Dipende tutto dal sito dal quale prendi i link.. Se noti quello dell'amiga e' farcito di commenti e spiegazioni, quello ST e' solo un elenco tecnico poco completo per altro.
Ad esempio TI SEI SCORDATO di dire che l'st usci' con le porte midi, non solo per conquistare il mercato musicale (come fece), ma anche per surrogare il chip audio poco costoso implementato nella macchina e molti giochi, se collegati ad un economicissimo roland mt32, uscivano in audio con questo (dopo che il gioco stesso lo aveva programmato) e ti assicuro che il cio' ridicolizzava il fantomatico audio dell'amiga, soprattutto dal punto di vista musicale ed in oltre risparmiava memoria preziosa. La soluzione non e' logicamente stata usata quanto le caratteristiche avanzate dell'amiga (vista la ovviamente scarsa diffusione dell'MT32 se paragonato ad un chip di serie), ma ne hanno ridotto il costo facendo sì che l'ST fosse il computer piu' vendto del mondo (fino al guinnes dei primati del 97, poi oltre non l'ho piu' comprato). Tant'e' vero che la commodore e' fallita assai prima dell'Atari. (94).

Secondo poi la schiacciante superiorita' architetturale del'Amiga, generava un gap prestazionale notevole in ogni gioco che facesse uso di grafica poligonale. Questo lo motiviamo con 0.84 mhz in meno??
Se prendi una punto e la vesti da rolce royce, hai la comodita' di quest'ultima e le prestazioni di una bicicletta.

Il progetto Amiga ne 94 rischio il crash vista l'esosita' dello stesso. Richedeva troppe risorse finanziarie e di tempo. Fu comprato incompleto dalla Comodore (avrebbe dovuto comprarlo l'atari che era gia' in trattative e possedeva parte del team di sviluppo, situazione dalla quale scaturi' una controversia legale tra le due case).
Sta di fatto che la Comodore si trovo' in mano un computer incompleto e complesso, privo anche di un amiga dos finito e di un qualunque altro sistema operativo degno di questo nome, il workbench infatti non era su rom e non era certamente degno della concorrenza. (la complessita' dell'hardware portò vantaggi e svantaggi). Assolutamente non paragonabile con il TOS della digital, forse scopiazzato da quello che vendette anche apple, ma decisamente il migliore all'epoca (so bene come non fosse multitasking, ma sarebbe stato prematuro per le conoscienze del tempo).

Io sul mio ST usavo tranquillamente 512 colori contemporaneamente e sull'STE ne usavo 4096.
In ogni caso i due computer primeggiavano nei loro rispettivi campi ed a parer mio il vantaggio dell'amiga non giustificava un costo DOPPIO rispetto a quello dell'ST.
La grafica evoluta cosi' come l'audio, richiedevano grandi quantitativi di ram, al tempo molto costosa. Anche questo io giudico nell'equilibrio di un progetto.

Non nego che L'Amiga fosse una grande idea, ma conservava dei punti deboli e per di piu' finì nelle mani gestionali piu' errate. La commodore senza Tramiel non valeva piu' nulla.





Risaputo... Allora doveva essere un fatto noto: com'è che nelle riviste dell'epoca, in cui è stato recensito, non trasparivano questi dati?


Non lo so, forse all'epoca ancora non sapevi leggere?? o piu' probabilmente eri chiuso nel mondo amiga.


Anche per l'Amiga valeva lo stesso, e tra l'altro non era necessario avere un'interfaccia esterna per la rom.


Forse non sai ancora leggere ora che ci penso; io ho detto che esisteva **"ANCHE"** una versione con le ROM sulla porta d'espansione. Questo era utile per accendere il computer e senza caricare nulla, avere un MAC piu' potente dell'originale e "con tutta la ram libera".. Difficile da intuire vero?? :)


La risoluzione video era maggiore di quella offerta dall'ST(640x400 per NTSC e 640x512 PAL, e inoltre erano disponibili le modelità overscan con A-Max: 704x480 NTSC e 704x576 PAL).
Inoltre grazie all'uso del Blitter tutta la parte grafica del Mac veniva scaricata su questo processore, e le prestazioni erano superiori al Mac Plus a col 68000 a 8Mhz (nell'ST, come nel Mac, doveva essere il 68000 a gestirle; gli ST col Blitter sono arrivati dopo, con l'STE, e sono state poche le applicazioni ad usarlo).


Indubbiamente dal punto di vista grafico (solo se si parla di bitmap) l'amiga era piu' prestante, ma a me risulta che l'impiego di overscreen e piu' colori di quanti imposti dal SO, fosse una realta' anche su ST (certamente meno diffusa e piu' limitata).
Per quanto riguarda l'STE, era un'ottima macchina poco sfruttata. La parte audio era il doppio piu' potente di quella dell'amiga (4 ch a 50khz o 8 a 25khz).
Un evoluzione possibile grazie all'abbassamento dei costi dell'hardware e ad un armonico potenziamento della macchina. C'e' da dire che Atari (come comodore) riteneva il proprio ST "perfetto" e ritardo' per questo l'uscita della versione "E", cosi' come quella del falcon. Quest'ultimo usci castrato per via della nascente crisi economica (avrebbe dovuto avere un 60030/40 a 32mhz e due dsp56001).
Se poi il tuo concetto di superiorita' e' dettato solo da un audio ed una grafica piu' evoluti, senza badare alla funzionalita', ai costi ed alle altre prestazioni.. beh, allora parliamo di x68000.. L'Amiga scompare d'incanto.
Fortunatamente un computer non e' fatto solo d'apparenza e di giochi.




Le idee confuse le hai tu, invece. Guarda qui: http://www.emuita.it/emu.php?cat=Atari%20ST e in particolare

"CPU audio: AY-3-8910 ed interfaccia MIDI (la cui gestione era a carico della CPU)"

Come accadeva con tutti gli altri computer dell'epoca: veniva generato un interrupt quando c'era un byte disponibile da leggere, ed era possibile generare un interrupt quando il buffer di invio poteva accettare un altro byte da spedire.


Un programma di annotazione midi su pc, mac o amiga quando va in crash e torna al desk smette di suonare, con l'st non succedeva. Questo fa la differenza per un professionista. Qualunque spiegazione tu abbia.



Assembly (il linguaggio), non assembler (il compilatore).

Non li ho fatti io né ho i sorgenti a disposizione per poter controllare.


Alla fine quando si parla con te, finisce tutto per essere ricondotto ad una mala programmazine. Mentre secondo me, se una determinata tipologia di programmi girava "sempre" meglio, si puo' parlare di comprovata superiorita' hardware (almeno nel segmanto).


Anche qui hai le idee un po' confuse. Sempre dal link di cui sopra che parla dell'Atari ST:

Le origini sono sempre le stesse... Con un po' di lifting... :p


A parte la poca pertinenza con l'argomento, le idee confuse le hai tu.
Il TT era l'evoluzione a 32bit (anche se per te e' inoncepibile questo argomento), dell'ST, venduto come postazione professionale!!. Il falcon usci molto tempo dopo come macchina completamente nuova che, dall'ST avrebbe dovuto ereditare solo la fascia di mercato, il case ed una discreta retrocompatibilita'. L'unico difetto fu la data di lancio, come detto prima, il progetto era pronto nel 90/91 e fu lanciato a meta' 93.


No, hanno molto in comune coi 386, invece. Hanno tagliato i ponti con l'8086 e il 286 (anche se non è del tutto vero: è sempre possibile eseguire codice 8086 e 286, ma ciò non comporta alcun handicap per tutto il resto dell'architettura), ma il 386 è stato sostanzialmente il progenitore di tutte le architetture x86 moderne.
Quindi, anche se "partita male" (a me non è mai piaciuto né l'8086 né il 286), col 386 si è messa sulla giusta strada.


Non era una questione di inferiorita' architetturale quella che causo la dismissione evolutiva dei 68k, bensi' il diffondersi di un'altra piattaforma. La motorola provo' anche a creare uan versione RISC del 68000, chiamata inizialmente 78000 e poi 88000, ma a nulla servi', passo quasi inosservata.


E qual è il problema? Le schede grafiche dei PC, dopo la VGA, erano diventate molto efficienti e competitive, mentre l'hardware dell'Amiga rimaneva sostanzialmente fermo (l'ST navigava in acque peggiori).


E chi ha parlato di problemi?? Io non di certo!!
Era solo la motivazione per la quale i pc, grazie alla loro modularita' ed espandibilita', (che e' il loro unico punto di forza) e grazie a taiwan, sopraffecero i computer che "puzzavano" di stantio (incredibile, siamo d'accordo su qualcosa).
Ma se non fosse stato per il mercato orientale, il pc sarebbe rimasto per sempre relegato al ruolo di macchina da ufficio, vistone il costo assurdo per l'uso domestico ed i vantaggi inesitenti.


Questo cosa c'entra con l'abbandono dei 680x0 da parte di Motorola? Nulla.


Ma no, certo, come posso non averci pensato prima!! La motorola avrebbe dovuto sprecare milioni di dollari per lo sviluppo di una cpu che oramai non era piu' usata da nessuno!!
Comuqnue alla fine il ppc eredita parte delle caratteristiche del 68k, ma paragonato ad un 68060, (di pari epoca) e inferiore. Alla fine sono solo scelte commerciali dettate non solo dalla motorola, ma anche dai suoi partner.


L'Amiga fino al 1996 è rimasta la piattaforma d'elezione per i giochi, ed esistevano già da parecchi anni le schede SuperVGA: poi la Commodore è morta e così il mercato dei giochi si è definitivamente spostato sui PC (gli ST, come al solito, non erano molto considerati).


Gli ST non furono considerati solo negli ultimi anni, quando l'Amiga riusci a raggiungere un prezzo decente. E questo riguarda solo ed ESCLUSIVAMENTE il mercato vudeoludico, del quale parli tu, mercato che ha fatto affermare i pc come standard, ma che tuttavia non e' l'unico target di un utente (né di ora, né del tempo).

Comuqnue sono d'accordissimo con chiunque sostenga che dal punto di vista ludico, l'amiga fosse piu' idoneo. Questo perche' aveva grandi capacita' di manipolazione delle bitmap, che al tempo erano il fulcro dei giochi. Mentre l'evoluzione del mercato ha poi decretato la vittoria della grafica poligonale.


Ripeto: schede video e bontà del processore sono due cose completamente diverse che vanno valutate separatamente.


Non ho mai affrontato quest'argomento.


A me non fa ridere: continuo a ritenerla un'ottima architettura. Con tutti i suoi limiti, ovviamente. E un 386 fa tutt'altro che ridere...

Non è così e te l'ho già spiegato quando ti ho mostrato le difficoltà intrinseche della realizzazione di un 680x0 utilizzando le tecnologie attuali.

Ti avevo già detto che se avevi bisogno di ulteriori chiarimenti, ero disponibile a fornirteli: non hai né capito né chiesto spiegazioni.


Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.


Non mettermi in bocca parole che non ho detto. Tu hai detto questo:

"E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)"

e io ho risposto con questo:

"Hai mai programmato un PC con 386 in vita tua? E' un TANTINO DIVERSO da quello di cui conservi un cattivo ricordo..."


E molto prima dicesti: "Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..




Non ho negato il fatto che altre architetture potessero far uso delle medesime tecnologie (e infatti è ciò che fa IBM con la famiglia Power, che sono dei RISC), ma ho anche detto che bisogna valutare le PROBLEMATICHE INTRINSECHE che si portano dietro.


Ne ho parlato pocanzi


Invece dimostra esattamente ciò che ho detto: che la conversione ha subito delle modifiche consistenti (e ciò traspare anche da quella recensione, e da tutte le altre) che hanno appesantito molto il gioco, elevando i requisiti per poter godere di una giocabilità equivalente a quella dell'X-Box.


Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente. Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime. I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.

Per quanto mi riguarda, l'oggettivita degli eventi va ben oltre a qualunque "teoria".


Appunto. Mentre prima tu prima hai COMPLETAMENTE NEGATO questa possibilità.


La mia negazione era assoluta non meno di quanto lo fosse la tua relativamente ai dsp cell.


Se l'intorno lo prendi con lo scarto di 1Ghz, sono d'accordo con te. Ma mi sembra un po' troppo...


Che simpatico, tuttavia AMD lavorando sull'efficienza, piu' che sulla potenza bruta dei mhz, vendeva un 2,2ghz come oppositore di un 3,2 (scarto di un ghz ancora presente, rispetto ai processori Intel) e questa differenza si e' accumilata per lo piu' durante il 2003. Solo con l'avvento dei K8 si e' spinta oltre i 2,2 ghz.. frequenza che raggiunse molto tempo prima.



Non è che lo penso: E' possibile.

Tra il dire ed il fare..


Non è esatto: per adesso non ci si è messo nessuno...
MAME e MESS emulano già sistemi molto più complessi del Falcon. Perfino il Jaguar, che ha un hardware superiore e più complicato di quello del Falcon, viene già emulato dal MESS a piena velocità (ho due Athlon64 2800+ a casa).


Mi dai un link con un emulatore Jaguar degno di questo nome??
Per ora io uso quello vero.


Non credo proprio. Non solo l'IDE, ma anche lo SCSI viene già emulato tranquillamente da MAME e MESS e non presenta i problemi di cui parli.


Infatti non parlo di problemi emulativi.. ma del pc stesso, al difuori di ogni emulazione. Sono problemi che tutt'ora affliggono questi sistemi ed (nel campo musicale si riflettono in particolar modo), rendono praticamente inutilizzabile un pc privo di una costosa scheda che lavori per conto proprio.
Se questa me la chiami evoluzione..


Non c'è problema: se la chiave hardware è collegata alla porta seriale o parallela, che vengono già emulate perfettamente, ti basterebbe attaccarla e lasciarle credere che sta girando su un vero computer...

Purtroppo quasi tutte le chiavi di protezione dell'atari, come anche quella del cubase Audio, erano inserite nella porta laterale per cartucce d'espansione. (come lo spectre gcr).. Dunque mi sembra un po' difficile inserirla in un pc. Il problema purtoppo non si pone, vista l'inesitenza dell'emulatore.
Non sai che darei per averlo, ma purtroppo nemmeno quello dell'ST e' ancora perfetto.

[MadRat]

Hai ragione. Hai ragione perché non si può discutere con te.
A certe persone è meglio dare ragione anche quando dicono che la Luna è fatta di formaggio.

[img]
Con me si puo' discutere, e me lo dicono tutti a parte te. Ci sara' un perche' :)
E quando si parla di processori, gpu e programmazione, so di che cosa sto parlando, non mi invento che una memoria locale e' un processore.

Ora devi continuare a metterla sul personale oppure la smetti con questa pagliacciata? E' la terza volta che te lo chiedo. Se non ti piace come mi comporto puoi sempre comunicarmelo in PM.


Fek, discutere con te e' molto difficile, tendi a prevaricare non ascoltando, travisando le argomentazioni e puntando su tematiche tecniche spesso non chiamate in causa, questo solo per spiazzare un eventuale interlocutore piu' inesperto nell'ambito al quale vuoi sempre ricondurre i tuoi discorsi.
L'impressione che si ha, tuttavia, e' che tu voglia affermare tramite spiegazioni, che la terra giri al contrario.

Purtroppo non tutte le "battaglie" si possono combattere in casa, altrimenti ti direi "giochiamoci la soluzione alle nostre controversie su due ruote" o "vediamo chi disegna meglio una vignetta al riguardo" o ancora a chi la musica meglio..

Forse ti manca una bella dose di umilta' e la capacita' di ascoltare cio' che la gente ha da dire.

[fantoibed]

MadRat, pensa che finora mi ero interessato solo di sviscerare l'architettura di Cell ma visto che spesso in queste discussioni si contrappone il Xenon, il processore di Xbox360, mi sono incuriosito e sono andato a leggermi qualche articolo e..... sorpresa! E' anch'esso basato sull'esecuzione in-order:

http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/3

L'articolo è aggiornato, il sito è affidabile, l'autore è molto conosciuto e preparato....
Poi ognuno tragga le sue conclusioni....

Tra l'altro a pag.4 di quell'articolo dicono che Xenon avrà una pipeline lunga (21 stadi, come il Pentium4 Northwood).
Ma come? La Intel sta per pensionare il netburst e la CPU dell'Xbox360 inizia ora la strada delle pipeline lunghe?

Bah, io non vedo proprio tutta questa differenza tra Xbox e PS3 nella CPU, almeno non tanto da paragonarli ad una Punto e una Ferrari. Per me la differenza è minima e la pipeline corta del Cell potrebbe portare a dei vantaggi. Alla fine penso che, con queste premesse, la differenza di prestazioni si giocherà tutta sulla GPU.
Aspetteremo e vedremo.

[MadRat]

MadRat, pensa che finora mi ero interessato solo di sviscerare l'architettura di Cell ma visto che spesso in queste discussioni si contrappone il Xenon, il processore di Xbox360, mi sono incuriosito e sono andato a leggermi qualche articolo e..... sorpresa! E' anch'esso basato sull'esecuzione in-order:

http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/3

L'articolo è aggiornato, il sito è affidabile, l'autore è molto conosciuto e preparato....
Poi ognuno tragga le sue conclusioni....


Sorpresa!!


Tra l'altro a pag.4 di quell'articolo dicono che Xenon avrà una pipeline lunga (21 stadi, come il Pentium4 Northwood).
Ma come? La Intel sta per pensionare il netburst e la CPU dell'Xbox360 inizia ora la strada delle pipeline lunghe?


Bella ca... che hanno fatto, pure intel sta tornando sui propri passi, il pentium m, basato sull'architettura del vecchio P3, e' molto piu' efficace e potente dei P4 EE a frequenze spropositatamente piu' elevate, e soprattutto nei giochi, si e' rivelato sorprendentemente piu' veloce anche di AMD64 (ovviamente a 32bit).

Per chi volesse dare un'occhiata..
http://www.tomshw.it/cpu.php?guide=20050525
Sempbra assurdo come una cpu piu' simile ad un pentium3 costruito a 90nm, possa ridicolizzare cosi' un P4EE ed un Athlon FX!! Gli unici cali sono sui bench delle memorie, ma all'atto pratico, nel vero utilizzo non pesa affatto.
Senza tener conto del non utilizzo da parte del P-M di tecnologie avanzate e costose come le ddr2 del P4 ad esempio.
Credo che quest'argomento possa meritare un Thread tutto per se!!


Mi chiedo dopo l'esperienza Intel, come si faccia a perseguire la strada delle pipe lunghe.. e quanto lunghe!!


Bah, io non vedo proprio tutta questa differenza tra Xbox e PS3 nella CPU, almeno non tanto da paragonarli ad una Punto e una Ferrari. Per me la differenza è minima e la pipeline corta del Cell potrebbe portare a dei vantaggi. Alla fine penso che, con queste premesse, la differenza di prestazioni si giocherà tutta sulla GPU.
Aspetteremo e vedremo.

Io seguito a credere molto nell'efficienza del Cell, soprattutto inserito in una console.. Il P4 e' gia' un fiasco di suo, ma nell'impiego ludico ha dei limiti allucinanti.

[cdimauro]

Su questo non c'è dubbio, ma considera che il branch prediction hardware su CPU OOO non è infallibile, soprattutto nei videogiochi in cui è difficile prevedere le azioni di tutti i giocatori, delle AI, ecc...
Cerchiamo di chiarire le cose: tutti i processori più moderni, siano essi Out-Of-Order o In-Order, utilizzano dei sistemi di branch prediction.
Per cui è chiaro che i branch miss sono legati alla loro implementazione, non al tipo di architettura OOO o IO in cui sono inseriti.
Qui:http://www.research.ibm.com/people/m/mikeg/papers/2004_msp.pdf vengono stimate su un PPC970 ed un FPS: sono circa il 10%. Teniamo conto, poi, che in un'architettura OOO con pipeline lunga le latenze sono elevate e una misprediction fa' perdere moltissimi cicli di clock.
Innazitutto in quell'articolo sono confrontati 3 FPS, di questi due arrivano quasi all'8% di misprediction e uno circa al 4%.

Poi bisogna vedere, appunto, la lunghezza della pipeline e quanti stadi sono necessari prima di invalidare la pipeline a causa di un branch miss, perché si tratta di cose diverse.

Per il primo punto, dipende dall'architettura: PPC970 è soltanto un'architettura dotata di pipeline (intera, chiaramente: in questi discorsi generalmente si esclude la pipeline delle istruzioni floating point), ma ce ne sono tante altre che sono dotate di pipeline più corte. Questo soltanto per puntualizzare: tu hai parlato di PPC970, che ha 16 stadi di pipeline e possimo prendere pure questo come punto di riferimento, non c'è problema.

Il secondo punto è molto importante, perché indica l'efficienza dell'implementazione, A PRESCINDERE DALLA LUNGHEZZA DELLA PIPELINE.
Ad esempio, posso avere un processore con una pipeline di 30 stadi, ma se il controllo dei branch miss viene effettuato al quarto stadio, la penalizzazione sarà soltanto di 4 cicli di clock per riempire nuovamente la pipeline.
In un'architettura a pipeline molto corta come quella del Cell, una misprediction crea un danno molto ma molto minore,
Non è esatto. La PPE ha ben 21 stadi di pipeline: 5 in più del PPC970, e le SPE hanno una lunghezza paragonabile.
anche pensando che le unità di esecuzione sono molte e se una stalla le altre mandano comunque avanti i thread.
Ci sono solamente due thread che si possono mandare avanti.
Inoltre le unità di esecuzione della PPE sono decisamente poche e molto specializzate, per cui per utilizzarle al meglio e non andare in problemi di stallo dovuti all'attesa che si liberi l'unità interessata, sarebbe meglio avere due thread che svolgano lavori piuttosto diversi (es: uno si occupa di calcoli interi, l'altro di quelli FP o VMX, o altri pattern simili).
Qui http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf stimano una perdita di 8 cicli per la PPU e 18 per una SPE:
Appunto perché la PPE, pur avendo 21 stadi, ha il controllo della validità dei salti che termina all'ottavo stadio di pipeline, per cui è meno penalizzato rispetto ad altre architetture che lo protraggono fino agli ultimi stadi.
Per la SPE ciò non è stato necessario, perché il tipo di codice da eseguire è molto meno soggetto da eseguire (il codice eseguito dagli stream processor è piuttosto lineare).

Per quanto riguarda il PPC970, ad esempio, sono necessari 12 cicli di clock (http://www-1.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4_3.html).

Ho visto che, dalla prima stesura del tuo messaggio, hai rimosso il fatto che il PPC970 abbia 100 cicli di clock di penalizzazione. ;)
Edit: inoltre vorrei far notare che, stando a quando dice Jon "Hannibal" Stokes di ArsTechnica, anche Xenon (il triple-core di Xbox360) come Cell richiede un'ottimizzazione statica per ILP e TLP: From ILP to TLP, from the processor to the programmer (http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/2) e soprattutto, stando a quanto dicono quelli di ArsTechnica, utilizzerà un'architettura in-order proprio come quella di Cell: http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/3
Diciamo che Xenon ha 3 PPE, MOLTO simili a quella presente in Cell (con la differenza di integrare in ognuna qualcosa di simile all'SPE).
Io non so se ha preso un granchio anche Hannibal, di sicuro se avesse ragione i sostenitori di Xbox360 dovrebbero trovare un'altra motivazione per celebrare la superiorità della console Microsoft non valendo più il OOO vs IOO...
Per applicazioni general purpose, sicuramente vale lo stesso discorso fatto per il Cell.

Il vantaggio di Xenon è che, avendo 3 core in grado di eseguire ognuno due thread diversi, per applicazioni multi-threaded (non di tipo SIMD / stream) presenterà prestazioni superiori al Cell.
Nel testo viene spiegato come vengono generati i workloads
No: vengono elecante le applicazioni usate. Non c'è un riferimento che permetta di riprodurre esattamente i test effettuati.
e comunque le prestazioni sono allineate su quasi tutti i test tranne uno (MS-Office2000), dove è PentiumIII-650 a prevalere sul Crusoe-533 e non il contrario come dici tu, visto che il workload viene eseguito in un tempo inferiore (=prestazione migliore).
Su questo hai ragione. Generalmente nei benchmark in cui i numeri più bassi indicano prestazioni maggiori c'è sempre un'indicazione: qui mancava del tutto.
D'altra parte fek contestava il fatto che il Crusoe-667 potesse avere prestazioni simili al PentiumIII-500, mentre nella fattispecie il confronto viene fatto con un Crusoe a frequenza più bassa rispetto a quella del PentiumIII.
Non è esatto: è vero che il P3 è a 650Mhz, ma viene fatto girare a 500Mhz. E' scritto chiaramente su ogni immagine dei test effettuati.

Non solo: il Crusoe utilizza memorie PC133 e il P3 invece PC100.

Un'altra cosa strana è che entrambi i computer vengono fatti girare con le impostazioni al massimo risparmio energetico: mi sembra un po' una forzatura. Se volevano testare la bontà del processore per quanto riguarda le prestazioni, perché non testare il sistema al massimo delle capacità (e minimo consumo, chiaramente)? Insomma, sento puzza di bruciato...
Il punto, comunque, non era se fosse più veloce il Crusoe o il PentiumIII quanto se fosse una traduzione obiettiva o no
"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"
=
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"
Mi spiace, ma sono d'accordo con fek. Le sue parole mi sembrano molto chiare e lo stesso vale per la "traduzione".

Tra l'altro, proprio il fatto che nel benchmark di Office il Crusoe (a 667Mhz) presenta prestazioni inferiori al P3 (a 500Mhz), e non il contrario come pensavo io, dimostra che il Crusoe è performante about/quasi (e quindi per me inferiore, nell'accezione comunque di questo termine in entrambe le lingue) come un P3.

Se poi teniamo in considerazioni i dubbi di cui sopra che ho espresso su questi "benchmark" (e considera che, per il tipo di lavoro fatto da Crusoe, la banda verso la memoria è particolarmente importante per riempire velocemente la sua cache di blocchi di codice tradotto), direi che il quadro generale si commenta da sé.

[cdimauro]

Io voglio il parere di repne scasb :ave: :D
IMHO è sufficiente leggere tutta la discussione... ;)

Poi è chiaro che il contributo di repne scasb è ben accetto, data la sua esperienza. :)

[cdimauro]

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo :(

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro :ave:
Quoto. Visto che è un thread molto interessante, preferirei che si mantenesse sul piano esclusivamente tecnico.

Gradirei inoltre, che nel caso in cui si effettuassero delle contestazioni su frasi dette, si riportassero sempre (per intero, se necessario): così evitiamo parte dei problemi di "miscomprensione" che si possono generare (e relativi accesi diverbi).

[fek]

Fek, discutere con te e' molto difficile, tendi a prevaricare non ascoltando, travisando le argomentazioni e puntando su tematiche tecniche spesso non chiamate in causa, questo solo per spiazzare un eventuale interlocutore piu' inesperto nell'ambito al quale vuoi sempre ricondurre i tuoi discorsi.
L'impressione che si ha, tuttavia, e' che tu voglia affermare tramite spiegazioni, che la terra giri al contrario.

Purtroppo non tutte le "battaglie" si possono combattere in casa, altrimenti ti direi "giochiamoci la soluzione alle nostre controversie su due ruote" o "vediamo chi disegna meglio una vignetta al riguardo" o ancora a chi la musica meglio..


E' una vostra opinione che non trova riscontro con gli altri utenti e dico anche a te che sei hai rimostranze da fare sul mio atteggiamento sul forum puoi parlarmene in privato.
Facendolo in pubblico dimostri solamente di esserti scottato per una discussione e voler cercare rivalsa sul piano personale.

Se fornisci informazioni palesemente sbagliate come come l'RSX con pipeline unificate, il Cell che non e' uno stream processor, l'RSX che non e' derivato dal G70 e' giusto che qualcuno corregga civilmente le tue affermazioni come e' giusto che le mie vengano corrette quando sono sbagliate.

Non capisco perche' a seguito di tuoi errori che sono stati corretto tu la debba voler buttare sul personale. Non e' un modo civile di affrontare discussioni su un forum tecnico come questo.



Forse ti manca una bella dose di umilta' e la capacita' di ascoltare cio' che la gente ha da dire.

Tutti gli altri mi dicono al contrario che non faccio mai pesare la mia preparazione e sono sempre pronto ad ascoltare cio' che mi viene detto. La verita' e' che non si puo' essere simpatici a tutti e purtroppo qualcuno per orgoglio reagisce male a normali correzioni su un forum che io personalmente accetto sempre con grande piacere.

Ed ho abbastanza umilta' e capacita' di ascoltare per capire che le questioni personali si risolvono in privato e non in pubblico. Le tue critiche pubbliche su una persona che non conosci lasciano il tempo che trovano.
E risolverle in privato non vuol dire minacciarmi di guerre sui forum come all'asilo :)

[fek]

Quoto. Visto che è un thread molto interessante, preferirei che si mantenesse sul piano esclusivamente tecnico.

Gradirei inoltre, che nel caso in cui si effettuassero delle contestazioni su frasi dette, si riportassero sempre (per intero, se necessario): così evitiamo parte dei problemi di "miscomprensione" che si possono generare (e relativi accesi diverbi).

Sarebbe molto bello, ma purtroppo in questo caso non e' una incomprensione, ma c'e' qualcosa sotto di piu' profondo. Nulla che l'ignore list non curi :)

[fantoibed]

Ad esempio, posso avere un processore con una pipeline di 30 stadi, ma se il controllo dei branch miss viene effettuato al quarto stadio, la penalizzazione sarà soltanto di 4 cicli di clock per riempire nuovamente la pipeline.
Ok, ma allora ti chiedo (perché non lo so, non per provocare! E' meglio precisarlo visti i tempi...): spostando indietro il controllo sul branch si ha il vantaggio della minor penalizzazione ma si avranno anche degli svantaggi suppongo. Quali sono?

E poi, se c'è stato un branch misprediction, le istruzioni caricate nella cache non saranno più quelle giuste (quelle che secondo il branch predictor si sarebbero dovute eseguire) e quindi la cache va scaricata e ricaricata di nuovo, quindi in totale i cicli persi saranno molto più di 4.

Non è esatto. La PPE ha ben 21 stadi di pipeline: 5 in più del PPC970, e le SPE hanno una lunghezza paragonabile.
Io ho sempre sentito parlare di pipeline molto corta degli SPE..

Ho visto che, dalla prima stesura del tuo messaggio, hai rimosso il fatto che il PPC970 abbia 100 cicli di clock di penalizzazione. ;)
Infatti, l'avevo letto in un documento che non riesco più a trovare. Dicevano che per caricare la cache normalmente servono circa 20 cicli di preavviso, nel senso che da quando parte l'ordine sul "cosa" caricare a quando te lo trovi in cache passano 20 cicli. Nel caso di un errore della predizione devi svuotare la cache delle istruzioni caricate erroneamente, individuare quelle giuste da caricare e poi caricarle e che in totale servono circa 100 cicli di clock. Siccome non trovo il documento, trovo troppo pessimistiche queste informazioni e soprattutto stavo editando il messaggio per aggiungere il link all'architettura dello Xenon ho eliminato anche quell'informazione per evitare che qualcuno ci trolleggiasse sopra...
D'altra parte potrei andare a prendere un bel po' di thread in cui alcune persone sostengono la superiorità di Xbox360 rispetto alla PS3 in virtù del esecuzione OOO della prima, ma non lo faccio... ;)

Mi spiace, ma sono d'accordo con fek. Le sue parole mi sembrano molto chiare e lo stesso vale per la "traduzione".
Vabbè, allora d'ora in poi dirò che le prestazioni delle Minardi rispetto a quelle delle McLaren sono "about the same" perché fek ha dimostrato fuori da ogni dubbio e vocabolario alla mano che "about the same" significa "più lento di".

[^TiGeRShArK^]

scusate l'OT...cmq è un peccato che non partecipi + :(

sicuramente ci sn altre teste con quel livello di preparazione tecnica cmq una in + male n faceva...

Fine OT


continuo a seguire con interesse il thread e complimenti a tutti cmq per le nozioni sviscerate :)
l'altra volta era tornata in programmazione...
ma ora in effetti è da un pò ke nn si fa vedere....

[leoneazzurro]

Ok, ma allora ti chiedo (perché non lo so, non per provocare! E' meglio precisarlo visti i tempi...): spostando indietro il controllo sul branch si ha il vantaggio della minor penalizzazione ma si avranno anche degli svantaggi suppongo. Quali sono?

E poi, se c'è stato un branch misprediction, le istruzioni caricate nella cache non saranno più quelle giuste (quelle che secondo il branch predictor si sarebbero dovute eseguire) e quindi la cache va scaricata e ricaricata di nuovo, quindi in totale i cicli persi saranno molto più di 4.



La pipeline, non la cache in generale ;). Potresti avere le istruzioni giuste in cache anche se devi svuotare la pipe per intero.
Per quanto riguarda il branch predictor, il discorso è molto complesso, in quanto dipende enormamente da come è implementato, dal grado di affidabilità, ecc.

[^TiGeRShArK^]

Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.

si vede ke anke lui, come me, ha programmato qualcosina in assembly 68000 e capisce le differenze tra un processore a 32 bit e uno a 16 bit....
se la sua architettura interna è a 32 bit IMHO non c'entra assolutamente niente il fatto ke il bus sia dimezzato. Questo implica solo delle penalità prestazionali (un pò come il 386 sx ke rispetto al dx aveva il bus dimezzato, ma nn mi pare ke nessuno abbia mai definito un 386 sx come un processore a 16 bit.....).

Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.

l'ha già spiegato.Per la difficoltà implementativa delle istruzioni CISC utilizzate nell'assembly 68000, ke erano fantastiche x scrivere direttamente in assembly, ma MOLTO pesanti.

E molto prima dicesti: "Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..

non mi pare ke cdimauro abbia mai detto ke l'assembly x86 è pià facile da programmare dell'equivalente 68000...anzi mi sembra il contrario.
Casomai diceva ke uqnato affermato da te ke gli x86 sono un'accrokkio nato da 8 bit e 640 kb (o qualcosa del genere) non corrispondeva affatto a verità.

Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente. Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime. I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.

questo è palesemente falso.I gioki su xbox giravano a 640X480.
L'unico vantaggio ke si ha x le console è ke si conosce esattamente l'hardware su cui far girare il gioco e qdi è possibile ottimizzare SOLO ed ESCLUSIVAMENTE x quella piattaforma. Sui pc invece sono necessari differenti path x mantenere la compatibilità con le skede di fascia bassa (ke tra l'altro sono la maggior parte tra tutte quelle in circolazione) e in questo modo ovviamente il lavoro dei programmatori è maggiore in quanto devono lavorare su pià fronti.
Qdi qdo dici ke se si abbandonassero le infrastrutture attuali si otterrebbero prestazioni migliori non è assolutamente vero. O meglio, potrebbe anche accadere, ma non ha alcun collegamento col discorso ke hai fatto con l'xbox....anke tenendo conto del fatto ke in realtà l'xbox è un pc e anke piuttosto scarso. Le prestazioni "relativamente" migilori dell'xbox sono dovute a qto appena spiegato.

[cdimauro]

Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.
Il parere di una rivista lascia il tempo che trova, visto che i redattori normalmente non sono studiosi o professionisti competenti in materia.
Preferisco un criterio oggettivo di uno studioso di architetture degli elaboratori.

Quanto a 68000 e 68008, l'unica cosa che gli puoi contestare è che abbiano i soli bus esterni "castrati", non che lo sia la loro architettura.
Se Motorola avesse prodotto un 68000 con bus dati esterno a 32 bit, avresti detto che è un processore a 32 bit? Eppure avrebbe condiviso la STESSA ARCHITETTURA degli altri due.

Non hai ancora risposto alla mia domanda: per te un 68008 è un processore a 8 bit? E quindi al pari di Rockwell 6510, Zilog Z80, Intel 8085, Intel 8088 (a questo punto) e addirittura del suo "progenitore", il Motorola 6800?
I tuoi ricordi sono offuscati, non girerebbe fluido come un st nemmeno su un A4000.
Vedremo.
Quasi quasi me lo ricarico su un amiga vero e non emulato.
Provalo.
Dipende tutto dal sito dal quale prendi i link.. Se noti quello dell'amiga e' farcito di commenti e spiegazioni, quello ST e' solo un elenco tecnico poco completo per altro.
Non c'è problema. Qui http://atari-ste.anvil-soft.com/html/devdocu6.htm trovi un confronto fra i vari modelli si Atari ST/TT/Falcon.
Ad esempio TI SEI SCORDATO di dire che l'st usci' con le porte midi, non solo per conquistare il mercato musicale (come fece), ma anche per surrogare il chip audio poco costoso implementato nella macchina e molti giochi, se collegati ad un economicissimo roland mt32, uscivano in audio con questo (dopo che il gioco stesso lo aveva programmato)
Quanti giochi hanno sfruttato questa possibilità? Non numeri "che ricordi tu", ma un elenco
e ti assicuro che il cio' ridicolizzava il fantomatico audio dell'amiga,
Non credo proprio, visto che i canali Amiga riproducevano sample, e non soltanto delle note.
soprattutto dal punto di vista musicale ed in oltre risparmiava memoria preziosa.
Certamente, ma l'esperienza sonora era parecchio limitata con la MIDI, a causa della mancanza dei sample. Infatti il sonoro nei giochi con l'Amiga è stato qualitativamente elevato rispetto alle altre piattaforme.
La soluzione non e' logicamente stata usata quanto le caratteristiche avanzate dell'amiga (vista la ovviamente scarsa diffusione dell'MT32 se paragonato ad un chip di serie),
Appunto, e vorrei vedere i numeri.
ma ne hanno ridotto il costo facendo sì che l'ST fosse il computer piu' vendto del mondo (fino al guinnes dei primati del 97, poi oltre non l'ho piu' comprato).
Il guiness ce l'ha ancora oggi il Commodore 64.
Tant'e' vero che la commodore e' fallita assai prima dell'Atari. (94).
Questo non c'entra nulla col resto del discorso. Gli ST sono sempre stati inferiori all'Amiga nel campo multimediale, e in quello dei giochi in particolare: questo è un dato di fatto.
Vogliamo vedere quanti giochi sono stati sviluppati per Amiga e ST? Dici che hai una notevole collezione di retrogaming: prova a contarli.
Dopo averli contati facciamo un confronto sulla qualità video e audio dei titoli disponibili su entrambe le piattaforme, così ci facciamo quattro risate...
Secondo poi la schiacciante superiorita' architetturale del'Amiga, generava un gap prestazionale notevole in ogni gioco che facesse uso di grafica poligonale. Questo lo motiviamo con 0.84 mhz in meno??
Se prendi una punto e la vesti da rolce royce, hai la comodita' di quest'ultima e le prestazioni di una bicicletta.
Anche nel campo del poligonale l'Amiga si è sempre distinta. Anzi, ha introdotto il genere, se vogliamo essere pignoli. E non soffriva di particolari gap prestazionali: anche se il Blitter era stato pensato per la grafica bitmap / bitplane, è stato sfruttato molto bene anche per la generazione di linee (poteva generare quasi un milione di pixel al secondo per questo compito) e per il riempimento dei poligoni (aveva una logica hardware di fill mentre copiava porzioni di memoria).

Basti vedere i titoli 3D disponibili: Stunt Car Racer era estremamente fluido (ancora oggi merita di essere giocato), così come Elite, Falcon F16, FA/18 Interceptor, ecc. Vogliamo confrontare gli stessi titoli disponibili per ST?
Il progetto Amiga ne 94 rischio il crash vista l'esosita' dello stesso.
Era l'84.
Richedeva troppe risorse finanziarie e di tempo.
Specifica: per quella piccola società che l'aveva fatto partire.
Fu comprato incompleto dalla Comodore (avrebbe dovuto comprarlo l'atari che era gia' in trattative e possedeva parte del team di sviluppo, situazione dalla quale scaturi' una controversia legale tra le due case).
Vinta dalla Commodore. E il progetto non era incompleto, ma in uno stadio avanzato: i chip custom erano stati completati.
Sta di fatto che la Comodore si trovo' in mano un computer incompleto e complesso, privo anche di un amiga dos finito e di un qualunque altro sistema operativo degno di questo nome,
Le cose non stanno così. Ecco qui uno dei tanti link che si trovano in rete e che riportano la storia dell'Amiga: http://www.betatesting.it/backforthefuture/storia/storianoframe.html

Poi l'AmigaDOS NON E' IL SISTEMA OPERATIVO DELL'AMIGA, ma soltanto la parte che si occupa dell'interfaccia con i filesystem.
il workbench infatti non era su rom e non era certamente degno della concorrenza. (la complessita' dell'hardware portò vantaggi e svantaggi). Assolutamente non paragonabile con il TOS della digital,
Infatti: il TOS si è rivelato sempre inferiore ad AmigaOS.
forse scopiazzato da quello che vendette anche apple,
Mi fai vedere dove l'avrebbe scopiazzato? Il s.o. ha poco a che spartire, e la GUI è completamente diversa visivamente, nelle API e nei concetti di programmazione.
ma decisamente il migliore all'epoca (so bene come non fosse multitasking, ma sarebbe stato prematuro per le conoscienze del tempo).
Il TOS era peggio perfino del MacOS, che almeno aveva un'interfaccia grafica decisamente più user friendly.

Quanto al multitasking, è la solita storia della volpe e l'uva: se non ce l'hai non è bello ed era prematuro. Intanto chi usava l'Amiga si divertiva a usarlo e a lanciare applicazioni a josa...
Io sul mio ST usavo tranquillamente 512 colori contemporaneamente e sull'STE ne usavo 4096.
Tanto tranquillamente no: per ogni riga video da visualizzare era necessario generare un interrupt ogni 16 pixel (per l'ST. Ogni 256 pixel per l'STE), per cambiare la palette dei colori. Un compito estremamente oneroso per la CPU: vai a vedere quanti cicli di clock sono necessari a un 68000 a seguito di un'interrupt e quanti ce ne vogliono per ritornare al task precedente; per non parlare poi del salvataggio e ripristino dei registri usati nello stack, e del lavoro vero e proprio di caricamento dei colori nella palette). Tu non hai la minima idea di quello che significa, visto che non hai mai programmato un 68000 in vita tua...
In ogni caso i due computer primeggiavano nei loro rispettivi campi
Gli ST solo nel MIDI.
ed a parer mio il vantaggio dell'amiga non giustificava un costo DOPPIO rispetto a quello dell'ST.
Doppio? Se lo confronti col primo Amiga, forse, il 1000. Il 500 era di poco più costoso di un ST.
La grafica evoluta cosi' come l'audio, richiedevano grandi quantitativi di ram, al tempo molto costosa. Anche questo io giudico nell'equilibrio di un progetto.
Sarà per questo che gli ST hanno sempre avuto dotazioni di memoria superiori agli Amiga...
Non nego che L'Amiga fosse una grande idea, ma conservava dei punti deboli e per di piu' finì nelle mani gestionali piu' errate. La commodore senza Tramiel non valeva piu' nulla.
E infatti s'è visto come s'è mangiato le mani per essersi fatto sfuggire l'Amiga. :asd:
Non lo so, forse all'epoca ancora non sapevi leggere?? o piu' probabilmente eri chiuso nel mondo amiga.
Leggevo di tutto. Usavo di tutto. E ho una buona memoria. Tant'è che trovo puntualmente riscontro a ciò che dico.
Forse non sai ancora leggere ora che ci penso;
Ti consiglio di risparmiare questi insulti. Piuttosto argomenta ciò che hai da dire.
io ho detto che esisteva **"ANCHE"** una versione con le ROM sulla porta d'espansione. Questo era utile per accendere il computer e senza caricare nulla, avere un MAC piu' potente dell'originale e "con tutta la ram libera".. Difficile da intuire vero?? :)
L'unico vantaggio, ma costoso: meglio investire quei soldi per comprare della ram, che si poteva usare con tutte le applicazioni.
Indubbiamente dal punto di vista grafico (solo se si parla di bitmap) l'amiga era piu' prestante,
Anche per grafica non bitmap.
ma a me risulta che l'impiego di overscreen e piu' colori di quanti imposti dal SO, fosse una realta' anche su ST (certamente meno diffusa e piu' limitata).
Con l'Amiga potevi sfruttare overscan, HalfBrite (64 colori) e HAM (4096 colori) anche da s.o.: non era una prerogativa dei giochi e dell'applicazioni che accedevano direttamente all'hardware.
Quanto all'ST, per avere più colori visualizzati contemporaneamente dovevi per forza di cose ricorre alla tecnica di cui sopra, che consumava PARECCHIA potenza di calcolo.
Sull'overscan non saprei: hai delle informazioni tecniche a riguardo che dimostrano che era possibile farlo anche con l'ST?
Per quanto riguarda l'STE, era un'ottima macchina poco sfruttata. La parte audio era il doppio piu' potente di quella dell'amiga (4 ch a 50khz o 8 a 25khz).
Non mi risulta: http://atari-ste.anvil-soft.com/html/devdocu4.htm Qui trovi tutte le informazioni su come funziona il DMA audio degli STE e su COME PROGRAMMARLO. Come puoi vedere, è in grado di riprodurre soltanto due canali stereo, e a frequenze fisse.

Al contrario, Amiga ha 4 canali completamente indipendenti, su cui è possibile controllare singolarmente volumi ed effetti vari, e che permettevano di riprodurre frequenze arbitrarie fino a 28Khz. Il limite dei 28Khz si poteva superare programmando i canali direttamente con la CPU: Aegis AudioMaster è stato il primo programma a presentare e utilizzare questa tecnica per riprodurre suoni a 56Khz.

Quindi, come vedi, l'audio dell'Amiga è rimasto superiore anche con l'arrivo degli STE.
Se poi il tuo concetto di superiorita' e' dettato solo da un audio ed una grafica piu' evoluti, senza badare alla funzionalita', ai costi ed alle altre prestazioni..
Un Amiga 500 non costava molto, e aveva un hardware favoloso (per quei tempi). Il poco di più che si pagava rispetto all'ST permetteva di avere hardware e s.o. di livello notevolmente superiore: ampiamente giustificato IMHO, e non sono il solo visto l'enorme successo che ha avuto.
beh, allora parliamo di x68000.. L'Amiga scompare d'incanto.
Per forza: era stato progettato appositamente per realizzare dei giochi, con hardware dedicato molto simile a quello che si trovava in sala giochi.
Fortunatamente un computer non e' fatto solo d'apparenza e di giochi.
Infatti anche per tutto il resto l'Amiga è stato eccellente: l'unico campo in cui non ha sfondato è stato il settore audio professionale a causa della mancanza dell'interfaccia MIDI di serie.
Un programma di annotazione midi su pc, mac o amiga quando va in crash e torna al desk smette di suonare, con l'st non succedeva. Questo fa la differenza per un professionista. Qualunque spiegazione tu abbia.
Non mettere le mani avanti: tu non hai dato NESSUNA SPIEGAZIONE, e pretendi di tapparmi la bocca col nulla? Sei troppo presuntuoso.

I programmi che giravano in background su ST installavano un hook che veniva eseguito a intervalli regolari indipendetemente dal task corrente: in questo modo il suono poteva essere riprodotto mentre si faceva altro. La STESSA tecnica è stata usata con i player per il PC / DOS.

Tutto ciò era INUTILE con l'Amiga, perché era multitasking: bastava lanciare un player e dedicarsi ad altro.
Alla fine quando si parla con te, finisce tutto per essere ricondotto ad una mala programmazine. Mentre secondo me, se una determinata tipologia di programmi girava "sempre" meglio, si puo' parlare di comprovata superiorita' hardware (almeno nel segmanto).
I "secondo me" non dico niente e non valgono nulla: a me interessano i fatti. E per i fatti serve poter mettere le mani sui sorgenti o disassemblare gli eseguibili.

In mancanza di fatti, preferisco non espormi, come invece ami fare tu.
A parte la poca pertinenza con l'argomento, le idee confuse le hai tu.
Il TT era l'evoluzione a 32bit (anche se per te e' inoncepibile questo argomento), dell'ST, venduto come postazione professionale!!.
Mi ricorda un certo Amiga 3000: l'evoluzione "professionale" dell'Amiga 2000 con tanto di 68030.
Il falcon usci molto tempo dopo come macchina completamente nuova che, dall'ST avrebbe dovuto ereditare solo la fascia di mercato, il case ed una discreta retrocompatibilita'. L'unico difetto fu la data di lancio, come detto prima, il progetto era pronto nel 90/91 e fu lanciato a meta' 93.
Non era una macchina completamente nuova. Ecco qua: http://atari-ste.anvil-soft.com/html/devdocu6.htm puoi trovare un bel po' di informazioni, anche su come programmarlo (nelle 5 pagine precedenti). Te ne riporto uno stralcio:

"The Falcon030 and its features:

? How compatible is the Falcon to the STE ? Will my STE code work flawlessly on the Falcon ?

! Yes, the Falcon was meant to be an (68000-based) successor to the 1040 STE, therefore it is easy to code Falcon-compatible STE-code. The only exceptions are:

- The Falcon does not allow 6.125 KHz DMA sound

- The Falcon's screen base address has to be a multiple of 4

- The Falcon does not have the so-called "Shadow"registers of the YM2149

To also make sure that the timing of the CPU is (almost) correct, switch the processor caches off and the CPU and the Blitter down to 8 MHz. Now, the only obstacle is the DMA-sound matrix of the Falcon which might be setup wrongly."

Inoltre qui: ftp://ftp.lip6.fr/pub/atari/Docs/hardware.txt trovi l'elenco completo delle zone di memoria usate dai vari Atari, dall'ST al Falcon, e dei registri dei vari chip. Come vedi il Falcon è MOLTO simile ai suoi predecessori, nonché abbastanza compatibile.
Non era una questione di inferiorita' architetturale quella che causo la dismissione evolutiva dei 68k, bensi' il diffondersi di un'altra piattaforma.
Chi ha mai parlato di "inferiorità architetturale" (qualunque cosa tu voglia dire con ciò)? Motorola ha ammazzato i 680x0 in favore dei PowerPC. Più esattamente, ha mantenuto i 680x0 nell'ambito dei microcontroller ad alte prestazioni.
La motorola provo' anche a creare uan versione RISC del 68000, chiamata inizialmente 78000 e poi 88000, ma a nulla servi', passo quasi inosservata.
L'unica cosa che avevano in comune 68000 e 88000 era il produttore: Motorola.
E chi ha parlato di problemi?? Io non di certo!!
Era solo la motivazione per la quale i pc, grazie alla loro modularita' ed espandibilita', (che e' il loro unico punto di forza) e grazie a taiwan, sopraffecero i computer che "puzzavano" di stantio (incredibile, siamo d'accordo su qualcosa).
Ma se non fosse stato per il mercato orientale, il pc sarebbe rimasto per sempre relegato al ruolo di macchina da ufficio, vistone il costo assurdo per l'uso domestico ed i vantaggi inesitenti.
I vantaggi c'erano, altrimenti non si sarebbe affermata come piattaforma. Hai mai programmato un PC? Sai come funziona una SuperVGA? Sei in grado di confrontare un PC con SVGA con un Amiga o un ST dal punto di vista dell'hardware?
Ma no, certo, come posso non averci pensato prima!! La motorola avrebbe dovuto sprecare milioni di dollari per lo sviluppo di una cpu che oramai non era piu' usata da nessuno!!
Infatti non l'ha buttata nel cesso: l'ha riciclata per fare altro.
Comuqnue alla fine il ppc eredita parte delle caratteristiche del 68k,
Non vedo quali, visto che sono nettamente diversi. Inoltre i PowerPC derivano dalla famiglia Power di IBM, non dai 680x0 di Motorola.
ma paragonato ad un 68060, (di pari epoca) e inferiore. Alla fine sono solo scelte commerciali dettate non solo dalla motorola, ma anche dai suoi partner.
Certamente. A ciò aggiungi anche la lungimiranza di Motorola nel ritenere l'architettura 680x0 poco scalabile per il futuro.
Gli ST non furono considerati solo negli ultimi anni, quando l'Amiga riusci a raggiungere un prezzo decente.
Cioè nell'87, con l'introduzione dell'Amiga 500: sono passati soltanto due anni dalla commercializzazione dell'ST prima e dell'Amiga 1000 dopo.
E questo riguarda solo ed ESCLUSIVAMENTE il mercato vudeoludico, del quale parli tu,
No, l'Amiga s'è affermato e, anzi, ha inventato tanti altri settori (il termine multimedia è nato con Amiga).
mercato che ha fatto affermare i pc come standard, ma che tuttavia non e' l'unico target di un utente (né di ora, né del tempo).
E chi l'ha mai negato?
Comuqnue sono d'accordissimo con chiunque sostenga che dal punto di vista ludico, l'amiga fosse piu' idoneo. Questo perche' aveva grandi capacita' di manipolazione delle bitmap, che al tempo erano il fulcro dei giochi. Mentre l'evoluzione del mercato ha poi decretato la vittoria della grafica poligonale.
Questo è avvenuto coi PC, non con altre piattaforme.
Non ho mai affrontato quest'argomento.
Li hai mischiati.
Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.
Infatti non c'entra la "qualità", ma ti ho già detto che è una questione puramente tecnica. Un 68020+ ha un'ISA molto versatile ma complesso da implementare rispetto a un 80386+, perché è dotato di istruzioni che eseguono parecchio lavoro e modalità d'indirizzamento estremamente avanzate.
Tutto ciò comporta il fatto che già la sola sezione di decodifica delle istruzioni sarebbe estremamente complessa, e richiederebbe parecchi milioni di transistor per poter garantire un throughput (erogazione) di microistruzioni paragonabili a quelli di x86.
Considera che un Athlon ha 4 decoder che sono in grado di decodificare ognuno fino a 4 istruzioni per ciclo di clock, ed è in grado di erogare fino a 3 microistruzioni per ciclo di clock. Soltanto che l'istruzione più complicata che può avere un Athlon è quella che presenta un indirizzo di memoria simile a questo: , e questo per la sola sorgente o la sola destinazione.
Un 68020+ permette qualcosa come ([Base + Offset a 32 bit] + Indice * Fattore di scala + Offset a 32 bit). E questo per sorgente e destinazione nel caso di una MOVE.
Quindi puoi immaginare l'enorme lavoro che dovrebbe fare il decoder per tirare fuori le microistruzioni da spedire all'unita di esecuzione RISC-like.
E molto prima dicesti: "Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, [B]ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..
Non cercare di rigirare le carte: i discorsi erano DIVERSI. Ciò che hai riportato è relativo all'IMPLEMENTAZIONE dell'architettura, mentre il mio commento sulla semplicità riguarda la sua PROGRAMMAZIONE.
Mi sembra di essere stato piuttosto chiaro su questo punto.
Ne ho parlato pocanzi
Di cosa?
Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente.
Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime.
Infatti è così, e le piattaforme non sono così simili, visto che non esiste una scheda video che funzioni come l'X-Box.
I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.
Non puoi confrontare capra e cavoli: Halo per X-Box e PC è un PRODOTTO DIVERSO CHE FUNZIONA IN MODO DIVERSO E RICHIEDE HARDWARE DIVERSO. Punto.
Per quanto mi riguarda, l'oggettivita degli eventi va ben oltre a qualunque "teoria".
Oggettività che è tutta da dimostrare, visto che manca un elemento fondamentale: il fatto che le due applicazioni NON SIANO IDENTICHE.

In mancanza di una valutazione che sia DIMOSTRATA oggettiva, sono le tue che rimangono soltanto teorie.
La mia negazione era assoluta non meno di quanto lo fosse la tua relativamente ai dsp cell.
:mc: E' inutile che provi a cambiare discorso: non attacca.

Quanto alla mia valutazione su Cell, cosa vorresti mettermi in bocca questa volta?
Che simpatico, tuttavia AMD lavorando sull'efficienza, piu' che sulla potenza bruta dei mhz, vendeva un 2,2ghz come oppositore di un 3,2 (scarto di un ghz ancora presente, rispetto ai processori Intel) e questa differenza si e' accumilata per lo piu' durante il 2003. Solo con l'avvento dei K8 si e' spinta oltre i 2,2 ghz.. frequenza che raggiunse molto tempo prima.
Athlon e P4 sono processori diversi con un'implementazione completamente diversa dell'architettura x86: non puoi confrontare i 2,2Ghz del primo coi 3,2Ghz del secondo. E' un confronto assolutamente privo di senso.
Tra il dire ed il fare..
Bastano le specifiche e la buona volontà di qualcuno. Come è sempre stato fatto nel campo degli emulatori, tra l'altro.
Mi dai un link con un emulatore Jaguar degno di questo nome??
Per ora io uso quello vero.
www.mess.org.
Infatti non parlo di problemi emulativi.. ma del pc stesso, al difuori di ogni emulazione. Sono problemi che tutt'ora affliggono questi sistemi ed (nel campo musicale si riflettono in particolar modo), rendono praticamente inutilizzabile un pc privo di una costosa scheda che lavori per conto proprio.
Se questa me la chiami evoluzione..
I problemi di cui non fai altro che parlare non li hai mai esplicitati: a cosa ti riferisci di preciso? E cerca di essere chiaro: dev'essere possibile riprodurlo su un PC nelle condizioni che elencherai (spero).
Purtroppo quasi tutte le chiavi di protezione dell'atari, come anche quella del cubase Audio, erano inserite nella porta laterale per cartucce d'espansione. (come lo spectre gcr).. Dunque mi sembra un po' difficile inserirla in un pc. Il problema purtoppo non si pone, vista l'inesitenza dell'emulatore.
Non sai che darei per averlo, ma purtroppo nemmeno quello dell'ST e' ancora perfetto.
Allora amen. Per emulare anche quella porta d'espansione sarebbe necessario sviluppare un dispositivo a cui collegare queste chiavi: non ha senso farlo, perché non ci sarebbe mercato.

[^TiGeRShArK^]

Fek, discutere con te e' molto difficile, tendi a prevaricare non ascoltando, travisando le argomentazioni e puntando su tematiche tecniche spesso non chiamate in causa, questo solo per spiazzare un eventuale interlocutore piu' inesperto nell'ambito al quale vuoi sempre ricondurre i tuoi discorsi.
L'impressione che si ha, tuttavia, e' che tu voglia affermare tramite spiegazioni, che la terra giri al contrario.

Purtroppo non tutte le "battaglie" si possono combattere in casa, altrimenti ti direi "giochiamoci la soluzione alle nostre controversie su due ruote" o "vediamo chi disegna meglio una vignetta al riguardo" o ancora a chi la musica meglio..

Forse ti manca una bella dose di umilta' e la capacita' di ascoltare cio' che la gente ha da dire.
non sono d'accordo.
è ovvio ke x parlare di certe cose sono necessarie delle basi tecniche.
E tra l'altro non credo ke sia questo il caso...
il problema di fantoibed, a quanto ho capito, piu' ke dovuto a mancanza di basi tecniche credo dipendesse da una certa "fantasia" ke l'ha portato a immaginare cose di cui, allo stato attuale, non si sa niente.
E infine non mi pare assolutamente ke fek stia affermando ke la terra giri al contrario. se poi ci si vuole attaccare al cavillo di una traduzione x dire ke si ha ragione è un altro conto.

[CONFITEOR]

Il parere di una rivista lascia il tempo che trova, visto che i redattori normalmente non sono studiosi o professionisti competenti in materia.
Preferisco un criterio oggettivo di uno studioso di architetture degli elaboratori.

Quanto a 68000 e 68008, l'unica cosa che gli puoi contestare è che abbiano i soli bus esterni "castrati", non che lo sia la loro architettura.
Se Motorola avesse prodotto un 68000 con bus dati esterno a 32 bit, avresti detto che è un processore a 32 bit? Eppure avrebbe condiviso la STESSA ARCHITETTURA degli altri due.

Non hai ancora risposto alla mia domanda: per te un 68008 è un processore a 8 bit? E quindi al pari di Rockwell 6510, Zilog Z80, Intel 8085, Intel 8088 (a questo punto) e addirittura del suo "progenitore", il Motorola 6800?

Vedremo.

Provalo.

Non c'è problema. Qui http://atari-ste.anvil-soft.com/html/devdocu6.htm trovi un confronto fra i vari modelli si Atari ST/TT/Falcon.

Quanti giochi hanno sfruttato questa possibilità? Non numeri "che ricordi tu", ma un elenco

Non credo proprio, visto che i canali Amiga riproducevano sample, e non soltanto delle note.

Certamente, ma l'esperienza sonora era parecchio limitata con la MIDI, a causa della mancanza dei sample. Infatti il sonoro nei giochi con l'Amiga è stato qualitativamente elevato rispetto alle altre piattaforme.

Appunto, e vorrei vedere i numeri.

Il guiness ce l'ha ancora oggi il Commodore 64.

Questo non c'entra nulla col resto del discorso. Gli ST sono sempre stati inferiori all'Amiga nel campo multimediale, e in quello dei giochi in particolare: questo è un dato di fatto.
Vogliamo vedere quanti giochi sono stati sviluppati per Amiga e ST? Dici che hai una notevole collezione di retrogaming: prova a contarli.
Dopo averli contati facciamo un confronto sulla qualità video e audio dei titoli disponibili su entrambe le piattaforme, così ci facciamo quattro risate...

Anche nel campo del poligonale l'Amiga si è sempre distinta. Anzi, ha introdotto il genere, se vogliamo essere pignoli. E non soffriva di particolari gap prestazionali: anche se il Blitter era stato pensato per la grafica bitmap / bitplane, è stato sfruttato molto bene anche per la generazione di linee (poteva generare quasi un milione di pixel al secondo per questo compito) e per il riempimento dei poligoni (aveva una logica hardware di fill mentre copiava porzioni di memoria).

Basti vedere i titoli 3D disponibili: Stunt Car Racer era estremamente fluido (ancora oggi merita di essere giocato), così come Elite, Falcon F16, FA/18 Interceptor, ecc. Vogliamo confrontare gli stessi titoli disponibili per ST?

Era l'84.

Specifica: per quella piccola società che l'aveva fatto partire.

Vinta dalla Commodore. E il progetto non era incompleto, ma in uno stadio avanzato: i chip custom erano stati completati.

Le cose non stanno così. Ecco qui uno dei tanti link che si trovano in rete e che riportano la storia dell'Amiga: http://www.betatesting.it/backforthefuture/storia/storianoframe.html

Poi l'AmigaDOS NON E' IL SISTEMA OPERATIVO DELL'AMIGA, ma soltanto la parte che si occupa dell'interfaccia con i filesystem.

Infatti: il TOS si è rivelato sempre inferiore ad AmigaOS.

Mi fai vedere dove l'avrebbe scopiazzato? Il s.o. ha poco a che spartire, e la GUI è completamente diversa visivamente, nelle API e nei concetti di programmazione.

Il TOS era peggio perfino del MacOS, che almeno aveva un'interfaccia grafica decisamente più user friendly.

Quanto al multitasking, è la solita storia della volpe e l'uva: se non ce l'hai non è bello ed era prematuro. Intanto chi usava l'Amiga si divertiva a usarlo e a lanciare applicazioni a josa...

Tanto tranquillamente no: per ogni riga video da visualizzare era necessario generare un interrupt ogni 16 pixel (per l'ST. Ogni 256 pixel per l'STE), per cambiare la palette dei colori. Un compito estremamente oneroso per la CPU: vai a vedere quanti cicli di clock sono necessari a un 68000 a seguito di un'interrupt e quanti ce ne vogliono per ritornare al task precedente; per non parlare poi del salvataggio e ripristino dei registri usati nello stack, e del lavoro vero e proprio di caricamento dei colori nella palette). Tu non hai la minima idea di quello che significa, visto che non hai mai programmato un 68000 in vita tua...

Gli ST solo nel MIDI.

Doppio? Se lo confronti col primo Amiga, forse, il 1000. Il 500 era di poco più costoso di un ST.

Sarà per questo che gli ST hanno sempre avuto dotazioni di memoria superiori agli Amiga...

E infatti s'è visto come s'è mangiato le mani per essersi fatto sfuggire l'Amiga. :asd:

Leggevo di tutto. Usavo di tutto. E ho una buona memoria. Tant'è che trovo puntualmente riscontro a ciò che dico.

Ti consiglio di risparmiare questi insulti. Piuttosto argomenta ciò che hai da dire.

L'unico vantaggio, ma costoso: meglio investire quei soldi per comprare della ram, che si poteva usare con tutte le applicazioni.

Anche per grafica non bitmap.

Con l'Amiga potevi sfruttare overscan, HalfBrite (64 colori) e HAM (4096 colori) anche da s.o.: non era una prerogativa dei giochi e dell'applicazioni che accedevano direttamente all'hardware.
Quanto all'ST, per avere più colori visualizzati contemporaneamente dovevi per forza di cose ricorre alla tecnica di cui sopra, che consumava PARECCHIA potenza di calcolo.
Sull'overscan non saprei: hai delle informazioni tecniche a riguardo che dimostrano che era possibile farlo anche con l'ST?

Non mi risulta: http://atari-ste.anvil-soft.com/html/devdocu4.htm Qui trovi tutte le informazioni su come funziona il DMA audio degli STE e su COME PROGRAMMARLO. Come puoi vedere, è in grado di riprodurre soltanto due canali stereo, e a frequenze fisse.

Al contrario, Amiga ha 4 canali completamente indipendenti, su cui è possibile controllare singolarmente volumi ed effetti vari, e che permettevano di riprodurre frequenze arbitrarie fino a 28Khz. Il limite dei 28Khz si poteva superare programmando i canali direttamente con la CPU: Aegis AudioMaster è stato il primo programma a presentare e utilizzare questa tecnica per riprodurre suoni a 56Khz.

Quindi, come vedi, l'audio dell'Amiga è rimasto superiore anche con l'arrivo degli STE.

Un Amiga 500 non costava molto, e aveva un hardware favoloso (per quei tempi). Il poco di più che si pagava rispetto all'ST permetteva di avere hardware e s.o. di livello notevolmente superiore: ampiamente giustificato IMHO, e non sono il solo visto l'enorme successo che ha avuto.

Per forza: era stato progettato appositamente per realizzare dei giochi, con hardware dedicato molto simile a quello che si trovava in sala giochi.

Infatti anche per tutto il resto l'Amiga è stato eccellente: l'unico campo in cui non ha sfondato è stato il settore audio professionale a causa della mancanza dell'interfaccia MIDI di serie.

Non mettere le mani avanti: tu non hai dato NESSUNA SPIEGAZIONE, e pretendi di tapparmi la bocca col nulla? Sei troppo presuntuoso.

I programmi che giravano in background su ST installavano un hook che veniva eseguito a intervalli regolari indipendetemente dal task corrente: in questo modo il suono poteva essere riprodotto mentre si faceva altro. La STESSA tecnica è stata usata con i player per il PC / DOS.

Tutto ciò era INUTILE con l'Amiga, perché era multitasking: bastava lanciare un player e dedicarsi ad altro.

I "secondo me" non dico niente e non valgono nulla: a me interessano i fatti. E per i fatti serve poter mettere le mani sui sorgenti o disassemblare gli eseguibili.

In mancanza di fatti, preferisco non espormi, come invece ami fare tu.

Mi ricorda un certo Amiga 3000: l'evoluzione "professionale" dell'Amiga 2000 con tanto di 68030.

Non era una macchina completamente nuova. Ecco qua: http://atari-ste.anvil-soft.com/html/devdocu6.htm puoi trovare un bel po' di informazioni, anche su come programmarlo (nelle 5 pagine precedenti). Te ne riporto uno stralcio:

"The Falcon030 and its features:

? How compatible is the Falcon to the STE ? Will my STE code work flawlessly on the Falcon ?

! Yes, the Falcon was meant to be an (68000-based) successor to the 1040 STE, therefore it is easy to code Falcon-compatible STE-code. The only exceptions are:

- The Falcon does not allow 6.125 KHz DMA sound

- The Falcon's screen base address has to be a multiple of 4

- The Falcon does not have the so-called "Shadow"registers of the YM2149

To also make sure that the timing of the CPU is (almost) correct, switch the processor caches off and the CPU and the Blitter down to 8 MHz. Now, the only obstacle is the DMA-sound matrix of the Falcon which might be setup wrongly."

Inoltre qui: ftp://ftp.lip6.fr/pub/atari/Docs/hardware.txt trovi l'elenco completo delle zone di memoria usate dai vari Atari, dall'ST al Falcon, e dei registri dei vari chip. Come vedi il Falcon è MOLTO simile ai suoi predecessori, nonché abbastanza compatibile.

Chi ha mai parlato di "inferiorità architetturale" (qualunque cosa tu voglia dire con ciò)? Motorola ha ammazzato i 680x0 in favore dei PowerPC. Più esattamente, ha mantenuto i 680x0 nell'ambito dei microcontroller ad alte prestazioni.

L'unica cosa che avevano in comune 68000 e 88000 era il produttore: Motorola.

I vantaggi c'erano, altrimenti non si sarebbe affermata come piattaforma. Hai mai programmato un PC? Sai come funziona una SuperVGA? Sei in grado di confrontare un PC con SVGA con un Amiga o un ST dal punto di vista dell'hardware?

Infatti non l'ha buttata nel cesso: l'ha riciclata per fare altro.

Non vedo quali, visto che sono nettamente diversi. Inoltre i PowerPC derivano dalla famiglia Power di IBM, non dai 680x0 di Motorola.

Certamente. A ciò aggiungi anche la lungimiranza di Motorola nel ritenere l'architettura 680x0 poco scalabile per il futuro.

Cioè nell'87, con l'introduzione dell'Amiga 500: sono passati soltanto due anni dalla commercializzazione dell'ST prima e dell'Amiga 1000 dopo.

No, l'Amiga s'è affermato e, anzi, ha inventato tanti altri settori (il termine multimedia è nato con Amiga).

E chi l'ha mai negato?

Questo è avvenuto coi PC, non con altre piattaforme.

Li hai mischiati.

Infatti non c'entra la "qualità", ma ti ho già detto che è una questione puramente tecnica. Un 68020+ ha un'ISA molto versatile ma complesso da implementare rispetto a un 80386+, perché è dotato di istruzioni che eseguono parecchio lavoro e modalità d'indirizzamento estremamente avanzate.
Tutto ciò comporta il fatto che già la sola sezione di decodifica delle istruzioni sarebbe estremamente complessa, e richiederebbe parecchi milioni di transistor per poter garantire un throughput (erogazione) di microistruzioni paragonabili a quelli di x86.
Considera che un Athlon ha 4 decoder che sono in grado di decodificare ognuno fino a 4 istruzioni per ciclo di clock, ed è in grado di erogare fino a 3 microistruzioni per ciclo di clock. Soltanto che l'istruzione più complicata che può avere un Athlon è quella che presenta un indirizzo di memoria simile a questo: [Base + Indice * Fattore di scala + Offset a 32 bit], e questo per la sola sorgente o la sola destinazione.
Un 68020+ permette qualcosa come ([Base + Offset a 32 bit] + Indice * Fattore di scala + Offset a 32 bit). E questo per sorgente e destinazione nel caso di una MOVE.
Quindi puoi immaginare l'enorme lavoro che dovrebbe fare il decoder per tirare fuori le microistruzioni da spedire all'unita di esecuzione RISC-like.

Non cercare di rigirare le carte: i discorsi erano DIVERSI. Ciò che hai riportato è relativo all'IMPLEMENTAZIONE dell'architettura, mentre il mio commento sulla semplicità riguarda la sua PROGRAMMAZIONE.
Mi sembra di essere stato piuttosto chiaro su questo punto.

Di cosa?

Infatti è così, e le piattaforme non sono così simili, visto che non esiste una scheda video che funzioni come l'X-Box.

Non puoi confrontare capra e cavoli: Halo per X-Box e PC è un PRODOTTO DIVERSO CHE FUNZIONA IN MODO DIVERSO E RICHIEDE HARDWARE DIVERSO. Punto.

Oggettività che è tutta da dimostrare, visto che manca un elemento fondamentale: il fatto che le due applicazioni NON SIANO IDENTICHE.

In mancanza di una valutazione che sia DIMOSTRATA oggettiva, sono le tue che rimangono soltanto teorie.

:mc: E' inutile che provi a cambiare discorso: non attacca.

Quanto alla mia valutazione su Cell, cosa vorresti mettermi in bocca questa volta?

Athlon e P4 sono processori diversi con un'implementazione completamente diversa dell'architettura x86: non puoi confrontare i 2,2Ghz del primo coi 3,2Ghz del secondo. E' un confronto assolutamente privo di senso.

Bastano le specifiche e la buona volontà di qualcuno. Come è sempre stato fatto nel campo degli emulatori, tra l'altro.

www.mess.org.

I problemi di cui non fai altro che parlare non li hai mai esplicitati: a cosa ti riferisci di preciso? E cerca di essere chiaro: dev'essere possibile riprodurlo su un PC nelle condizioni che elencherai (spero).

Allora amen. Per emulare anche quella porta d'espansione sarebbe necessario sviluppare un dispositivo a cui collegare queste chiavi: non ha senso farlo, perché non ci sarebbe mercato.
:eek:

[fantoibed]

E' una vostra opinione che non trova riscontro con gli altri utenti e dico anche a te che sei hai rimostranze da fare sul mio atteggiamento sul forum puoi parlarmene in privato.
Facendolo in pubblico dimostri solamente di esserti scottato per una discussione e voler cercare rivalsa sul piano personale.

Se fornisci informazioni palesemente sbagliate come come l'RSX con pipeline unificate, il Cell che non e' uno stream processor, l'RSX che non e' derivato dal G70 e' giusto che qualcuno corregga civilmente le tue affermazioni come e' giusto che le mie vengano corrette quando sono sbagliate.

Non capisco perche' a seguito di tuoi errori che sono stati corretto tu la debba voler buttare sul personale. Non e' un modo civile di affrontare discussioni su un forum tecnico come questo.




Tutti gli altri mi dicono al contrario che non faccio mai pesare la mia preparazione e sono sempre pronto ad ascoltare cio' che mi viene detto. La verita' e' che non si puo' essere simpatici a tutti e purtroppo qualcuno per orgoglio reagisce male a normali correzioni su un forum che io personalmente accetto sempre con grande piacere.

Ed ho abbastanza umilta' e capacita' di ascoltare per capire che le questioni personali si risolvono in privato e non in pubblico. Le tue critiche pubbliche su una persona che non conosci lasciano il tempo che trovano.
E risolverle in privato non vuol dire minacciarmi di guerre sui forum come all'asilo :)

:eek:

[cdimauro]

Ok, ma allora ti chiedo (perché non lo so, non per provocare! E' meglio precisarlo visti i tempi...): spostando indietro il controllo sul branch si ha il vantaggio della minor penalizzazione ma si avranno anche degli svantaggi suppongo. Quali sono?
Quello della non linearità della pipeline: inserire dei controlli in mezzo agli stadi di pipeline non è semplice come delegare all'ultimo stadio di pipeline questo compito.
E poi, se c'è stato un branch misprediction, le istruzioni caricate nella cache non saranno più quelle giuste (quelle che secondo il branch predictor si sarebbero dovute eseguire) e quindi la cache va scaricata e ricaricata di nuovo, quindi in totale i cicli persi saranno molto più di 4.
Su questo leoneazzurro mi anticipato leoneazzurro. ;)
Io ho sempre sentito parlare di pipeline molto corta degli SPE..
Rifletti su questo: se una SPE ha 19 cicli di penalizzazione a causa di un branch misprediction, non pensi che debba avere almeno 19 stadi di pipeline?

Comunque se leggi il documento di presentazione del 2005 di presentazione di Cell, di cui hai postato il link in merito a questo discorso, trovi il diagramma completo della pipeline sia del PPE sia delle SPE.
Infatti, l'avevo letto in un documento che non riesco più a trovare. Dicevano che per caricare la cache normalmente servono circa 20 cicli di preavviso, nel senso che da quando parte l'ordine sul "cosa" caricare a quando te lo trovi in cache passano 20 cicli. Nel caso di un errore della predizione devi svuotare la cache delle istruzioni caricate erroneamente, individuare quelle giuste da caricare e poi caricarle e che in totale servono circa 100 cicli di clock. Siccome non trovo il documento, trovo troppo pessimistiche queste informazioni e soprattutto stavo editando il messaggio per aggiungere il link all'architettura dello Xenon ho eliminato anche quell'informazione per evitare che qualcuno ci trolleggiasse sopra...
OK. Comunque anche su questo vale quanto scritto da leoneazzurro: si verifica soltanto nel caso in cui il codice non sia presente in cache, non a ogni misprediction (altrimenti, con la lentezza di caricamento della cache, i processori passerebbero la maggior parte del tempo a girarsi i pollici).
D'altra parte potrei andare a prendere un bel po' di thread in cui alcune persone sostengono la superiorità di Xbox360 rispetto alla PS3 in virtù del esecuzione OOO della prima, ma non lo faccio... ;)
Postali pure, non c'è problema: anch'io pensavo che fosse OOO, come tutti quanti del resto (non ho visto un solo commento che sostenesse che Xenon fosse In order). ADESSO ci sono delle informazioni specifiche, per cui è ovvio che quanto scritto risulta parzialmente non valido.
Vabbè, allora d'ora in poi dirò che le prestazioni delle Minardi rispetto a quelle delle McLaren sono "about the same" perché fek ha dimostrato fuori da ogni dubbio e vocabolario alla mano che "about the same" significa "più lento di".
Lasciando perdere le parole, su cui è facile giocare (ma per quanto MI riguarda, e lo ripeto, il discorso è chiaro), direi che i fatti sono ben più importanti. Quel link riporta dei fatti da cui è possibile trarre delle valutazioni ben precise. Valutazioni che danno ragione a fek.

Comunque è inutile continuare su questa linea: lasciamo che siano i lettori del forum a giudicare chi ha ragione e chi no. Io ho espresso la mia opinione, e mi fermo qui.

[Marco71]

Se parli del 68000, sì, e tra l'altro l'avevo già scritto nel mio messaggio.

Il 68008, che internamente aveva la stessa architettura, era però più limitato, perché aveva 20 bit per il bus indirizzi e 8 bit per quello dei dati: secondo il tuo criterio avrei dovuto definirlo come processore a 8 bit? Oppure a 8 / 32 bit?

"Full 32 bit": ti ho già chiesto in base a quale criterio (oggettivo) classifichi un processore come "full x bit" o "non full x bit".

Quanto alla flessibilità, non so a cosa ti riferisci: dovresti essere più chiaro.

Ti ricordo che tu hai confrontato un 68000 a 8 Mhz con un 486 a 66Mhz.
Ti ho fatto notare che un 68000, per eseguire una NOP (che è un'istruzione che non fa nulla), impiega ben 4 cicli di clock.
Ti ho fatto notare che un 486 esegue la maggior parte delle istruzioni (quindi anche ben più complicate di una NOP) in un solo ciclo di clock.
Questo avrebbe dovuto farti dedurre che la disparità fra la "potenza di calcolo / efficacia" (qualunque cosa tu intendi con questi termini) è MOSTRUOSAMENTE a favore di quest'ultimo.

Hai mai visto girare la prima versione di UAE (l'emulatore Amiga più conosciuto / diffuso / preciso / usabile) su un 486 (a 50Mhz)? Se lo ritieni così inefficiente / poco potente, mi spieghi come faceva ad emulare un 68000 a 7,09Mhz, con tanto di chip custom, discretamente?

Ovviamente l'emulazione dei chip custom era primordiale, ma in questo contesto m'interessa puntualizzare la capacità del 486 di emulare il 68000: in base a quanto hai scritto, come potrebbe un 486 emulare un processore che tu hai definito come "suo pari", un 68000 a 8Mhz?

Questo perché l'hai postato? A me non serviva e non vedo cosa c'entri col resto del discorso.

Anch'io ho parlato di architetture, e le ho messe in relazione in base a quel che erano in grado di fare (tipo di operazioni) e a come lo facevano (tempo di esecuzione), per dimostrare che il tuo confronto non era (e non è) assolutamente realistico.

Ti ho già scritto che bisogna vedere in che modo sono stati realizzati i programmi / conversioni: non puoi giudicare soltanto in base all'apparenza.

Idem come sopra: non puoi effettuare dei confronti senza avere in mano dati chiari su come sono stati realizzati i programmi per le due architetture.

Esempio: Halo è un gioco per X-Box e per PC, ma è stato scritto e funziona in maniera diversa. Non hanno preso il programma così com'era, e semplicemente ricompilato (e anche qui bisognerebbe vedere come, ma tralascio questo dettaglio perché complicherebbe ulteriormente il discorso).

Sono informato, ed è perfettamente in grado di farlo. Puoi dirmi che non è ciò per cui è stato pensato e realizzato, ma questo è UN ALTRO DISCORSO.

Vedi sopra: questo è il motivo per cui è stato integrato nel Falcon, ma non vuol dire che non lo si possa usare anche per altro (anche nel campo dell'elaborazione grafica avrebbe delle buone prestazioni).

Atari ST e Falcon hanno la stessa interfaccia MIDI, che altri non è se non una seriale che "viaggia" a circa 31000 baud: gestire una seriale a velocità così basse è capace di farlo anche il 6502 a 1Mhz del Vic20.

Il problema, come ti ho già detto, è che bisogna vedere IN CHE MODO è stato realizzato il programma che la usa.

Stai mischiando capra e cavoli: parli di sistemi completamente diversi, che usano programmi completamente diversi.
Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD. Chissà perché...

La mia, ai tempi, era più che una simpatia. D'altra parte un Amiga permetteva di emulare tranquillamente anche un Mac o un Atari ST, ma il viceversa non è mai stato possibile...

Sono anni che ci penso, e penso che Motorola abbia avuto le sue buone ragioni per abbandonare quest'architettura. Anche se era molto "bella" (ti parlo come programmatore assembly), a livello di implementazione era estremamente complicata.

Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Anche ipotizzando l'adozione di un "core RISC", come oggi avviene per la famiglia x86 (e i PowerPC di IBM), il lavoro sarebbe enorme. Per l'esempio di cui sopra, sarebbero necessarie almeno 5 microistruzioni per portare a termine l'operazione (una "semplice" MOVE), e i due accessi in memoria metterebbero sotto stress sia le cache dati sia la cache TLB.

Poi non parliamo nemmeno del decoder delle istruzioni, che risulterebbe MOSTRUOSAMENTE più complicato, rispetto a quello degli x86.

Quindi, in definitiva e per rispondere a quanto chiedevi, mi sembra alquanto difficile già soltanto pensare di implementare un'architettura come quella dei 68000 "secondo i canoni attuali", e sicuramente sarebbe impossibile raggiungere frequenze di lavoro comparabili, a parità di tecnologia produttiva utilizzata.

Anche questo è un altro discorso, e non c'entra niente col confronto che hai tirato in ballo.

Ti ricordo che il paragone l'hai fatto tu: io non me lo sarei mai sognato.

Le architetture le possiamo anche paragonare, ma non ne salterebbe nulla di utile (che te ne fai?)

Per i risultati, bisognerebbe prima decidere il tipo di applicazioni da usare, e poi, simulatori alla mano (a meno che tu non abbia a disposizione i processori oggetto del confronto), verificare quanti cicli di clock sono necessari per portare a termine un ben preciso lavoro.

E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486... ;)

Non potevi capire: è un discorso che è stato affrontato in un altro thread.

Se volevi che finisse, ti sarebbe bastata una riga per farlo, non un romanzo in cui rispondevi a quanto ho scritto. Comodo uscirtene fuori così, sottraendoti al confronto dopo aver detto la tua.

Salve Dr. Di Mauro...
Volevo aggiungere se posso una piccola frasucola alla vostra ampia digressione...
L'Intel 80486 era in grado di eseguire in un "ciclo di clock" (simil R.I.S.C) un ristretto sottoinsieme di istruzioni del set x86 e precisamente quelle definite da Intel di "nucleo"...
Poi leggendo il manuale intel di rif. per il programmatore il numero di cicli effettivamente impiegato è variabilissimo e dipende da molte variabili quali ad esempio il modo di indirizzamento, la presenza o meno delle istruzioni e dei dati all'interno della cache memory interna ecc. ecc.
Io personalmente ho sempre "strizzato l'occhio" molto di più alla famiglia 68000 di processori a 32bit (e ci includo anche il 68008 del QL Sinclair, il 68010 ed il 68012).
Nessuno di questo thread sa dove sia possibile reperire maggiori informazioni sul coprocessore Weitek 4167 (mi interessa di più il "lato hardware") ?
Grazie.

Marco71.

P.S: Quando avevo i miei due Amiga 500 (ora riposti) "sbavavo" per le schede acceleratrici dotate di 68020/68030 e 68881/68882...
Mi piacerebbe trovare gli hardware manuals dei 6888x...sigh!

[fantoibed]

Quello della non linearità della pipeline: inserire dei controlli in mezzo agli stadi di pipeline non è semplice come delegare all'ultimo stadio di pipeline questo compito.
Ok. Quindi è solo una questione di semplicità di implementazione sul die?

Su questo leoneazzurro mi anticipato leoneazzurro. ;)
Sì, e tra l'altro ho notato sul documento in cui si stimano gli errori di predizione sui PPC970 già linkato, che la mancata presenza in cache delle istruzioni corrette è un fenomeno alquanto raro.
Ma a questo punto chiedo (a te, leoneazzurro o a chi ha voglia di rispondere), se da una predizione corretta ad una scorretta la latenza passa da 1 a 4 cicli, ha ancora senso togliere spazio sul die alle unità di calcolo per implementare funzioni di ILP/TLP dinamiche anziché statiche (o eventualmente dinamiche fatte via software anziché via hardware) solo per guadagnare 3 cicli in quelle poche volte in cui la branch-prediction dinamica sia più efficiente di quella statica?
Anche se ILP/TLP statiche fatte in fase di compilazione facessero lievitare dall'8% al 20% il mispredict rate, le maggiore potenza di calcolo (dovuta alla sostituzione della logica di controllo con unità di esecuzione) non potrebbe più che compensare l'aumentato fattore di predizioni errate?

Rifletti su questo: se una SPE ha 19 cicli di penalizzazione a causa di un branch misprediction, non pensi che debba avere almeno 19 stadi di pipeline?
Comunque se leggi il documento di presentazione del 2005 di presentazione di Cell, di cui hai postato il link in merito a questo discorso, trovi il diagramma completo della pipeline sia del PPE sia delle SPE.
C'è anche qui: http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf e mi sembra molto corta. Non è che magari gli stages sono pochi ma ognuno di essi ha una latenza di più cicli? In effetti i conti non tornerebbero altrimenti.

[fantoibed]

Nessuno di questo thread sa dove sia possibile reperire maggiori informazioni sul coprocessore Weitek 4167 (mi interessa di più il "lato hardware") ?
Mi piacerebbe trovare gli hardware manuals dei 6888x...sigh!

Prova a dare un'occhiata a questi:
http://hysteria.sk/~mikro/Coding/Atari/Maggie/FPU.TXT
http://fux0r.phathookups.com/programming-tutorials/Assembly/fpuopcode.html
http://thorkildsen.no/faqsys/docs/copro16a.txt

[Marco71]

...l'ultimo file Copro16A.txt lo avevo già "divorato" tempo fà...
Mi potete confermare che anche la f.p.u dell'MC68060 come quella del 68040 implementava le funzioni trascendenti (sin, cos, log, ecc.) tramite delle trap ad apposite routine "software" ?
All'epoca mi dispiacque non poco vedere che il mio amato MC68040 non aveva in hardware tutto il set di istruzioni I.E.E.E 754/854.
Cmq. l'architettura "Harvard" del 68030 mi piaceva di più di quella 80386...
Grazie.

Marco71.

[cdimauro]

Salve Dr. Di Mauro...
Cesare, semplicemente Cesare. ;)
Volevo aggiungere se posso una piccola frasucola alla vostra ampia digressione...
L'Intel 80486 era in grado di eseguire in un "ciclo di clock" (simil R.I.S.C) un ristretto sottoinsieme di istruzioni del set x86 e precisamente quelle definite da Intel di "nucleo"...
Poi leggendo il manuale intel di rif. per il programmatore il numero di cicli effettivamente impiegato è variabilissimo e dipende da molte variabili quali ad esempio il modo di indirizzamento, la presenza o meno delle istruzioni e dei dati all'interno della cache memory interna ecc. ecc.
Infatti è così, e la stessa cosa si verifica col 68040 di Motorola.
Motorola ha dichiarato 20 MIPS per un 68040 a 25Mhz, ma è chiaro che sono valori "sulla carta", come i 15MIPS che Intel dichiarato per l'80486 a 25Mhz.
Io personalmente ho sempre "strizzato l'occhio" molto di più alla famiglia 68000 di processori a 32bit (e ci includo anche il 68008 del QL Sinclair, il 68010 ed il 68012).
Quoto in toto: è l'architettura che tutt'ora preferisco/rei programmare in assembly. ;)
Nessuno di questo thread sa dove sia possibile reperire maggiori informazioni sul coprocessore Weitek 4167 (mi interessa di più il "lato hardware") ?
Grazie.
Mi spiace.
Marco71.

P.S: Quando avevo i miei due Amiga 500 (ora riposti) "sbavavo" per le schede acceleratrici dotate di 68020/68030 e 68881/68882...
Mi piacerebbe trovare gli hardware manuals dei 6888x...sigh!
A casa ho il manuale Motorola sul 68030, che include 68881/2 e la PMMU68451, ma è un "mattone di carta" che è difficile farti avere. Al più se ci sono delle informazioni particolari, possono controllare e riportarle. ;)

[cdimauro]

Ok. Quindi è solo una questione di semplicità di implementazione sul die?
E' una semplicità che si paga (a seconda dell'architettura) in termini di non pochi transistor, però: un conto è "biforcare" la pipeline a uno stadio avanzato (e quindi condividendo gran parte della logica), suddividendo l'esecuzione delle istruzioni "intere" da quelle "FP", e tutt'altra cosa è farlo già dopo pochi stadi d'esecuzione soltanto per i salti (per poi suddividersi nuovamente).

Diciamo che ogni scelta è sempre frutto di compromessi: ha poco senso farlo per architetture con pipeline corte, dove l'impatto prestazionale è più limitato, mentre diventa importante con quelle dotate di diversi stadi di pipeline, che soffrono parecchio se devono svuotare la pipeline dopo parecchi cicli di clock.
Sì, e tra l'altro ho notato sul documento in cui si stimano gli errori di predizione sui PPC970 già linkato, che la mancata presenza in cache delle istruzioni corrette è un fenomeno alquanto raro.
Esatto. I processori di oggi sono dotati di buoni predittori di salto (siamo intorno al 95%).
Ma a questo punto chiedo (a te, leoneazzurro o a chi ha voglia di rispondere), se da una predizione corretta ad una scorretta la latenza passa da 1 a 4 cicli, ha ancora senso togliere spazio sul die alle unità di calcolo per implementare funzioni di ILP/TLP dinamiche anziché statiche (o eventualmente dinamiche fatte via software anziché via hardware) solo per guadagnare 3 cicli in quelle poche volte in cui la branch-prediction dinamica sia più efficiente di quella statica?
Anche se ILP/TLP statiche fatte in fase di compilazione facessero lievitare dall'8% al 20% il mispredict rate, le maggiore potenza di calcolo (dovuta alla sostituzione della logica di controllo con unità di esecuzione) non potrebbe più che compensare l'aumentato fattore di predizioni errate?
Dipende sempre dalla lunghezza della pipeline, chiaramente: passare da 1 a 4 cicli di penalizzazione quando siamo già al 15-esimo stadio (per fare un esempio) della pipeline, non è che sia un gran vantaggio, IMHO.

Poi considera che inserire unità di esecuzione anziché un meccanismo di esecuzione OOO non è sempre vantaggioso: il codice "general purpose" è piuttosto "frastagliato" (o non regolare / con dipendenze, ecc. che dir si voglia), per cui non sempre è possibile avvantaggiarsene, anzi superato un certo numero sono pochi i casi di sfruttameno di parecchie unità di esecuzione dello stesso tipo.
Non è un caso se il numero massimo di istruzioni eseguibili negli x86 è rimasto di 3: evidentemente nelle simulazioni effettuate sul codice reale ci si è accorti che il numero di transistor dovuti, ad esempio, a un'altra unità di esecuzione intera o FPU ha portato a un modesto aumento prestazionale, a fronte di un consistente aumento dei transistor e della complessità del chip (c'è anche questo da considerare).

Discorso diverso nel caso in cui si hanno precisi obiettivi, come quella di avere prestazioni elevati nel campo multimediale, ad esempio, com'è il caso di Cell con le SPE e di Xenon con le tre PPE ("potenziate" con l'inclusione di unità simil-SPE).
C'è anche qui: http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf e mi sembra molto corta. Non è che magari gli stages sono pochi ma ognuno di essi ha una latenza di più cicli? In effetti i conti non tornerebbero altrimenti.
No, le latenze non c'entrano: contano soltanto gli stadi.

Dal documento si vede che ci sono 8 stadi "base", che poi si "biforcano" a seconda del tipo di istruzione da eseguire. Contando i singoli "rami" che seguono, si vede che si aggiungono altri 7-9 stadi, a seconda del tipo di istruzione. Quindi siamo già a 15-17 stadi. Però non è mica finita qui: dallo stadio finale di ogni tipo di pipeline ci sono delle frecce che arrivano a collegarsi con altri stadi, per cui non si capisce bene quando una particolare istruzione è stata completata. "A naso" direi che ci sono altri stadi aggiuntivi.
D'altra parte i 19 cicli di clock di penalizzazione in caso di misprediction devono trovare una giustificazione in qualche modo. Il tutto IMHO, chiaramente.

[cdimauro]

...l'ultimo file Copro16A.txt lo avevo già "divorato" tempo fà...
Mi potete confermare che anche la f.p.u dell'MC68060 come quella del 68040 implementava le funzioni trascendenti (sin, cos, log, ecc.) tramite delle trap ad apposite routine "software" ?
Sì, è così.
All'epoca mi dispiacque non poco vedere che il mio amato MC68040 non aveva in hardware tutto il set di istruzioni I.E.E.E 754/854.
Ti dispiacerà sapere che al 68060 mancano altri "pezzi" che vanno emulati tramite librerie o apposite trap di linea A o di linea F.
Purtroppo la mannaia di Motorola è calata anche su alcune istruzioni intere, oltre che su quelle dell'FPU: adesso non ricordo bene, ma anche MOVEP (istruzione comunque poco utile) e le LMUL/LDIV dovrebbero essere emulate. Purtroppo non ti so dire di preciso, perché sono passati parecchi anni da quando ho letto queste informazioni...
Cmq. l'architettura "Harvard" del 68030 mi piaceva di più di quella 80386...
Grazie.

Marco71.
Idem. ;)

[MadRat]

Ops, ho visto solo adesso il casino che ho fatto.. Dunque dunque..
Devo chiedere scusa a Fek, ieri ho fatto un molta confusione, volevo commentare Fantoibed al che ho iniziato il post, ma mi e' arrivata una chiamata ed ho dovuto lasciare per un po', quando ho ripreso mi sono confuso e credevo fosse il messaggio che avevo intenzione di scrivere a cdimuro, riallacciandomi al discorso che fanto faceva a te.

Per quanto mi riguarda, con te (fek) mi trovo bene a discorrere (anche se sei un po' duro), gli appunti che hai mosso erano fondati e non perentori, quello che avevo intenzione di scrivere (e che non ho fatto!!) era semplicemente che capisco che con te a volte sia difficile confrontarsi, ma questo dipende dal carattere, capisco il punto di vista di fanto (tenendo presente che con lui hai discusso di piu'), ma mi limito a capirlo, senza sbilanciarmi né da un lato né dall'altro.

Mentre alla fine il messaggio che ho scritto era solo ed esclusivamente per cdimauro. Che pertanto puo' ritenere suo quel concetto da me espresso ed invito fantoibed a seguire le nostre tedianti discussioni per rendersi conto di chi veramente con una teoria incontrovertibile farebbe girare la terra al contrario.

Chiedo venia a fek, sorry.

P.S. Avevo ritrovato il sito nel quale si parlava di shaders unificati per RSX, ma non l'ho salvato perche' ritenevo chiuso l'argomento. E' comuqnue ovvio l'errore del sito.

[MadRat]

Saltero' alcuni passi che abbiamo gia' ripetuto fino alla noia restando sul monotono andante..


Non credo proprio, visto che i canali Amiga riproducevano sample, e non soltanto delle note.
Certamente, ma l'esperienza sonora era parecchio limitata con la MIDI, a causa della mancanza dei sample. Infatti il sonoro nei giochi con l'Amiga è stato qualitativamente elevato rispetto alle altre piattaforme.


Si vede che non lo hai mai usato, all'interno di un sintetizzatore si pososno "sintetizzare" dei suoni, spesso partendo da basi campionate, non e' come avere la "liberta" di campionamento, ma questo estende e di molto il panorama. Mi spiace per i numeri ma proprio non li ho, tantomeno mi interessa procurarmeli.


Il guiness ce l'ha ancora oggi il Commodore 64.


Purtroppo in questa casa ho solo quello del 90 ed ancora non riporta questa voce.. Spero di ricordarmi di scansionare quello piu' recente.



Questo non c'entra nulla col resto del discorso. Gli ST sono sempre stati inferiori all'Amiga nel campo multimediale, e in quello dei giochi in particolare: questo è un dato di fatto.
Vogliamo vedere quanti giochi sono stati sviluppati per Amiga e ST? Dici che hai una notevole collezione di retrogaming: prova a contarli.
Dopo averli contati facciamo un confronto sulla qualità video e audio dei titoli disponibili su entrambe le piattaforme, così ci facciamo quattro risate...


Credo che se vedessi il quantitativo di floppy che possiedo dell'ST ti faresti 4 pianti. Non credo tu ne abbia la piu' pallida idea.


Anche nel campo del poligonale l'Amiga si è sempre distinta. Anzi, ha introdotto il genere, se vogliamo essere pignoli. E non soffriva di particolari gap prestazionali: anche se il Blitter era stato pensato per la grafica bitmap / bitplane, è stato sfruttato molto bene anche per la generazione di linee (poteva generare quasi un milione di pixel al secondo per questo compito) e per il riempimento dei poligoni (aveva una logica hardware di fill mentre copiava porzioni di memoria).

Basti vedere i titoli 3D disponibili: Stunt Car Racer era estremamente fluido (ancora oggi merita di essere giocato), così come Elite, Falcon F16, FA/18 Interceptor, ecc. Vogliamo confrontare gli stessi titoli disponibili per ST?


Comincio a credere che tu viva di fantasia pura e che non abbia mai avuto un ST per le mani, anzi ne sono convinto.
Hai citato 3 giochi con i quali sono cresciuto.

Stuntcar racer, (Ricordo ancora il pesante cavo che passava da una stanza all'altra per collegare i due computer) su amiga vantava un audio migliore (anche se il rumore di vetri che si rompevano al minimo strusciamento, per di piu' su una macchina senza finestrini per natura, era un po' ridicolo), ma in termini di velocita' rispetto alla versione ST, era ridicola, sembrava spastico.

F16 Falcon era molto piu' fluido sull'atari e per di piu' aveva suoni campionati come sull'amiga, anche se di qualita' inferiore. (notare come l'emulazione ST sia cosi' indietro tutt'oggi da non essere in grado di emulare correttamente i suoni campionati da esso generati). Girava notevolmente meglio su Atari.

Ed Elite, cosi' come il 2 (la miglior versione era pc oramai al tempo), girava ugualmente meglio su Atari.

Ritengo che tu lo abbia sempre e solo snobbato e mai usato veramente.

Inoltre mi piacerebbe sapere quali giochi abbiano usato il blitter dell'amiga come acceleratore vettoriale, non mi risulta che nessun gioco famoso abbia mai fatto questo,né per Amiga, né per ST con blitter (la serie mega esisteva da molti anni prima della serie E), né per ST-E.


Era l'84.


Ma dai, veramente?? Vedo che hai capito ugualmente!! se e' per questo ho pure scritto ne al posto di nel, potresti correggere pure quello. ;) :doh:


Specifica: per quella piccola società che l'aveva fatto partire.


Se per te 7 milioni di dollari nell'80 sembrano pochi..


Vinta dalla Commodore. E il progetto non era incompleto, ma in uno stadio avanzato: i chip custom erano stati completati.


Vinse la commodore solo per questioni finanziarie, ma non vedo che cosa c'entri.
I chip erano completi, ma il computer no.. Non vedo cosa cambi.


Le cose non stanno così. Ecco qui uno dei tanti link che si trovano in rete e che riportano la storia dell'Amiga: http://www.betatesting.it/backforthefuture/storia/storianoframe.html


Le cose stanno cosi', quella storia la mia famiglia l'ha vissuta, posso scriverla anche io una pagina internet con le mie interpretazioni degli stessi argomenti, cosi' hai altri link da postare.



Poi l'AmigaDOS NON E' IL SISTEMA OPERATIVO DELL'AMIGA, ma soltanto la parte che si occupa dell'interfaccia con i filesystem.

Infatti: il TOS si è rivelato sempre inferiore ad AmigaOS.


Ma veramente non era il sistema operativo?? Oggi c'e' aria di scoperte.
Il TOS si mangiava e ric.. l'AmigaOS, soprattutto quello del tempo. (quale?? :)) )


Mi fai vedere dove l'avrebbe scopiazzato? Il s.o. ha poco a che spartire, e la GUI è completamente diversa visivamente, nelle API e nei concetti di programmazione.

Il TOS era peggio perfino del MacOS, che almeno aveva un'interfaccia grafica decisamente più user friendly.


Se prima avevo qualche dubbio sul fatto che tu non abbia mai usato un ST, ora ne sono certo.
Addirittura ci fu una causa tra Atari-Apple e digital, riguardo proprio la cessione del GEM ad Atari.
Ora mi invento una parola Jackintosh, che fantasia che ho!! eppure mi sembra di averla gia' sentita 20 anni fa.
Potresti fare l'avvocato.. Magari con te avrebbero avuto piu' facilmente ragione. Sarebbe bastato che andassi tu a dir loro "no signori, a me l'Atari sta sulle balle, percio' il TOS fa schifo ed il MAC OS e' migliore e non c'entra nulla!!". Semplice no??



Quanto al multitasking, è la solita storia della volpe e l'uva: se non ce l'hai non è bello ed era prematuro. Intanto chi usava l'Amiga si divertiva a usarlo e a lanciare applicazioni a josa...


Tu che sei un esperto Atari, hai mai provato il multitos?? o forse hai provato il MagiC??
Io ci facevo di tutto mentre in una finestra giravano anche giogni della pesantezza di Legende Of Vaour, il tutto su 8mhz di computer..



Tanto tranquillamente no: per ogni riga video da visualizzare era necessario generare un interrupt ogni 16 pixel (per l'ST. Ogni 256 pixel per l'STE), per cambiare la palette dei colori. Un compito estremamente oneroso per la CPU: vai a vedere quanti cicli di clock sono necessari a un 68000 a seguito di un'interrupt e quanti ce ne vogliono per ritornare al task precedente; per non parlare poi del salvataggio e ripristino dei registri usati nello stack, e del lavoro vero e proprio di caricamento dei colori nella palette). Tu non hai la minima idea di quello che significa, visto che non hai mai programmato un 68000 in vita tua...


Ho mai sostenuto che fosse la stessa cosa?? :o e si che ne sai parecchie di cose al mio riguardo!! ;)
Ho solo detto che determinati limiti non erano poi cosi' ferrei.


Gli ST solo nel MIDI.


Nel Midi, nel calcolo, nel costo e nell'affidabilita' ecc..


Doppio? Se lo confronti col primo Amiga, forse, il 1000. Il 500 era di poco più costoso di un ST.


Probabilmente te lo sei comprato solo ad un annetto dall'uscita dell'Amiga 500, ovviamente noi non potevamo aspettare quel periodo.
E poi io lo paragono per date d'uscita. Mi sembra logico.


Sarà per questo che gli ST hanno sempre avuto dotazioni di memoria superiori agli Amiga...


Bella risposta del c.. :D Credo che dal prossimo reply non ti terro' piu' in considerazione. Signori e signori quest'individuo ha appena asserito che l'ST avesse piu' Ram per via delle maggiori richieste da parte delle applicazioni.
Mentre per un povero realista come me (che non ha mai prigrammato un 68k in vita sua!! :cry: ) La realta' e' ben differente; l'ST poteva permettersi quantitativi di RAM maggiori per via dei prezzi determinati dalla non customizzazione dell'80% delle sue parti.
Spesso i giochi risiedevano su un floppy da 320k (finquando possibile ovviamente) che per Amiga diventava uno da 880 e tanti giochi per Amiga richiedevano un mega di Ram, mentre per ST solo mezzo.. Che questo dipendesse dall'Audio campionato ed a volte dalla presenza di piu' colori, e' solo una mia fantasia!!


E infatti s'è visto come s'è mangiato le mani per essersi fatto sfuggire l'Amiga. :asd:


tramiel non e' mai stato uno scemo, sapeva come tutti i commercianti, che un concorrente sul mercato e' pericoloso e sapeva bene che, nascendo senza fretta ed unificandosi al progetto atari, avrebbe creato sicuramente una macchina migliore.


Leggevo di tutto. Usavo di tutto. E ho una buona memoria. Tant'è che trovo puntualmente riscontro a ciò che dico.


"Non sono d'accordo", questo dimostra come errata la tua affermazione..



Ti consiglio di risparmiare questi insulti. Piuttosto argomenta ciò che hai da dire.


Ma quali insulti?? se hai la coda di paglia non e' colpa mia, leggi le frasi per intero. Oggi mi sento buono e te la spiego.

E' ovvio che tu sappia leggere, dunque la spiegazione non e' quella, ma probabilmente l'altra da me ipotizzata e cioe' la tua fossilizzazione nel mondo Amiga.


L'unico vantaggio, ma costoso: meglio investire quei soldi per comprare della ram, che si poteva usare con tutte le applicazioni.


Seguiti a dare segni di mancanza d'esperienza in merito. Sai quanto costava espandere un 520ST da 512K ad un solo mega?? Te lo dico io, 2 milioni di lire nei primi due anni!!


Anche per grafica non bitmap.


ancora me lo ricordo il CAD3D e 4D per amiga.. Ho i brividi per la velocita'!! forse usava il blitter.. Ma che Amiga avevi tu??


Con l'Amiga potevi sfruttare overscan, HalfBrite (64 colori) e HAM (4096 colori) anche da s.o.: non era una prerogativa dei giochi e dell'applicazioni che accedevano direttamente all'hardware.
Quanto all'ST, per avere più colori visualizzati contemporaneamente dovevi per forza di cose ricorre alla tecnica di cui sopra, che consumava PARECCHIA potenza di calcolo.


Gia' discusso. C'e' da dire che Dragon's lair usava l'alta risoluzione!! fantastica, uno sfarfallio bellissimo, un francobollo sullo schermo al posto dell'immagine e l'audio perso per strada.. Non c'e' che dire, proprio una macchina equilibrata.


Sull'overscan non saprei: hai delle informazioni tecniche a riguardo che dimostrano che era possibile farlo anche con l'ST?



Guardati qualcuna delle centinaia di demo che ci sono in giro per gli ftp pub. Ovviamente vedile su un ST vero, perche' sugli emulatori girano male.
Vedrai schermi pieni a fluidita' assurde. Cerano anche dei programmi di grafica che li usavano.


Non mi risulta: http://atari-ste.anvil-soft.com/html/devdocu4.htm Qui trovi tutte le informazioni su come funziona il DMA audio degli STE e su COME PROGRAMMARLO. Come puoi vedere, è in grado di riprodurre soltanto due canali stereo, e a frequenze fisse.


Scaricati l'octalyser, usava 8 canali a 25khz sui quali poteva gestire anche l'interpolazione.
Oppure l'audio sculpture, usava 4 canali a 50 khz, io cosi' ho iniziato a scrivere musica da ragazzino!! :) Mi ero anche modificato il mio STE per prelevare l'audio prima dei filtri e degli equalizzatori.
Ovviamente questi programmi non girano sugli emulatori, ma nel tuo parco computer avrai ancora un STE sul quale provare. Se ti manca, ti vendo uno dei miei.
Ovviamente senza l'utilizzo della cpu per aggiungere canali.


Al contrario, Amiga ha 4 canali completamente indipendenti, su cui è possibile controllare singolarmente volumi ed effetti vari, e che permettevano di riprodurre frequenze arbitrarie fino a 28Khz. Il limite dei 28Khz si poteva superare programmando i canali direttamente con la CPU: Aegis AudioMaster è stato il primo programma a presentare e utilizzare questa tecnica per riprodurre suoni a 56Khz.


Senza CPU come detto sopra l'STE ne faceva 4 a 50..

http://atari-ste.anvil-soft.com/html/trackdoc1.htm

La scelta del link e' dettata dalla rigorosa legge della casualita', e' il primo link saltato fuori da Google, a me basta a te probabilmente no, ma mi sembra scontato.

Nota: Fosse stato ottenuto anche tramite l'ausilio della cpu come l'esempio da te riportato per Amiga, i risultati sono comunque doppi sull'STE.
Non ci scordiamo che non perse l'YM2149, che rimane pur sempre un generatore e modulatore di onde quadre molto cristallino e capace di 9 ottave.. mettendoci pure il generatore di rumori bianchi i canali finiscono a 8.



Quindi, come vedi, l'audio dell'Amiga è rimasto superiore anche con l'arrivo degli STE.


Come vedi tu forse.



Un Amiga 500 non costava molto, e aveva un hardware favoloso (per quei tempi). Il poco di più che si pagava rispetto all'ST permetteva di avere hardware e s.o. di livello notevolmente superiore: ampiamente giustificato IMHO, e non sono il solo visto l'enorme successo che ha avuto.


Hai le idee confuse.. Il sistema operativo decente l'amiga lo ha visto solo durante l'ultima fase della sua vita e non si paragona con il TOS, che temo proprio tu non abbia mai usato, ma questo oramai e' chiaro e per quanto riguarda l'HW e' parere tuo che sia superiore. Lo e', ma vincolatamente ad alcune cose, era comuqnue un progetto finito di corsa e vittima di mille tagli e al personale ed ai finanziamenti.



Per forza: era stato progettato appositamente per realizzare dei giochi, con hardware dedicato molto simile a quello che si trovava in sala giochi.


E quello gli riusciva bene infatti.


Infatti anche per tutto il resto l'Amiga è stato eccellente: l'unico campo in cui non ha sfondato è stato il settore audio professionale a causa della mancanza dell'interfaccia MIDI di serie.


A causa anche della lentezza dei programmi che vi girarano sopra e dell'assenza di un'alta risoluzione video stabile come la monocromatica dell'ST.

"Anche al Mac mancava l'interfaccia midi".. non mi pare che questo ne impedi' il diffondersi in quell'ambito. :mc:


Non mettere le mani avanti: tu non hai dato NESSUNA SPIEGAZIONE, e pretendi di tapparmi la bocca col nulla? Sei troppo presuntuoso.


Stavo pensando invece che tu con la tua teoria vorresti dimostrare l'assurdo. Non sempre risponde a realta'.


I programmi che giravano in background su ST installavano un hook che veniva eseguito a intervalli regolari indipendetemente dal task corrente: in questo modo il suono poteva essere riprodotto mentre si faceva altro. La STESSA tecnica è stata usata con i player per il PC / DOS.


Assolutamente falso, comincio a stancarmi sinceramente, hai campato chiuso in un eremo con un amiga ed un 486.
Da come parli, parrebbe che un ST fosse un 68k attaccato direttamente alla corrente!! Ti stai sbagliado pesantemente, aveva anch'esso chip di supporto che se pur non customizzati, davano i loro bei risultati, forse non essendo cosi' pirotecnici come quelli Amiga, non li hai mai notati, Ma sono problemi tuoi non miei.
A me risulta che l'ST avesse un processore chiamato GLUE (c070qualcosa) che fungeva da controllore logico dell'architettura del computer stesso, interagento con i principali sottositemi (grafico, audio e delle periferiche).
ed uno Shifter (c0707qualchecavolopurequesto), che non era il processore grafico, ma parte del sottosistema video. Non intendo paragonarlo alla controparte Amiga (che mi pare fosse il mos 8362), ma sicuramente formiva una discreta prestazione (visto il costo) e delle risoluzioni (soprattutto la monocromatica) che fecero la differenza in ambito professionale.
L'ST era concepito per battersi con il MAC del tempo, non con l'Amiga, che ancora non esisteva (sul mercato).
E comunque l'evoluzione dello stesso montato nell'STe colmava prte delle differenze.
Poi c'era LYM2149F, che era una sorta di clone compatibile con l'AY38910
non solo era capace di spaziare da 30hz a 120 khz, (dinamica che il paula si sognava) con le proprie quadre, ma assolveva anche ad alcune funzioni legate all'IO.
In oltre il WD1772hp (controller floppy che conosci) controllava 2 floppy in DMA.
DMA, gestito dal.. (confesso di non essermi ricordato il nome, sono passati 20 anni) C100110-001 (che infatti non aveva un nome ma solo una sigla), incaricato del trasferimento diretto dalla ram (ovviamente direi). Era un basmaster assieme al 68k.
poi c'era l'ST EF6850P ACIA per la midi ed il Motorola MC68901P, processore multifunzione che ad esempio generava gli interrupt per il 68k ed il Glue e gestiva l'IN assieme allo Yamaha.
Questa e' una panoramica generale ed assolutamente incompleta.

Poi cosi' solo non era 'sto benedetto 68K, tant'e' vero che le rare volte che il compurer andava in crash, alcune funzioni indipendenti continuavano a svolgere il loro lavoro.



Tutto ciò era INUTILE con l'Amiga, perché era multitasking: bastava lanciare un player e dedicarsi ad altro.


Al masismo era multi finestra, il multitsk dell'amiga era ridicolo come il SO stesso.
I player lavoravano in bg pure su ST. :o Tu hai vissuto un'altra realta'.


I "secondo me" non dico niente e non valgono nulla: a me interessano i fatti. E per i fatti serve poter mettere le mani sui sorgenti o disassemblare gli eseguibili.


Tra la teoria e l'a pratica c'e' molta differenza, tu vivi di teoria e speri che il mondo giri secondo essa, io, a volte, mi limito ad osservare la realta' dei fatti. Non ritengo probabile una generica mala programmazione diffusa sempre nello stesso segmanto e sulla stessa piattaforma. Punti di vista e d'approccio, non penso potremmo mai trovare un incontro.
I fatti non te li posso provare, visto che non ho nessuna intenzione di scomodare me ed i miei computer per venire da te a dimostrarti come qualunque gioco poligonale girasse palesemente meglio su un ST. Nemmeno K e TGM leggevi al tempo!! :) (a proposito, ho un mare di riveste del tempo, tecniche e ludiche).



In mancanza di fatti, preferisco non espormi, come invece ami fare tu.


I fatti per me sono costituiti da cio' che i miei occhi hanno visto.
Se le tue spiegazioni non collimano con la realta' sono errate e visto che sei tu a riportare sempre il tutto su un piano profondamente tecnico, devi spiegare tu il perche' di determinate situazioni, non io.
FS, come F16, come stuntcar su Atari girava meglio che su Amiga (e lo ricordo come se fosse ieri), secondo le tue logiche questo non e' possibile, secondo la realta' invece, e' cosi'. So bene quanto possa rimanerti ostico da accettare, ma c'e' una spiegazione.
Un certo Einstein una volta disse che quando una cosa non funziona, in realta' sta funzionando perfettamente, siamo noi che non capiamo come.
La mia modesta spiegazione e' che l'HW customizzato dell'Amiga avesse pregi e difetti. ;)

Che tu possa contestare le mie esperienze, a me risulta trasparente ed ininfluente. Io posso portartele e tu puoi prendere come ca***** se la cosa ti aggrada. :) Resta il fatto che io non abbia alcuna motivazione per dirne.
Non sono in un tribunale, non devo dimostrare nulla a nessuno, cercare link e rispondere a questi post.. porta via tempo prezioso al mio lavoro.
Se lo faccio e' solo per portare la mia esperienza ad altri ed imparare dalla loro. Con te risulta veramente inutile tutto cio'. Tu non devi mettere in dubbio le mie affermazioni, non mi pagano per dire che FS girasse 20 anni fa piu' rapidamente su una piattaforma anziché su un'altra.



Mi ricorda un certo Amiga 3000: l'evoluzione "professionale" dell'Amiga 2000 con tanto di 68030.


E questo che c'entra?? Mi sembra ovvio che entrambe le case proposero una soluzione dedicata ai professionisti.


Non era una macchina completamente nuova. Ecco qua: http://atari-ste.anvil-soft.com/html/devdocu6.htm puoi trovare un bel po' di informazioni, anche su come programmarlo (nelle 5 pagine precedenti). Te ne riporto uno stralcio:

"The Falcon030 and its features:

? How compatible is the Falcon to the STE ? Will my STE code work flawlessly on the Falcon ?

! Yes, the Falcon was meant to be an (68000-based) successor to the 1040 STE, therefore it is easy to code Falcon-compatible STE-code. The only exceptions are:

- The Falcon does not allow 6.125 KHz DMA sound

- The Falcon's screen base address has to be a multiple of 4

- The Falcon does not have the so-called "Shadow"registers of the YM2149

To also make sure that the timing of the CPU is (almost) correct, switch the processor caches off and the CPU and the Blitter down to 8 MHz. Now, the only obstacle is the DMA-sound matrix of the Falcon which might be setup wrongly."

Inoltre qui: ftp://ftp.lip6.fr/pub/atari/Docs/hardware.txt trovi l'elenco completo delle zone di memoria usate dai vari Atari, dall'ST al Falcon, e dei registri dei vari chip. Come vedi il Falcon è MOLTO simile ai suoi predecessori, nonché abbastanza compatibile.


Bello riscrivere le stesse cose piu' volte, almeno risparmio di pensare nuovamente.
Io ho detto che il Falon e' l'evoluzione dell'ST. Da quanto tu asserisci, risulta evidente come tu non abbia mai visto l'interno di un falcon (ne tantomeno programmato, visto che ci fai tanto spesso riferimento). Non aveva pressoche' nulla di uguale alle vecchie macchine (mentre il TT era similissimo in quasi tutto, diciamo che fu il papa' dell'STE).
Non era poi cosi' compatibile con la vecchia serie, per far girare i giochi ST serviva un progamma (mi pare si chiamasse Backworld), che richiese diversi aggiornamenti per non raggiungere mai una piena retrocompatibilita' con il vecchio sistema, soprattutto in ambito ludico. Vista la radicale differenza hardware con le macchine precedenti.
Mi chiedo che parli a fare se non sai le cose?!?! In realta' l'ho capito, hai solo voglia di sopraffare, lo dimostra il tuo criticare TUTTO, come se non avessi detto una cosa giusta fin'ora, anche a costo di sparare a caso come hai fatto ripetutamente in questo post.
Infatti come ho gia' chiarito prima questo e' l'ultimo post al quale ti rispondero'.



Chi ha mai parlato di "inferiorità architetturale" (qualunque cosa tu voglia dire con ciò)? Motorola ha ammazzato i 680x0 in favore dei PowerPC. Più esattamente, ha mantenuto i 680x0 nell'ambito dei microcontroller ad alte prestazioni.


Scordi gli accordi con altre case interessate ad entrare nel settore MAC tramite il progetto PPC, vedi la Apple stessa e la IBM (pressioni pesanti direi).


L'unica cosa che avevano in comune 68000 e 88000 era il produttore: Motorola.


Sì, probabile, anche se non ho mai visto un m88k in vita mia. So di per certo che lo spinsero anche come sostituto della vecchia serie ma non prese per la non compatibilita', dunque e' probabile cio' che dici. Ricordo pero' delle dichiarazioni riguardo la logica progettuale, motorola sosteneva che pur essendo differenti i processori erano figli della stessa logica, uno in ambito CISC e l'altro ovviamente RISC. Non chiedermi delucidazini, perche' non ricordo altro e comunque, il concetto mi sembra anche piuttosto chiaro.



I vantaggi c'erano, altrimenti non si sarebbe affermata come piattaforma. Hai mai programmato un PC? Sai come funziona una SuperVGA? Sei in grado di confrontare un PC con SVGA con un Amiga o un ST dal punto di vista dell'hardware?


Ora che c'entra questo?? ma lo vedi che sei monotematico?? Guarda, ti riposto identica la mia spiegazione di prima, ora pero' cerca di non andare fuori tema che ti metto 2!!

"E chi ha parlato di problemi?? Io non di certo!!
Era solo la motivazione per la quale i pc, grazie alla loro modularita' ed espandibilita', (che e' il loro unico punto di forza) e grazie a taiwan, sopraffecero i computer che "puzzavano" di stantio (incredibile, siamo d'accordo su qualcosa).
Ma se non fosse stato per il mercato orientale, il pc sarebbe rimasto per sempre relegato al ruolo di macchina da ufficio, vistone il costo assurdo per l'uso domestico ed i vantaggi inesitenti."

Vorrei fari un'aggiunta per rendere il concetto piu' chiaro, ma non credo sia possibile.
Ecco fatto, che pazienza che ci vuole!!


Infatti non l'ha buttata nel cesso: l'ha riciclata per fare altro.


Lo so bene, la meta' degli strumenti musicali che possiedo all'interno ha un processore di quella famiglia. Tuttavia non e' stato un ripiego o riciclo, perche' quest'implementazione era gia' diffusa in precedenza, e' solo un settore che e' durato piu' a lungo ed ha visto l'ausilio anche di evoluzioni dello stesso (come il coldfire). Ma non mi sembra una risposta soddisfacente, anzi non e' una risposta la tua.



Non vedo quali, visto che sono nettamente diversi. Inoltre i PowerPC derivano dalla famiglia Power di IBM, non dai 680x0 di Motorola.


Se trovo qualche link in merito te lo posto, comuqnue motorola ci mise molto del proprio, se non ricordo male l'emulazione 680x0 girava alla grande.
Comuqnue non mi sono mai interessato piu' di tanto a quelle macchine, pertanto non vado oltre a qualche ipotesi senza pretese.



Certamente. A ciò aggiungi anche la lungimiranza di Motorola nel ritenere l'architettura 680x0 poco scalabile per il futuro.


Tutti sbagliano, ma quest'affermazione e' relativamente giusta. Anche gli x86 sono stati stravolti per scalare.


Cioè nell'87, con l'introduzione dell'Amiga 500: sono passati soltanto due anni dalla commercializzazione dell'ST prima e dell'Amiga 1000 dopo.


La migrazione del software da una piattaforma all'altra avvenne nell'arco di molto tempo, all'inizio (per i primi 2-3 anni) fu da ST ad Amiga, successivamente con la confidenza maggiore delle softwarehose dell'HW Amiga e la diffusione a livello ST (ed il calante successo dell'ST come piattaforma ludica, ovviamente non si paragonava da tale aspetto, visto che i giochi erano in bitmap al 99%) si comincio' a scrivere per Amiga e portare poi (ed in fine affatto) su ST. Questo fino all'avvento del 486, con la strada spianata dal 386 (ed alle ragioni spiegate in precedenza), che segnarono l'inizio del tramonto delle piattaforme 68k.
In totale si distribuirono 2-3 anni di gloria a testa.



No, l'Amiga s'è affermato e, anzi, ha inventato tanti altri settori (il termine multimedia è nato con Amiga).


Ci mancherebbe, ma le volumetrie di vendita e gli incassi erano quelli del mercato ludico.
Anche il TT (come l'ST) venne largamente impiegato professionalmente, ad esempio la BMW lo utilizzava per la progettazione delle proie vetture, dal motore alla scocca.
Addirittua mio padre vendette degli ST ad un centro di ricerche al polo sud (sotto loro espressa richiesta).
Questi sono due esempi pratici presi tra migliaia, ma torno a dire che il grosso del mercato era ben altro.

Il fatto del termine multimedia che sia nato con Amiga non lo sapevo, mi infrmero' sicuramente in merito.


E chi l'ha mai negato?

Hai la coda di paglia.. era un chiarimento, per aiutarti a comprendere meglio quanto stavo dicendo. Non prendere tutto con il tuo spirito. Io non scrivo per contraddirti come obbiettivo.


Questo è avvenuto coi PC, non con altre piattaforme.

Idem come sopra.. :mbe:


Li hai mischiati.

Non ho mischiato nulla, sei tu che prendi esempi di chiarimento come spunti per controbattere e fai un pure' del tutto.
Hai diviso un concetto unico in piu' frasi (come fai sempre), non ci hai capito nulla e te la prendi con il prossimo.


Infatti non c'entra la "qualità", ma ti ho già detto che è una questione puramente tecnica. Un 68020+ ha un'ISA molto versatile ma complesso da implementare rispetto a un 80386+, perché è dotato di istruzioni che eseguono parecchio lavoro e modalità d'indirizzamento estremamente avanzate.
Tutto ciò comporta il fatto che già la sola sezione di decodifica delle istruzioni sarebbe estremamente complessa, e richiederebbe parecchi milioni di transistor per poter garantire un throughput (erogazione) di microistruzioni paragonabili a quelli di x86.
Considera che un Athlon ha 4 decoder che sono in grado di decodificare ognuno fino a 4 istruzioni per ciclo di clock, ed è in grado di erogare fino a 3 microistruzioni per ciclo di clock. Soltanto che l'istruzione più complicata che può avere un Athlon è quella che presenta un indirizzo di memoria simile a questo: [Base + Indice * Fattore di scala + Offset a 32 bit], e questo per la sola sorgente o la sola destinazione.
Un 68020+ permette qualcosa come ([Base + Offset a 32 bit] + Indice * Fattore di scala + Offset a 32 bit). E questo per sorgente e destinazione nel caso di una MOVE.
Quindi puoi immaginare l'enorme lavoro che dovrebbe fare il decoder per tirare fuori le microistruzioni da spedire all'unita di esecuzione RISC-like.


Hai pienamente ragione, ma non credo che il panorama sia tutto cosi', cioe', ci saranno pure dei vantaggi in tale struttura no??!! magari perde da un lato e vince dall'altro. Poi credo che dovremmo almeno accantonare il 68020 e prendere lo 060. Quante istruzioni poteva decodificare uno 060 per ciclo?? 3 se non erro. Una meno del pentium del quale era il doppio piu' veloce a parita' di clock.



Infatti è così, e le piattaforme non sono così simili, visto che non esiste una scheda video che funzioni come l'X-Box.


Non e' una gefforce3 con uno shader aggiunto?? o qualcosa di estrememente simile.
Non e' la scheda che deve lavorare come l'xbox, ma il computer intero. Del resto e' un P3 733 con chipset SIS mi pare.


Non puoi confrontare capra e cavoli: Halo per X-Box e PC è un PRODOTTO DIVERSO CHE FUNZIONA IN MODO DIVERSO E RICHIEDE HARDWARE DIVERSO. Punto.


Pertanto programmare uan geffo3 per xbox ed una per un p3+geffo3 e' cosi' differente..



Oggettività che è tutta da dimostrare, visto che manca un elemento fondamentale: il fatto che le due applicazioni NON SIANO IDENTICHE.

In mancanza di una valutazione che sia DIMOSTRATA oggettiva, sono le tue che rimangono soltanto teorie.


Non sono identiche, ma si somigliano molto dire, ma molto molto!! La PS2 e' differente.


:mc: E' inutile che provi a cambiare discorso: non attacca.

Non credo proprio, tu mi attaccasti quando io dissi che i dsp del cell avrebbero potuto adempiere a funzioni GP negandolo assolutamente, definendo ridicole le loro prestazioni in merito. Al che, visti i tuoi commenti errati riguardo l'ausilio del 56001 io mi sono riallacciato alla tua affermazione, certo della tua critica, poi arrivata su un piatto d'argento.
La mia affermazione riguardo l'inutilizabilita' del 56001 come processore GP era assoluta cosi' quanto la tua riguardo a quelli del Cell.


Quanto alla mia valutazione su Cell, cosa vorresti mettermi in bocca questa volta?


Io non voglio metterti in boca nulla, tieni i tuoi vizi al difuori del forum. ;)


Athlon e P4 sono processori diversi con un'implementazione completamente diversa dell'architettura x86: non puoi confrontare i 2,2Ghz del primo coi 3,2Ghz del secondo. E' un confronto assolutamente privo di senso.


Gradirei non mi spiegassi la differenza tra un K8 ed un P4, voglio morire nella mia immensa inoranza (almeno a questo crederai).
Se prima lo avevo detto per provocarti, ora lo penso. Tu non sai leggere!!
Si parlava STASI AMD relativa alle frequenze, evento che tu asserisci non essere mai accaduto. Io ti ho detto quando e' successo.
Il commento riguardo l'efficienza delle soluzioni AMD era solo una precisazione (tanto inutile quanto semplice da capire), per chiarire che il percorso seguito non fosse quello della rincosa (improficua) alle frequenze maggiori (come stupidamente ha fatto Intel).
Spero di essere stato ulteriormente piu' chiaro.


Bastano le specifiche e la buona volontà di qualcuno. Come è sempre stato fatto nel campo degli emulatori, tra l'altro.

www.mess.org.


Lo provero'. (lo sto provando.. per ora da solo schermate nere.. ora ci smanetto un po')


I problemi di cui non fai altro che parlare non li hai mai esplicitati: a cosa ti riferisci di preciso? E cerca di essere chiaro: dev'essere possibile riprodurlo su un PC nelle condizioni che elencherai (spero).


Forse non parlo italiano..
Un qualunque pc di oggi ha seri problemi con le periferiche ide, che siano ottiche o hd. quando lavora intensamente subisce rallentamenti (e con i cd arriva pure a freezarsi poi no ti dico se sono rovinati!!).
Inoltre non mantiene di suo una precisione ritmica degna di un professionista con i piu' avanzati programmi a meno che non si implementi una scheda che gestisca il comparto midi/audio per conto proprio. Non vedo come possa farlo sotto emulazione.


Allora amen. Per emulare anche quella porta d'espansione sarebbe necessario sviluppare un dispositivo a cui collegare queste chiavi: non ha senso farlo, perché non ci sarebbe mercato.

Non mi spaventa fare un adattatore simile in fin dei conti, tutto starebbe nel vedere dove un eventuale emulatore potrebbe indirizzare quella porta.
Va be', purtroppo non ci sara' mai.


I miei rispetti Dott. Di Mauro :D

Senta, ho un dolorino da una parte..

[fek]

Ops, ho visto solo adesso il casino che ho fatto.. Dunque dunque..
Devo chiedere scusa a Fek, ieri ho fatto un molta confusione, volevo commentare Fantoibed al che ho iniziato il post, ma mi e' arrivata una chiamata ed ho dovuto lasciare per un po', quando ho ripreso mi sono confuso e credevo fosse il messaggio che avevo intenzione di scrivere a cdimuro, riallacciandomi al discorso che fanto faceva a te.

Scuse accettate :)

Ma trovo che non sia comunque mai il caso di parlare del carattere di una persona che hai incontrato solo sul forum, io, cdimauro, o chiunque altro.

[fek]

[qupte]Non e' una gefforce3 con uno shader aggiunto?? o qualcosa di estrememente simile.[/quote]

E' qualcosa di simile, diciamo che sono anche loro cugini stretti, ma si programmano in maniera differente, ed hanno profili prestazionali molto differenti.

Pertanto programmare uan geffo3 per xbox ed una per un p3+geffo3 e' cosi' differente..

Guarda, ho lavorato sia su xbox sia su PC e la GPU dell'xbox si programma in maniera quasi totalmente differente, si usano proprio algoritmi e ottimizzazioni diverse, spesso agl'antipodi.

Le differenze principali sono:
- la memoria condivisa su xbox
- pixel shader molto potenziati su xbox

[Marco71]

Il chipset di Amiga era principalmente costituito da questi chip:
8362 Denise, 8364 Paula, 8370 Agnus, 5917 Gary, 8520 CIA set...
Esisteva anche una versione di Agnus denominata 8371 e l'ultima la 8372.
Comunque a mio parere un confronto tra Atari ST ed Amiga appare un poco fuori topic o sbaglio ?
Poi un piccolo "appunto" per tradurre dall'inglese "to scan" forse sarebbe più "elegante" utilizzare la frase "effettuare una scansione" invece dei vari: "scannare", "scansire", "scannerizzare" ecc.
L'italiano di oggi è un vero e proprio guazzabuglio di neologismi.
Grazie.

Marco71.

[cdimauro]

Saltero' alcuni passi che abbiamo gia' ripetuto fino alla noia restando sul monotono andante..
Idem.
Si vede che non lo hai mai usato, all'interno di un sintetizzatore si pososno "sintetizzare" dei suoni, spesso partendo da basi campionate, non e' come avere la "liberta" di campionamento, ma questo estende e di molto il panorama. Mi spiace per i numeri ma proprio non li ho, tantomeno mi interessa procurarmeli.
Hai dimenticato il contesto: i giochi. Se voglio inserire un campione da riprodurre, chessò "Welcome to Fright Night", la tastiera collegata alla porta non potrà farlo. Potrebbe farlo scaricandolo tramite MIDI, ma a 3KB/s di velocità faresti prima a finire il gioco...
Purtroppo in questa casa ho solo quello del 90 ed ancora non riporta questa voce.. Spero di ricordarmi di scansionare quello piu' recente.
Sono stati venduti 17 milioni di Commodore 64.
Credo che se vedessi il quantitativo di floppy che possiedo dell'ST ti faresti 4 pianti. Non credo tu ne abbia la piu' pallida idea.
Contali. E poi contiamo quelli per Amiga.
Comincio a credere che tu viva di fantasia pura e che non abbia mai avuto un ST per le mani, anzi ne sono convinto.
Hai citato 3 giochi con i quali sono cresciuto.

Stuntcar racer, (Ricordo ancora il pesante cavo che passava da una stanza all'altra per collegare i due computer) su amiga vantava un audio migliore (anche se il rumore di vetri che si rompevano al minimo strusciamento, per di piu' su una macchina senza finestrini per natura, era un po' ridicolo), ma in termini di velocita' rispetto alla versione ST, era ridicola, sembrava spastico.
Tanti non sono d'accordo con te. Te riporto un paio.

http://www.lemonamiga.com/?game_id=1014
GRAPHICS: 8 / 10: The graphics in Stunt Car Racer are nicely done, giving you a real sense of height and more importantly speed! The 3D graphics run very smoothly indeed. And although not very detailed they do the job more than sufficiently!
SOUND: 8 / 10: Stunt Car Racer lacks music but the in-game sounds are very good. There are some nice soundFX when disaster strikes in the form of collision-sounds and scraping metal on concrete. The engine sound could have been a bit more violent.

http://www.classicgaming.com/amigareviews/stuntcar.htm
GRAPHICS 95%: Solid 3-D track graphics may not look amazing, but they move incredibly fast. The flaming engine and bouncing wheels are great too.
SOUND 85%: Effective engine revving stuff.
"This is one of the most exhilarating racing games I have ever played. The solid 3-D tracks move amazingly fast: akin to riding on a rollercoaster. But even better, you literally fly over jumps and come crashing down with a thump, the car wheels bobbing up realistically, only to bounce up in the air again. And when you crash, it is really spectacular as the whole world seems to spin around before you hit the ground in a cloud of dust. I lost count of the times I wrecked my car, but the game is so much fun to play that it never got at all frustrating. And with eight tortuous tracks and a whole host of different computer drivers – who all have their own driving styles – you should be kept playing for months."

Ovviamente i tuoi ricordi valgono più delle recensioni di professionisti del settore (Zzap, si sa, è da buttare come rivista).
F16 Falcon era molto piu' fluido sull'atari e per di piu' aveva suoni campionati come sull'amiga, anche se di qualita' inferiore. (notare come l'emulazione ST sia cosi' indietro tutt'oggi da non essere in grado di emulare correttamente i suoni campionati da esso generati). Girava notevolmente meglio su Atari.

Ed Elite, cosi' come il 2 (la miglior versione era pc oramai al tempo), girava ugualmente meglio su Atari.

Ritengo che tu lo abbia sempre e solo snobbato e mai usato veramente.
Idem per gli altri. Inoltre la tua memoria vacilla. Ecco qui: http://www.classicgaming.com/amigareviews/elite.htm#elitezzap cosa dicono rispetto alla versione Atari che ritieni migliore:

"The 3D graphics are incredibly fast and smooth, looking more like real solid objects rather than a computer simulation of 3D shapes - and, surprisingly enough, the 3D seems actually faster than the ST version."

Inoltre mi piacerebbe sapere quali giochi abbiano usato il blitter dell'amiga come acceleratore vettoriale, non mi risulta che nessun gioco famoso abbia mai fatto questo,né per Amiga, né per ST con blitter (la serie mega esisteva da molti anni prima della serie E), né per ST-E.
Per Amiga tutti: non usare il blitter ma la CPU per il filling dei poligoni, disponendo di grafica a bitplane anziché chunky sarebbe stato da suicidio.
Se per te 7 milioni di dollari nell'80 sembrano pochi..
Per una società che vendeva joystick e che ha investito tutti i suoi fondi per quel progetto, direi proprio di sì.
Vuoi mettere con Commodore o Atari?
Vinse la commodore solo per questioni finanziarie, ma non vedo che cosa c'entri.
I chip erano completi, ma il computer no.. Non vedo cosa cambi.
Neppure l'ST era pronto, all'epoca: infatti Jack Tramiel voleva infilargli proprio quei chip custom.
Le cose stanno cosi', quella storia la mia famiglia l'ha vissuta, posso scriverla anche io una pagina internet con le mie interpretazioni degli stessi argomenti, cosi' hai altri link da postare.
Preferisco queste storie, le interviste e le biografie di chi ha creato Amiga ai tuoi ricordi...
Ma veramente non era il sistema operativo?? Oggi c'e' aria di scoperte.
Il TOS si mangiava e ric.. l'AmigaOS, soprattutto quello del tempo. (quale?? :)) )
http://it.wikipedia.org/wiki/Immagine:Wb_13boing3.jpg
http://it.wikipedia.org/wiki/AmigaOS
"Caratteristiche

AmigaOS è un sistema operativo monoutente multiprogrammato e si distingue per:
Preemptive multitasking : Round Robin prioritizzato
Architettura modulare a memoria dinamica basata sul microkernel Exec (ExecSG dalla versione 4)
Interrupt programmabili in tempo reale e con bassa latenza
Nessuna protezione della memoria (fino alla versione 3.9)/ protezione della memoria limitata (dalla versione 4)
Design a 32-bit
Programmabilità dispositivi accessibili da filesystem
Supporto per le librerie condivise
Comunicazioni inter-processo molto veloci (IPC con messaggi passati per riferimento)"

http://en.wikipedia.org/wiki/Image:Atari_tos_gem.png
http://en.wikipedia.org/wiki/Atari_TOS
"TOS combined Digital Research's GEM GUI running on top of the DOS-like GEMDOS. Features included a flat memory model, MS-DOS-compatible disk format, support for MIDI, and a variant of SCSI called ACSI (in later versions)."
http://it.wikipedia.org/wiki/Atari_ST
"La Digital Research concedeva in licenza l'uso dei propri sistemi operativi, ma non era interessata al loro porting su altre piattaforme, pertanto, l'Atari inviò un proprio team di programmatori presso la Digital Research a Monterey, che avrebbero dovuto occuparsi della conversione. Ad essi furono consegnate le ultime versioni dei codici per Intel 8086 che furono convertite in codice 68000 in un tempo brevissimo. L'interfaccia grafica lavorava sulla base di un sistema operativo del tipo CP/M-68K e fu resa disponibile per il gennaio del 1985, giusto in tempo per l'introduzione dell'Atari ST al CES (una fiera di elettronica che si teneva ogni gennaio a Las Vegas).

Il CP/M-68K era una conversione diretta del vecchio sistema operativo CP/M. Già per il 1985, si trattava di un sistema operativo piuttosto antiquato come struttura dei comandi e, soprattutto, per la mancanza di un supporto ad un file system gerarchico (ovvero, tutti i file dovevano stare nella directory principale). La Digital Research stava anche sviluppando un nuovo sistema operativo simile al DOS, scritto specificamente per il GEM, il GEMDOS, ma ci furono delle discussioni sulla possibilità di convertire o meno il GEMDOS sull'Atari ST per la data di lancio di giugno. Alla fine si decise di effettuare il porting ed il sistema operativo definitivo dell'Atari ST, combinazione di GEM e GEMDOS, prese il nome TOS. Fu decisamente una buona mossa, poiché il nuovo sistema era compatibile con il formato standard dei dischetti per i PC IBM."

Proprio la stessa cosa, vero?
Se prima avevo qualche dubbio sul fatto che tu non abbia mai usato un ST, ora ne sono certo.
Addirittura ci fu una causa tra Atari-Apple e digital, riguardo proprio la cessione del GEM ad Atari.
Ora mi invento una parola Jackintosh, che fantasia che ho!! eppure mi sembra di averla gia' sentita 20 anni fa.
Potresti fare l'avvocato.. Magari con te avrebbero avuto piu' facilmente ragione. Sarebbe bastato che andassi tu a dir loro "no signori, a me l'Atari sta sulle balle, percio' il TOS fa schifo ed il MAC OS e' migliore e non c'entra nulla!!". Semplice no??
Confronta con questa:
http://en.wikipedia.org/wiki/Image:Apple_Macintosh_Desktop.png
GEM avevo ripreso dei concetti, ma era più scarsa della GUI di MacOS.
Infatti qui: http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface dicono questo di GEM:

"At the same time Microsoft was developing Windows in the 1980s, Digital Research developed the GEM Desktop GUI system. GEM was created as an alternative window system to run on IBM PC systems, either on top of MS-DOS (like Microsoft Windows) or on top of CPM-86, DR's own operating system that MS-DOS was patterned after. GEM achieved minimal success in the PC world, but was later used as the native GUI on the Atari ST machines. Gem provoked and succumbed to the first "look and feel" lawsuit by Apple Computer."

Perché era veramente scarsa come GUI.
Tu che sei un esperto Atari, hai mai provato il multitos?? o forse hai provato il MagiC??
No, non l'ho mai provato.
Io ci facevo di tutto mentre in una finestra giravano anche giogni della pesantezza di Legende Of Vaour, il tutto su 8mhz di computer..
E magari senza rallentamenti...
Ho mai sostenuto che fosse la stessa cosa?? :o e si che ne sai parecchie di cose al mio riguardo!! ;)
Ho solo detto che determinati limiti non erano poi cosi' ferrei.
Comunque ricordavo male:

1) la palette di 16 colori veniva cambiata 3 volte per riga di raster anziché ogni 16 pixel, per cui la qualità era molto più scarsa;
2) con gli STE la palette era sempre di 16 colori, ma presi da una palette di 4096 anziché i canonici 512 dell'ST.
Nel Midi, nel calcolo,
Per 0,9Mhz in più? Ma gli mancava tutto il resto.
nel costo e nell'affidabilita' ecc..
Affidabilità che aveva anche l'Amiga. Sul costo ti rispondo dettagliatamente dopo.
Probabilmente te lo sei comprato solo ad un annetto dall'uscita dell'Amiga 500, ovviamente noi non potevamo aspettare quel periodo.
E poi io lo paragono per date d'uscita. Mi sembra logico.
Ho comprato un Amiga 2000 nel'87, pochi mesi dopo la sua commercializzazione in Italia.

Fortunatamente conservo ancora parecchie riviste del settore. La cronistoria, alla loro data di uscita, con tanto di costi è la seguente:

Inizio 1986
Atari 520ST: $899 (ma qui manca il monitor)
Amiga 1000: $1799

Metà 1986
Atari 520ST + Monitor monocromatico: L.2.100.000
Atari 520ST + Monitor colore: L.2.850.000
Amiga 1000 + Monitor colore: L.3.000.000

Inizio 1987
Atari 520ST + Monitor monocromatico: L.1.850.000
Atari 520ST + Monitor colore: L.2.270.000
Amiga 1000 + Monitor colore: L.2.250.000

Metà 1987
Atari 520ST: L.540.000
Atari 1024ST: L.1.100.000
Monitor monocromatico: L.300.000
Monitor colore: L.630.000
Amiga 500: L.950.000
Monitor colore: L.570.000
Espansione 512KB: L.210.000

Fine 1989
Atari 1024 ST: L.730.000
Amiga 500: L.670.000
Espansione 512KB: L.110.000

Inizio 1993
Atari 1024STE: L.660.000
Amiga 600: L.499.000

Atari MegaSTE: L.999.000
Amiga 1200: L.699.000

Nell'ultimo caso ho affiancato i rispettivi "concorrenti".

Direi che ci sia ben poco da commentare...
Bella risposta del c.. :D Credo che dal prossimo reply non ti terro' piu' in considerazione. Signori e signori quest'individuo ha appena asserito che l'ST avesse piu' Ram per via delle maggiori richieste da parte delle applicazioni.
Mentre per un povero realista come me (che non ha mai prigrammato un 68k in vita sua!! :cry: ) La realta' e' ben differente; l'ST poteva permettersi quantitativi di RAM maggiori per via dei prezzi determinati dalla non customizzazione dell'80% delle sue parti.
Era una battuta... :rolleyes:
Comunque sopra sono riportati i prezzi dei computer, e non ho problemi a fornirti anche quelli delle espansioni di memoria per i rispettivi Amiga: conservo ancora TUTTO.
Spesso i giochi risiedevano su un floppy da 320k (finquando possibile ovviamente)
I floppy a singola faccia degli ST erano da 360KB: come utente Atari, è un dato che dovresti conoscere bene.
che per Amiga diventava uno da 880 e tanti giochi per Amiga richiedevano un mega di Ram, mentre per ST solo mezzo.. Che questo dipendesse dall'Audio campionato ed a volte dalla presenza di piu' colori, e' solo una mia fantasia!!
Infatti: per avere giochi qualitativamente superiori, era necessaria l'espansione.
I primi giochi, comunque, funzionavano con soli 512KB.
Ma quali insulti?? se hai la coda di paglia non e' colpa mia, leggi le frasi per intero. Oggi mi sento buono e te la spiego.

E' ovvio che tu sappia leggere, dunque la spiegazione non e' quella, ma probabilmente l'altra da me ipotizzata e cioe' la tua fossilizzazione nel mondo Amiga.
Non provare a rigirare la frittata. Questa:

"Forse non sai ancora leggere ora che ci penso;"

è chiaramente una frase offensiva. A meno che l'italiano non sia un optional...
Seguiti a dare segni di mancanza d'esperienza in merito. Sai quanto costava espandere un 520ST da 512K ad un solo mega?? Te lo dico io, 2 milioni di lire nei primi due anni!!
Per gli Amiga molto meno, fortunatamente.
ancora me lo ricordo il CAD3D e 4D per amiga.. Ho i brividi per la velocita'!! forse usava il blitter.. Ma che Amiga avevi tu??
Amiga 2000 nel '97. Amiga 1200 nel '93. E anche nel 3D funzionavano molto bene.
Gia' discusso. C'e' da dire che Dragon's lair usava l'alta risoluzione!! fantastica, uno sfarfallio bellissimo, un francobollo sullo schermo al posto dell'immagine e l'audio perso per strada.. Non c'e' che dire, proprio una macchina equilibrata.
I tuoi ricordi lasciano il tempo che trovano, come al solito (ormai è evidente): http://www.classicgaming.com/amigareviews/draglai1.htm#dragonslair1zzap

"GRAPHICS 92%: Big, colourful, very fast, and slick. Lots of variety and imagination.
SOUND 85%: Hilarious spot FX, great arcade samples."
Guardati qualcuna delle centinaia di demo che ci sono in giro per gli ftp pub. Ovviamente vedile su un ST vero, perche' sugli emulatori girano male.
Vedrai schermi pieni a fluidita' assurde. Cerano anche dei programmi di grafica che li usavano.
L'overscan richiedeva PARECCHIO tempo di calcolo. Ecco qua: http://mysite.freeserve.com/antspants/st_info/fullscrn.zip

"The disadvantage of this method is that the border annihilation takes up to 50 per cent of the processor time."

Questo per utilizzare TUTTI i bordi (sopra, sotto, destra e sinistra) dello schermo con l'ST. Usandone soltanto alcuni, o con meno spazio, le richieste erano inferiori.

Sull'Amiga l'impatto dell'overscan sulla CPU era di qualche ciclo di clock rubato per ogni riga di raster (visibile).
Scaricati l'octalyser, usava 8 canali a 25khz sui quali poteva gestire anche l'interpolazione.
Oppure l'audio sculpture, usava 4 canali a 50 khz, io cosi' ho iniziato a scrivere musica da ragazzino!! :) Mi ero anche modificato il mio STE per prelevare l'audio prima dei filtri e degli equalizzatori.
Ovviamente questi programmi non girano sugli emulatori, ma nel tuo parco computer avrai ancora un STE sul quale provare. Se ti manca, ti vendo uno dei miei.
Hai mai provato con SainT o STeem?
Ovviamente senza l'utilizzo della cpu per aggiungere canali.

Senza CPU come detto sopra l'STE ne faceva 4 a 50..

http://atari-ste.anvil-soft.com/html/trackdoc1.htm

La scelta del link e' dettata dalla rigorosa legge della casualita', e' il primo link saltato fuori da Google, a me basta a te probabilmente no, ma mi sembra scontato.

Nota: Fosse stato ottenuto anche tramite l'ausilio della cpu come l'esempio da te riportato per Amiga, i risultati sono comunque doppi sull'STE.
Non ci scordiamo che non perse l'YM2149, che rimane pur sempre un generatore e modulatore di onde quadre molto cristallino e capace di 9 ottave.. mettendoci pure il generatore di rumori bianchi i canali finiscono a 8.
Non ti sei neppure accorto che il link che hai postato fa parte del sito di cui t'avevo postato dei link proprio sull'audio.
Ovviamente ti sei fermato a leggere solo quello che t'interessava. Ecco qui, continuando da quella pagina, cosa viene fuori dai commenti su alcuni player:

"CD-PLAYER: However, it is pretty to look at and let it play old mods if you have nothing else to do with your computer.
PAULA: On the other hand the use of 50 khz replay frequency is almost impossible as the player seems to be pretty slow."

Questo perché i canali sono soltanto due, e per suonare moduli con 4 o 8 canali è necessario miscelarli e ridurgli, quindi, agli unici due disponibili.

Qui: http://mysite.freeserve.com/antspants/st_info/ste.zip Ci sono le specifiche dell'STE e nel file STEINFO.TXT, che descrive dettagliatamente come funziona il suo hardware, trovi questo:

"STE DIGITIZED SOUND OVERVIEW

There are two channels which behave as described above; they are intended
to be used as the left and right channels of a stereo system when using the
audio outputs of the machine. A monophonic mode is provided which will
send the same sample data to each channel.

The stereo sound output is also mixed onto the standard ST audio output
sent to the monitor's speaker. The ST's GI sound chip output can be mixed
to the monitor and to both stereo output jacks as well."

Quindi, come vedi, i canali sono soltanto due. Nel file di cui sopra comunque ci sono i sorgenti (in assembly) di alcuni player di moduli. Ecco qui cosa riporta l'autore del ProTracker player (4 canali audio):

"I am now able to do a 50kHz routine with every command around 30% of the STe's totally processing power"

La tua memoria vacilla non poco...
Come vedi tu forse.
Io vedo bene e soprattutto capisco come stanno le cose: hai torto marcio, come ho dimostrato.
Hai le idee confuse.. Il sistema operativo decente l'amiga lo ha visto solo durante l'ultima fase della sua vita e non si paragona con il TOS, che temo proprio tu non abbia mai usato, ma questo oramai e' chiaro e per quanto riguarda l'HW e' parere tuo che sia superiore. Lo e', ma vincolatamente ad alcune cose, era comuqnue un progetto finito di corsa e vittima di mille tagli e al personale ed ai finanziamenti.
Sul TOS vedi sopra. E ho postato link e immagini dell'AmigaOS 1.3, che era già sufficiente a ridicolizzare il TOS quanto a funzionalità e interfaccia utente: nel 1990 è arrivato AmigaOS 2.0, che era UN TANTINO MEGLIO:
http://en.wikipedia.org/wiki/Image:Amiga_Workbench_2.gif
Nel 1993, con Amiga 1200 e 4000 arrivò la versione 3.0:
http://en.wikipedia.org/wiki/Image:Amiga_Workbench_3.gif
E poi la 3.5/3.9:
http://en.wikipedia.org/wiki/Image:AmigaOS_3_9_Workbench.jpg
Qui http://en.wikipedia.org/wiki/AmigaOS trovi tutta la storia di questo s.o.: confrontalo pure col TOS e col MultiTOS...
A causa anche della lentezza dei programmi che vi girarano sopra
I tuoi soliti ricordi...
e dell'assenza di un'alta risoluzione video stabile come la monocromatica dell'ST.
Ti riferisci all'interlace? Esistevano i deinterlacer. Nel 1990 l'Amiga 3000 lo implementava in hardware.
"Anche al Mac mancava l'interfaccia midi".. non mi pare che questo ne impedi' il diffondersi in quell'ambito. :mc:
Infatti anche per Amiga esistevano parecchi programmi in questo campo: http://it.wikipedia.org/wiki/Amiga

"L'architettura dei programmi Amiga fu presa ad esempio da molte software house: ad esempio, il programma sequencer e editing audio Bars and Pipes fu acquistato dalla Microsoft la quale utilizzò alcuni concetti presenti in questo programma per la progettazione della componente audio di DirectX."
Assolutamente falso, comincio a stancarmi sinceramente, hai campato chiuso in un eremo con un amiga ed un 486.
No, ho usato parecchi computer nella mia vita, compreso un Atari 1024ST.
Da come parli, parrebbe che un ST fosse un 68k attaccato direttamente alla corrente!! Ti stai sbagliado pesantemente, aveva anch'esso chip di supporto che se pur non customizzati, davano i loro bei risultati, forse non essendo cosi' pirotecnici come quelli Amiga, non li hai mai notati, Ma sono problemi tuoi non miei.
[...]ma sicuramente formiva una discreta prestazione (visto il costo) e delle risoluzioni (soprattutto la monocromatica) che fecero la differenza in ambito professionale.
L'ST aveva 3 risoluzioni: 320x200 a 16 colori, 640x200 a 4 colori e 640x400 a 2 colori, da una palette di 512.
Vuoi mettere con le risoluzioni dell'Amiga, che andavano dalla 320x200 a 32, 64 (Half Brite) o 4096 (HAM) colori alla 640x512 a 16 colori, con una palette di 4096 colori? E non sto considerando neppure l'overscan...
E comunque l'evoluzione dello stesso montato nell'STe colmava prte delle differenze.
Ben poco: le risoluzioni e il numero di colori sono rimaste le stesse, e soltanto la palette è passata da 512 a 4096 colori. Aggiungiamoci i due canali audio PCM a 8 bit, e abbiamo finito con i miglioramenti.
Poi c'era LYM2149F, che era una sorta di clone compatibile con l'AY38910
non solo era capace di spaziare da 30hz a 120 khz, (dinamica che il paula si sognava) con le proprie quadre, ma assolveva anche ad alcune funzioni legate all'IO.
La dinamica di Paula se la sognava, caso mai, visto che poteva competere col Commodore64... E quanto all'I/O, Paula era messo anche meglio.
In oltre il WD1772hp (controller floppy che conosci) controllava 2 floppy in DMA.
Amiga poteva controllare 4 floppy in DMA, e poteva anche scrivere contemporaneamente gli stessi dati su 4 floppy.
Inoltre permetteva di controllare in maniera completamente arbitraria i dati spediti ai floppy: io riuscivo a infilare 1029KB di dati nei floppy (12 settori da 512 byte e uno da 128 byte, per traccia).
DMA, gestito dal.. (confesso di non essermi ricordato il nome, sono passati 20 anni) C100110-001 (che infatti non aveva un nome ma solo una sigla), incaricato del trasferimento diretto dalla ram (ovviamente direi). Era un basmaster assieme al 68k.
Amiga metteva a disposizione 25 (VENTICINQUE) canali DMA per le varie periferiche.
poi c'era l'ST EF6850P ACIA per la midi ed il Motorola MC68901P, processore multifunzione che ad esempio generava gli interrupt per il 68k ed il Glue e gestiva l'IN assieme allo Yamaha.
Paula permetteva di multiplexare gli interrupt disponibili, ampliandone la "gamma".
Questa e' una panoramica generale ed assolutamente incompleta.
Ma basta a mettere in evidenza l'obsolenscenza dell'hardware dell'ST rispetto all'Amiga.
Poi cosi' solo non era 'sto benedetto 68K, tant'e' vero che le rare volte che il compurer andava in crash, alcune funzioni indipendenti continuavano a svolgere il loro lavoro.
Merito degli hook, come t'ho gia spiegato. Come il PC con i TSR del DOS...
Al masismo era multi finestra, il multitsk dell'amiga era ridicolo come il SO stesso.
I player lavoravano in bg pure su ST. :o Tu hai vissuto un'altra realta'.
Sei tu che non hai mai visto un'Amiga e come gestiva benissimo il multitasking dei programmi.
I fatti non te li posso provare, visto che non ho nessuna intenzione di scomodare me ed i miei computer per venire da te a dimostrarti come qualunque gioco poligonale girasse palesemente meglio su un ST.
Non serve: t'ho fatto vedere che non è così.
Nemmeno K e TGM leggevi al tempo!! :) (a proposito, ho un mare di riveste del tempo, tecniche e ludiche).
Idem. Allora dovresti anche vedermi in qualche foto del 1996 (anche su C+VG e Zeta).
Che tu possa contestare le mie esperienze, a me risulta trasparente ed ininfluente. Io posso portartele e tu puoi prendere come ca***** se la cosa ti aggrada. :) Resta il fatto che io non abbia alcuna motivazione per dirne.
Non sono in un tribunale, non devo dimostrare nulla a nessuno, cercare link e rispondere a questi post.. porta via tempo prezioso al mio lavoro.
Se lo faccio e' solo per portare la mia esperienza ad altri ed imparare dalla loro. Con te risulta veramente inutile tutto cio'. Tu non devi mettere in dubbio le mie affermazioni, non mi pagano per dire che FS girasse 20 anni fa piu' rapidamente su una piattaforma anziché su un'altra.
Le metto in dubbio e ho già dimostrato ampiamente che la tua memoria ha fatto cilecca non poche volte. Visto che non conosci neppure come funzionano i computer che dici di aver usato, e campi di leggende metropolitane (gli 8 canali audio dell'STE, poi, sono una vera chicca...)
Bello riscrivere le stesse cose piu' volte, almeno risparmio di pensare nuovamente.
Io ho detto che il Falon e' l'evoluzione dell'ST. Da quanto tu asserisci, risulta evidente come tu non abbia mai visto l'interno di un falcon (ne tantomeno programmato, visto che ci fai tanto spesso riferimento). Non aveva pressoche' nulla di uguale alle vecchie macchine (mentre il TT era similissimo in quasi tutto, diciamo che fu il papa' dell'STE).
Non m'interessa l'interno: neppure il TT era simile ai precedenti ST. A me interessa come funzionano, e da questo punto di vista sono una normale evoluzione dei loro predecessori.
Questo dati alla mano: ma ovviamente i link che ho postato non li hai degnati neppure di uno sguardo (ma tanto dubbito che tu possa carpirne qualche dettaglio).
Infatti come ho gia' chiarito prima questo e' l'ultimo post al quale ti rispondero'.
Non c'è problema: tanto è evidente che hai ben poco da argomentare per sostenere i tuoi pessimi ricordi...
Lo so bene, la meta' degli strumenti musicali che possiedo all'interno ha un processore di quella famiglia. Tuttavia non e' stato un ripiego o riciclo, perche' quest'implementazione era gia' diffusa in precedenza, e' solo un settore che e' durato piu' a lungo ed ha visto l'ausilio anche di evoluzioni dello stesso (come il coldfire). Ma non mi sembra una risposta soddisfacente, anzi non e' una risposta la tua.
La realtà non la puoi cancellare: i 680x0 sono stati relegati al ruolo di microcontrollori. Che ti piaccia o meno. Punto.
Se trovo qualche link in merito te lo posto, comuqnue motorola ci mise molto del proprio, se non ricordo male l'emulazione 680x0 girava alla grande.
Ricordi male: l'emulazione non è farina del suo sacco.
Comuqnue non mi sono mai interessato piu' di taTutti sbagliano, ma quest'affermazione e' relativamente giusta. Anche gli x86 sono stati stravolti per scalare.
Hai capito tutto... :rolleyes: OK, lasciamo perdere perché tanto è inutile continuare su questa strada con te...
In totale si distribuirono 2-3 anni di gloria a testa.
Già a partire dal 1988 le riviste erano piene di lettere di utenti Atari che si lamentavano del supporto sempre più scarso. Al contrario dell'Amiga, che continuava la sua ascesa, ed è rimasta la piattaforma di riferimento nel campo dei videogiochi (il più grosso: ma anche in tanti altri) fino al 1996.

Il momento di gloria degli ST è durato ben poco... Amen.
Il fatto del termine multimedia che sia nato con Amiga non lo sapevo, mi infrmero' sicuramente in merito.
Poi sarei io quello che è rimasto chiuso con l'Amiga e il 486... :rolleyes:
E' un dato storico talmente noto, che soltanto tu potevi sconoscere.
Hai pienamente ragione, ma non credo che il panorama sia tutto cosi', cioe', ci saranno pure dei vantaggi in tale struttura no??!! magari perde da un lato e vince dall'altro. Poi credo che dovremmo almeno accantonare il 68020 e prendere lo 060. Quante istruzioni poteva decodificare uno 060 per ciclo?? 3 se non erro. Una meno del pentium del quale era il doppio piu' veloce a parita' di clock.
Ricordi, ricordi, ricordi... Mah. Un 68060 poteva decodificare ed eseguire fino a 2 istruzioni per ciclo di clock: esattamente come il Pentium.
Non credo proprio, tu mi attaccasti quando io dissi che i dsp del cell avrebbero potuto adempiere a funzioni GP negandolo assolutamente, definendo ridicole le loro prestazioni in merito.
Ti sei contraddetto nell'arco di una frase: complimenti per il record.

Poi se gentilmente mi fai vedere quando l'avrei "negato assolutamente"...
Io non voglio metterti in boca nulla, tieni i tuoi vizi al difuori del forum. ;)
Dobbiamo ridere? Ah Ah Ah Contento? Ti basta così poco per farti sentire felice...
Gradirei non mi spiegassi la differenza tra un K8 ed un P4, voglio morire nella mia immensa inoranza (almeno a questo crederai).
Se prima lo avevo detto per provocarti, ora lo penso. Tu non sai leggere!!
Io so leggere bene: sei tu che ti sei sbilanciato in confronti assolutamente privi di senso.
Lo provero'. (lo sto provando.. per ora da solo schermate nere.. ora ci smanetto un po')
Ma non eri un retrogamer? Non conosci neppure il MESS...
Forse non parlo italiano..
Un qualunque pc di oggi ha seri problemi con le periferiche ide, che siano ottiche o hd. quando lavora intensamente subisce rallentamenti (e con i cd arriva pure a freezarsi poi no ti dico se sono rovinati!!).
Inoltre non mantiene di suo una precisione ritmica degna di un professionista con i piu' avanzati programmi a meno che non si implementi una scheda che gestisca il comparto midi/audio per conto proprio. Non vedo come possa farlo sotto emulazione.
Ripeto: mi fornisci degli esempi di problemi dovuti all'IDE, che siano RIPRODUCIBILI?
Non mi spaventa fare un adattatore simile in fin dei conti, tutto starebbe nel vedere dove un eventuale emulatore potrebbe indirizzare quella porta.
Ci sarebbe l'imbarazzo della scelta: seriale, parallela, USB... Il bus di espansione degli Atari ST è un vecchissimo VME a 16 bit.
I miei rispetti Dott. Di Mauro :D
Come volevasi dimostrare: a un certo punto, in mancanza di argomenti, si deve per forza attaccare il titolo. Ormai è un classico: dovremmo metterlo nel regolamento di evitare comportamenti come questi...
Senta, ho un dolorino da una parte..
Mi spiace: io mi occupo di computer, non di cervelli...

[cdimauro]

Comunque a mio parere un confronto tra Atari ST ed Amiga appare un poco fuori topic o sbaglio ?
Se è per questo neppure Cell, PPC970, Xenon, ecc. c'entravano col topic... :p

[MadRat]

Comunque a mio parere un confronto tra Atari ST ed Amiga appare un poco fuori topic o sbaglio ?



Se è per questo neppure Cell, PPC970, Xenon, ecc. c'entravano col topic... :p

Almeno quei due computer hanno un 68k, in qualche modo c'entrano..ma il Cell appunto?? :D
Piu' che altro direi che vadano bene entrambi i discorsi, in realta' e' sbagliato il titolo del topic stesso. La discussione nacque dalla differenza tra architetture ed efficienza delle stesse. E' un discorso molto generico e con margini molto vaghi. Poi a noi sta bene cosi'. :)

[Marco71]

Io ho "amato" "Lorraine"...
Conservo ancora custoditi "gelosamente" una scheda "acceleratrice" 68020/68881 (fatta ahimè con i "piedi" da una ditta di Milano che aveva il nome che iniziava per H e finiva con L) più varie buste antistatiche con alcuni MC68000-10 ed -8 più un 68010-8...
Grazie.

Marco71.

[MadRat]

Io ho "amato" "Lorraine"...
Conservo ancora custoditi "gelosamente" una scheda "acceleratrice" 68020/68881 (fatta ahimè con i "piedi" da una ditta di Milano che aveva il nome che iniziava per H e finiva con L) più varie buste antistatiche con alcuni MC68000-10 ed -8 più un 68010-8...
Grazie.

Marco71.

Purtroppo ho dovuto buttare un sacco di roba, specialmente riguardo le macchine ad 8bit (soprattutto la parte cartacea/tecnica), ma ho ancora molte schede acceleratrici e simili per quelle macchine.. Peccato che non abbiano piu' le confezioni.

Che emozione ripensarci!! :)

[MadRat]

Ti rispndo ugualmente, non mi va di lasciarti l'ultima corbelleria, ne voglio dire qualcuna pure io!! :D
Sei troppo sicuro delle tue astrazioni.



Hai dimenticato il contesto: i giochi. Se voglio inserire un campione da riprodurre, chessò "Welcome to Fright Night", la tastiera collegata alla porta non potrà farlo. Potrebbe farlo scaricandolo tramite MIDI, ma a 3KB/s di velocità faresti prima a finire il gioco...


Va be', qui non hai capito cio' che ho detto, al masismo te lo rileggi.


http://www.lemonamiga.com/?game_id=1014
GRAPHICS: 8 / 10: The graphics in Stunt Car Racer are nicely done, giving you a real sense of height and more importantly speed! The 3D graphics run very smoothly indeed. And although not very detailed they do the job more than sufficiently!
SOUND: 8 / 10: Stunt Car Racer lacks music but the in-game sounds are very good. There are some nice soundFX when disaster strikes in the form of collision-sounds and scraping metal on concrete. The engine sound could have been a bit more violent.
Ecc..


Poco conta una recensione di qualcuno come te. :) Stuntcar era un gioco programmato benissimo su entrambe le piattaforme ad esempio, ma se paragonate le due versioni, saltava all'occhio come quella Atari girasse molto piu' rapidamente.. Senza contare il fatto che lanciando il computer a 60hz, tutto girava assolutamente piu' velocemente.


Neppure l'ST era pronto, all'epoca: infatti Jack Tramiel voleva infilargli proprio quei chip custom.


L'ST non era finito?? mah e comunque se JT lo avesse preso, ne avremmo guadagnato tutti.




http://it.wikipedia.org/wiki/Immagine:Wb_13boing3.jpg
http://it.wikipedia.org/wiki/AmigaOS
"Caratteristiche

AmigaOS è un sistema operativo monoutente multiprogrammato e si distingue per:
Preemptive ...............

.........il porting ed il sistema operativo definitivo dell'Atari ST, combinazione di GEM e GEMDOS, prese il nome TOS. Fu decisamente una buona mossa, poiché il nuovo sistema era compatibile con il formato standard dei dischetti per i PC IBM."


Proprio la stessa cosa, vero?


Non c'e' che dire, un bell'albero di natale su floppy. Accendendo un Amiga non potevi nemmeno copiare un floppy. Caricando in WB sacrificavi quello sputo di ram che c'era.


E magari senza rallentamenti...


Assolutamente minimi, nulla che avesse a che vedere con il multitos in ogni caso.



Affidabilità che aveva anche l'Amiga. Sul costo ti rispondo dettagliatamente dopo.


Il guru del mio Amiga aveva il culo quadrato a forza di stare seduto.



Fortunatamente conservo ancora parecchie riviste del settore. La cronistoria, alla loro data di uscita, con tanto di costi è la seguente:

Inizio 1986
Atari 520ST: $899 (ma qui manca il monitor)
Amiga 1000: $1799

..


Atari MegaSTE: L.999.000
Amiga 1200: L.699.000

Nell'ultimo caso ho affiancato i rispettivi "concorrenti".

Direi che ci sia ben poco da commentare...


In laboratorio ho sicuramente ancora qualche listino ufficiale che distribuivamo ai negozi, qualora dovessi ritrovarlo te lo scansionerei.
Comunque commentiamo.. Meta' della Ram e prezzo piu' alto (mentre per l'ST un mega era oltre ogni possibile utilita', per l'Amiga era il minimo). Non c'e' che dire.


Era una battuta... :rolleyes:
Comunque sopra sono riportati i prezzi dei computer, e non ho problemi a fornirti anche quelli delle espansioni di memoria per i rispettivi Amiga: conservo ancora TUTTO.


Allora devo ridere pure io :D hahaha!!
Io purtroppo ho bisogno di spazio per il mio studio.


I floppy a singola faccia degli ST erano da 360KB: come utente Atari, è un dato che dovresti conoscere bene.


Cavolo hai proprio ragione, allora sappi che il 1024 ST si chiama 1040!! ;) Quale inutilita' di discorsi..


Per gli Amiga molto meno, fortunatamente.


Per il 500 forse.. non certo per il 1000 che di ram era proprio scarsino direi. Caricato il SO poteva giusto far girare pacman. Non che il 500 stesse meglio. ;)


Amiga 2000 nel '97. Amiga 1200 nel '93. E anche nel 3D funzionavano molto bene.


Pareri tuoi e di chi come te.


I tuoi ricordi lasciano il tempo che trovano, come al solito (ormai è evidente): http://www.classicgaming.com/amigareviews/draglai1.htm#dragonslair1zzap

"GRAPHICS 92%: Big, colourful, very fast, and slick. Lots of variety and imagination.
SOUND 85%: Hilarious spot FX, great arcade samples."


Io credo sempre di piu' che dovresti soffermarti a leggere cio' che la gente scrive. Dove ho mai detto che quel gioco fosse brutto?? io lo adoravo in tutte le sue forme!! Lo ho solo riportato come esempio, perche' era uno dei pochissimi giochi che poteva far ricorso all'alta risoluzione (spingendo h mi pare) ma l'immagine rimaneva 320 * 240+ overscreen, finiva al centro dello schermo e disattivava l'audio.. che a detta tua non richiedeva altro che qualche ciclo di clock.. Mentre per me è l'evidente dimostrazione di come quella macchina non fosse ben dimensionata.

Inoltre aggiungerei una cosa che si chiama "riflessione" Ammesso e non concesso che Elite fosse piu' veloce su Amiga che su ST.. Su amiga l'ho solo provato, su ST l'ho giocato (percio' ammetto che possa ricordare male), il recensore dice che:

"E' abbastanza SORPRENDENTE che SEMBRA realmente piu' veloce che nella versione ST".
Questo vuol dire EVIDENTEMENTE che su amiga girassero sempre piu' velocemente i giochi 3d, no??
Oppure significa che:
1) quel gioco SEMBRA, piu' veloce, e' una vaga impressione.
2) sull'ST di i programmi 3d (ghiochi ed utility) giravano sempre piu' velocemente, tanto da destare stupore una parita'(forse con leggero vantaggio) da parte dell'Amiga.

Oh mamma, quando uno e' di coccoarmato, nemmeno una cannonata lo smuove.



L'overscan richiedeva PARECCHIO tempo di calcolo. Ecco qua: http://mysite.freeserve.com/antspants/st_info/fullscrn.zip
ecc..


Non l'ho mai paragonato dal punto di vista grafico. Ho solo detto che compunque non era cosi' rigido come lo disegni.


Hai mai provato con SainT o STeem?


Sicuramente molto piu' di te, solo che io posso paragonarlo all'originale, tu no.


Non ti sei neppure accorto che il link che hai postato fa parte del sito di cui t'avevo postato dei link proprio sull'audio.
Ovviamente ti sei fermato a leggere solo quello che t'interessava.

Questo perché i canali sono soltanto due, e per suonare moduli con 4 o 8 canali è necessario miscelarli e ridurgli, quindi, agli unici due disponibili.
La tua memoria vacilla non poco...
Io vedo bene e soprattutto capisco come stanno le cose: hai torto marcio, come ho dimostrato.



Del link me ne sono accorto e dice quanto ho riportato io.

La mia memoria non vacilla affatto, se per te avere due canali fisici e 4 virtuali ai fini dello stereo sia differente, questo non vuol dire che all'atto pratico la cosa cambi i risultati.
Che tu ne dica l'audiosculpture suona 4 ch a 50 khz l'uno. Tanto e' vero che campionavo 50 khz (con il prosound designer ed il pandal) e poi riutilizzavp il prodotto per inserirlo in quel tracker. Che tu sia "tecnicamente d'accordo o meno". E su ogni pubblicita', manuale e recensione del tempo l'STE era dato per 8 ch, visti come 4 pcm, 3 sintetizzatori quadri ed 1 dedito al rumore bianco.


Ti riferisci all'interlace? Esistevano i deinterlacer. Nel 1990 l'Amiga 3000 lo implementava in hardware.


Mi riferisco esattamente alle interlacciate. L'A3000 non credo proprio facesse testo visto che non era proprio la macchina di riferimento del mercato.. Se proprio vogliamo essere pignoli il TT poteva arrivare a 1280 * 960.
E poi anche con i deinterlacciatori, non si poteva lavorare per ore/giorni/anni davanti ad un monitor a 50hz.


No, ho usato parecchi computer nella mia vita, compreso un Atari 1024ST.


1040 ;)


Ben poco: le risoluzioni e il numero di colori sono rimaste le stesse, e soltanto la palette è passata da 512 a 4096 colori. Aggiungiamoci i due canali audio PCM a 8 bit, e abbiamo finito con i miglioramenti.


Come no!! primo ti sei dimanticato il blitter, secondo l'evoluzione dello shifter video in ambito di scrolling (creato apposta) e poi non insistere con questi 2 canali, perche' allora l'amiga ne aveva uno solo, visto che la somma delle frequenze da la meta' come risultato!!. Caricati l'octalyzer per STE sugli emulatori fantomatici ti accorgerai che a 25 khz potrei usare 8 ch ed avrai pure modo di attivare l'intermpolazione. (questa richiedeva potenza alla cpu)

Altro piccolo punto. Io non ho mai parlato di protraker che ritengo una gran cagata, un pessimo porting da Amiga.



La dinamica di Paula se la sognava, caso mai, visto che poteva competere col Commodore64... E quanto all'I/O, Paula era messo anche meglio.


Temo che tu non sappia il significato della parola dinamica. Ti ho portato dei valori molto significativi. avendo una riproduzione a 22khz in pcm a 8bit, l'Amiga non puo' arrivare a dinamiche simili, e' tecnicamente impossibile avere una simile pressione e profondita' sonora con simili caratteristiche.
Per quanto io sia un estimatore del SID del C64, la dinamica sonora era esattamente il suo limite. Anche se indubbiamente piu' vario nelle timbriche e nelle forme generate rispetto all'YM.


Amiga poteva controllare 4 floppy in DMA, e poteva anche scrivere contemporaneamente gli stessi dati su 4 floppy.
Inoltre permetteva di controllare in maniera completamente arbitraria i dati spediti ai floppy: io riuscivo a infilare 1029KB di dati nei floppy (12 settori da 512 byte e uno da 128 byte, per traccia).


Anche l'st lo poteva fare, ma non pensarono (giustamente) di implementare l'utilizzo di 4 floppy, inutili alla stragrande maggioranza dell'utenza, tanto da poter essere definita la totalita'.

Io con il semplicissimo Fcopy, che era il piu' semplice dei copiatori per atari, formattavo alle stesse dimensioni da te citate.. dovresti saperle queste cose.
Inoltre il floppy dell'Amiga era di una lentezza esorbitante in tutto. Copiare un disco faceva venire sonno!!
Anche le versioni della blitz syncro per Amiga era nettamente piu' lente.




Amiga metteva a disposizione 25 (VENTICINQUE) canali DMA per le varie periferiche.


Gia', mammaquanti (MAMMAQUANTI). l'ST ne aveva semplicemente quanti gliene servivano per gestire i propri sottosistemi.


Ma basta a mettere in evidenza l'obsolenscenza dell'hardware dell'ST rispetto all'Amiga.


Sotto la tua interpretazione.

All'atto pratico un Amiga impallato cessava ogni funzione, inchiodando la nota di un eventuale musica su se stessa.
I comparti dell'ST erano decisamente piu' indipendenti. Che la tua teoria sia d'accordo o meno.


Sei tu che non hai mai visto un'Amiga e come gestiva benissimo il multitasking dei programmi.


Benissimissimo direi. :D



Idem. Allora dovresti anche vedermi in qualche foto del 1996 (anche su C+VG e Zeta).


Spero almeno sorridessi.


(gli 8 canali audio dell'STE, poi, sono una vera chicca...)


Che ti piaccia o meno li aveva, pero' potremmo inventare la macchina del tempo ed andare a riscrivere tutti gli articoli del tempo, manuali e pubblicita'. E' pur sempre una soluzione.
In fin dei conti chi sarebbe mai il pazzo che non ti darebbe retta di fronte ad una tua spiegazione tecnica!! ;)

Aggiungo pure che la qualita' finale dell'audio dell'STE era migliore di quella Amiga, forse grazie a dei codec differenti. Ma qui si parla di gusto ed orecchio.


Non m'interessa l'interno: neppure il TT era simile ai precedenti ST


Era similissimo ad un STE ed in ogni caso lo era decisamente piu' del Falcon.


A me interessa come funzionano, e da questo punto di vista sono una normale evoluzione dei loro predecessori.
Questo dati alla mano: ma ovviamente i link che ho postato non li hai degnati neppure di uno sguardo (ma tanto dubbito che tu possa carpirne qualche dettaglio).


Li ho guiardati eccome, ti diro' di piu', gia' li conoscevo. Tuttavia ti ho gia' spiegato che questa compatibilita' da te diagnosticata tramite la tua interpretazione (di quello che io non posso capire), non si avvicina nemmeno di striscio alla realta' dei fatti. Sul falcon non gira un sacco di roba dell'ST. Se poi prendiamo i giochi.. E' difficile trovarne uno che giri senza necessitare dell'emulatore e con esso sono comunque tantissimi quelli che non vanno, nonostante l'ottimizzazione singola per ogni gioco da scegliere nell'elenco del programma stesso, (ovviamentente ce ne stava solo una piccola parte).


La realtà non la puoi cancellare: i 680x0 sono stati relegati al ruolo di microcontrollori. Che ti piaccia o meno. Punto.


Non ho mai discusso riguardo la realta', ancora una volta ti riinvito a rileggere il post precedente per rimanere in tema e non rispondere a caso.
Ti metto pure un considerazione riguardo l'argomento. Il 68060 era completamente differente rispetto ad un 040, un progetto totalmente nuovo, dalle 2 alle tre volte piu' veloce a parita' di clock. Come lo stravolsero una volta, lo avrebbero potuto fare in seguito, Wickipedia da te tanto citato esprime anche una sua considerazione riguardo a come sarebbe stata una teorica evoluzione dello 060.. simile ad un P2.
Che a te piaccia o meno. Punto. ;)



Già a partire dal 1988 le riviste erano piene di lettere di utenti Atari che si lamentavano del supporto sempre più scarso. Al contrario dell'Amiga, che continuava la sua ascesa, ed è rimasta la piattaforma di riferimento nel campo dei videogiochi (il più grosso: ma anche in tanti altri) fino al 1996.


Dall'85 all'88 sono 3 anni, piu' uno o due anni di calare..fanno 5 e gia siamo oltre quelli che avevo detto io ad occhio, che poi l'amiga fosse il punto di riferimento per i giochi fino al 96, e' quanto di piu' personale tu potessi esprimere.


Il momento di gloria degli ST è durato ben poco... Amen.


Abbiamo gia' contato.. forse ti sei perso un pezzo di storia, quando comprasti il tuo primo Amiga, io avevo un ST da parecchio tempo.


Ricordi, ricordi, ricordi... Mah. Un 68060 poteva decodificare ed eseguire fino a 2 istruzioni per ciclo di clock: esattamente come il Pentium.


http://www.dizionarioinformatico.com/allegati/PPC.html

Qui non sono d'accordo con te, dichiaragli guerra.


Ma non eri un retrogamer? Non conosci neppure il MESS...


Chi lo ha detto, io ho detto di essere un retrogamer?? E comunque conosco ogni emulatore che esita in rete. (ora l'ho detto) ;)
Io, in ogni caso, ho solo detto che stavo vedendo schermate nere, mentre scrivevo testavo, visto che non mettevo le mani su quell'emulatore da un pochetto, speravo che nelle ultime versioni fosse migliorato..
Non c'e' che dire, ottima emulazione!! perfetta direi!! Ci gira Alien vs predator senza audio, e se ci carichi mutant penguin o quant'altro da solo schermate nere!! Hai ragione, emulato il Jaguar, si puo' emulare il Falcon.


Ripeto: mi fornisci degli esempi di problemi dovuti all'IDE, che siano RIPRODUCIBILI?


Gia spiegati piu' volte, poi il discorso era piu' ampio e verteva su problematiche legate ai rallentamenti eterogenei dai quali sono afflitti questi computer. Basta.


Ci sarebbe l'imbarazzo della scelta: seriale, parallela, USB... Il bus di espansione degli Atari ST è un vecchissimo VME a 16 bit.


Intendevo dire che dovrei essere nell'eventuale testa di un eventuale programmatore che eventualmente srivesse un eventuale emulatore del falcon, per capire eventualmente dove potrebbe decidere di mettere la porta in questione. Piu' chiaro ora no?? ;)


Come volevasi dimostrare: a un certo punto, in mancanza di argomenti, si deve per forza attaccare il titolo. Ormai è un classico: dovremmo metterlo nel regolamento di evitare comportamenti come questi...


Non mi sembra proprio di essere mai rimasto senza parole, piu' che altro reputo la perdita di tempo eccessiva rispetto alle cose che si possono apprendere da essa.


Mi spiace: io mi occupo di computer, non di cervelli...

Si nota. Ragioni come un computer e non e' un complimento.

[Marco71]

...vi invidio MadRat e Dr. Di Mauro dato che nella "golden age" dei computer "personali" avete potuto avere hardware per Amiga ed S.T di cui io leggevo su M.C Microcomputer, Byte (quello "originale") ed alcune riviste in inglese su Amiga che riuscivo ad "acchiappare"...
Nello "stanzino" dove affronto l'ultima manciata (o poco più) di esami per la agognata Laurea (con "L" maiuscola) sotto ad un mobile ho un Amiga 500 con 512KB di "slow" ram ed una espansione da 2MB di "fast" ram condito con una scheda acceleratrice 68020/68881 "Made In Italy" (dramma).
Non vi dico il "calore" sprigionato dal povero Amiga 500...
Per caso per l'Atari TT esistevano delle schede acceleratrici basate su Inmos T800/T805 ?
Sono ahem anche io off-topic...
Continuerò a leggermi la cronaca della "vostra battaglia"...
Grazie.

Marco71.

[cdimauro]

Va be', qui non hai capito cio' che ho detto, al masismo te lo rileggi.
Sei tu che non hai le capacità per capire come funziona un gioco e come viene realizzato, che non è fatto di sole note strumentali...
Poco conta una recensione di qualcuno come te. :) Stuntcar era un gioco programmato benissimo su entrambe le piattaforme ad esempio, ma se paragonate le due versioni, saltava all'occhio come quella Atari girasse molto piu' rapidamente..
Se saltava all'occhio doveva essere evidente. Evidenza che non traspare.
Senza contare il fatto che lanciando il computer a 60hz, tutto girava assolutamente piu' velocemente.
Al contrario: mantenendo lo schermo a 320x200 e 16 colori, a 60Hz il processore video ha bisogno di effettuare il redraw dello schermo 10 volte in più al secondo.
L'ST non era finito??
Non dicevi di conoscerne la storia?
mah e comunque se JT lo avesse preso, ne avremmo guadagnato tutti.
Se mia nonna avesse avuto le ruote, sarebbe stata una carriola...
Non c'e' che dire, un bell'albero di natale su floppy.
Ti capisci solo tu...
Accendendo un Amiga non potevi nemmeno copiare un floppy.
E chi se ne frega...
Caricando in WB sacrificavi quello sputo di ram che c'era.
Il Workbench occupava 10KB: una quantità di memoria enorme...
Assolutamente minimi, nulla che avesse a che vedere con il multitos in ogni caso.
Certo certo. Ovviamente è risaputo che un s.o. con multitasking preemptive non consuma risorse rispetto a uno batch, vero?
Perché non vai a raccontarla a chi sviluppa s.o. questa bella storiella: magari ti propongono per il prossimo Nobel per l'informatica...
In laboratorio ho sicuramente ancora qualche listino ufficiale che distribuivamo ai negozi, qualora dovessi ritrovarlo te lo scansionerei.
Io ho preso i listini dei distributori che si trovavano sui numeri di MC MicroComputer: chiunque li conserva può controllare l'attendibilità di quello che ho riportato...
Comunque commentiamo.. Meta' della Ram e prezzo piu' alto
Dipende da cosa confronti:
- ST 520 e Amiga 1000/500 avevano entrambi 512KB di ram;
- 1040, Amiga 500 + espansione da 512KB e Amiga600 avevano 1MB;
- MegaSTE e Amiga 1200 avevano 2MB (nell'Amiga 1200 era ram a 32 bit, mentre nel MegaSTE, che montava ancora un 68000, era a 16 bit).
(mentre per l'ST un mega era oltre ogni possibile utilita', per l'Amiga era il minimo). Non c'e' che dire.
Dipende da quel che ci dovevi fare. Chiaramente la miglior qualità audio / video dei giochi per Amiga non si poteva ottenere senza quei 512KB di memoria in più. Questo per i giochi più nuovi: per i primi anni tutti i giochi giravano con soli 512KB di memoria.
Cavolo hai proprio ragione, allora sappi che il 1024 ST si chiama 1040!! ;) Quale inutilita' di discorsi..
Hai ragione, ho avuto un lapsus: era il 1040. Basta riconoscere i propri errori, no?
Per il 500 forse.. non certo per il 1000 che di ram era proprio scarsino direi.
Per il 500 sicuramente, come ho anche riportato. Per il 1000 le Zorro con 1MB di ram non costavano certo 2 milioni.
Caricato il SO poteva giusto far girare pacman.
Dimentichi che i giochi non caricavano il s.o., ma lo "ammazzavano" e si prendevano la ram tutta per loro: quindi non c'era alcun problema di memoria in questo caso. Inoltre i primi giochi che caricavano il s.o. giravano lo stesso.
Non che il 500 stesse meglio. ;)
Visto che aveva 256KB di rom per il s.o., direi che stava anche meglio del 520 ST...
Pareri tuoi e di chi come te.
Allora la cosa mi consola, visto che siamo in tanti.
Io credo sempre di piu' che dovresti soffermarti a leggere cio' che la gente scrive. Dove ho mai detto che quel gioco fosse brutto?? io lo adoravo in tutte le sue forme!! Lo ho solo riportato come esempio, perche' era uno dei pochissimi giochi che poteva far ricorso all'alta risoluzione (spingendo h mi pare) ma l'immagine rimaneva 320 * 240+ overscreen, finiva al centro dello schermo e disattivava l'audio.. che a detta tua non richiedeva altro che qualche ciclo di clock.. Mentre per me è l'evidente dimostrazione di come quella macchina non fosse ben dimensionata.
L'audio veniva disattivato a causa della mancanza di spazio per la memoria. Sui cicli di clock per elaborlarlo, ti rispondo dopo.
Inoltre aggiungerei una cosa che si chiama "riflessione" Ammesso e non concesso che Elite fosse piu' veloce su Amiga che su ST.. Su amiga l'ho solo provato, su ST l'ho giocato (percio' ammetto che possa ricordare male), il recensore dice che:

"E' abbastanza SORPRENDENTE che SEMBRA realmente piu' veloce che nella versione ST".
Questo vuol dire EVIDENTEMENTE che su amiga girassero sempre piu' velocemente i giochi 3d, no??
Oppure significa che:
1) quel gioco SEMBRA, piu' veloce, e' una vaga impressione.
2) sull'ST di i programmi 3d (ghiochi ed utility) giravano sempre piu' velocemente, tanto da destare stupore una parita'(forse con leggero vantaggio) da parte dell'Amiga.

Oh mamma, quando uno e' di coccoarmato, nemmeno una cannonata lo smuove.
Il problema dei recensori è che si facevano abbagliare da quel Mhz in meno del 68000 degli Amiga rispetto all'ST.
Non essendo tecnici, non potevano capire in che modo era distributo il carico computazionale per elaborare una scena: l'operazione di tracciamento delle linee dei poligoni e il loro successivo riempimento erano le operazioni più critiche e su cui gravava la maggior parte del calcolo, tanto più grande quanto più grande era il numero di bitplane / colori da visualizzare.
Non l'ho mai paragonato dal punto di vista grafico. Ho solo detto che compunque non era cosi' rigido come lo disegni.
Era molto rigido, invece, visto che rimaneva ben poco tempo alla CPU per fare altro.
Del link me ne sono accorto e dice quanto ho riportato io.
Per forza: hai ricopiato soltanto ciò che t'interessava, tralasciando tutto il resto (ma ho provveduto io).
La mia memoria non vacilla affatto, se per te avere due canali fisici e 4 virtuali ai fini dello stereo sia differente, questo non vuol dire che all'atto pratico la cosa cambi i risultati.
All'atto pratico vuol dire che per suonare un modulo con soli 4 canali è necessario utilizzare il 30% della CPU: se a te pare poco...

Per confronto, il player di moduli che ho scritto per i giochi che stavo sviluppando per Amiga, richiedeva soltanto una riga di raster. Una riga di raster = circa 227 cicli di clock. Moltiplicato per 50 fotogrammi al secondo, fanno circa 11350 cicli di clock. Per un Amiga PAL, con clock a 7,09 Mhz, fanno 11.350 / 7.093.750 = 0,16% di CPU utilizzata.

Praticamente l'STE per fare la stessa cosa richiede più (perché il 30% è relativo alla CPU che lavora a 8Mhz, mentre lo 0,16% è in rapporto a 7,09Mhz) di 200 (DUECENTO) volte la potenza di calcolo rispetto a un Amiga.

Ma già, all'atto pratico questo non vuol dire niente... per te. Vuol dire molto, invece, per chi realizza videogiochi o applicazioni che non siano soltanto dei player, visto che gli rimane ben poca potenza di calcolo per fare altro...
Che tu ne dica l'audiosculpture suona 4 ch a 50 khz l'uno.
Non c'è dubbio che IL RISULTATO FINALE SIA QUELLO: su questo non ho proprio nulla da dire. Ma come vedi non è un risultato che si ottiene a costo zero: tutt'altro.
Tanto e' vero che campionavo 50 khz (con il prosound designer ed il pandal) e poi riutilizzavp il prodotto per inserirlo in quel tracker. Che tu sia "tecnicamente d'accordo o meno".
Tecnicamente sono d'accordo: si può fare. Ma an costo molto elevato, mentre su Amiga è praticamente a costo zero: una bella differenza...
E su ogni pubblicita', manuale e recensione del tempo l'STE era dato per 8 ch, visti come 4 pcm, 3 sintetizzatori quadri ed 1 dedito al rumore bianco.
Pubblicità ingannevole, allora.
Mi riferisco esattamente alle interlacciate. L'A3000 non credo proprio facesse testo visto che non era proprio la macchina di riferimento del mercato..
Ma non stavamo parlando di professionisti? E' chiaro che non interessava al ragazzino attaccato al joystick.
Se proprio vogliamo essere pignoli il TT poteva arrivare a 1280 * 960.
Anche l'Amiga3000, e a 4 colori anziché i due offerti dal TT...
E poi anche con i deinterlacciatori, non si poteva lavorare per ore/giorni/anni davanti ad un monitor a 50hz.
C'erano anche i monitor ad alta persistenza per i professionisti: anche questo l'hai dimenticato, vero?
Come no!! primo ti sei dimanticato il blitter,
Guarda che era arrivato PRIMA dell'STE, col MegaST: anche questo l'avevi dimenticato?
secondo l'evoluzione dello shifter video in ambito di scrolling (creato apposta)
Hai ragione: questo l'avevo dimanticato. Siamo a 3 cose nuove. Amen.
e poi non insistere con questi 2 canali,
Ma non insisto proprio: è la pura è semplice verità, com'è riportato in tutta la documentazione tecnica sugli STE.
Capisco che sia una cosa difficile da accettare per uno che è sempre stato convinto che avessero 8 canali (a costo zero), ma fattene una ragione...
perche' allora l'amiga ne aveva uno solo,
No, ne aveva ben quattro, con risoluzione di 14 bit.
visto che la somma delle frequenze da la meta' come risultato!!.
Se ce la spieghi, ci fai un favore.
Caricati l'octalyzer per STE sugli emulatori fantomatici ti accorgerai che a 25 khz potrei usare 8 ch
Vedi sopra: ma chi l'ha mai negato questo? Il problema (leggi: a che prezzo per la CPU) è andare a vedere COME li ottenevano questi 8 canali.
ed avrai pure modo di attivare l'intermpolazione. (questa richiedeva potenza alla cpu)
Specifica: potenza aggiuntiva.
Altro piccolo punto. Io non ho mai parlato di protraker che ritengo una gran cagata, un pessimo porting da Amiga.
Non è certo il player diverso il problema: la potenza di calcolo per miscelare i canali era necessaria PER QUALUNQUE TRACKER.
Vogliamo vedere i sorgenti del player di Oktalyzer? Per me non c'è problema: ho anche i sorgenti del player di Oktalyzer per Amiga. Eh, già: esisteva anche per Amiga. Con una piccola differenza: mentre suonava potevo fare altro... :asd:
Temo che tu non sappia il significato della parola dinamica.
Qui: http://sc68.atari.org/developers_technicals.html dice questo

"Built-in 5 bit D/A convertor"

Sullo YM2149 dell'ST.
[QUOTE]Ti ho portato dei valori molto significativi. avendo una riproduzione a 22khz in pcm a 8bit, l'Amiga non puo' arrivare a dinamiche simili, e' tecnicamente impossibile avere una simile pressione e profondita' sonora con simili caratteristiche.
Infatti riporti delle informazioni inesatte:

1) il range dinamico di ogni canale è 14 bit;
2) la riproduzione TRAMITE CANALE DMA era limitata, sì, ma 29Khz;
3) la riproduzione TRAMITE CPU permetteva di arrivare a 56Khz.
Anche l'st lo poteva fare, ma non pensarono (giustamente) di implementare l'utilizzo di 4 floppy, inutili alla stragrande maggioranza dell'utenza, tanto da poter essere definita la totalita'.
Ma infatti al più si avevano due drive anche con Amiga.

Soltanto i pirati apprezzavano (e usavano) la possibilità di attaccare 4 drive e il fatto di poter copiare 4 dischi nello stesso tempo di uno...
Io con il semplicissimo Fcopy, che era il piu' semplice dei copiatori per atari, formattavo alle stesse dimensioni da te citate.. dovresti saperle queste cose.
http://www.stack.nl/~chemmad/Tekstbestand

"Disk size.

If you format a disk with the gem desktop format facility the disksize becomes 720 kbytes Fast Copy Pro is much faster and flexible it is even possible to reservate more than 900 kbytes if your diskdrive allows 82 tracks and 11 sectors per track."

82 * 11 = 902KB

Mentre 82 * 12,5 = 1025KB
Inoltre il floppy dell'Amiga era di una lentezza esorbitante in tutto. Copiare un disco faceva venire sonno!!
Anche le versioni della blitz syncro per Amiga era nettamente piu' lente.
Copiare un disco su Amiga richiedeva circa 35 secondi. Hai mai provato programmi come X-Copy? Era IL programma per copiare dischi ed era velocissimo.
Gia', mammaquanti (MAMMAQUANTI). l'ST ne aveva semplicemente quanti gliene servivano per gestire i propri sottosistemi.
Appunto: hardware scarso -> pochi canali DMA.
Sotto la tua interpretazione.
No, quella di chi ha una base tecnica che gli consente di valutare le caratteristiche dei due sistemi.
All'atto pratico un Amiga impallato cessava ogni funzione, inchiodando la nota di un eventuale musica su se stessa.
I comparti dell'ST erano decisamente piu' indipendenti. Che la tua teoria sia d'accordo o meno.
Un Amiga impallato valeva quanto un ST impallato, e questa non è solo teoria, ma anche pratica.

Se l'ST continuava a suonare è perché il programma che si era agganciato (hook) al sistema continuava a farlo.

Se l'Amiga continuava a suonare è perchè il programma che veniva eseguito normalmente continuava a farlo.

Sic et simpliciter.
Spero almeno sorridessi.
La solita storia della volpe e l'uva...

Tu quelle riviste hai potuto soltanto leggerle: io faccio parte della loro storia. Una differenza "da poco"...
Che ti piaccia o meno li aveva, pero' potremmo inventare la macchina del tempo ed andare a riscrivere tutti gli articoli del tempo, manuali e pubblicita'. E' pur sempre una soluzione.
Vedi sopra: chi l'ha mai negato questo? Che fosse possibile farlo è un conto: COME è tutt'altra cosa, come ti ho spiegato dettaglitamente prima...
In fin dei conti chi sarebbe mai il pazzo che non ti darebbe retta di fronte ad una tua spiegazione tecnica!! ;)
Soltanto un pazzo o un fanatico dai ricordi poco precisi...
Aggiungo pure che la qualita' finale dell'audio dell'STE era migliore di quella Amiga, forse grazie a dei codec differenti. Ma qui si parla di gusto ed orecchio.
Balle: già il solo fatto di dover MISCELARE i canali faceva perdere parecchia qualità al segnale finale. Ma queste sono cose che il tuo orecchio "fino" non è in grado di comprendere, a quanto pare...

Quanto alla qualità del segnale d'uscita dell'Amiga, faceva così "schifo" che è stato impiegato per il pilotaggio di laser di precisione...
Era similissimo ad un STE ed in ogni caso lo era decisamente piu' del Falcon.
Guarda che stavo parlando di INTERNO: il TT aveva poco a che spartire con l'STE. Perfino la CPU stava su una doughterboard a parte... Ovviamente anche questo l'hai dimenticato...
Li ho guiardati eccome, ti diro' di piu', gia' li conoscevo. Tuttavia ti ho gia' spiegato che questa compatibilita' da te diagnosticata tramite la tua interpretazione (di quello che io non posso capire), non si avvicina nemmeno di striscio alla realta' dei fatti. Sul falcon non gira un sacco di roba dell'ST. Se poi prendiamo i giochi.. E' difficile trovarne uno che giri senza necessitare dell'emulatore e con esso sono comunque tantissimi quelli che non vanno, nonostante l'ottimizzazione singola per ogni gioco da scegliere nell'elenco del programma stesso, (ovviamentente ce ne stava solo una piccola parte).
Incompatibilità che esistevano anche col TT, e dovresti ricordarlo bene. All'epoca dell'introduzione del TT, Atari stessa stimava nel 25% la compatibilità coi titoli sviluppati per l'ST.
Non ho mai discusso riguardo la realta', ancora una volta ti riinvito a rileggere il post precedente per rimanere in tema e non rispondere a caso.
L'ho fatto e ho risposto, ma tu continui a non (voler) capire...
Ti metto pure un considerazione riguardo l'argomento. Il 68060 era completamente differente rispetto ad un 040, un progetto totalmente nuovo, dalle 2 alle tre volte piu' veloce a parita' di clock. Come lo stravolsero una volta, lo avrebbero potuto fare in seguito, Wickipedia da te tanto citato esprime anche una sua considerazione riguardo a come sarebbe stata una teorica evoluzione dello 060.. simile ad un P2.
Che a te piaccia o meno. Punto. ;)
Forse wikipedia non l'hai letto molto bene, allora: http://en.wikipedia.org/wiki/68060

"The 68060 shares most architectural features with the original Pentium. Both have a very similar superscalar in-order dual instruction pipeline configuration, and an instruction decoder which breaks down complex instructions into simpler ones before execution. However, a significant difference is that the 68060 FPU is not pipelined and is therefore up to three times slower than the Pentium in floating point applications. In contrast to that, integer multiplications and bit shifting instructions are significantly faster on the 68060. An interesting feature of the 68060 is the ability to execute simple instructions in the address generation unit (AGU) and thereby supply the result two cycles before the ALU."

Ci sono pro e contro per entrambi, ovviamente. Inoltre su quel che poteva fare Motorola in futuro sono soltanto delle supposizioni, prive di alcuna considerazione tecnica.
Dall'85 all'88 sono 3 anni, piu' uno o due anni di calare..fanno 5 e gia siamo oltre quelli che avevo detto io ad occhio,
5 anni sono il totale, fra salire e scendere: non è l'intero periodo di gloria. Comunque, anche volendo essere buoni, è sempre poco visto che per l'Amiga si parla di più di 10 anni.
che poi l'amiga fosse il punto di riferimento per i giochi fino al 96, e' quanto di piu' personale tu potessi esprimere.
A giudicare dalle riviste che tu stesso hai citato, direi che si tratta di uno dato tutt'altro che personale.
Abbiamo gia' contato.. forse ti sei perso un pezzo di storia, quando comprasti il tuo primo Amiga, io avevo un ST da parecchio tempo.
Vedi sopra: i conti bisogna saperli fare, però...
http://www.dizionarioinformatico.com/allegati/PPC.html

Qui non sono d'accordo con te, dichiaragli guerra.
Non c'è neppure una mail a cui scrivergli.

Comunque tu hai citato prima wikipedia e poi questo sito: visto che dicono cose completamente diverse sul 68060, a questo punto devi dirmi quale dei due ritieni più attendibile.

In base alla tua scelta, quel che hai detto prima citando l'uno o l'altro sito risulterà privo di fondamento, e quindi falso. Accomodati pure... :asd:
Chi lo ha detto, io ho detto di essere un retrogamer?? E comunque conosco ogni emulatore che esita in rete. (ora l'ho detto) ;)
Ma non conoscevi il MESS, che è piuttosto famoso nell'ambito dell'emulazione di sistemi non arcade (console e computer).
Io, in ogni caso, ho solo detto che stavo vedendo schermate nere, mentre scrivevo testavo, visto che non mettevo le mani su quell'emulatore da un pochetto, speravo che nelle ultime versioni fosse migliorato..
Non capisco quali difficoltà tu abbia avuto per avere quelle schermate nere: basta decomprimerlo, copiare il file col firmware del Jaguar nell'apposita cartella, e far puntare il path delle immagini dei giochi alla cartella che li contiene.
Non c'e' che dire, ottima emulazione!! perfetta direi!! Ci gira Alien vs predator senza audio, e se ci carichi mutant penguin o quant'altro da solo schermate nere!!
Lo riprovo in questo week-end e poi ti faccio sapere.
Hai ragione, emulato il Jaguar, si puo' emulare il Falcon.
E' una forzatura priva di alcun nesso logico.

http://www.myatari.net/issues/dec2002/aranym.htm

"Thomas: What about special features like DSP emulation?

Milan: It is very nice. But not for real work. Maybe somebody writes an interface to Déesse, then it could be more interesting.

Standa: The DSP emulation doesn't make much sense. It was developed by Patrice Mandin to let a few clean DSP programs work. The main problem here is that DSP utilizing software is mostly not written as system clean and therefore it won't run on any TOS clone.

Petr: The DSP MC56001 emulation is actually a great thing for studying the existing software from inside. You can trace the software in a way that would not be possible on real DSP. I think Patrice wrote it mainly for this studying purpose. It definitely was not meant as something that would allow running old Falcon games, demos or even sound applications. No way. Those programs are usually written in a very dirty way (avoiding system clean programming and going to hardware registers directly) and always rely on exact timing - a thing we don't have in ARAnyM (if you haven't realized it yet - Aranym's CPU runs as fast as possible so only real system clean software works properly)."

Quindi in futuro potrebbero migliorare l'emulazione del DSP 56001...
Gia spiegati piu' volte, poi il discorso era piu' ampio e verteva su problematiche legate ai rallentamenti eterogenei dai quali sono afflitti questi computer. Basta.
Non hai ancora fornito degli esempi RIPRODUCIBILI di problemi dovuti all'hardware del PC.
Intendevo dire che dovrei essere nell'eventuale testa di un eventuale programmatore che eventualmente srivesse un eventuale emulatore del falcon, per capire eventualmente dove potrebbe decidere di mettere la porta in questione. Piu' chiaro ora no?? ;)
Adesso sì, direi, ma comunque la mia risposta era ugualmente valida: un programmatore avrebbe l'imbarazzo della scelta.
Non mi sembra proprio di essere mai rimasto senza parole, piu' che altro reputo la perdita di tempo eccessiva rispetto alle cose che si possono apprendere da essa.
Le parole non m'interessano: io parlavo di argomenti. Sono questi che mancano a sostegno delle tue idee.

Inoltre il fatto che ti attacchi al mio titolo, oltre che risultare puerile, mette in evidenza le tue difficoltà nell'affrontare la discussione...
Si nota. Ragioni come un computer e non e' un complimento.
Allora meglio un computer, che almeno le cose se le ricorda bene...

[jappilas]

Se proprio vogliamo essere pignoli il TT poteva arrivare a 1280 * 960.

Anche l'Amiga3000, e a 4 colori anziché i due offerti dal TT...
meglio non dire a che livelli arrivasse il "misero" A3000 con l' aggiunta di una scheda (che tra l'altro era a 32 bit se non ricordo male ) chiamata Rambrandt... ops :sofico:
perche' allora l'amiga ne aveva uno solo,
No, ne aveva ben quattro, con risoluzione di 14 bit.
ah... l' audio di Amiga... :D
ammmetto che prima di capire che i due spinotti RCA non erano uno stereo normale ci ho messo un po' ...:D ma da lì in poi... :sofico:
so che c' era anche gente che li usava per maneggiare suono surround.. :cool:

[Marco71]

...l'MC68000 negli Amiga che lo utilizzavano non aveva una frequenza di funzionamento di 7.16MHz ?
Mentre l'Atari ST 512 ecc. di 8MHz ?
Grazie.

Marco71.

[cdimauro]

allora meglio non dire a che livelli arrivasse il "misero" A3000 con l' aggiunta di una scheda (che tra l'altro era a 32 bit se non ricordo male ) chiamata Rambrandt... ops :sofico:
Per dovere di cronaca le prime schede grafiche sono arrivate per Atari ST... per ovvi motivi... :asd:
ah... l' audio di Amiga... :D
ammmetto che prima di capire che i due spinotti RCA non erano uno stereo normale ci ho messo un po' ...:D ma da lì in poi... :sofico:
so che c' era anche gente che li usava per maneggiare suono surround.. :cool:
Ma scherzi? Quello degli STE era meglio!!! :asd: :asd: :asd:

:)

EDIT: http://www.midwest-laser.com/html/computer_controlled_laser_show.html

Computer Controlled Laser Light Show Kit

Just connect the left and right audio outputs of the computer to the terminals on the scanner amp board, connect the power supply provided, and your ready to start projecting laser graphics.

[cdimauro]

...l'MC68000 negli Amiga che lo utilizzavano non aveva una frequenza di funzionamento di 7.16MHz ?
Mentre l'Atari ST 512 ecc. di 8MHz ?
Grazie.

Marco71.
I 68000 degli ST erano a 8Mhz (16 per i "Mega").

Quelli dell'Amiga erano a 7,09Mhz per la versione PAL e 7,16Mhz per quella NTSC.

[MadRat]

I 68000 degli ST erano a 8Mhz (16 per i "Mega").

Quelli dell'Amiga erano a 7,09Mhz per la versione PAL e 7,16Mhz per quella NTSC.

L'ST aveva 8 mhz per TUTTI i computer basati su 6800 esclusi i MEGA ST "E" i MEGA erano ad 8mhz.

Gli amiga erano a 7.14mhz (da noi).

[MadRat]

[
Al contrario: mantenendo lo schermo a 320x200 e 16 colori, a 60Hz il processore video ha bisogno di effettuare il redraw dello schermo 10 volte in più al secondo.


Prova a caricare QUALUNQUE gioco a 60hz (procurati un ST) e vedrai un incremento prestazionale pari alla percentuale di scarto tra 50 e 60.
Questa cosa era risaputa da tutti gli utenti Atari, anche i piu' semplici giocatori.... Ma tu hai una spiegazione tecnica che dimastra il contrario.. ti giuro che ho il sorriso in faccia.
Il ragionamento che fai tu e valido solo per architetture modulari come il PC.

Ti dico il primo gioco che mi viene in mente ora che lo supportasse da pannello. BloodMoney, gia' citato.. A 60hz metteva il turbo!!
Mentre per quelli che non lo supportavano, lo mettevo nel folder auto quando si poteva.



Se mia nonna avesse avuto le ruote, sarebbe stata una carriola...


Una carriola ha una ruota sola.. nemmeno questo sai.


Ti capisci solo tu...

O forse i limiti li hai tu.


E chi se ne frega...

A molti fregava.

Pensa che da quando prendemmo l'Amiga e lo mettemmo affianco all'ST nel nostro ufficio a via illiria a Roma, vendevamo piu' facilmente i nostri Atari. :)


Certo certo. Ovviamente è risaputo che un s.o. con multitasking preemptive non consuma risorse rispetto a uno batch, vero?
Perché non vai a raccontarla a chi sviluppa s.o. questa bella storiella: magari ti propongono per il prossimo Nobel per l'informatica...

Magari dovresti provarlo. Ne fecero anche una versione per HW mac, per portare la piattaforma Atari verso HW piu' evoluti dopo la cessazione della produzione di nuovi computer 'Atari .


Dipende da cosa confronti:
- ST 520 e Amiga 1000/500 avevano entrambi 512KB di ram;
- 1040, Amiga 500 + espansione da 512KB e Amiga600 avevano 1MB;
- MegaSTE e Amiga 1200 avevano 2MB (nell'Amiga 1200 era ram a 32 bit, mentre nel MegaSTE, che montava ancora un 68000, era a 16 bit).


Quello era il periodo del declino, l'atari italia era gia' chiusa ed i prezzi non fanno piu' testo. Comuqnue il 1200 usci' veramente troppo tardi, non potevano sperare di venderlo a prezzi maggiori. (infatti e' l'unica eccezione della lista).


Dipende da quel che ci dovevi fare. Chiaramente la miglior qualità audio / video dei giochi per Amiga non si poteva ottenere senza quei 512KB di memoria in più. Questo per i giochi più nuovi: per i primi anni tutti i giochi giravano con soli 512KB di memoria.


..e facevano piu' schifo che su ST.


Hai ragione, ho avuto un lapsus: era il 1040. Basta riconoscere i propri errori, no?


Basta essere maturi e non cavillare sulle idiozie (320 anziché 360 kb).


Per il 500 sicuramente, come ho anche riportato. Per il 1000 le Zorro con 1MB di ram non costavano certo 2 milioni.


Se ne avessi fatta una nell'85 tanto l'avresti pagata.


Dimentichi che i giochi non caricavano il s.o., ma lo "ammazzavano" e si prendevano la ram tutta per loro: quindi non c'era alcun problema di memoria in questo caso. Inoltre i primi giochi che caricavano il s.o. giravano lo stesso.

Ma perche' non capisci?? Parlo ovviamente di giochi/applicazioni sotto SO.
Riflessione: Se per avere un desk ed un interfaccia grafica all'Amiga fossero bastati 10KB in piu', li avrebbero messi in ROM.


L'audio veniva disattivato a causa della mancanza di spazio per la memoria. Sui cicli di clock per elaborlarlo, ti rispondo dopo.


Lo disattivava anche avendo l'espansione.


Il problema dei recensori è che si facevano abbagliare da quel Mhz in meno del 68000 degli Amiga rispetto all'ST.
Non essendo tecnici, non potevano capire in che modo era distributo il carico computazionale per elaborare una scena: l'operazione di tracciamento delle linee dei poligoni e il loro successivo riempimento erano le operazioni più critiche e su cui gravava la maggior parte del calcolo, tanto più grande quanto più grande era il numero di bitplane / colori da visualizzare.


Hai eluso la considerazione, non mi andrebbe proprio di attaccare lo scanner per farti leggere le tonnellate di carta sulle quali c'e' scritto come la versione per ST di questo piuttosto che di quell'altro gioco 3D fosse piu' fluida, ma con audio inferiore. Lo ritengo una perdita di tempo.
Poi spiegami per quale motivo il 68k a 8 mhz sull'Amica era castrato a 7 e spicci.. Se non per limiti architetturali, visto che il processore stesso era identico e prodotto ad 8mhz.
Comunque la percentuale di differenza tra 7 ed 8 non e' poi cosi' trascurabile.



Era molto rigido, invece, visto che rimaneva ben poco tempo alla CPU per fare altro.


Una buona programmazione (vedi ad esempio i bitmap brothers) dimostrava che queste enormi differenze poi non ci fossero.


All'atto pratico vuol dire che per suonare un modulo con soli 4 canali è necessario utilizzare il 30% della CPU: se a te pare poco...


Sempre quella cagata di protracker.


Per confronto, il player di moduli che ho scritto per i giochi che stavo sviluppando per Amiga, richiedeva soltanto una riga di raster. Una riga di raster = circa 227 cicli di clock. Moltiplicato per 50 fotogrammi al secondo, fanno circa 11350 cicli di clock. Per un Amiga PAL, con clock a 7,09 Mhz, fanno 11.350 / 7.093.750 = 0,16% di CPU utilizzata.
Praticamente l'STE per fare la stessa cosa richiede più (perché il 30% è relativo alla CPU che lavora a 8Mhz, mentre lo 0,16% è in rapporto a 7,09Mhz) di 200 (DUECENTO) volte la potenza di calcolo rispetto a un Amiga.


Nel file che mi hai lincato tu c'e' scritto che il processore audio DMA dell'STE puo' prelevare la forma pcm dalla ram ed inviarla ai codec.. Grande fatica per la CPU, non c'e' che dire.. Ora, qualora mi venissi a dire che la lettura di un file MOD (mi hai portato l'esempio di un player per Amiga), esclusa la gestione audio, sull'STE occupasse il 30% della CPU, potrei mettermi a ridere.
Stando alla tua conclusione finale allora mi sembra OVVIO che nel mio STE ci fosse montato un 68000 a 1428 mhz (MILLEQUATTROCENTOVENTOTTOMHZ :D) (7.14 * 200), dato che funzionava nella piu' totale disinvolutura ed i giochi che utilizzavano l'audio dell'STE, non risentivano di rallentamenti, al contrario di quanto non accadesse per ST, che per riprodurre una forma PCM di buona qualita', aveva bisogno di vendere un rene.

.. Mi sa proprio che quel traker e' una bella cagata.. Ma conosci solo quello purtroppo.


Ma già, all'atto pratico questo non vuol dire niente... per te. Vuol dire molto, invece, per chi realizza videogiochi o applicazioni che non siano soltanto dei player, visto che gli rimane ben poca potenza di calcolo per fare altro...


Fortunatamente qualcuno lo ha saputo programmare meglio di quanto avresti saputo far tu.


Non c'è dubbio che IL RISULTATO FINALE SIA QUELLO: su questo non ho proprio nulla da dire. Ma come vedi non è un risultato che si ottiene a costo zero: tutt'altro.


Non e' esatto nemmeno questo. anche se occupasse il 30% per arrivare a 4 ch a 50khz (molto piu' in la di quanto non potesse l'Amiga) sarebbe gia' un risultato notevole, ma i dati non li hai come non li ho io. Posso dirti che nell'uso del protracker avevo una sensazione di pesantezza e lentezza sconvolgente, con altri (come AS), non c'era affatto. Guarda caso il PT era una conversione dall'Amiga. Mentre l'oktalyzer era abbastanza lento, ma con risultati decisamente ottimi.



Tecnicamente sono d'accordo: si può fare. Ma an costo molto elevato, mentre su Amiga è praticamente a costo zero: una bella differenza...


Seguiti a confondere l'STE con l'ST.


Pubblicità ingannevole, allora.


pubblicita' e tutto il resto!! E se lo dici tu..


Ma non stavamo parlando di professionisti? E' chiaro che non interessava al ragazzino attaccato al joystick.


Giusto,ma si ma sti c... un professionista puo' pure diventare becalino. :D



Anche l'Amiga3000, e a 4 colori anziché i due offerti dal TT...


Ma non mi risulta proprio!! Al massimo aveva 1280×512 (che poi era 1280*400 con overscan inferiore ed interlacciata, dunque due pagine a 1280*200 a 25hz l'una). Direi quasi la meta' dei pixel anche se consideriamo l'intarlacciata!! e poi la scelta del monocromatico ad alto refresh ("con il bianco carta") anziche' con 4 (inutili) colori a frequenze stancanti, era decisamente piu' logica.
Frall'altro l'A3000 aveva maggiori limiti d'espansione RAM e CPU piu' lente (al massimo 25mhz contro i 32 del TT) Erano due macchine estremamente differenti con potenze applicate in settori differenti.
Se proprio volessimo fare paragoni con le tecnologie disponibili, comunque, l'Atari nell'87 presento' il Transputer (ATW800), con CPU risc da 4mips e capace di lavorare in parallelo con altri suoi simili (direi molto all'avanguardia). Questo poteva arrivare a 1280*960 a 16 colori o 1280*768 a 256 su 16milioni. Non male per l'87. ;)
Diciamo che questa chiamata in causa del A3000 e' stata fuori luogo, quanto sbagliata. Ricordando che l'hai chiamata tu parlando del deinterlacciatore di serie mentre parlavamo di A500 e di 1040 ed io ti risposi dicendo che se fosse stato per quello, allora anche il TT ecc.. ;)





C'erano anche i monitor ad alta persistenza per i professionisti: anche questo l'hai dimenticato, vero?


Sì, sì, quelli che quando muovevi il mouse lasciavano la scia come sul mio vecchio prodest a fosfori verdi. Bellissimo.


Guarda che era arrivato PRIMA dell'STE, col MegaST: anche questo l'avevi dimenticato?


No, l'ho citato ben prima di te se rileggi i post, ma il mega ST non era una macchina per l'utenza ludica.


Hai ragione: questo l'avevo dimanticato. Siamo a 3 cose nuove. Amen.


Mi sembra una dimenticanza da poco.. darebbe un po' come scordarsi un chip custom dell'Amiga.
Questo dimostra pienamente la tua lacuna in merito.. Non e' un reato non conoscere tutte le piattaforme, in fin dei conti sei notevolmente preparato in ambito Amiga, anche tu hai dei limiti.. o forse no??


Ma non insisto proprio: è la pura è semplice verità, com'è riportato in tutta la documentazione tecnica sugli STE.
Capisco che sia una cosa difficile da accettare per uno che è sempre stato convinto che avessero 8 canali (a costo zero), ma fattene una ragione...


Dovresti farmi vedere questi dati.
all'atto pratico lìAmiga non arrivava dove arrivava l'STE nemmeno con l'ausilio della CPU (4 ch a 50khz).. ah, gia', L'STE aveva un 68000 a 1,4ghz!!


No, ne aveva ben quattro, con risoluzione di 14 bit.


:o Ti giuro che fino a quest'affermazione credevo che sapessi qualcosa al riguardo. Ora hai palesato il contrario.
L'Amiga aveva 4 CH a 8 (OTTO:D) bit, con 4 convertitori DAC (a OTTO bit) ed un modulatore di periodo O volume a 6 bit. Qui il tuo calcolo maccheronico (imboccando alle dichiarazioni Commodore del tempo) di 8+6=14 :D, ma la sai la differenza tra un suono a 8bit ed uno a 14?? Anche se lo dici a 14bit, sempre 256 livelli aveva giammai non 16384!!!!
Altro punto poi e' che l'Amiga aveva 4 DAC alla meta' della frequenza dei DUE DAC dell'STE. Chiunque abbia un minimo di conoscenza in merito, sa che e' la stessa identica cosa!! Poi questi erano gestiti come 4ch indipendenti dal processore DMA dell'STE. In teoria sarebbe pure potuto essere un DAC unico a 100khz (ovviamente perdendo lo stereo a questo punto). Un DAC non e' il processore audio!!


Vedi sopra: ma chi l'ha mai negato questo? Il problema (leggi: a che prezzo per la CPU) è andare a vedere COME li ottenevano questi 8 canali.


Semplice: 4 PCM in DMA+ 3 Sintetizzati in DMA+ uno sempre sintetizzato ma con onda bianca anziche' quadra sempre in DMA.
Mi pareva di averlo gia' scritto.
Poi c'e' da dire che dimezzando le frequenze, si possono raddoppiare i canali, ma questo e' un altro discorso.


Specifica: potenza aggiuntiva.

L'interpolazione non era trasparente nemmeno per l'Amiga. Inoltre c'e' da dire attivandola, si raggiungeva piu' o meno la qualita' ottenuta con il doppio della frequenza di riproduzione, solo che sull'STE, a parer mio era meglio raddoppiare i khz che attivare l'interpolazione stessa, vista la possibilita' di scegliere.


Non è certo il player diverso il problema: la potenza di calcolo per miscelare i canali era necessaria PER QUALUNQUE TRACKER.
Vogliamo vedere i sorgenti del player di Oktalyzer? Per me non c'è problema: ho anche i sorgenti del player di Oktalyzer per Amiga. Eh, già: esisteva anche per Amiga. Con una piccola differenza: mentre suonava potevo fare altro... :asd:
Qui: http://sc68.atari.org/developers_technicals.html dice questo
"Built-in 5 bit D/A convertor"

Temo che tu non sappia il significato della parola dinamica. Quel manuale lo ho in pdf da una vita, se vuoi te lo passo in versione piu' completa.
Qualora volessimo, inoltre, sparare bit a caso potremmo anche notare i 12 bit dei della frequenza o i 16 dei periodi d'inviluppo (quest'ultimo non tanto a caso).

Hai grossa confusione riguardo la dinamica di un suono di un sintetizzatore e' quella di un campionatore. Tant'e' che ho pure parlato di ottave.
Sull' YM2149 dell'ST. Per non parlare della modulazione piu' lineare e definita, nonché la possibilita di applicare varie forme d'onda alla stessa modulazione sonora. (Come sintetizzatore e' tutt'oggi oggetto di culto, come lo e' il SID.)


Infatti riporti delle informazioni inesatte:



1) il range dinamico di ogni canale è 14 bit;


E se mio nonno avesse avuto tre palle sarebbe stato un flipper. ;)


2) la riproduzione TRAMITE CANALE DMA era limitata, sì, ma 29Khz;


Io ricordo 22, ma cambia poco paragonato a 50khz.


3) la riproduzione TRAMITE CPU permetteva di arrivare a 56Khz.

Per due canali in tutto, non per quattro e qui pure l'utilizzo della CPU arrivava a picchi notevoli. ;)


Ma infatti al più si avevano due drive anche con Amiga.


Dunque non vedo disparita'.


Soltanto i pirati apprezzavano (e usavano) la possibilità di attaccare 4 drive e il fatto di poter copiare 4 dischi nello stesso tempo di uno...


Lo so benissimo, tuttavia con la blitz dell'ST copiavo in una frazione del tempo di quella richiesta dall'Amiga e con risultati migliori (copiava pure dragon's lair protetto a laser e Dungeon master).


http://www.stack.nl/~chemmad/Tekstbestand

"Disk size.

If you format a disk with the gem desktop format facility the disksize becomes 720 kbytes Fast Copy Pro is much faster and flexible it is even possible to reservate more than 900 kbytes if your diskdrive allows 82 tracks and 11 sectors per track."

82 * 11 = 902KB

Mentre 82 * 12,5 = 1025KB


Ti servirebbe proprio di usare un ST dal vivo. Non solo i limiti li riportati sono tutto tranne che veritieri, ma con alcune meccaniche si poteva arrivare ad 83 * 12 (anche se i seteaggi arrivavano fino ad 85 mi pare). Caricatelo su un emulatore e vedilo con i tuoi occhi.
Ovviamente i limiti della meccanica esistevano anche per Amiga, non e' detto che un disco formattato ad un mega, fosse poi utilizzabile, dipendeva dalla generosita' dell ameccanica installata.



Copiare un disco su Amiga richiedeva circa 35 secondi. Hai mai provato programmi come X-Copy? Era IL programma per copiare dischi ed era velocissimo.


Non c'e' che dire 10 secondi piu' che su Atari, con potenza inferiore, moltiplicalo per un centinaio di dischi a botta..



Appunto: hardware scarso -> pochi canali DMA.


HW bilanciato, canali bilanciati. Direi lo zen del computer..


No, quella di chi ha una base tecnica che gli consente di valutare le caratteristiche dei due sistemi.


Dunque, visto che io ho detto: "sotto la tua interpretazione" e tu hai detto: "No, quella di chi ha una base tecnica che gli consente.. ecc"
Questo significa che tu non sei colui che ha una base tecnica che gli consenta ecc... Beh, su questo siamo d'accordo ;).
Se di Amiga puoi parlare, di Atari proprio no. Le tue "deduzioni" danno l'impressione di essere prese direttamente da manuali tecnici letti al volo qui e li per rispondere alle mie considerazioni.


Un Amiga impallato valeva quanto un ST impallato, e questa non è solo teoria, ma anche pratica.


Bisogna vedere quanto questo accadesse, visto che l'HW dell'Amiga era piu' complesso e piu' difficile da gestire.
La stabilita' dell'ST era assolutamente invidiabile, nonché del TOS da te tanto denigrato, che tuttavia costiutui' la vera' fortuna dell'ST.



Se l'ST continuava a suonare è perché il programma che si era agganciato (hook) al sistema continuava a farlo.

Se l'Amiga continuava a suonare è perchè il programma che veniva eseguito normalmente continuava a farlo.

Sic et simpliciter.


L'Amiga non continuava a suonare del il 68k era in panne ed il guru posava le chiappette in terra.



La solita storia della volpe e l'uva...


Guarda, non sai quanto ti invidi :)), ma sei proprio uno sbruffone.


Tu quelle riviste hai potuto soltanto leggerle: io faccio parte della loro storia. Una differenza "da poco"...


Ti cito: "E chisene frega". Sai quante cazzate ho letto su quelle testate al tempo, almeno ora so chi le scriveva ed il perche'. Semplice, una cultura parziale.



Vedi sopra: chi l'ha mai negato questo? Che fosse possibile farlo è un conto: COME è tutt'altra cosa, come ti ho spiegato dettaglitamente prima...


Hai pure detto "pubblicita' ingannevole" confondendo il numero dei DAC con il numero dei canali.. Errore veramente assurdo.
Il mio Yamaha Motif ha 256 ch e 6 convertitori.. oh mamma.. mi hanno fregato!! ora glielo riporto, me ne faccio dare uno con un DAC per ogni canale, dunque 256*2 (visto che sono stereo) 512!! bello grosso, cosi' non me lo perdo e lo posso usare come sgabello. In compenso, visto che a parer tuo, avrei un incremento qualitativo, sentirei un stupendo ronzio dovuto alle risonanze eletroniche della componentistica esposta (piedini e piste), dovuta alla separazione (qualitativa :)) ) dei DAC.. Mah.


Soltanto un pazzo o un fanatico dai ricordi poco precisi...


Hem, che c'entra questa risposta??
Ti riposto al frase da non dividere: " Che ti piaccia o meno li aveva, pero' potremmo inventare la macchina del tempo ed andare a riscrivere tutti gli articoli del tempo, manuali e pubblicita'. E' pur sempre una soluzione. In fin dei conti chi sarebbe mai il pazzo che non ti darebbe retta di fronte ad una tua spiegazione tecnica!!"



Balle: già il solo fatto di dover MISCELARE i canali faceva perdere parecchia qualità al segnale finale. Ma queste sono cose che il tuo orecchio "fino" non è in grado di comprendere, a quanto pare...


Gia', hai proprio ragione!! questa si che e' una cazzata orbitale!! La qualita' deriva SOLO dalla qualita' del DAC stesso a partia' di frequenza.
Il DAC divide i propri cicli per l'elaborazione dei canali, proponendo due segnali ben distinti contemporaneamente. Questo non determina NESSUNA perdita di qualita'. La somma sonora la percepisce l'orecchio e la miscelazione avveniva anche nell'Amiga, visto che usciva in stereo.

Il mio orecchio fino ed allenato (gia' al tempo) comprendeva tutte le differenze possibili ed immaginabili tra i vari chip presenti, tanto e' vero che adoravo il comparto audio dell'Amiga che ho sempre prediletto (peccato per la mancanza di un sintetizzatore come lo YM), fino all'avvento dell'STE, che non solo colmava il gap PCM (e solo PCM era il gap), ma lo superava in quantita' e qualita' (del resto usci anche diversi anni dopo, mi sembrava anche il minimo), mantenendo anche il sintetizzatore.



Quanto alla qualità del segnale d'uscita dell'Amiga, faceva così "schifo" che è stato impiegato per il pilotaggio di laser di precisione...


Mi piacerebbe trovare un link dettagliato in merito, visto che ritengo che bastassero 4 bit per adempiere a quelle funzioni.



Forse wikipedia non l'hai letto molto bene, allora: http://en.wikipedia.org/wiki/68060

Ci sono pro e contro per entrambi, ovviamente. Inoltre su quel che poteva fare Motorola in futuro sono soltanto delle supposizioni, prive di alcuna considerazione tecnica.


“Forse” l'ho letto benissimo, ma la mia considerazione riguardo la velocita' e' scaturita da diversi commenti (non miei, ma raccolti nel web) in merito. Wikipedia l'ho citata solo per l'esempio della teorica evoluzione, ovviamente la prendo come tale. Era solo per farti notare come non solo io ipotizzassi possibile un'ulteriore evoluzione di questa famiglia di CPU. Se non ti faccio i disegnino non capisci!!


5 anni sono il totale, fra salire e scendere: non è l'intero periodo di gloria. Comunque, anche volendo essere buoni, è sempre poco visto che per l'Amiga si parla di più di 10 anni.


Per l'Amiga “PARLI” di piu' di dieci. Quando arrivo il PC nelle case, schiaccio' l'Amiga come gli ultimi focolai di Atari (in ambito ludico).


A giudicare dalle riviste che tu stesso hai citato, direi che si tratta di uno dato tutt'altro che personale.


Hai parlato del 96 o dell'86?? ;)


Vedi sopra: i conti bisogna saperli fare, però...


E li so fare.. anche molto bene direi.


Non c'è neppure una mail a cui scrivergli.


E da quando una guerra si dichiara via e-mail?!?! :D


Comunque tu hai citato prima wikipedia e poi questo sito: visto che dicono cose completamente diverse sul 68060, a questo punto devi dirmi quale dei due ritieni più attendibile.


Sinceramente Wikipedia non l'ho sempre trovato attendibile. E' bello vasto ed anche utile, ma le fonti, spesso, lasciano a desiderare. Pensa che anche tu potresti scrivere un articolo per loro, questo la dice lunga.


In base alla tua scelta, quel che hai detto prima citando l'uno o l'altro sito risulterà privo di fondamento, e quindi falso. Accomodati pure... :asd:


E quindi sarebbe da prendere una documentazione piu' tecnica e vedere.


Ma non conoscevi il MESS, che è piuttosto famoso nell'ambito dell'emulazione di sistemi non arcade (console e computer).


Ti riposto la mia frase: "Io, in ogni caso, ho solo detto che stavo vedendo schermate nere, mentre scrivevo testavo, visto che non mettevo le mani su quell'emulatore da un pochetto, speravo che nelle ultime versioni fosse migliorato"
Ho leggermente evidenziato una frase, ora fai due piu' due e cerca di capire se lo conoscessi o meno.


Non capisco quali difficoltà tu abbia avuto per avere quelle schermate nere: basta decomprimerlo, copiare il file col firmware del Jaguar nell'apposita cartella, e far puntare il path delle immagini dei giochi alla cartella che li contiene.


Non illuminarmi troppo, poi non i vedo piu'!!


Lo riprovo in questo week-end e poi ti faccio sapere.


Lo faro' anche io


E' una forzatura priva di alcun nesso logico.


Mi riallacciavo alla tua affermazione secondo la quale, visto che hanno fatto un emulatore funzionante del Jaguar, lo possono fare anche del Falcon.. ed io ti dissi che non esiste alcun emulatore Jaguar degno di nota in quanto a compatibilita'. ecc..


http://www.myatari.net/issues/dec2002/aranym.htm

"Thomas: What about special features like DSP emulation?

Milan: It is very nice. But not for real work. Maybe somebody writes an interface to Déesse, then it could be more interesting.

Standa: The DSP emulation doesn't make much sense. It was developed by Patrice Mandin to let a few clean DSP programs work. The main problem here is that DSP utilizing software is mostly not written as system clean and therefore it won't run on any TOS clone.

Petr: The DSP MC56001 emulation is actually a great thing for studying the existing software from inside. You can trace the software in a way that would not be possible on real DSP. I think Patrice wrote it mainly for this studying purpose. It definitely was not meant as something that would allow running old Falcon games, demos or even sound applications. No way. Those programs are usually written in a very dirty way (avoiding system clean programming and going to hardware registers directly) and always rely on exact timing - a thing we don't have in ARAnyM (if you haven't realized it yet - Aranym's CPU runs as fast as possible so only real system clean software works properly)."

Quindi in futuro potrebbero migliorare l'emulazione del DSP 56001...


Non dubito che questo possa accadere.. ma emulare il computer intero.. Non ci credo, ma lo spero.


Non hai ancora fornito degli esempi RIPRODUCIBILI di problemi dovuti all'hardware del PC.


Caricati un VST, scriviti una partitura molto ritmica a 16esimi, mandala in play con una semplice sounblaster e SE per caso la dovesse suonare a tempo, al primo accesso ai dischi (magari per richieste di windows), sentirai il tempo che se ne va a puttane. Comunque non ci riesci a mandarlo a tempo con una SB, ti serve una scheda motlo piu' evoluta.


Le parole non m'interessano: io parlavo di argomenti. Sono questi che mancano a sostegno delle tue idee.


Credo dovresti rileggere ATTENTAMENTE tutti i miei post.


Inoltre il fatto che ti attacchi al mio titolo, oltre che risultare puerile, mette in evidenza le tue difficoltà nell'affrontare la discussione...


Io trovo inutile ed anche abbastanza poco signorile, mettere il proprio "titolo" come firma in un forum, se ti identifichi nel tuo titolo.. stai messo malino. ;)
Qualche giorno fa gli inquilini dl piano sotto a quello nel quale vive una mia cara amica sono andati via, al posto loro e' arrivata una famiglia (non dico di dove per non essere tacciato di campanilismo), la prima cosa che hanno fatto, mentre ancora sballavano e portavano gli scatoloni, e' stato appendere la patacca d'oro sulla porta di casa (casa non studio) con il TITOLO della figlia appena laureata. Sono tuttora gli zimbelli del palazzo.
E' questione di gusto, pertanto assolutamente insindacabile.


Allora meglio un computer, che almeno le cose se le ricorda bene...

La mia memoria a lungo termine non e' poi cosi' male, mi sembra di aver ricordato vagonate di cose, che per quanto tu ritenesi errate, ho dimostrato giuste e corrette.
Punti di vista pure qui.

Ciao ciao Dotto'!!


P.S. L'atari non ha mai avuto la mancanza della tecnologia necessaria a sovrastare l'Amiga (leggasi E-ST progetto dal quale nacque il meno potente ST-E ma con due blitter e due shifter http://www.maedicke.de/atari/hardware/est.htm, Sparrow FX.1 ed ATW800), ma scelse sempre il giosto punto d'equilibrio, tra prezzo, prestazioni, affidabilita' ed armonia. (leggiti le due caratteristiche riportate dell E-ST) (l'ATW800 fu prodotto in piccola serie, quasi prototipale e distribuito in enti come centri di ricerca, nulla c'entrava con le macchine in questione, e' solo un esempio della tecnologia che quella casa poteva concepire e realizzare).

[fek]

Sinceramente Wikipedia non l'ho sempre trovato attendibile. E' bello vasto ed anche utile, ma le fonti, spesso, lasciano a desiderare. Pensa che anche tu potresti scrivere un articolo per loro, questo la dice lunga.

Queste sparate non ti fanno certo onore dato che cdimauro e' uno dei piu' preparati qui.

Quando insulti il tuo interlocutore (e lo hai fatto spesso) dimostri solo di non avere argomenti con i quali controbattere, e alla fine fai un danno solo a te.

[MadRat]

Queste sparate non ti fanno certo onore dato che cdimauro e' uno dei piu' preparati qui.

Quando insulti il tuo interlocutore (e lo hai fatto spesso) dimostri solo di non avere argomenti con i quali controbattere, e alla fine fai un danno solo a te.

Lo ha fatto anche lui senza conoscermi e comuqnue era solo una battuta.. Un insulto e' fatto in ben altro modo. So bene la preparazione (anche se in alcuni casi "ovviamente" parziale come quella di tutti), di cdimauro, altrimenti non ci perderei il mio tempo.

[cdimauro]

Prova a caricare QUALUNQUE gioco a 60hz (procurati un ST) e vedrai un incremento prestazionale pari alla percentuale di scarto tra 50 e 60.
Questa cosa era risaputa da tutti gli utenti Atari, anche i piu' semplici giocatori.... Ma tu hai una spiegazione tecnica che dimastra il contrario.. ti giuro che ho il sorriso in faccia.
Il ragionamento che fai tu e valido solo per architetture modulari come il PC.
No, perché il contesto era chiaro: stavamo parlando di giochi 3D, la cui resa di frame richiede un tempo di calcolo variabile.
In questo caso passando da 50 a 60Hz non v'è alcun beneficio, ma un decremento di prestazioni dovuto al maggior numero di accessi in memoria da parte del chip video per la visualizzazione dei frame.
Ti dico il primo gioco che mi viene in mente ora che lo supportasse da pannello. BloodMoney, gia' citato.. A 60hz metteva il turbo!!
Mentre per quelli che non lo supportavano, lo mettevo nel folder auto quando si poteva.
Infatti hai citato un gioco 2D, per il quale la norma era che il tempo di calcolo era "costante" (per essere precisi non si poteva superare un certo valore), pena la perdita di un fotogramma, che comportava un vistoso e sgradevole scatto.

I 60Hz "per far girare i giochi più fluidamente" si potevano impostare anche con l'Amiga (hai detto di averne avuti: dovresti esserne a conoscenza).

Comunque non era sempre possibile farlo, e per due motivi:
- passando da 50Hz (PAL) a 60Hz (NTSC), il tempo disponibile per ogni fotogramma diminuiva (si passava da 312,5 a 262,5 righe, quindi da 70.937,5 a 59.587,5 cicli di clock);
- da 50Hz a 60Hz la musica veniva suonata più velocemente.

Nel primo caso, se il gioco ce la faceva a completare tutti i calcoli nel minor tempo che gli rimaneva, poteva girare tranquillamente a 60fps, altrimenti subiva degli scatti o addirittura un rallentamento (girava a 30fps anziché ai 60fps desiderati).
Nel secondo caso, se il gioco era scritto bene, variava la velocità di playback del suono in modo da mantenere il ritmo. Cosa che non era sempre possibile facendo uso di moduli, perché era "calibrati" per suonare a 50 o 60hz e non c'era disponibile un'apposita versione per l'altra frequenza di lavoro.
A molti fregava.

Pensa che da quando prendemmo l'Amiga e lo mettemmo affianco all'ST nel nostro ufficio a via illiria a Roma, vendevamo piu' facilmente i nostri Atari. :)
Non è servito a molto, allora: Atari Italia ha venduto circa 10 mila ST dall'85 all'88, mentre Commodore Italia ha venduto circa 14.200 Amiga 1000 fra luglio e dicembre 1986... :asd:
Magari dovresti provarlo. Ne fecero anche una versione per HW mac, per portare la piattaforma Atari verso HW piu' evoluti dopo la cessazione della produzione di nuovi computer 'Atari .
Non è questione di provare o meno: hai presente come funziona un s.o. monotask e uno preemptive? Mi sembra proprio di no. Hanno costi computazionali diversi, e il secondo ha uno scheduler che richiede un certo tempo di esecuzione.
Gli scheduler sono uno degli argomenti più trattati della storia dell'informatica: ci sarebbe stato ben poco da studiare e discutere se fossero stati "a costo zero", come vorresti far credere tu.
Quello era il periodo del declino, l'atari italia era gia' chiusa ed i prezzi non fanno piu' testo.
Falso, perché ho riportato la storia dei modelli ST e Amiga a partire dalla loro uscita, e non soltanto quelli relativi al periodo della morte di Atari Italia.
Comuqnue il 1200 usci' veramente troppo tardi, non potevano sperare di venderlo a prezzi maggiori. (infatti e' l'unica eccezione della lista).
No, è che col 1200 la Commodore ha utilizzato massicciamente componenti VLSI e tecnologia SMD, per cui piastra madre e componenti costavano molto poco. Infatti se hai mai smontato un 1200 dovresti sapere che all'interno era praticamente una scatoletta vuota, con una piccola piastra su cui stava tutto.
..e facevano piu' schifo che su ST.
E si vedeva proprio: Marble Madness, titolo della Atari Arcade che ha sbancato in sala giochi, per Amiga è stato convertito alla perfezione (e non solo girava col s.o., ma usava le API di AmigaOS per sprite, grafica e sonoro); la versione ST non era assolutamente all'altezza dal lato grafico, e molto peggio da quello sonoro.
Space Harrier della SEGA ha finalmente avuto giustizia proprio con la versione Amiga, che vantava overscan, grafica fedele all'originale (ricchissima di sfumature) e sonoro superlativo.
Idem per Super HangOn, Silkworm (capolavoro assoluto all'epoca), Ghosts'n'Goblins, ecc. (la lista è lunga).
Anche senza scomodare le conversioni da sala giochi, il verdetto era lo stesso: roba come Defender of the Crown (ancora oggi un titolo bellissimo), SDI, The Pawn, Turrican, ecc. sono rimasti nel mito non per le sbiadite versioni ST, ma per quelle maestose Amiga...
Ma perche' non capisci?? Parlo ovviamente di giochi/applicazioni sotto SO.
I giochi che giravano sotto s.o. sono stati sostanzialmente soltanto i primi: poi la norma è stata quella di far fuori il s.o. al boot, e di prendersi tutta la memoria. D'altra parte il s.o. ai giochi serviva a ben poco...
Per le applicazioni hai ragione: rimaneva poca memoria con l'Amiga 1000. Soltanto con questa macchina, comunque, che è durata appena un anno...
Riflessione: Se per avere un desk ed un interfaccia grafica all'Amiga fossero bastati 10KB in piu', li avrebbero messi in ROM.
Il WorkBench è rimasto sempre su disco (col comando LoadWB) anche con l'arrivo di Amiga 500/2000, che avevano 256KB di rom, e col 3000 (e successivi) che ne aveva ben 512KB.
Il motivo è molto semplice: in caso di problemi / bug era più facile sostituire il comando che faceva partire l'applicazione di gestione del desktop, che fare la stessa con la rom...

E' chiaro che il WB è un'applicazione che fa uso delle librerie di sistema, che si occupano di effettuare la maggior parte del lavoro.
Lo disattivava anche avendo l'espansione.
Allora come spieghi che me lo sono goduto col sonoro pur avendo soltanto 1MB di ram? Il mio Amiga 2000 ha visto un'espansione da 2MB soltanto pochi mesi prima che lo cambiassi per l'Amiga 1200...
Hai eluso la considerazione, non mi andrebbe proprio di attaccare lo scanner per farti leggere le tonnellate di carta sulle quali c'e' scritto come la versione per ST di questo piuttosto che di quell'altro gioco 3D fosse piu' fluida, ma con audio inferiore. Lo ritengo una perdita di tempo.
Il tempo per scrivere lo trovi, e non mi sembra poco a giudicare dalla lunghezza dei messaggi...
Poi spiegami per quale motivo il 68k a 8 mhz sull'Amica era castrato a 7 e spicci.. Se non per limiti architetturali, visto che il processore stesso era identico e prodotto ad 8mhz.
Molto semplice: perché il suo clock era perfettamente sincronizzato con quello dei chip custom e di tutto il resto (e qui rispondo anche al tuo messaggio precedente, che riportava un'informazione inesatta).
Nel caso di macchine NTSC, il clock del processore era generato da quello generale, che era di 28.563.864 cicli di clock, diviso 4: 7.140.966 (7,14Mhz. Prima m'era scappato un 7,16Mhz).
Nel caso di macchine PAL, il clock del processore era generato da quello generale, che era di 28.375.000 cicli di clock, diviso 4: 7.093.750 (7,09Mhz).

Perché far girare il processore a un clock inferiore (il 68000 era la versione a 8Mhz)? Perché avendo il clock sincronizzato con quello dei chip custom, non si andava incontro a cicli di wait state quando si accedeva alla memoria condivisa (come invece avveniva con altre macchine, come l'ST).
Comunque la percentuale di differenza tra 7 ed 8 non e' poi cosi' trascurabile.
Dipende dal tipo di applicazioni: è chiaro che quelle di "calcolo puro" ne risentivano, ci mancherebbe. Negarlo sarebbe da stupidi. Però, coi giochi o in generale con applicazioni che facevano largo uso dei chip custom, le cose stavano diversamente, come s'è visto poi.
Una buona programmazione (vedi ad esempio i bitmap brothers) dimostrava che queste enormi differenze poi non ci fossero.
I cicli di clock sprecati per ottenere l'overscan non si possono certo nascondere. Nulla si crea e nulla si distrugge: mancano e basta.
E' chiaro che i programmatori dovevano ridimensionare qualche altra cosa (es: meno oggetti grafici a video, o di dimensione più ridotta, ecc.).
Nel file che mi hai lincato tu c'e' scritto che il processore audio DMA dell'STE puo' prelevare la forma pcm dalla ram ed inviarla ai codec.. Grande fatica per la CPU, non c'e' che dire..
Infatti la fatica non sta affatto qui. Fin qui, anzi, è esattamente ciò che avviene con i 4 canali dell'Amiga.
Ora, qualora mi venissi a dire che la lettura di un file MOD (mi hai portato l'esempio di un player per Amiga), esclusa la gestione audio, sull'STE occupasse il 30% della CPU, potrei mettermi a ridere.
Infatti la fatica non sta affatto qui. Fin qui, anzi, è esattamente ciò che avviene con l'Amiga per i MOD.
Sostanzialmente è ciò che faceva il mio player di moduli a ogni frame: andare a recuperare le 4 note (o comandi) da suonare (o eseguire), e impostare i parametri dei 4 canali DMA in accordo (uno solo, "stereo", nel caso degli STE).
Stando alla tua conclusione finale allora mi sembra OVVIO che nel mio STE ci fosse montato un 68000 a 1428 mhz (MILLEQUATTROCENTOVENTOTTOMHZ :D) (7.14 * 200), dato che funzionava nella piu' totale disinvolutura
Disivoltura che richiedeva parecchio tempo di calcolo, invece. Perché il problema non è in quello che hai scritto finora: ciò che faceva perdere parecchio tempo era la miscelazione dei 4 (oppure 8) canali negli unici 2 canali disponibili nell'STE.
ed i giochi che utilizzavano l'audio dell'STE, non risentivano di rallentamenti,
Bisogna vedere come li usavano i due canali PCM: è probabile che usassero i due canali così com'era, senza effettuare alcuna miscelazione. In questo modo era possibile mantenere un'eccellente compatibilità anche coi precedenti ST, che usavano soltanto l'YM2149.
al contrario di quanto non accadesse per ST, che per riprodurre una forma PCM di buona qualita', aveva bisogno di vendere un rene.
E neanche di qualità: con 4 bit per l'ampiezza del segnale non si poteva fare nulla di più del SID del C64.
.. Mi sa proprio che quel traker e' una bella cagata.. Ma conosci solo quello purtroppo.
Veramente ti ho detto di confrontare i sorgenti di oktalyzer o di qualunque altro player per l'ST. Appello che è rimasto lettera morta...
Fortunatamente qualcuno lo ha saputo programmare meglio di quanto avresti saputo far tu.
Questo come fai a dirlo? Per Amiga avevo realizzato un player di moduli a 8 canali molto veloce, che contavo usare in qualche futuro gioco meno esoso dal punto di vista grafico (avventure, RPG, ecc.)

Tra l'altro i player di moduli a 4 canali che avevo scritto si serviva del Copper (il coprocessore grafico) per programmare i registri audio, svincolando ancora di più la CPU: ad oggi non mi risulta che altri abbiano fatto la stessa cosa... ;)
Non e' esatto nemmeno questo. anche se occupasse il 30% per arrivare a 4 ch a 50khz (molto piu' in la di quanto non potesse l'Amiga) sarebbe gia' un risultato notevole, ma i dati non li hai come non li ho io.
I dati sono quelli, e sono scritti nero su bianco: puoi soltanto fartene una ragione.
Posso dirti che nell'uso del protracker avevo una sensazione di pesantezza e lentezza sconvolgente, con altri (come AS), non c'era affatto.
Può darsi che fossero un po' più leggeri, ma in ogni per riprodurre 4 o 8 canali dovevano per forza di cose miscelarli, riducendoli ai soli 2 disponibili. Per quanto buona fosse la routine di miscelazione (era possibile usare dei trucchetti), il tempo di calcolo era comunque consistente (e inevitabile).
Guarda caso il PT era una conversione dall'Amiga. Mentre l'oktalyzer era abbastanza lento, ma con risultati decisamente ottimi.
Il che dimostra che, in ogni caso, era necessario effettuare dei calcoli abbastanza pesanti a carico della CPU.
Seguiti a confondere l'STE con l'ST.
Direi proprio di no, da quanto ho scritto finora, e non mi hai ancora smentito.
Infatti ti ho chiesto di analizzare i sorgenti di ALTRI player, oltre al ProTracker, ma sto ancora aspettando...
Ma non mi risulta proprio!! Al massimo aveva 1280�12 (che poi era 1280*400 con overscan inferiore ed interlacciata, dunque due pagine a 1280*200 a 25hz l'una). Direi quasi la meta' dei pixel anche se consideriamo l'intarlacciata!!
No, c'era la 1280x512 per il PAL e la 1280x400 per l'NTSC. Con l'overscan si arrivava a 1440x576 e 1440x480 rispettivamente.

Comunque dimentichi che già ai tempi dell'Amiga 1000 era possibile visualizzare schermate a 1004x1024 pixel a 4 colori con uno speciale monitor. Per maggiori informazioni e per vedere il mostriciattolo in azione, recuperare i numeri di MC MicroComputer fra giugno e settembre 1986.
e poi la scelta del monocromatico ad alto refresh ("con il bianco carta") anziche' con 4 (inutili) colori a frequenze stancanti, era decisamente piu' logica.
E' un'affermazione che manca di logica, invece: 4 colori sono comunque molto più utili di 2. Al più, se sei così attaccato al monocromatico, ne usi soltanto due. Ma passare da 2 colori a 4 era impossibile per l'ST...
Frall'altro l'A3000 aveva maggiori limiti d'espansione RAM
Falso. Proprio l'A3000 introdusse lo Zorro III come espansione, con indirizzamento della memoria 32 bit, portando il limite della memoria installabile a poco più di 2GB...
e CPU piu' lente (al massimo 25mhz contro i 32 del TT)
Per forza: i TT sono arrivati più di un anno dopo l'Amiga 3000. Dopo il 3000 la Commodore ha lavorato al 4000, che integrava un ben più potente 68040, che Atari non ha potuto usare per gli ST (è defunta prima).
Erano due macchine estremamente differenti con potenze applicate in settori differenti.
Mi fai qualche esempio?
Se proprio volessimo fare paragoni con le tecnologie disponibili, comunque, l'Atari nell'87 presento' il Transputer (ATW800), con CPU risc da 4mips e capace di lavorare in parallelo con altri suoi simili (direi molto all'avanguardia). Questo poteva arrivare a 1280*960 a 16 colori o 1280*768 a 256 su 16milioni. Non male per l'87. ;)
Sì, ma non era un computer "di classe ST"
Diciamo che questa chiamata in causa del A3000 e' stata fuori luogo, quanto sbagliata. Ricordando che l'hai chiamata tu parlando del deinterlacciatore di serie mentre parlavamo di A500 e di 1040 ed io ti risposi dicendo che se fosse stato per quello, allora anche il TT ecc.. ;)
No, hai parlato di risoluzione interlacciata e ti ho detto che esistevano i deinterlacciatori (per Amiga 1000, 500 e 2000) E (congiunzione) che l'Amiga 3000 ne aveva uno di serie integrato.
Sì, sì, quelli che quando muovevi il mouse lasciavano la scia come sul mio vecchio prodest a fosfori verdi. Bellissimo.
Come sopra, stavamo parlando di professionisti che avevano bisogno di lavorare con risoluzioni video elevate. Al 99% degli utenti non interessavano né i deinterlacciatori né i monitor ad alta persistenza.
No, l'ho citato ben prima di te se rileggi i post, ma il mega ST non era una macchina per l'utenza ludica.
L'hai citato come innovazione introdotta con gli STE, e non è così. Punto.
Mi sembra una dimenticanza da poco.. darebbe un po' come scordarsi un chip custom dell'Amiga.
Questo dimostra pienamente la tua lacuna in merito.. Non e' un reato non conoscere tutte le piattaforme, in fin dei conti sei notevolmente preparato in ambito Amiga, anche tu hai dei limiti.. o forse no??
Infatti basta riconoscerli: non ho una memoria perfetta, e non posso ricordare tutto, ma certo sono messo MOLTO meglio di te, visto che trovo puntalmente riscontro a ciò che dico (smentendo le tue affermazioni).
Dovresti farmi vedere questi dati.
Ti stai arrampicando sugli specchi, perché l'ho già fatto: ho postato parecchi link a pagine o documenti in cui sono descritte non solo le caratteristiche tecniche, ma anche COME SI PROGRAMMA l'hardware degli STE. Si parla di UN canale DMA in grado di prelevare i dati per DUE canali PCM.
Ora, se mi fai vedere come si programma un STE utilizzando 4 o 8 canali SENZA L'USO DELLA CPU PER MISCELARLI, non avrò difficoltà ad ammetterlo pubblicamente. L'onere della controprova sta a te: niente "ricordi", ma FATTI.
all'atto pratico lìAmiga non arrivava dove arrivava l'STE nemmeno con l'ausilio della CPU (4 ch a 50khz).. ah, gia', L'STE aveva un 68000 a 1,4ghz!!
:mc: L'Amiga arriva tranquillamente a 4 canali a 56Khz e senza ricorre a nessuna miscelazione, come ti ho già spiegato. Tutto il resto sono chiacchiere di chi non porta NESSUN FATTO a sostegno delle proprie tesi.
Ti stai arrampicando sugli specchi. DIMOSTRA OLTRE OGNI RAGIONEVOLE DUBBIO CHE CIO' CHE HO SCRITTO E' FALS O, PORTANDO DOCUMENTI TECNICI, SE CI RIESCI. Altrimenti è evidente che sei soltanto un troll che non ha nulla da fare se non quello di raccontare balle in un forum, pretendendo che altri gli credano, ma a raccontar balle sono bravi tutti...
:o Ti giuro che fino a quest'affermazione credevo che sapessi qualcosa al riguardo. Ora hai palesato il contrario.
L'Amiga aveva 4 CH a 8 (OTTO:D) bit, con 4 convertitori DAC (a OTTO bit) ed un modulatore di periodo O volume a 6 bit. Qui il tuo calcolo maccheronico (imboccando alle dichiarazioni Commodore del tempo) di 8+6=14 :D, ma la sai la differenza tra un suono a 8bit ed uno a 14?? Anche se lo dici a 14bit, sempre 256 livelli aveva giammai non 16384!!!!
Siamo scarsetti in matematica: dalle mie parti 2^14 fa 16384...
In questo caso il SEGNALE d'uscita dei 4 DAC dell'Amiga presenta 16384 livelli: è un segnale a 14 bit a tutti gli effetti, checché tu ne dica.
Altro punto poi e' che l'Amiga aveva 4 DAC alla meta' della frequenza dei DUE DAC dell'STE. Chiunque abbia un minimo di conoscenza in merito, sa che e' la stessa identica cosa!!
E' completamente falso, come ti ho già detto: l'Amiga aveva 4 canali audio con frequenza massima di 29Khz SE PILOTATI DAL DMA (quindi SENZA alcun intervento della CPU), ma questo limite era superato usando la CPU, e ciò valeva PER TUTTI E 4 I CANALI. Anzi, si potevano raggiungere frequenze molto più elevate dei 56Khz (per tutti e 4 canali: lo ripeto perché a quanto pare ne hai bisogno).
Poi questi erano gestiti come 4ch indipendenti dal processore DMA dell'STE.
Totalmente falso: il canale DMA trasportava i dati di DUE SOLI canali PCM, come ho ampiamente dimostrato. Tutto il resto sono soltante fantasie non surrogate da alcun fatto.
In teoria sarebbe pure potuto essere un DAC unico a 100khz (ovviamente perdendo lo stereo a questo punto). Un DAC non e' il processore audio!!
Ma infatti io ho sempre parlato di canali, non di DAC: non mettermi in bocca parole che non detto.
Semplice: 4 PCM in DMA+ 3 Sintetizzati in DMA+ uno sempre sintetizzato ma con onda bianca anziche' quadra sempre in DMA.
Mi pareva di averlo gia' scritto.
Ed è falso, perché sono 2 i canali PCM pilotati dal DMA. Punto.
Poi c'e' da dire che dimezzando le frequenze, si possono raddoppiare i canali, ma questo e' un altro discorso.
Anche questo è falso: il DMA degli STE pilotata soltanto due canali, e lo può fare fino a 50Khz senza alcun intervento della CPU.
Il fatto che sia possibile suonare soltanto 4 canali a 50Khz oppure 8 a 22Khz è dovuto "semplicemente" alla CPU, che non è abbastanza potente da poter miscelare 8 canali a 50Khz. Al DMA non frega niente di quanti canali sono stati miscelati nei due PCM di cui trasporta i dati: potrebbero essere anche 12, 16, 20, 32, ecc. Il problema è soltanto della CPU, che non ce la fa a miscelarli per mancanza di potenza di elaborazione.
Temo che tu non sappia il significato della parola dinamica. Quel manuale lo ho in pdf da una vita, se vuoi te lo passo in versione piu' completa.
Qualora volessimo, inoltre, sparare bit a caso potremmo anche notare i 12 bit dei della frequenza o i 16 dei periodi d'inviluppo (quest'ultimo non tanto a caso).

Hai grossa confusione riguardo la dinamica di un suono di un sintetizzatore e' quella di un campionatore. Tant'e' che ho pure parlato di ottave.
Stai soltanto cercando di rigirare la frittata...
Per un segnale i due parametri fondamentali sono frequenza e livelli di ampiezza: il primo è legato alle ottave raggiungibili, il secondo alla dinamica. Se hai delle informazioni (tecniche ovviamente) diverse, non hai che da documentare.
Per due canali in tutto, non per quattro e qui pure l'utilizzo della CPU arrivava a picchi notevoli. ;)
Vedi sopra: ogni canale audio dell'Amiga è indipendente e pilotabile indifferentemente tramite DMA o CPU. Nel secondo caso, TUTTI E QUATTRO I CANALI potevano arrivare a 56Khz (e anche più).
Quanto all'utilizzo della CPU, si tratta di generare un solo interrupt per ogni riga di raster, e impostare la word (due byte) "mancante" per ogni canale. Diciamo che richede MOLTO MENO TEMPO rispetto a quello necessario per visualizzare 512 colori coi tuoi ST...
Dunque non vedo disparita'.
Quello era l'UTILIZZO TIPICO. La disparità c'è tutta invece, perché CHI VOLEVA poteva attaccarci fino a 4 drive.
Lo so benissimo, tuttavia con la blitz dell'ST copiavo in una frazione del tempo di quella richiesta dall'Amiga e con risultati migliori (copiava pure dragon's lair protetto a laser e Dungeon master).
I copiatori hardware c'erano anche per Amiga, ma in questo contesto non fanno testo: stiamo parlando delle macchine nude e crude che la gente si trovava per le mani.
Ti servirebbe proprio di usare un ST dal vivo. Non solo i limiti li riportati sono tutto tranne che veritieri, ma con alcune meccaniche si poteva arrivare ad 83 * 12 (anche se i seteaggi arrivavano fino ad 85 mi pare). Caricatelo su un emulatore e vedilo con i tuoi occhi.
Ovviamente i limiti della meccanica esistevano anche per Amiga, non e' detto che un disco formattato ad un mega, fosse poi utilizzabile, dipendeva dalla generosita' dell ameccanica installata.
Appunto. Io ho riportato soltanto 82 tracce nei mie conti, perché erano quelle raggiungibili da tutti gli Amiga. La meccanica del mio 1200 arriva a 84 tracce, come pure quella di molti altri Amiga che ho testato; alcuni arrivavano soltanto a 83 tracce. Per sicurezza nei miei giochi utilizzavo soltanto 82 tracce.
Quanto ai 12 settori per traccia degli ST, è una cosa nuova per me: hai della documentazione in merito?
Non c'e' che dire 10 secondi piu' che su Atari,
Vedi sopra: i copiatori hardware non fanno testo.
con potenza inferiore,
Cioé? Spiegati meglio.
moltiplicalo per un centinaio di dischi a botta..
Ma tu cosa facevi, il pirata? Dopo tutto ciò che hai scritto, il dubbio è legittimo. Io, come la quasi totalità della gente che ha avuto un computer (non solo Amiga), non ho mai avuto né sentito l'esigenza di copiare dischi a josa. Era roba da pirati che, ripeto, avevano delle batterie di Amiga con 4 drive attaccati ciascuno per effettuare 4 copie nel tempo di una...
HW bilanciato, canali bilanciati.
L'unica cosa su cui sono d'accordo.
Direi lo zen del computer..
E infatti s'è vista la fine che ha fatto...
Dunque, visto che io ho detto: "sotto la tua interpretazione" e tu hai detto: "No, quella di chi ha una base tecnica che gli consente.. ecc"
Questo significa che tu non sei colui che ha una base tecnica che gli consenta ecc... Beh, su questo siamo d'accordo ;).
Se di Amiga puoi parlare, di Atari proprio no. Le tue "deduzioni" danno l'impressione di essere prese direttamente da manuali tecnici letti al volo qui e li per rispondere alle mie considerazioni.
Il problema è che le tue considerazioni sono frutto di ricordi errati e mancanza di conoscenza tecnica. Quest'ultima non la si acquisisce semplicemente usando il computer, come fa la maggior parte della gente...
Io non ho mai programmato un Atari ST, perché ho avuto di meglio fra le mani, ma non ho difficoltà a colmare questa lacuna proprio andando a cercare informazioni e integrandole nel mio bagaglio culturale e di esperienza che mi sono fatto col passare del tempo.
Informazioni che, comunque, contrastano palesemente con ciò che hai riportato tu. E visto che si tratta di informazioni che per buona parte provengono da chi un Atari ST non l'ha semplicemente usato, ma anche programmato (con tanto di sorgenti rilasciati e che ho avuto modo di analizzare), direi che sono decisamente più affidabili di tutto ciò che finora hai malamente riportato.
Bisogna vedere quanto questo accadesse, visto che l'HW dell'Amiga era piu' complesso e piu' difficile da gestire.
Più complesso, sì, internamente, ma più facile da programmare e gestire.
La stabilita' dell'ST era assolutamente invidiabile,
Anche quella dell'Amiga. Con la differenza che potevi lanciare diverse applicazioni contemporaneamente
nonché del TOS da te tanto denigrato, che tuttavia costiutui' la vera' fortuna dell'ST.
"Fortuna" che l'ha portato velocemente alla tomba, e al contrario di AmigaOS, che tutt'ora prospera.
L'Amiga non continuava a suonare del il 68k era in panne ed il guru posava le chiappette in terra.
Quindi avevi il sistema totalmente bloccato: rientriamo nel primo caso che ho esposto.
Hai pure detto "pubblicita' ingannevole" confondendo il numero dei DAC con il numero dei canali.. Errore veramente assurdo.
Hai una pessima memoria anche per gli avvenimenti recenti, a quanto pare... Tu hai scritto questo:

"E su ogni pubblicita', manuale e recensione del tempo l'STE era dato per 8 ch, visti come 4 pcm, 3 sintetizzatori quadri ed 1 dedito al rumore bianco."

E io ho scritto questo:

"Pubblicità ingannevole, allora."

Adesso mi spieghi dove ho parlato di DAC e canali.
Gia', hai proprio ragione!! questa si che e' una cazzata orbitale!! La qualita' deriva SOLO dalla qualita' del DAC stesso a partia' di frequenza.
Il DAC divide i propri cicli per l'elaborazione dei canali, proponendo due segnali ben distinti contemporaneamente. Questo non determina NESSUNA perdita di qualita'. La somma sonora la percepisce l'orecchio e la miscelazione avveniva anche nell'Amiga, visto che usciva in stereo.
Questo dimostra la tua "preparazione" in materia. Quindi per te è la stessa cosa avere a disposizione 4 canali a 8 bit indipendenti, ognuno collegato al proprio DAC, e miscelare 4 canali a 8 bit in due canali a bit, vero? Ovviamente la miscelazione non comporta alcuna perdita di precisione al segnale associato ai due canali miscelati...
Quindi a questo punto potremmo anche miscelare 1000 canali a 8 bit in un solo canale, tanto la qualità sarebbe la stessa... :rolleyes:
Mi piacerebbe trovare un link dettagliato in merito, visto che ritengo che bastassero 4 bit per adempiere a quelle funzioni.
Un link l'ho già postato prima. Quel che ritieni tu ha poca importanza, perché ciò che conta è l'ambito applicativo: se ho bisogno di una maggior precisione per pilotare i laser, 4 bit per l'ampiezza del segnale possono non bastare.
“Forse” l'ho letto benissimo, ma la mia considerazione riguardo la velocita' e' scaturita da diversi commenti (non miei, ma raccolti nel web) in merito. Wikipedia l'ho citata solo per l'esempio della teorica evoluzione, ovviamente la prendo come tale. Era solo per farti notare come non solo io ipotizzassi possibile un'ulteriore evoluzione di questa famiglia di CPU. Se non ti faccio i disegnino non capisci!!
E ti ho fatto notare quanto, TECNICAMENTE PARLANDO (e quindi siamo ben distanti dalle "voci" che si trovano su internet), ciò presenti parecchi problemi dal punto di vista implementativo. La differenza è evidente...
Per l'Amiga “PARLI” di piu' di dieci. Quando arrivo il PC nelle case, schiaccio' l'Amiga come gli ultimi focolai di Atari (in ambito ludico).
Quando arrivò il PC nelle case aveva l'Hercules o la CGA (per i "ricchi") e il cicalino dello speaker: perfino il Commodore 64 era messo meglio.
L'Amiga come piattaforma d'elezione per i giochi è sopravvissuta fino al 1996 (poi è andata scemando), e l'ST era già morto da parecchio tempo.
Questa è storia, e la si può andare a controllare riviste dell'epoca alla mano. Tra queste ci sono le stesse riviste che hai citato tu, e che adesso vorresti malamente smentire.
I tuoi ricordi lasciano il tempo che trovano...
Hai parlato del 96 o dell'86?? ;)
Anche qui, come sopra: anche la tua memoria recente fa cilecca, a quanto pare. Ecco quello che hai scritto tu e per cui ho scritto quella frase:

"che poi l'amiga fosse il punto di riferimento per i giochi fino al 96, e' quanto di piu' personale tu potessi esprimere."
E da quando una guerra si dichiara via e-mail?!?! :D
Io non faccio la guerra a nessuno: volevo scrivergli per metterlo al corrente che le informazioni che aveva pubblicato erano sbagliate, in modo da correggerle. Sei tu che vedi guerra da tutte le parti...
Sinceramente Wikipedia non l'ho sempre trovato attendibile. E' bello vasto ed anche utile, ma le fonti, spesso, lasciano a desiderare. Pensa che anche tu potresti scrivere un articolo per loro, questo la dice lunga.

E quindi sarebbe da prendere una documentazione piu' tecnica e vedere
Cercare di cambiare discorso non toglierà il fuoco dalle castagne...
Hai riportato due fonti a sostegno di due tesi. Fonti che sono in completo disaccordo sul 68060. Ti ho chiesto quale due ritieni attendibile, e non hai ancora risposto.
Se ritieni wikipedia inaffidabile, ciò che hai preso da lei dimostra la falsità delle tue parole in quel contesto. Se ritieni inaffidabile l'altro sito, ciò che hai preso dimostra la falsità delle tue parole in quel contesto. E' un discorso molto semplice, e attendo una tua risposta.

Quanto alla documentazione tecnica, se ne hai bisogno valla a controllare tu: io conoscevo già come funzionava il 68060 senza bisogno di interpellare alcun sito...

Questo, comunque, è UN ALTRO DISCORSO: a me interessa la tua risposta a quanto scritto sopra. E non farla mancare, cortesemente.
Lo faro' anche io
L'emulazione non è perfetta: funziona bene con alcuni giochi, male con altri, altri non funzionano proprio. Il problema è questo: http://www.bannister.org/ubb/ultimatebb.php?ubb=get_topic;f=7;t=002412#000000

"The MESS Jaguar driver is based on the MAME Cojag driver. Only a few Jaguar games work, as the Jaguar blitter is only partially implemented."

Ci stanno ancora lavorando. Quindi non è in discussione l'emulabilità o meno: si tratta semplicemente di tempo. Ci vuole qualcuno che dedichi il suo tempo per implementare le parti parti rimanenti.

Infatti il driver Cojag di MAME riguarda una piattaforma arcade che fa uso di parte del Jaguar: parte che viene emulata perfettamente. Se avessero usato tutto l'hardware del Jaguar probabilmente l'emulazione sarebbe finita o comunque a buon punto.

Questo perché il team che lavora al MAME è composto da migliaia di persone, per cui c'è parecchia mano d'opera e la scrittura e il miglioramento dei driver procedono molto velocemente. Il team di MESS, invece, vive "di riflesso": sfrutta il lavoro del MAME, e ci sono poche persone che si occupano di integrare questo lavoro con altro, in modo da realizzare l'emulazione di computer.
Non dubito che questo possa accadere.. ma emulare il computer intero.. Non ci credo, ma lo spero.
Leggi meglio: il computer intero viene già emulato (anche buona parte del video migliore del Falcon).

Il problema è che ARAnyM ha obiettivi diversi rispetto agli altri emulatori: si propone di emulare gli ST (di qualunque classe) il più velocemente possibile, superando quindi i limiti prestazionali di questi computer. Questo però avviene sacrificando la piena compatibilità, ed è infatti ciò di cui si lamentano i suoi autori (i programmi che saltano il s.o. per accedere direttamente all'hardware del Falcon non funzionano o non funzionano bene).

Al contrario, emulatori come SainT e STeem si propongo come primo obiettivo l'emulazione fedele, quindi ricreare esattamente ciò che quei computer erano in grado di fare, "trucchetti sporchi" inclusi. E' per questo sono molto più lenti: infatti emulano la macchina "al ciclo di clock", similmente a quanto avviene con MAME, MESS, WinUAE (se impostato con quest'opzione), ecc.
Caricati un VST, scriviti una partitura molto ritmica a 16esimi, mandala in play con una semplice sounblaster e SE per caso la dovesse suonare a tempo, al primo accesso ai dischi (magari per richieste di windows), sentirai il tempo che se ne va a puttane. Comunque non ci riesci a mandarlo a tempo con una SB, ti serve una scheda motlo piu' evoluta.
Ho capito. Visto che hai queste esigenze, hai mai provato a impostare la priorità del task a quella più elevata? Alcune applicazioni permettono di impostare anche la priorità "real time": in questo modo la CPU sarà quasi esclusivamente impegnata a eseguire l'applicazione, a danno anche dei servizi del s.o...
Puoi farlo anche con WinAmp, ad esempio.

Avere un s.o. multitasking / preemptive non significa dover rinunciare per forza ad eseguire task molto delicati con la massima precisione...
Credo dovresti rileggere ATTENTAMENTE tutti i miei post.
E' quel che faccio, e non soltanto coi tuoi post. Se poi seguo una discussione, l'attenzione è anche maggiore.
In questo caso noto una generale non aderenza delle tue parole alla realtà dei fatti: si scontrano con tutte le informazioni tecniche che ho trovato, anche da parte di chi gli ST li ha programmati (mentre tu ti sei limitato a usarli).
Io trovo inutile ed anche abbastanza poco signorile, mettere il proprio "titolo" come firma in un forum, se ti identifichi nel tuo titolo.. stai messo malino. ;)
Potrebbe essere un'obiezione da valutare nel caso in cui fosse immediatamente esposta dagli interlocutori.
Invece accade puntualmente (tu sei soltanto l'ultimo di una lunga lista di gente che si è comportata così) che prima si inizia una discussione, e STRANAMENTE dopo un po' arrivano le classiche battutine sul titolo che traspare dalla mia firma.
Puzza fortemente di mancanza di argomenti a sostegno delle proprie tesi, per cui ci si aggrappa alle cose più banali e che nulla hanno a che vedere con ciò di cui si parla.

Per quanto mi riguarda, e lo ripeto esattamente come ho fatto con tutti gli altri, in questo forum scrivo riportando i miei dati reali: il mio titolo è uno di questi. E non l'ho mai usato per sostenere le mie idee: mi sono sempre basato su fatti e logica.
Qualche giorno fa gli inquilini dl piano sotto a quello nel quale vive una mia cara amica sono andati via, al posto loro e' arrivata una famiglia (non dico di dove per non essere tacciato di campanilismo),
Fallo pure invece: m'interessa capire cosa pensi della gente che proviene da determinati luoghi, come traspare da ciò che hai scritto.
E' questione di gusto, pertanto assolutamente insindacabile.
Se è insindacabile, non capisco il motivo delle tue considerazioni: è una contraddizione in termini.
La mia memoria a lungo termine non e' poi cosi' male, mi sembra di aver ricordato vagonate di cose, che per quanto tu ritenesi errate, ho dimostrato giuste e corrette.
Finora l'unica cosa che hai dimostrato è l'assoluta inconsistenza di tutto ciò che hai scritto e il completo distacco con la realtà...
Vogliamo parlare del 68000 a 16 bit? E che dire del 68000 a 8Mhz che aveva capacità paragonabili al 486 a 66Mhz? E questo è soltanto l'inizio: la lista è molto lunga...
Punti di vista pure qui.
Sui dati tecnici non ci sono punti di vista che tengono: contano i fatti. E i fatti dimostrano ampiamente, con tanto di documentazione verificabile da chiunque, la falsità delle tue affermazioni.
Ciao ciao Dotto'!!
Anche questo è una questione di gusti "insindacabili", eh? :rolleyes:
P.S. L'atari non ha mai avuto la mancanza della tecnologia necessaria a sovrastare l'Amiga (leggasi E-ST progetto dal quale nacque il meno potente ST-E ma con due blitter e due shifter http://www.maedicke.de/atari/hardware/est.htm, Sparrow FX.1 ed ATW800), ma scelse sempre il giosto punto d'equilibrio, tra prezzo, prestazioni, affidabilita' ed armonia. (leggiti le due caratteristiche riportate dell E-ST) (l'ATW800 fu prodotto in piccola serie, quasi prototipale e distribuito in enti come centri di ricerca, nulla c'entrava con le macchine in questione, e' solo un esempio della tecnologia che quella casa poteva concepire e realizzare).
Coi se e coi ma non dimostri niente. Qui stiamo parlando di macchine reali, regolarmente commercializzate, e ciò che è evidente è l'assoluta mediocrità delle macchine Atari rispetto alle concorrenti offerte dalla Commodore.

Citando prototipi e macchine rimaste in laboratorio, non fai altro che aggrapparti a sogni e fantasie di presunta superiorità che non hanno alcuna aderenza con la realtà.

Anch'io posso riportarti http://www.thule.no/haynie/research/nyx/docs/AAA.pdf le specifiche dei prototipi dei successori degli Amiga, e come vedi si tratta di un documento riservatissimo (ai tempi) della Commodore, scritto nel 1993 (Amiga 1200 e 4000 era appena usciti) da Dave Haynie, suo ingegnere leader.
Ne possiamo parlare quanto vogliamo: vedere che già all'epoca era dotato di vram dual ported che arrivava a 250MB/s di banda, grafica truecolor a 24 bit in salse varie (fino a 16 bitplane: una meraviglia per realizzare giochi, e inoltre modalità video compresse), supporto all'acquisizione audio e video, sprite larghi 128 bit, copper a 32 bit, blitter a 32 bit (e fino a 9 volte più veloce), 8 canali a 16 bit e fino a 64Khz con controllo volume a 12 bit (con la possibilità di scegliere il canale sinistro o destro per l'output), controller per floppy avanzato (e possibilità di pilotare anche floptical da 20MB, lettore CD, DAT), ecc. ecc. ecc.
Ma si tratterà sempre e soltanto di prototipi: roba che non è mai arrivata nelle mani della gente comune, anche se non su carta, ma che è realmente esistita (nel 1994 Dave Haynie aveva realizzato alcuni protopiti con 68040, chipset AAA e, ti farà piacere saperlo, anche un DSP Motorola 56001).

Io preferisco lasciarli perdere e mantenermi coi piedi per terra, con ciò che è stato realmente commercializzato.

Tra l'altro proprio in questo documento, fra i varii e interessanti dati, ecco cosa riporta Dave:

Function Paula Mary
Dynamic range 15 bits 16 bits
Questo per rispondere a proposito del discorso di cui sopra sulla dinamica...
Lo ha fatto anche lui senza conoscermi
Quando?
e comuqnue era solo una battuta..
Che potevi anche risparmiarti...
Un insulto e' fatto in ben altro modo.
Come questo:

"Forse non sai ancora leggere ora che ci penso;"

[MadRat]

Poi analiziamo meglio .. ma ne hai di tempo da perdere :D

Dovresti solo spiegarmi per quale motivo accelerasse pure la musica (pure su ST), se il campio di HZ coinvolgeva solo l'aggiornamento video. Comuqne su ST accelerava tutto, pure il CAD3D.

[cdimauro]

Poi analiziamo meglio ..
OK
ma ne hai di tempo da perdere :D
Veramente non ne ho proprio: se non sapessi che i mie post sono letti con interesse e possono servire a qualcuno, nemmeno scriverei... ;)
Dovresti solo spiegarmi per quale motivo accelerasse pure la musica (pure su ST), se il campio di HZ coinvolgeva solo l'aggiornamento video. Comuqne su ST accelerava tutto, pure il CAD3D.
Perché i giochi e i player utilizzano la generazione di un fotogramma come "base di lavoro". Mi spiego meglio facendoti vedere macroscopicamente come funzionava un gioco (2D chiaramente: per il 3D vale quanto ho scritto prima).

1) Dopo che il chip video ha finito di visualizzare l'ultima riga visibile del frame corrente, il controllo "passa" alle routine di gestione del gioco (che dovrà "elaborare" il frame successivo);
2) vengono "letti" tastiera e joystick per acquisire gli input dell'utente;
3) in accordo con ciò, vengono modificate le variabili associate al giocatore, ai nemici, ecc., compreso eventuali campioni da riprodurre a causa di questi cambiamenti (es: si verifica un'esplosione -> debbo riproddure un "BOOOOM!");
4) viene richiamato il player, che "aggiorna" la musica;
5) viene aggiornato lo schermo.

I punti 4 e 5 possono anche essere scambiati.

Tutto ciò si ripete per OGNI fotogramma, quindi 50 volte al secondo (sto supponendo che il gioco completi tutte le operazioni nel tempo a disposizione per un fotogramma) nel caso del sistema PAL, 60 per quello NTSC.

Da ciò si vede che il player verrà richiamato 50 volte al secondo nel primo caso e 60 nel secondo caso, ed è questo il motivo per cui la musica verrà eseguita più velocemente, forzando un gioco a lavorare a 60hz anziché ai 50hz per cui è stato progettato. In pratica il player aggiorna il suo stato più volte di quelle che dovrebbe.
E' chiaro che i campioni vengono eseguiti sempre alla stessa frequenza (es: se ho campionato un "BOOOM!" a 13Khz, continuerà a essere riprodotto allo stesso identico modo, perché è il chip sonoro che provvede a caricare via via i sample rispettando la frequenza impostata, e non il player, che gliel'ha semplicemente "ordinato").
In particolare, i famosi MOD (ProTracker, Oktalyzer, ecc.) utilizzano proprio i frame come temporizzazione della musica. Ad esempio, se imposto a 5 questo valore, vuol dire che il player aspetterà 5 frame prima di leggere i dati dei 4 (o 8) canali, per aggiornarne lo stato. Questo vuol dire che, a 50hz, l'aggiornamento di stato verrà effettuato 10 volte al secondo; forzando i 60hz, ciò avverebbe invece 12 volte al secondo, che è errato.

Spero di essere stato chiaro.

[MadRat]

OK

Veramente non ne ho proprio: se non sapessi che i mie post sono letti con interesse e possono servire a qualcuno, nemmeno scriverei... ;)

Perché i giochi e i player utilizzano la generazione di un fotogramma come "base di lavoro". Mi spiego meglio facendoti vedere macroscopicamente come funzionava un gioco (2D chiaramente: per il 3D vale quanto ho scritto prima).

1) Dopo che il chip video ha finito di visualizzare l'ultima riga visibile del frame corrente, il controllo "passa" alle routine di gestione del gioco (che dovrà "elaborare" il frame successivo);
2) vengono "letti" tastiera e joystick per acquisire gli input dell'utente;
3) in accordo con ciò, vengono modificate le variabili associate al giocatore, ai nemici, ecc., compreso eventuali campioni da riprodurre a causa di questi cambiamenti (es: si verifica un'esplosione -> debbo riproddure un "BOOOOM!");
4) viene richiamato il player, che "aggiorna" la musica;
5) viene aggiornato lo schermo.

I punti 4 e 5 possono anche essere scambiati.

Tutto ciò si ripete per OGNI fotogramma, quindi 50 volte al secondo (sto supponendo che il gioco completi tutte le operazioni nel tempo a disposizione per un fotogramma) nel caso del sistema PAL, 60 per quello NTSC.

Da ciò si vede che il player verrà richiamato 50 volte al secondo nel primo caso e 60 nel secondo caso, ed è questo il motivo per cui la musica verrà eseguita più velocemente, forzando un gioco a lavorare a 60hz anziché ai 50hz per cui è stato progettato. In pratica il player aggiorna il suo stato più volte di quelle che dovrebbe.
E' chiaro che i campioni vengono eseguiti sempre alla stessa frequenza (es: se ho campionato un "BOOOM!" a 13Khz, continuerà a essere riprodotto allo stesso identico modo, perché è il chip sonoro che provvede a caricare via via i sample rispettando la frequenza impostata, e non il player, che gliel'ha semplicemente "ordinato").
In particolare, i famosi MOD (ProTracker, Oktalyzer, ecc.) utilizzano proprio i frame come temporizzazione della musica. Ad esempio, se imposto a 5 questo valore, vuol dire che il player aspetterà 5 frame prima di leggere i dati dei 4 (o 8) canali, per aggiornarne lo stato. Questo vuol dire che, a 50hz, l'aggiornamento di stato verrà effettuato 10 volte al secondo; forzando i 60hz, ciò avverebbe invece 12 volte al secondo, che è errato.

Spero di essere stato chiaro.


C'e' da dire inoltre che questo potrebbe portare ad una saturazione delle risorse HW, ma questo non ha mai dato problemi, almeno sull'ST, mentre con giochi "stressanti" (e dato l'HW da te additato come "scarso"), i 60hz avrebbe dovuto dar sempre luogo a fenomeni ti sovraccarico, come scatti o salti d'immagine e/o audio. Cosa che non avveniva mai.
Tenendo presente anche che il cambio di Hz era molto utilizzato anche nelle demo, (che veramente chiedevano il massimo al computer).

Quello che dici non fa una piega, ma spiega solo una parte degli effetti. Se non erro la cosa avviene anche con alcune console e queste, oramai lavorano quasi solo in 3d. Tuttavia non sono un fanatico di queste, non parlo per esperienza.
Mi informero' al riguardo.

[cdimauro]

C'e' da dire inoltre che questo potrebbe portare ad una saturazione delle risorse HW, ma questo non ha mai dato problemi, almeno sull'ST, mentre con giochi "stressanti" (e dato l'HW da te additato come "scarso"), i 60hz avrebbe dovuto dar sempre luogo a fenomeni ti sovraccarico, come scatti o salti d'immagine e/o audio. Cosa che non avveniva mai.
Tenendo presente anche che il cambio di Hz era molto utilizzato anche nelle demo, (che veramente chiedevano il massimo al computer).
Vuol dire che il computer non veniva spremuto al massimo.

Ti faccio un esempio pratico. Supponiamo che lo schermo sia di 320x200 pixel. Con lo schermo PAL ogni fotogramma è composto da 312,5 righe di raster, mentre per quello NTSC si tratta di 262,5.

Ora, supponiano che il mio gioco / demo / quello che vuoi è stato scritto per girare in sistemi PAL a 50Hz, e che richieda mediamente 250 righe di raster per aggiornare la grafica, e 30 per il sonoro: 250 + 30 = 280, e mi mantengono tranquillamente sotto le 312,5 righe di raster disponibili.

Se forzo il sistema a lavorare in NTSC, a 60hz, sta tranquillo che ti andrà sempre e comunque a scatti, perché non c'è abbastanza tempo per portare a termine tutto il lavoro.

Questa è pura e semplice matematica.

Non ho neppure tenuto conto del fatto che, quando il sistema video spedisce allo schermo le righe visibili, consuma banda di memoria e quindi ne blocca accesso. In soldoni, questo vuol dire che quando il chip video prende i dati da visualizzare, limiterà l'accesso alla CPU, che perderà molto più tempo. Col PAL abbiamo 312,5 (totali) - 200 (visibili) = 112,5 righe (non visibili) durante le quali la CPU girerà a pieno regime, non dovendo condividere l'accesso alla memoria video (il chip video ha sempre la priorità sulla CPU). Con l'NTSC avremmo invece 262,5 - 200 = 62,5 righe "a piena velocità" per la CPU.
Quello che dici non fa una piega, ma spiega solo una parte degli effetti. Se non erro la cosa avviene anche con alcune console e queste, oramai lavorano quasi solo in 3d. Tuttavia non sono un fanatico di queste, non parlo per esperienza.
Mi informero' al riguardo.
Col 3D il discorso è diverso, come ti ho spiegato: per la generazione di un fotogramma il tempo non è fisso, ma variabile, per cui si adotta una politica diversa.

P.S. I giochi che ho sviluppato per Amiga a 60Hz non avrebbero mai funzionato, anche riducendo lo schermo a 320x200 dell'NTSC anziché i 320x256 del PAL, perché la grafica da muovere rimane sempre la stessa.

[shodan]

Non e' una gefforce3 con uno shader aggiunto?? o qualcosa di estrememente simile.

E' qualcosa di simile, diciamo che sono anche loro cugini stretti, ma si programmano in maniera differente, ed hanno profili prestazionali molto differenti.



Guarda, ho lavorato sia su xbox sia su PC e la GPU dell'xbox si programma in maniera quasi totalmente differente, si usano proprio algoritmi e ottimizzazioni diverse, spesso agl'antipodi.

Le differenze principali sono:
- la memoria condivisa su xbox
- pixel shader molto potenziati su xbox

Ciao fek,
come mai parli di pixel shader molto potenziati?
L'NV2A dell'Xbox aveva delle differenze anche nei pixel shader rispetto alla versione PC (NV20)?
Mi pare di ricordare che l'unica differenza di rilievo (a parte il fatto che l'NV2A faceva anche da chipset) fosse la 2° unità vertex shader... :confused:

Sbaglio (probabile! :D)?

[fek]

Ciao fek,
come mai parli di pixel shader molto potenziati?
L'NV2A dell'Xbox aveva delle differenze anche nei pixel shader rispetto alla versione PC (NV20)?
Mi pare di ricordare che l'unica differenza di rilievo (a parte il fatto che l'NV2A faceva anche da chipset) fosse la 2° unità vertex shader... :confused:

Sbaglio (probabile! :D)?

l'NV2A ha alcune unita' in piu' nei register combiner (i pixel shader di allora) che si traducono in alcune istruzioni in piu.

[shodan]

l'NV2A ha alcune unita' in piu' nei register combiner (i pixel shader di allora) che si traducono in alcune istruzioni in piu.

Quindi l'unità di shading è più avanzata anche di quella di NV25, giusto?

Un'altra domanda: le capacitò di shading sono cambiate passando da NV10 a NV15? Nvidia dice ufficilamente che il motore NSR è stato implementato a partire da NV15 però, dato che in ultimo non era che un'estensione ai register combiners, mi chiedevo se non fosse supportato anche da NV10.

Scusate l'OT, ma è un dubbio che mi porto dietro da parecchio tempo! ;)

Ciao grazie! :)

[MadRat]

Vuol dire che il computer non veniva spremuto al massimo.

Ti faccio un esempio pratico. Supponiamo che lo schermo sia di 320x200 pixel. Con lo schermo PAL ..................... non dovendo condividere l'accesso alla memoria video (il chip video ha sempre la priorità sulla CPU). Con l'NTSC avremmo invece 262,5 - 200 = 62,5 righe "a piena velocità" per la CPU.

Col 3D il discorso è diverso, come ti ho spiegato: per la generazione di un fotogramma il tempo non è fisso, ma variabile, per cui si adotta una politica diversa.

P.S. I giochi che ho sviluppato per Amiga a 60Hz non avrebbero mai funzionato, anche riducendo lo schermo a 320x200 dell'NTSC anziché i 320x256 del PAL, perché la grafica da muovere rimane sempre la stessa.

Va bene, mi hai rispiegato per la seconda volta una cosa che per altro gia' sapevo (escludendo il fatto della musica, visto che credevo piu' indipendente il Paula), ma non mi hai spiegato perche' sull'ST questo non dava MAI luogo a scatti ed il 3D ne traeva giovamento.. Onestamente al riguardo ho cultura parziale e non riesco a trovare nulla e nessuno che lo tratti in maniera decente in rete.

Quello che ritengo probabile invece, e' che tutto fosse scritto per sistemi a 60Hz (perche' la portabilita' contraria non e' possibile) e poi, quando fatto girare a 50Hz, ne risentiva tutta la macchina.

Grazie comunque.

Ora ti rispondo pure a tutto il resto (che mi ha fatto innervosire :mad: ).. Pronto?? :D

[MadRat]

Non è servito a molto, allora: Atari Italia ha venduto circa 10 mila ST dall'85 all'88, mentre Commodore Italia ha venduto circa 14.200 Amiga 1000 fra luglio e dicembre 1986... :asd:


Non ho i dati a portata di mano, poi vedremo, ma non e' certo l'Italia il paese nel quale l'Atari ha venduto in grandi volumetrie.


Non è questione di provare o meno: hai presente come funziona un s.o. monotask e uno preemptive? Mi sembra proprio di no. Hanno costi computazionali diversi, e il secondo ha uno scheduler che richiede un certo tempo di esecuzione.
Gli scheduler sono uno degli argomenti più trattati della storia dell'informatica: ci sarebbe stato ben poco da studiare e discutere se fossero stati "a costo zero", come vorresti far credere tu.


Non ho mai detto costo zero, dovresti farmi vedere dove.. Ho solo detto che dovresti provarlo per renderti conto di come andasse (a scapito di alcuni problemi di compatibilita').



Falso, perché ho riportato la storia dei modelli ST e Amiga a partire dalla loro uscita, e non soltanto quelli relativi al periodo della morte di Atari Italia.


Invece e' vero, perche' solo l'ultimo caso mostra prezzi a favore dell'Amiga. Questo solo dovuto al fatto che L'Atari Italia non c'era piu'.



E si vedeva proprio: Marble Madness, titolo della Atari Arcade che ha sbancato in sala giochi, per Amiga è stato convertito alla perfezione (e non solo girava col s.o., ma usava le API di AmigaOS per sprite, grafica e sonoro); la versione ST non era assolutamente all'altezza dal lato grafico, e molto peggio da quello sonoro.
Space Harrier della SEGA ha finalmente avuto giustizia proprio con la versione Amiga, che vantava overscan, grafica fedele all'originale (ricchissima di sfumature) e sonoro superlativo.
Idem per Super HangOn, Silkworm (capolavoro assoluto all'epoca), Ghosts'n'Goblins, ecc. (la lista è lunga).
Anche senza scomodare le conversioni da sala giochi, il verdetto era lo stesso: roba come Defender of the Crown (ancora oggi un titolo bellissimo), SDI, The Pawn, Turrican, ecc. sono rimasti nel mito non per le sbiadite versioni ST, ma per quelle maestose Amiga...


Per la gente come me che prediligeva i giochi in 3d invece, tutta questa inferiorita' non c'e' mai stata. Sull'Amiga erano notevolmente piu' lenti. Si prenda Interphase (nonostante l'audio campionato), conqueror, resolution 101, StuntCar, Robocop, Tower of Babel .. Va be', piu' o meno tutti..
In ogni caso anche giochi 2D come Ghouls'n Ghost, Rainbow Island, Onslaught, 7 gates of jambala e molti altri, non avevano assolutamente nulla da invidiare alla versione Amiga. Programmati da chi sapeva usare entrambi gli HW.
E ti diro' di piu', anche l'audio fornito dall'YM2149, se usato con tracker appositi, dava soddisfazioni non indifferenti. Molti di questi davano la possibilita' di superare il limite delle onde quadre, proponendo anche delle onde a dente di sega e sega inversa, nonché delle triangolari. A tutto questo aggiungiamoci un controllo adsr evoluto per il volume, controllato anche tramite LFO seguenti le medesime forme, ma totalmente indipendenti, una modulazione FM!! ed una sorta di modulatore ad anello!! ed ecco fatto che si ottiene un sintetizzatore a tre canali (i sintetizzatori che hanno fatto la storia sono perlopiù monofonici) piu' uno PCM a 22Khz. Il tutto, musicalmente parlando, non ha nulla e sottolineo nulla da invidiare alla sterile tecnologia PCM supportata dall'Amiga (e non parlo di STE!!). E non venirmi a parlare di CPU load, perche' hai ampiamente dimostrato di non capirci nulla, siamo sempre su carichi bassissimi come vedrai di seguito.


Il tempo per scrivere lo trovi, e non mi sembra poco a giudicare dalla lunghezza dei messaggi...


Hai di nuovo eluso la domanda. Come mai I recensori del tempo (ed anche dello stesso articolo portato da te), dicevano che i giochi 3d per ST, fossero sempre piu' fluidi rispetto alle controparti Amiga??


Molto semplice: perché ....
Nel caso di macchine NTSC, il clock del processore era generato da quello generale, che era di 28.563.864 cicli di clock, diviso 4: 7.140.966 (7,14Mhz. Prima m'era scappato un 7,16Mhz).
Nel caso di macchine PAL, il clock del processore era generato da quello generale, che era di 28.375.000 cicli di clock, diviso 4: 7.093.750 (7,09Mhz).


Sono esterrefatto. Tuttavia temo che dovro' riproporti la domanda, visto che non l'hai capita o meglio, hai dato una risposta in stile microsoft: “perfettamente attinente alla domanda, assolutamente inappuntabile, che tuttavia non c'enta nulla con quanto richiesto e non spieghi un bel nulla".
Perche' la versione PAL aveva frequenze differenti da quella NTSC??
Dai che arriviamo ad una soluzione.
L'ST era sempre a 8..


Perché far girare il processore a un clock inferiore (il 68000 era la versione a 8Mhz)? Perché avendo il clock sincronizzato con quello dei chip custom, non si andava incontro a cicli di wait state quando si accedeva alla memoria condivisa (come invece avveniva con altre macchine, come l'ST).


Praticamente quel che ho detto io, i chip custom da una parte erano uno sprint, dall'altra erano una strozzatura.
Sull'ST era molto semplice, infatti, installare delle CPU a frequenze maggiori (12mhz in genere, per ragioni di costo) e la cpu e' molto piu' libera.
(Si' era ad 8Mhz anche quello dell'Amiga, dovresti saperlo, la sigla era MC68000P8 esattamente come quello dell'ST e del MAC. Non e' stato mai prodotto a 7,014Mhz, c'era anche a 4, 6, 10, 12, 12,5, 16 ecc.. ma niente numeri dispari.)


Dipende dal tipo di applicazioni: è chiaro che quelle di "calcolo puro" ne risentivano, ci mancherebbe. Negarlo sarebbe da stupidi. Però, coi giochi o in generale con applicazioni che facevano largo uso dei chip custom, le cose stavano diversamente, come s'è visto poi.


Appunto dipende dall'uso che se ne faceva. E sul 3D pesava eccome. Si vedeva tutta la leggerezza e sinergia del progetto e non solo quella percentuale di clock.


I cicli di clock sprecati per ottenere l'overscan non si possono certo nascondere. Nulla si crea e nulla si distrugge: mancano e basta.


Non ho mai detto che fosse implementabile tanto facilmente come su Amiga, sia mai, ti ho solo detto che non e' vero quanto da te sostenuto precedentemente e cioe', che sull'ST non vi fosse overscan. C'era anche un programma di grafica che lo utilizzava, ma non ricordo il nome, senza contare gli innumerevoli giochi che posizionavano il pannello di controllo fuori schermo.



E' chiaro che i programmatori dovevano ridimensionare qualche altra cosa (es: meno oggetti grafici a video, o di dimensione più ridotta, ecc.).


Il vero problema dell'ST (ed anche nell'STE) nell'ambito dei giochi in bitmap consisteva proprio nell'assenza di un supporto HW per gli sprite, anche se il blitter poteva sollevare da questo compito la CPU. Giochi come Xenon2 (che non usava l'STE) o Wings of death, dimostravano come si potessero abbattere certi limiti.


Infatti la fatica non sta affatto qui. Fin qui, anzi, è esattamente ciò che avviene con i 4 canali dell'Amiga.

Infatti la fatica non sta affatto qui. Fin qui, anzi, è esattamente ciò che avviene con l'Amiga per i MOD.
Sostanzialmente è ciò che faceva il mio player di moduli a ogni frame: andare a recuperare le 4 note (o comandi) da suonare (o eseguire), e impostare i parametri dei 4 canali DMA in accordo (uno solo, "stereo", nel caso degli STE).

Disivoltura che richiedeva parecchio tempo di calcolo, invece. Perché il problema non è in quello che hai scritto finora: ciò che faceva perdere parecchio tempo era la miscelazione dei 4 (oppure 8) canali negli unici 2 canali disponibili nell'STE.

E neanche di qualità: con 4 bit per l'ampiezza del segnale non si poteva fare nulla di più del SID del C64.


L'ST suonava nei giochi a 8 bit e non a 4.. dovresti informarti un po' meglio prima. Non disponendo di convertitori DA, usava i 3 controllori di volume a 4 bit dell'YM2149 che potevano lavorare insieme dato che erano unificati e non separati.


Qui c'e' qualcosa comunque, anche se non si tratta di giochi.
http://home.earthlink.net/~chhome/tcbtracker.html

Si parla del 20% di CPU di un tracker (non un player) su un ST e non STE. Qui fa uso di un unico canale (l'ST era mono) suddiviso in 4.

Ti ricordo che si parla di ST e non STE.

Aggiungerei inoltre che il DBE tracker usa 32 (TRENTADUE) canali su un STE. Questo significa che stando ai tuoi calcoli ESATTISSIMI perche' tu analizzi il codice (=D). Quel programma utilizza il .. 240% (DUECENTOQUARANTAPERCENTO) della CPU.

http://atari-ste.anvil-soft.com/html/archivapps.htm
Qui poi in elenco c'e' l'audiosculpture, non c'e' scritto molto purtroppo ma lo definisce cosi':
“4 channel DMA sound, supports 16bit modification”.
Dunque stando ai tuoi calcoli l'audio dell'STE era a 8+16 bit.. Bella 'sta cosa e pensare che non la sapevo mica!!


Bisogna vedere come li usavano i due canali PCM: è probabile che usassero i due canali così com'era, senza effettuare alcuna miscelazione. In questo modo era possibile mantenere un'eccellente compatibilità anche coi precedenti ST, che usavano soltanto l'YM2149.


L'STE aveva anche L'ym2149, non vedo i problemi di compatibilita' in cosa sussistano.


Questo come fai a dirlo? Per Amiga avevo realizzato un player di moduli a 8 canali molto veloce, che contavo usare in qualche futuro gioco meno esoso dal punto di vista grafico (avventure, RPG, ecc.)

Tra l'altro i player di moduli a 4 canali che avevo scritto si serviva del Copper (il coprocessore grafico) per programmare i registri audio, svincolando ancora di più la CPU: ad oggi non mi risulta che altri abbiano fatto la stessa cosa... ;)


Io intendevo in ambito Atari, per fortuna ci fu chi lo programmo' molto meglio di come avresti saputo fare tu. Visto che non lo conosci affatto.


I dati sono quelli, e sono scritti nero su bianco: puoi soltanto fartene una ragione.


Si e' visto proprio!! nero su bianco. ; )


Può darsi che fossero un po' più leggeri, ma in ogni per riprodurre 4 o 8 canali dovevano per forza di cose miscelarli, riducendoli ai soli 2 disponibili. Per quanto buona fosse la routine di miscelazione (era possibile usare dei trucchetti), il tempo di calcolo era comunque consistente (e inevitabile).


Infatti si parla proprio del 30% della cpu .. nemmeno con l'ST sotto traker e non player (dunque con tanto di grafica) e' vera sta cosa, figuriamoci con l'STE in DMA!!


Il che dimostra che, in ogni caso, era necessario effettuare dei calcoli abbastanza pesanti a carico della CPU.


Non hai dimostrato nulla, hai solo fatto illazioni, sparando carichi d'utilizzo della CPU completamente casuali. L'unica cosa che hai dimostrato, e' di non conoscere la macchina della quale parli.

**Some of the Amiga editors and players have been ported to the Atari.
Probably the most popular is the NoiseTracker which can be found
on many ftp sites, among them RUS in /pub/soft/atari/sound/players.
You can also retrieve the sources for the NoiseTracker there and a
NoiseTracker Compiler. This program converts the NST modules to
SEGM files. These can then be played on any Atari with almost no
CPU usage. The NoiseTracker package contains the editor and a re-
play program.**
Viene da qui “ http://archive.cs.uu.nl/pub/MIDI/DOC/Music-Formats


E qui “This version includes the version 3 of my Paula emulators
; It's totally rewritten and by combining several tricks
; I'm manage to do a 50kHz(!!!) replay routine that only
; takes around 30% and I'm not using any cheats like over-
; sample. This version is indeed four times faster than my
; first replay routine and I hope all you hackers out there
; will like my routine and would like to contact me”

Magari il tuo 30% lo hai pescato da qui, dal file che mi hai fatto scaricare. Ovviamente direi che non sia male per un Tracker con emulazione di un chip all'interno ed esecuzione a 50Khz!! Aggiungerei.. APPERO'!!



Direi proprio di no, da quanto ho scritto finora, e non mi hai ancora smentito.
Infatti ti ho chiesto di analizzare i sorgenti di ALTRI player, oltre al ProTracker, ma sto ancora aspettando...


Sì sì, tu analizza, analizza.. fossi almeno in grado di farlo.


No, c'era la 1280x512 per il PAL e la 1280x400 per l'NTSC. Con l'overscan si arrivava a 1440x576 e 1440x480 rispettivamente.


Io ho detto 1280*960 e tu hai detto che la ha anche l'Amiga ed a 4 colori.. Falso, strano, lo conosci cosi' bene che io lo so meglio di te.. Portando le frequenze in basso come l'Amiga, si possono ottenere pagine grafiche piu' ampie, mi pare ovvio.


Comunque dimentichi che già ai tempi dell'Amiga 1000 era possibile visualizzare schermate a 1004x1024 pixel a 4 colori con uno speciale monitor. Per maggiori informazioni e per vedere il mostriciattolo in azione, recuperare i numeri di MC MicroComputer fra giugno e settembre 1986.


Infatti fu usatissima, quanto il monitor “speciale”, forse sara' perche' il monitor si arroventava troppo viaggiando a 15Hz!! (QUINDICI)!! hahahaha ora mi rotolo in terra.
Se e' per questo con un multiscan particolare poteva arrivare anche a 640*960 (INTERL), peccato che il monitor costasse piu' del computer stesso. :D

Mentre il monitor bianco (carta) e nero (profondo) dell'Arati, e' stato venduto a tonnellate ed all'atto pratico, l'alta risoluzione dell'ST fu usata quanto la bassa (in ambito differente, ovviamente).



E' un'affermazione che manca di logica, invece: 4 colori sono comunque molto più utili di 2. Al più, se sei così attaccato al monocromatico, ne usi soltanto due. Ma passare da 2 colori a 4 era impossibile per l'ST...


Sull'Amiga non potevi avere 1280*960, ma solo strambe risoluzioni video, che non erano meglio della tanto criticata (da quelli come te) “media” dell'ST.
Non ci hai mai lavorato per ore davanti, non puoi capire cosa significhi usare quel monitor. Ci rimettevi gli occhi con l'interlacciata e con il costo del deinterlacciatore, ci prendevi una schedina video per ST da 900/1000 punti.


Falso. Proprio l'A3000 introdusse lo Zorro III come espansione, con indirizzamento della memoria 32 bit, portando il limite della memoria installabile a poco più di 2GB...


Vogliamo fare anche un elenco delle possibilita' via scheda d'espansione?? Mah!! E poi TT a 4Gb ne ho visti a palate e non a 2.. nemmeno a 32bit.. bella storia.


Per forza: i TT sono arrivati più di un anno dopo l'Amiga 3000. Dopo il 3000 la Commodore ha lavorato al 4000, che integrava un ben più potente 68040, che Atari non ha potuto usare per gli ST (è defunta prima).


E questo dove lo hai letto?? su topolino dell'87??
Sono entrambi del novanta.
http://www.crowl.org/Lawrence/history/computer_list

Posso postartene altri se ne hai bisogno.

Il falcon avrebbe dovuto integrare proprio il 68040 con 2 56001, che poi diventarono 030 con un solo DSP per ragioni economiche. Dunque ci e' arrivata eccome, dovresti sapere che fu presentato nell'89 (OTTANTANOVE) il 68040 (SESSANTOTTOMILAZEROQUARANTA).


Mi fai qualche esempio?


Certo, il TT era una macchina da CAD, per grandi calcoli a risoluzioni alte e non stancanti, L'A3000 era votata alla grafica per il piccolo schermo. (ovviamente parlo di macchine lisce, senza schede prodotte da terzi).



Sì, ma non era un computer "di classe ST"


Ho parlato di tecnologia disponibile prodotta ed usata (gia' dall'87 -OTTANTASETTE-) (c'e' chi dice 88, ma sbaglia), dimostrando cosi' che il resto sono solo scelte.. peccato non ci fossi stato tu tra loro a consigliarli per il meglio.


No, hai parlato di risoluzione interlacciata e ti ho detto che esistevano i deinterlacciatori (per Amiga 1000, 500 e 2000) E (congiunzione) che l'Amiga 3000 ne aveva uno di serie integrato.


Dunque per Amiga 500 serviva HW separato (comunque refresh ridicoli) e di queste macchine parlavamo, tu hai detto che sull'A3000 era di serie ed io tu ho risposto che sul TT (rimanendo fuori tema) era di serie la 1280*960 non interlacciata.
P.S. Il mio falcon con l'ausilio delle interlacciate, puo' raddoppiare le proprie risoluzioni video.. E' solo un sotterfugio. Il TT gestiva una pagina intera e vera a quella risoluzione e pure con un ottimo refresh.



Come sopra, stavamo parlando di professionisti che avevano bisogno di lavorare con risoluzioni video elevate. Al 99% degli utenti non interessavano né i deinterlacciatori né i monitor ad alta persistenza.


Ho parlato di professionisti perche' il mercato dell'ST come (specialmente) quello del TT era composto da professionisti in buona misura, mercato che e' sopravvissuto per un buon lasso di tempo a quello ludico. Io personalmente ho suonato e scritto in moltissimi studi che fino al 98 ed oltre, si affidavano tranquillamente al Falcon.
Stando percio' alle tue deduzioni (corrette), la meta' delle risoluzioni dell'Amiga, erano totalmente inutili al 99% degli utenti.



L'hai citato come innovazione introdotta con gli STE, e non è così. Punto.


No, l'ho citato precedentemente come innovazione introdotta nel mega ST, ma che non ho contato a livello ludico in quanto tale macchina era destinata ad un'altra tipologia di pubblico. (quanto non mi piace ripetere le cose due volte). PUNTO.


Infatti basta riconoscerli: non ho una memoria perfetta, e non posso ricordare tutto, ma certo sono messo MOLTO meglio di te, visto che trovo puntalmente riscontro a ciò che dico (smentendo le tue affermazioni).


Ma sì, MEGLISSIMO direi!! =D Stai accumulando una serie di strafalcioni dovuti alla tua spavalderia mal coadiuvata dalla tua scarsa conoscenza dell'argomento.


Ti stai arrampicando sugli specchi, perché l'ho già fatto: ho postato parecchi link a pagine o documenti in cui sono descritte non solo le caratteristiche tecniche, ma anche COME SI PROGRAMMA l'hardware degli STE. Si parla di UN canale DMA in grado di prelevare i dati per DUE canali PCM.
Ora, se mi fai vedere come si programma un STE utilizzando 4 o 8 canali SENZA L'USO DELLA CPU PER MISCELARLI, non avrò difficoltà ad ammetterlo pubblicamente. L'onere della controprova sta a te: niente "ricordi", ma FATTI.


Nulla.. proprio nulla, non ci capisci nulla ZERO.
Non serve miscelare due calali, non avviene alcuna miscelazione!! NESSUNA. L'STE ha due DAC capaci di convertire segnali ad 8bit a 50Khz. Se gli si richiede di riprodurre DUE segnali ad 8bit ciascuno, questi ne convertiranno uno per ogni ciclo, ovvero un Hz a suono, dedicando gli interi 8bit Ad OGNI canale riprodotto. La miscelazione avverrebbe SOLO qualora si volessero riprodurre due suoni contemporaneamente passando per lo stesso convertitore alla massima frequenza d'elaborazione, Dunque 50 per L'STE e 28 per Amiga. (Ventotto, non ventinove, non conosci bene nemmeno l'Amiga che hai programmato tanto.).


:mc: L'Amiga arriva tranquillamente a 4 canali a 56Khz e senza ricorre a nessuna miscelazione, come ti ho già spiegato. Tutto il resto sono chiacchiere di chi non porta NESSUN FATTO a sostegno delle proprie tesi.
Ti stai arrampicando sugli specchi. DIMOSTRA OLTRE OGNI RAGIONEVOLE DUBBIO CHE CIO' CHE HO SCRITTO E' FALSO, PORTANDO DOCUMENTI TECNICI, SE CI RIESCI. Altrimenti è evidente che sei soltanto un troll che non ha nulla da fare se non quello di raccontare balle in un forum, pretendendo che altri gli credano, ma a raccontar balle sono bravi tutti...


L'Amiga possedeva 4 convertitori digitale/analogico a 28Khz L'uno, questi potevano eseguire suoni ad un MASSIMO di 28Khz!! Qualora si fossero voluti riprodurre suoni a 56Khz(che guarda caso e' il doppio di 28 e non 29), si doveva impegnare pesantemente il DMA, tanto da escludere alcune risoluzioni video ed appesantire notevolmente il computer. Nessuno gioco intatti usava tali frequenze, cosa fatta solo da qualche programmino. Poi dovrei reperire uno schema tecnico del Paula, per stabilire se i 56 Khz fossero veri o solo interni. Sull'ST (ST non STE) esistono dei programmi che suonano in PCM a 50Khz, ma non te li riporto in quanto altrettanto poco attendibili.
Magari era una sorta di oversampling.

Avendo invece DUE convertitori a 50 Khz, si poteva riprodurre del suono EFFETTIVAMENTE a 50 Khz.


Siamo scarsetti in matematica: dalle mie parti 2^14 fa 16384...
In questo caso il SEGNALE d'uscita dei 4 DAC dell'Amiga presenta 16384 livelli: è un segnale a 14 bit a tutti gli effetti, checché tu ne dica.


Vedi, ti offendi e poi non sai leggere veramente.. io ho detto 16384.. Il tuo 16384 e' piu' corretto del mio??
Comuqnue rimane la questione dei 14 bit. :sofico: Che bello, il mio computer e' capace di qualche miliardo di colori, sul pannello c'e' scritto 32bit =D, ma ne sto scoprendo di cose oggi!! =D
Allora sommiamo pure i bit di controlo del volume destinalti ai canali dell'STE (gestito dal DMA o dalla CPU che sia), compresi quelli dell'YM2149.
Qualcuno (pochi) dice che questo sia stato fatto, voglio proprio capire come si possano mescolare i bit del volume assieme a quelli dei DAC o usi i primi o i secondi.

In ogni caso, renderebbe il tutto inutilizzabile perche' a volumi fissi e troppo oneroso in termini di CPU/DMA. (qualora fosse possibile).

Non lo escludo completamente solo perche' il Pokey dell'Atari 800/400, poteva unificando a coppie i suoi canali, arrivare alla riproduzione a 16bit. Ma il Pkey non miscelava controlli d'ampiezza con bit di decodifica!!


E' completamente falso, come ti ho già detto: l'Amiga aveva 4 canali audio con frequenza massima di 29Khz SE PILOTATI DAL DMA (quindi SENZA alcun intervento della CPU), ma questo limite era superato usando la CPU, e ciò valeva PER TUTTI E 4 I CANALI. Anzi, si potevano raggiungere frequenze molto più elevate dei 56Khz (per tutti e 4 canali: lo ripeto perché a quanto pare ne hai bisogno).


Come ho gia' abbondantemente chiarito e documentato, esistono player trasparenti per la CPU anche per l'STE e mooolto leggeri per ST (e se solo usanti l'ym2149, assolutamente trasparenti).
Delle risoluzioni e frequenze ne abbiamo gia' parlato.
Ad ogni modo, l'Amiga dalla casa stessa (ed in praticamente tutte le schede tecniche) e dato per 4 canali a 8bit fino a 28Khz. Ci sara' un motivo.


Totalmente falso: il canale DMA trasportava i dati di DUE SOLI canali PCM, come ho ampiamente dimostrato. Tutto il resto sono soltante fantasie non surrogate da alcun fatto.


Seguiti a confondere i canali con i DAC, Il DMA poteva fornire dati per 50Khz (8bit) a ciascun DAC, che questi dati fossero di uno o due canali non cambia nulla di nulla. E poi la documentazione in nostro possesso, in ogni caso, non specifica assolutamente il numero di canali gestiti dal comparto DMA, ma solo il numero di convertitori finali. La tua abbondanza e' soggettiva, che va contro il dato oggettivo dell'esistenza di player quadrifonici a carico 0 per la CPU.
Sta di fatto, che come ti ho fatto vedere prima, su un normalissimo computer a 8Mhz, girava un tracker a 32 (TRENTADUE) tracce. (qui ti concedo un buon carico della CPU ;) )


Ma infatti io ho sempre parlato di canali, non di DAC: non mettermi in bocca parole che non detto.


Male, avresti dovuto parlare di entrambi.


Ed è falso, perché sono 2 i canali PCM pilotati dal DMA. Punto.


La documentazione da te fornita non dice assolutamente questo ed anche se lo dicesse, non corrisponderebbe a verita', come visto.


Anche questo è falso: il DMA degli STE pilotata soltanto due canali, e lo può fare fino a 50Khz senza alcun intervento della CPU.
Il fatto che sia possibile suonare soltanto 4 canali a 50Khz oppure 8 a 22Khz è dovuto "semplicemente" alla CPU, che non è abbastanza potente da poter miscelare 8 canali a 50Khz. Al DMA non frega niente di quanti canali sono stati miscelati nei due PCM di cui trasporta i dati: potrebbero essere anche 12, 16, 20, 32, ecc. Il problema è soltanto della CPU, che non ce la fa a miscelarli per mancanza di potenza di elaborazione.


Gia', forse avevi un ST un po' fiacchetto, perche' parrebbe che quelli degli altri ce la facessero. Ti hanno fregato dotto'!!


Stai soltanto cercando di rigirare la frittata...
Per un segnale i due parametri fondamentali sono frequenza e livelli di ampiezza: il primo è legato alle ottave raggiungibili, il secondo alla dinamica. Se hai delle informazioni (tecniche ovviamente) diverse, non hai che da documentare.


Le informazioni tecniche non sono mancate direi. Per il resto.. ti servirebbe orecchio e quello non te lo insegna nessuno.


Vedi sopra: ogni canale audio dell'Amiga è indipendente e pilotabile indifferentemente tramite DMA o CPU. Nel secondo caso, TUTTI E QUATTRO I CANALI potevano arrivare a 56Khz (e anche più).
Quanto all'utilizzo della CPU, si tratta di generare un solo interrupt per ogni riga di raster, e impostare la word (due byte) "mancante" per ogni canale. Diciamo che richede MOLTO MENO TEMPO rispetto a quello necessario per visualizzare 512 colori coi tuoi ST...


Diciamo che non sai programmare un ST. Sempre che tu non asserisca che i programmi da me citati non esistano o siano “finti”. :) Saresti capacissimo.
E' poi piantala con sta storia dei 4 a 56 Khz a costo ZERO. L'Amiga secondo la tua testa, poteva aumentare la frequenza a 56Khz (ed anche di piu'!!) per ogni canale a costo minimo, non e' affatto vero, pesava eccome. Voglio in ogni caso vedere proprio se fosse tecnicamente possibile. Mi faro' rimediare prossimamente il materiale tecnico da chi di dovere. Qualora i DAC fossero a 28 Khz, al massimo i 56 potevano essere emulati. Vedremo.
Considera anche pero', la memoria occupata da un suono a “14”bit e 56Khz (oltre al dispendio oneroso in termini di CPU/DMA), un Amiga standard poteva farci proprio pochino!!


Quello era l'UTILIZZO TIPICO. La disparità c'è tutta invece, perché CHI VOLEVA poteva attaccarci fino a 4 drive.


Piccole cazzate, pressoché inutili, che aumentavano il prezzo.. Siamo sempre lì.


I copiatori hardware c'erano anche per Amiga, ma in questo contesto non fanno testo: stiamo parlando delle macchine nude e crude che la gente si trovava per le mani.


Ho parlato piu' che di HW di un accessorio, visto il costo ridicolo e la componentistica interna praticamente assente. La versione per Amiga non era altrettanto veloce.


Appunto. Io ho riportato soltanto 82 tracce nei mie conti, perché erano quelle raggiungibili da tutti gli Amiga. La meccanica del mio 1200 arriva a 84 tracce, come pure quella di molti altri Amiga che ho testato; alcuni arrivavano soltanto a 83 tracce. Per sicurezza nei miei giochi utilizzavo soltanto 82 tracce.
Quanto ai 12 settori per traccia degli ST, è una cosa nuova per me: hai della documentazione in merito?


Sinceramente, puo' essere che mi ricordi male riguardo i 12 settori, anche se si poteva fare, sicuramente non era con l'fcopy.. Con il quale, tuttavia, si puo' giungere a 950k circa, cifra di tutto rispetto, soprattutto partendo da 720.. (senza contare le potenziali 86 tracce, discorso gia' fatto). Dovessi poi ricordarmi come formattavo a 12 settori, te lo faro' presente. Direi che qui possa finire il discorso, non vedendo una gran disparita', considerando anche che l'ST non necessitasse degli stessi quantitativi di memoria su disco dell'Amiga.


Vedi sopra: i copiatori hardware non fanno testo.


HW.. era poco piu' di un cavo.


Cioé? Spiegati meglio.


Cioe' copiava TUTTO, anche un toast se ce lo avessi messo dentro.


Ma tu cosa facevi, il pirata? Dopo tutto ciò che hai scritto, il dubbio è legittimo. Io, come la quasi totalità della gente che ha avuto un computer (non solo Amiga), non ho mai avuto né sentito l'esigenza di copiare dischi a josa. Era roba da pirati che, ripeto, avevano delle batterie di Amiga con 4 drive attaccati ciascuno per effettuare 4 copie nel tempo di una...


Forse i pirati che conoscevi tu avevano le batterie di pentole da cucina Amiga.
Comunque la tua ultima affermazione conferma la mia precedente. Per la maggior parte degli utenti, gestire 4 (costosi) floppy era pressoché inutile ed alzava solo il costo della macchina.


L'unica cosa su cui sono d'accordo.


Bilanciato non vuol dire scarso, vuol dire bilanciato. Scarso lo e' solo nella tua visione approssimativa.


E infatti s'è vista la fine che ha fatto...


Nel suo settore non e' campato meno dell'Amiga nel proprio.


Il problema è che le tue considerazioni sono frutto di ricordi errati e mancanza di conoscenza tecnica.


Parli di te qui vero?? perché parrebbe proprio che quello con conoscenze sbagliate ed approssimative sia tu, nemmeno l'HW dell'Amiga che hai tanto programmato conosci, hai lacune pesanti sia sull'audio ed il video.


Quest'ultima non la si acquisisce semplicemente usando il computer, come fa la maggior parte della gente...


Non credo che tu possa dirmi come si acquisisca “la conoscenza”, vedi sopra.
Hai solo scritto qualche riga di programmazione piu' di me, ma presenti voragini tecniche molto screditanti.
Almeno io non ho avuto la faccia di venir a dire di conoscere l'Amiga meglio di te, (cosa che invece sta emergendo).



Io non ho mai programmato un Atari ST, perché ho avuto di meglio fra le mani, ma non ho difficoltà a colmare questa lacuna proprio andando a cercare informazioni e integrandole nel mio bagaglio culturale e di esperienza che mi sono fatto col passare del tempo.


Avevi di meglio da fare.. Come vedi ritenevi e ritieni ancora, “meglio da fare” il dedicarsi all'Amiga, decisione rispettabile qualora si conoscessero entrambi gli HW e non solo uno (ed anche approssimativamente).
Per ignoranza si sostengono cose strane. :)


Informazioni che, comunque, contrastano palesemente con ciò che hai riportato tu.


A sì?? e dove di grazia?? :-/


E visto che si tratta di informazioni che per buona parte provengono da chi un Atari ST non l'ha semplicemente usato, ma anche programmato (con tanto di sorgenti rilasciati e che ho avuto modo di analizzare), direi che sono decisamente più affidabili di tutto ciò che finora hai malamente riportato.


Menomale che ci si sono messe mani piu' esperte delle tue e delle tue sorgenti “affidabili”. Fatti un giretto per quei link che ti ho postato, magari trovi cose interessanti come dei player a 50Khz per ST.. ST non STE.


Più complesso, sì, internamente, ma più facile da programmare e gestire.


Cosi' leggiadro che rallentava la CPU stessa e gli scarti in talune operazioni erano ben maggiori della differenza di clock tra le CPU.



Anche quella dell'Amiga. Con la differenza che potevi lanciare diverse applicazioni contemporaneamente


Con la CPU che strillava pieta' e quello sputo di RAM con la quale veniva venduto quel computer, che non poteva permettersi di certo piu' applicazioni contemporaneamente. La sinergia ed il bilanciamento, non erano certo doti Commodore.


"Fortuna" che l'ha portato velocemente alla tomba, e al contrario di AmigaOS, che tutt'ora prospera.


Come no, ho giocato proprio ieri a Doom 3 su Amiga!! :))
Poi sindacherei sul “presto”, visto che se da te prospera (forse) un Amiga impolverato, da me prospera un Falcon vivo e lustro, che mi manda avanti tutta la mia strumentazione da anni ed anni senza essersi mai rotto o aver dimostrato limiti di sorta. Come da te c'e' (forse) un'Amiga ancora “vivo”, ci sara' da altri. Come da me C'E' l'Atari, ci sara' anche da altri.



Quindi avevi il sistema totalmente bloccato: rientriamo nel primo caso che ho esposto.


Quindi il DMA dell'ST era decisamente piu' indipendente dalla CPU.


Hai una pessima memoria anche per gli avvenimenti recenti, a quanto pare... Tu hai scritto questo:

"E su ogni pubblicita', manuale e recensione del tempo l'STE era dato per 8 ch, visti come 4 pcm, 3 sintetizzatori quadri ed 1 dedito al rumore bianco."

E io ho scritto questo:

"Pubblicità ingannevole, allora."

Adesso mi spieghi dove ho parlato di DAC e canali.


Infatti avresti dovuto parlarne (e due), ma ora che ho dimostrato che la gestione di 4 ch DMA sull'STE e' praticamente free, il discorso si puo' concludere. La pubblicita' diceva il vero, i canali DMA PCM erano 4 e senza CPU, discorso valido anche per quelli dell'YM2149f. Dunque sono 8 ch gratis!! (Pare una tele promozione per un decoder satellitare =D ).



Questo dimostra la tua "preparazione" in materia.


Gia' gia', proprio la mia.. ora vedremo quante altre ne riesci a dire per cercare di risalire un po'.


Quindi per te è la stessa cosa avere a disposizione 4 canali a 8 bit indipendenti, ognuno collegato al proprio DAC, e miscelare 4 canali a 8 bit in due canali a bit, vero?



Gia' te l'ho spiegato, ma lo rifaccio, due e' meglio di una. La miscelazione sul fronte dei bit avviene SOLO qualora non vi fosse abbastanza capacita' d'elaborazione da parte dei DAC, altrimenti si alternano i cicli degli stessi senza mescolare in alcun modo i suoni. Ergo, demoltiplicando le frequenze dei segnali, si puo' avere un aumento dei canali senza la perdita di mezzo bit di dinamica. (perdita che avverrebbe in frequenza, ripeto SOLO qualora si volesse superare il limite fisico dei DAC).


Ovviamente la miscelazione non comporta alcuna perdita di precisione al segnale associato ai due canali miscelati...


Ovviamente la miscelazione, quando richiesta, ad esempio volendo riprodurre piu' canali alle frequenze massime dei DAC, comporta una perdita di qualita' dipesa in linea di massima dalla qualita' della miscelazione fatta dalla CPU. Questo discorso e' RARO, nonché valido per entrambe le piattaforme.


Quindi a questo punto potremmo anche miscelare 1000 canali a 8 bit in un solo canale, tanto la qualità sarebbe la stessa... :rolleyes:


Vedo che hai capito tutto. Non ne dubitavo. Comunque se avessimo un dac a qualche Ghz, direi proprio di sì.


Un link l'ho già postato prima. Quel che ritieni tu ha poca importanza, perché ciò che conta è l'ambito applicativo: se ho bisogno di una maggior precisione per pilotare i laser, 4 bit per l'ampiezza del segnale possono non bastare.


Oh, ma guarda cosa leggono i miei occhi!! =D
Prima fai lo sborone portando l'esempio del laser, per lasciar intendere che fosse una cosa richiedente qualita' audio “eccezionali”, poi dici “4 BIT POSSONO NON BASTARE” :) Che duci ca si' Dotto'.
**QUATTRO bit POSSONO non bastare, DUNQUE potrebbero anche BASTARE**, siamo lì lì.. Non va bene come esempio!! Gli 8 bit PCM dell'YM2149f bastano di sicuro!!
Peccato, perche' volevi stupire tutti e spiazzarmi con la parola LASER!! Wow le lucette colorate!! =D


E ti ho fatto notare quanto, TECNICAMENTE PARLANDO (e quindi siamo ben distanti dalle "voci" che si trovano su internet), ciò presenti parecchi problemi dal punto di vista implementativo. La differenza è evidente...


Sei di coccoarmato!! il mio intento era quello di dimostrarti COME NON SOLO IO ABBIA IPOTIZZATO UN'EVOLUZIONE DI QUEL PROCESSORE. Te l'ho dimostrato, dato che tu mi hai contrastato dandomi del incompetente e dicendolo impossibile. Ti ho dimostrato che ci sono altri “ignoranti” e visionari come me. PUNTO fine dell'argomento!!
I problemi si sarebbero potuti risolvere.. lo 060 docet.. completamente diverso dallo 040


Quando arrivò il PC nelle case aveva l'Hercules o la CGA (per i "ricchi") e il cicalino dello speaker: perfino il Commodore 64 era messo meglio.


Quando il PC si diffuse grazie alle VGA era messo meglio dell'Amiga, del C64 e dell'ST messi insieme.


L'Amiga come piattaforma d'elezione per i giochi è sopravvissuta fino al 1996 (poi è andata scemando), e l'ST era già morto da parecchio tempo.


Tutto sbagliato, non ricordi una sola data corretta. Forse sei uno dei pochissimi a non ricordare The Secret of the Monkey Island 2 a 256 colori sul pc.. Non era il 96, bensì il 91!! Sai quella cifra con prima il NOVE e poi L'UNO?? ecco, quella!!

Parentesi: TUTTI quei giochi, da maniac mansion a zak mckracken, da future war ad Indiana Jones, usavano l'MT 32 sull'ST.. dal quale oltre alla musica, uscivano fuori i vari suoni, tipo passi, bussate ecc.. il tutto con 32 toni di polifonia. (era tanto per citare il fatto che nessuno lo usasse).

Sempre nel 91 circa arrivarono le SB16.. e nel 93 sul pc si poteva giocare a Doom, evoluzione di Wolfenstein 3d disponibile gia' da molto tempo prima e chi non aveva un PC, poteva solo “rosicare”.



Questa è storia, e la si può andare a controllare riviste dell'epoca alla mano. Tra queste ci sono le stesse riviste che hai citato tu, e che adesso vorresti malamente smentire.
I tuoi ricordi lasciano il tempo che trovano...


Come vedi la so MOLTO bene la storia, tu prendi un bel 2 invece, preparati meglio che ti riinterrogo la prossima volta. ;)


Anche qui, come sopra: anche la tua memoria recente fa cilecca, a quanto pare. Ecco quello che hai scritto tu e per cui ho scritto quella frase:


"che poi l'amiga fosse il punto di riferimento per i giochi fino al 96, e' quanto di piu' personale tu potessi esprimere."


E lo confermo, sei tu che non capisci il senso dei discorsi. Quando scrivevo “parli dell'96 o dell'86” ero ironico, visto che il panorama che descrivi sembrerebbe sfasato di quasi 10 anni.


Io non faccio la guerra a nessuno: volevo scrivergli per metterlo al corrente che le informazioni che aveva pubblicato erano sbagliate, in modo da correggerle. Sei tu che vedi guerra da tutte le parti...


Certo che fare una battuta con te e' assolutamente inutile, non lo capisci nemmeno con i disegnini!! ed e' inutile che provi a farmi figurare con e un guerrafondaio, per me tutto questo e' solo il riprendere un dibattito vecchio di anni.


Cercare di cambiare discorso non toglierà il fuoco dalle castagne...
Hai riportato due fonti a sostegno di due tesi. Fonti che sono in completo disaccordo sul 68060. Ti ho chiesto quale due ritieni attendibile, e non hai ancora risposto.
Se ritieni wikipedia inaffidabile, ciò che hai preso da lei dimostra la falsità delle tue parole in quel contesto. Se ritieni inaffidabile l'altro sito, ciò che hai preso dimostra la falsità delle tue parole in quel contesto. E' un discorso molto semplice, e attendo una tua risposta.


Ti ho spiegato cosa non mi piaccia di Wikipedia, ovvero l'inattendibilita' delle fonti, che possono essere giuste quanto possono non esserlo. Se tu scrivessi un articolo per loro relativamente all'ST/STE, la gente riceverebbe un'informazione incompleta ed errata.
Ed a quanto pare pure se lo scrivessi riguardo l'Amiga, stando alle ultime battute.


Quanto alla documentazione tecnica, se ne hai bisogno valla a controllare tu: io conoscevo già come funzionava il 68060 senza bisogno di interpellare alcun sito...


Gia', dimenticavo l'inappuntabilita' delle tue conoscenze.


Questo, comunque, è UN ALTRO DISCORSO: a me interessa la tua risposta a quanto scritto sopra. E non farla mancare, cortesemente.


Che risposta vuoi??


L'emulazione non è perfetta: funziona bene con alcuni giochi, male con altri, altri non funzionano proprio. Il problema è questo: http://www.bannister.org/ubb/ultimatebb.php?ubb=get_topic;f=7;t=002412#000000

"The MESS Jaguar driver is based on the MAME Cojag driver. Only a few Jaguar games work, as the J....
......sfrutta il lavoro del MAME, e ci sono poche persone che si occupano di integrare questo lavoro con altro, in modo da realizzare l'emulazione di computer.


Grazie per la traduzione, ma non mi serve. Quando tu dicesti “come e' stato emulato il Jaguar, possono EMULARE anche il Falcon, io risposi dicendo che non esiste un emulatore Jaguar funzionante come si deve. E' la verita'. Punto.
Il resto sono discorsi che possono essere anche interessanti ma che non c'entrano assolutamente nulla.
(e non mi pare il caso di allungare ulteriormente questo discorso).


Leggi meglio: il computer intero viene già emulato (anche buona parte del video migliore del Falcon).

Il problema è che ARAnyM ha obiettivi diversi rispetto agli altri emulatori: si propone di emulare gli ST (di qualunque classe) il più velocemente possibile, superando quindi i limiti prestazionali di questi computer. Questo però avviene sacrificando la piena compatibilità, ed è infatti ciò di cui si lamentano i suoi autori (i programmi che saltano il s.o. per accedere direttamente all'hardware del Falcon non funzionano o non funzionano bene).

Al contrario, emulatori come SainT e STeem si propongo come primo obiettivo l'emulazione fedele, quindi ricreare esattamente ciò che quei computer erano in grado di fare, "trucchetti sporchi" inclusi. E' per questo sono molto più lenti: infatti emulano la macchina "al ciclo di clock", similmente a quanto avviene con MAME, MESS, WinUAE (se impostato con quest'opzione), ecc.


Il punto e' proprio questo, non viene emulato il computer, ma il suo comportamento, troppo spesso le applicazioni escono dal sistema operativo e vanno a colloquiare con l'HW. E' un concetto sballato, quelle macchine erano belle per questo, perche' le “tiravi”, se gli togli questa prerogativa, tanto vale tenersi un pc.

Comunque, qualora lo facessero, sarei felicissimo, perche' se mi si dovesse rompere, (facciamo mille corna), sono nella m....!!


Ho capito. Visto che hai queste esigenze, hai mai provato a impostare la priorità del task a quella più elevata? Alcune applicazioni permettono di impostare anche la priorità "real time": in questo modo la CPU sarà quasi esclusivamente impegnata a eseguire l'applicazione, a danno anche dei servizi del s.o...
Puoi farlo anche con WinAmp, ad esempio.
Avere un s.o. multitasking / preemptive non significa dover rinunciare per forza ad eseguire task molto delicati con la massima precisione...


Se seguiti ad illuminarmi cosi', temo che diventero' cieco =D
Diciamo che confido nella risoluzione parziale di certi problemi con l'avvento delle CPU multicore. Anche se ne servirebbe una dedicata sempre e solo alle funzioni vitali del PC.


E' quel che faccio, e non soltanto coi tuoi post. Se poi seguo una discussione, l'attenzione è anche maggiore.


Eppure travisi troppe cose (e non ho detto tante, ho detto troppe).


In questo caso noto una generale non aderenza delle tue parole alla realtà dei fatti: si scontrano con tutte le informazioni tecniche che ho trovato, anche da parte di chi gli ST li ha programmati (mentre tu ti sei limitato a usarli).


A quanto pare, le conosco meglio di te 'ste due macchine. Chissa' come si spiega questo. La piu' grossa differenza tra me e te, consiste nel fatto che io le conoscevo tutte (qualcuna piu' qualcuna meno), compreso l'archimedes e so pregi e difetti di ognuna di esse. Non mi limito a bollarne una senza averci mai messo le mani per piu' di 30 secondi, dicendo inesattezze e pretendendo di imporle come vere.


Potrebbe essere un'obiezione da valutare nel caso in cui fosse immediatamente esposta dagli interlocutori.


Punti di vista.


Invece accade puntualmente (tu sei soltanto l'ultimo di una lunga lista di gente che si è comportata così)


La ridondanza degli eventi ha in genere una spiegazione, che con buona probabilita' va al di là delle tue convinzioni di superiorità che, tuttavia, vi e' legata in qualche modo (in questo caso specifico).


che prima si inizia una discussione, e STRANAMENTE dopo un po' arrivano le classiche battutine sul titolo che traspare dalla mia firma.


Ma dai, credevo di essere l'unico ad averla notata!! :))
Gira storto il mondo vero?? dovresti ricostruirlo a tua immagine Dotto'.


Puzza fortemente di mancanza di argomenti a sostegno delle proprie tesi, per cui ci si aggrappa alle cose più banali e che nulla hanno a che vedere con ciò di cui si parla.


Guarda, io senza argomenti non ci resto MAI, non parlo di cose che non conosco. Non provare a dire simili cavolate, non ci fai bella figura.


Per quanto mi riguarda, e lo ripeto esattamente come ho fatto con tutti gli altri, in questo forum scrivo riportando i miei dati reali: il mio titolo è uno di questi. E non l'ho mai usato per sostenere le mie idee: mi sono sempre basato su fatti e logica.


Il tuo titolo a molti da l'idea di “vedi chi so' io”. ;) , impressione che dai ad ogni riga che scrivi, anche solo per lo spirito di contrastare, mettendo in bocca agli altri concetti mai espressi o cercando di far leva sui punti deboli dell'interlocutore (dicendo castronerie, perche' tanto non le sa capire). Forse sei abituato a trovare persone che non sanno reagire (ne trovo spesso anche io). Sei solo un sopraffattore, un prepotente, nulla di piu'.

Ritieni che il tuo TITOLO faccia parte di te?? che dire.. menomale che hanno abolito i titoli nobiliari.

Una persona e' fatta di cio' che ha vissuto, di cio' che ha studiato, di cio' che ha dimostrato. (e ti prego non sindacare riguardo le reciproche dimostrazioni, perche' sai come andrebbe a finire).
Anche di pietro (scritto minuscolo di proposito) e' dottore, ma sempre un ignorante da 6 politico resta.

Dimostri solo di non essere abbastanza orgoglioso di essere “Cesare” fatto di concetti e di volerti mettere un gradino piu' in alto.
Questo e' il motivo per il quale la gente si “appiglia” al titolo per prenderti in giro. (Hai visto, anche io ti illumino oggi??). Poi vedila dal tuo punto di vista a me non puo' fregare di meno e a te che sfottono (per tua ammissione), non me.


Fallo pure invece: m'interessa capire cosa pensi della gente che proviene da determinati luoghi, come traspare da ciò che hai scritto.


Cosa traspare?? ma che cervello hai?? L'unica forma di razzismo che ho, e' contro quelli come te, che mettono abbiettamente e viscidamente, concetti (partoriti dalle loro menti) in bocca ad altri che cercano di evitare certi stupidi luoghi comuni.
Ti dico solo che la persona che ne rideva con me e' delle stesse origini. ;)
Evita l'argomento come ho fatto io, non esiste nulla di che parlare in merito.


Se è insindacabile, non capisco il motivo delle tue considerazioni: è una contraddizione in termini.


Il mio e' un parere insindacabile, dettato dal mio gusto e quello di chi come me, ti vede parato dietro lo scudo del tuo “titolo” (nemmeno fossi un libro ;) ).


Finora l'unica cosa che hai dimostrato è l'assoluta inconsistenza di tutto ciò che hai scritto e il completo distacco con la realtà...


Ogni volta ti posto link su link e spiego tutto cio' che dico TUTTO, tu seguiti a dire che questo non sia vero.. A me non piace perdere tempo. Fermo restando che chi legge sa che il tuo dire “non hai dimostrato”, non fa testo quando e' in presenza delle dimostrazioni stesse.


Vogliamo parlare del 68000 a 16 bit? E che dire del 68000 a 8Mhz che aveva capacità paragonabili al 486 a 66Mhz? E questo è soltanto l'inizio: la lista è molto lunga...


Ma sì, parliamone cosi' emerge ancora meglio come tu non sappia leggere (o se ti offende, dico “capire”, ti do la possibilita' di scegliere)..
All'inizio del thread, cosi' come in altre 6000 occasioni prima e dopo la creazione dello stesso, ho detto CHIARAMENTE, di non aver MAI paragonato un 486 ad un 68000, questa e' stata SOLO la tua scusa per attaccarmi all'inizio e fare il superfico dei miei stivali, dunque se giudichi una cazzata paragonare quelle due CPU, ti informo felicemente che lo hai fatto TU!! lo hai fatto anche con confronti tecnici. Non girare a me le tue cazzate, grazie. Io dissi semplicemente che l'efficenza di vecchi sistemi come l'Atari e l'Amiga spesso, fosse maggiore di quella delle architetture basate su CPU x86. Portati diversi esempi di programmi che sull'ST a 8 Mhz (che tutto il mondo tranne te, definisce ad 16 bit), dovettero aspettare dei 486 a 66 Mhz per girare allo stesso modo (ed alcuni addirittura dovettero aspettare CPU superiori al Ghz).
Questo non significa che io ritenga il 68000 piu' potente di un 486, significa solamente che l'architettura PC-Compatibile, e' (e soprattutto era) una vera cagata.
Non significa nemmeno che quello che poteva fare un PC basato su 486, potesse essere rifatto da un computer basato du 68000.
Odio dire le cose due volte, ma mille e' proprio inutile. Tanto traviserai anche questa volta. Ridarai tutta la colpa all'opinabilita' delle mie affermazioni (come se non lo si sapesse quanto il cubase su pc abbia avuto seri problemi precisione) ed a (improbabili) problemi di “porting”.. anche per programmi e versioni mai scritte per 68000 (per rimanere in tema, vedi il VST che presentava i medesimi problemi).
Il cubase Audio del mio Falcon gestisce 160 (CENTOSESSANTA) canali midi (e non e' il suo massimo teorico) e suona i sample in RAM a 16bit (fino a 50Khz) con latenza pressoché zero. Senza l'ausilio di schede separate da 250€ MINIMO (oggi, al tempo milioni su milioni). E con 4 mega di RAM!!
Fallo fare ad un 386 a 16 Mhz del tempo (e magari limitiamone pure il costo alla parita'). Ci sarebbe da ridere.... e non poco.



Sui dati tecnici non ci sono punti di vista che tengono: contano i fatti. E i fatti dimostrano ampiamente, con tanto di documentazione verificabile da chiunque, la falsità delle tue affermazioni.


Non ti commento ulteriormente. Se ti manca un commento in merito, ricavatelo da sopra.


Anche questo è una questione di gusti "insindacabili", eh? :rolleyes:


No, questa e' permalosita' ;)


Coi se e coi ma non dimostri niente. Qui stiamo parlando di macchine reali, regolarmente commercializzate, e ciò che è evidente è l'assoluta mediocrità delle macchine Atari rispetto alle concorrenti offerte dalla Commodore.

Citando prototipi e macchine rimaste in laboratorio, non fai altro che aggrapparti a sogni e fantasie di presunta superiorità che non hanno alcuna aderenza con la realtà.


Tra l'altro proprio in questo documento, fra i varii e interessanti dati, ecco cosa riporta Dave:

Function Paula Mary
Dynamic range 15 bits 16 bits[/CODE]
Questo per rispondere a proposito del discorso di cui sopra sulla dinamica...


Portarmi un DOCUMENTO, rappresentante la fantasia di un paio di progettisti, non e' una gran prova di nulla.
I PROTOTIPI da me citati erano funzionati (avevano addirittura gia' il case per la commercializzazione) e prodotti nel periodo di floridita' delle due case in questione.
Quelle macchine furono “lasciate” in cambio di migliori compromessi tra qualita', leggerezza de sistema, tecnologia disponibile (perche' non basta avere tre super chip per fare un super computer) e prezzo.
Da uno nacque l'STE, mentre l'altro spiano' la strada al Falcon. Uscito, vivo e vegeto. Gli esempi che ti ho fatto non sono assolutamente Casuali come invece lo e' il tuo.


Quando?


In una moltitudine di occasioni che per ovvie ragioni non mi metto a ricercare, ma tranquillo, io non me la prendo, dovresti avere un peso perche' questo possa accadere. In fin dei conti sono solo un troll, non ti capisco nemmeno. ;)


Che potevi anche risparmiarti...


Permalosita'. Tranquillo, la mia parola non ha alcuna valenza. :) Del resto io non so un c.. mentre solo tu porti il verbo, al di là di ogni dimostrazione contraria.


Come questo:

"Forse non sai ancora leggere ora che ci penso;"

Beh, se proprio vogliamo ammettere l'ipotesi che tu sappia leggere a questo punto comincia anche a “saper capire”(come ipotizzato poc'anzi). Perche' se io scrivo A e tu poi dici che dico cazzate perche' ho detto B, non dai l'impressione di saper capire/leggere bene.

Un bacio ai pupi.

Matteo.

[cdimauro]

Va bene, mi hai rispiegato per la seconda volta una cosa che per altro gia' sapevo (escludendo il fatto della musica, visto che credevo piu' indipendente il Paula), ma non mi hai spiegato perche' sull'ST questo non dava MAI luogo a scatti ed il 3D ne traeva giovamento.. Onestamente al riguardo ho cultura parziale e non riesco a trovare nulla e nessuno che lo tratti in maniera decente in rete.

Quello che ritengo probabile invece, e' che tutto fosse scritto per sistemi a 60Hz (perche' la portabilita' contraria non e' possibile) e poi, quando fatto girare a 50Hz, ne risentiva tutta la macchina.
E' l'unica spiegazione plausibile. D'altra parte il maggior mercato degli ST è stato quello degli USA, ed era quindi quello di riferimento per lo sviluppo di giochi / applicazioni. Se un gioco riesce a girare a 60fps, non avrà difficoltà a farlo a 50hz (con qualche adattamento).

Per il 3D, invece, mi sembra strano che tu abbia notato qualche miglioramento, proprio perché l'engine viene realizzato e funziona in maniera diversa.
Grazie comunque.

Ora ti rispondo pure a tutto il resto (che mi ha fatto innervosire :mad: ).. Pronto?? :D
Di niente.

La mia risposta arriverà fra qualche giorno, perché ho parecchie cose da fare, e non voglio abbandonare tutto il resto del forum per seguire un solo thread.

Comunque ti anticipo che ho intenzione di rimuovere tutte le parti polemiche: è inutile perderci altro tempo.

[^TiGeRShArK^]

Sono esterrefatto. Tuttavia temo che dovro' riproporti la domanda, visto che non l'hai capita o meglio, hai dato una risposta in stile microsoft: “perfettamente attinente alla domanda, assolutamente inappuntabile, che tuttavia non c'enta nulla con quanto richiesto e non spieghi un bel nulla".
Perche' la versione PAL aveva frequenze differenti da quella NTSC??
Dai che arriviamo ad una soluzione.
L'ST era sempre a 8..

:confused:
perkè la sua spiegazione non c'entrerebbe nulla????
ti ha spiegato perfettamente e chiaramente ke la differenza di frequenza era dovuta ai chip custom...
poichè ai 60 hz dell'ntsc il chip girava + veloce rispetto ai 50 hz del pal, cambianvano anke le frequenze del master clock.
Poikè il divisore era sempre fisso a 4, di conseguenza cambiava anke la frequenza del chip (+ o - km avviene oggi, solo ke abbiamo i Moltiplicatori ke agiscono sull'FSB anzikè i Divisore.... ma già il mio 386 sx era basato sui divisori, e si potevano impostare in maniera indipendente il fast clock divider (modalità turbo) e lo slow clock divider (modalità normale)).
Nell'atari invece a quanto pare è stata fatta la scelta di ottenere delle frequene a discapito però del sincronismo ke, ovviamente, introduceva dei cicli di wait state.

Io ho capito benissimo dalla spiegazione di cesare, nn capisco quali siano ancora i tuoi dubbi......

[Correx]

:confused:
.... ma già il mio 386 sx era basato sui divisori, e si potevano impostare in maniera indipendente il fast clock divider (modalità turbo) e lo slow clock divider (modalità normale)).
......

quello c'era già nei 286 ... Alcune vecchie applicazioni per XT giravano molto velocemente sul 286, così premevi il pulsantino e il pc si rallentava... Ma ovviamente te lo tenevi FISSO (INCOLLATO :D ) a turbo! (era quella la modalità <<normale>>). Poi venne l'overdrive , col 486, e il molti fece la sua fortuna... Ricordo una vecchio thr con cdimauro a proposito :D
Mi state facendo venire una nostalgiaaa :cry:

[MadRat]

E' l'unica spiegazione plausibile. D'altra parte il maggior mercato degli ST è stato quello degli USA, ed era quindi quello di riferimento per lo sviluppo di giochi / applicazioni. Se un gioco riesce a girare a 60fps, non avrà difficoltà a farlo a 50hz (con qualche adattamento).


Anche in francia e germania, tanto per dirne due piccoletti, venne venduto in quantitativi industriali.. Resta comunque piu' logico sviluppare per i 60hz (che tanto in linea dimassima, si potevano avere anche in europa), per non sfavorire nessuno.


Per il 3D, invece, mi sembra strano che tu abbia notato qualche miglioramento, proprio perché l'engine viene realizzato e funziona in maniera diversa.


Infatti il quesito verteva su questo punto, come trovo tempo lo riprovo sul computer stesso e vedo quanto e se fossero tangibili gli incrementi.
Se trovi (tu come chiunque altri) documentazione in merito online, non esitare a postarla.


La mia risposta arriverà fra qualche giorno, perché ho parecchie cose da fare, e non voglio abbandonare tutto il resto del forum per seguire un solo thread.


Io ci ho messo parecchio, ho risposto a tempo perso. Fai con comodo.


Comunque ti anticipo che ho intenzione di rimuovere tutte le parti polemiche: è inutile perderci altro tempo.
[/QUOTE]

Sarebbe anche ora. :)
Anche perche', senza voler prevalere o dar per scontato che l'altro dica cazzate (indovina di chi parlo??), si puo' arrivare a qualcosa di veritiero e costruttivo (per quanto, oramai inutile ;) ).

[cdimauro]

Non ho i dati a portata di mano, poi vedremo, ma non e' certo l'Italia il paese nel quale l'Atari ha venduto in grandi volumetrie.
Infatti: sono USA e Germania. Quanto ai dati, li ho presi sempre da MC MicroComputer.
Non ho mai detto costo zero, dovresti farmi vedere dove..
Certamente: "Assolutamente minimi, nulla che avesse a che vedere con il multitos in ogni caso."
Invece e' vero, perche' solo l'ultimo caso mostra prezzi a favore dell'Amiga.
Anche negli altri casi la differenza fra un ST e un Amiga con caratteristiche simili non era molta. L'unica eccezione è relativa all'introduzione di ST 520 e Amiga 1000, che era nettamente a favore del primo, e che ho comunque riportato.
Questo solo dovuto al fatto che L'Atari Italia non c'era piu'.
Anche negli USA la situazione non era diversa.
Per la gente come me che prediligeva i giochi in 3d invece, tutta questa inferiorita' non c'e' mai stata. Sull'Amiga erano notevolmente piu' lenti. Si prenda Interphase (nonostante l'audio campionato), conqueror, resolution 101, StuntCar, Robocop, Tower of Babel .. Va be', piu' o meno tutti..
Sui titoli 3D che ho elencato hai già visto le informazioni che ho riportato. Comunque sul 3D non c'era molta differenza, perché anche le versioni Amiga erano realizzate usando 16 colori generalmente.
In ogni caso anche giochi 2D come Ghouls'n Ghost, Rainbow Island, Onslaught, 7 gates of jambala e molti altri, non avevano assolutamente nulla da invidiare alla versione Amiga. Programmati da chi sapeva usare entrambi gli HW.
Non v'è dubbio che alcune versioni fossero paragonabili: non l'ho mai negato questo. Però è evidente che come piattaforma di gioco con Amiga si potevano realizzare titoli qualitativamente migliori.
Lo dimostrano anche le conversioni realizzate dalla SEGA per i propri titoli arcade: certamente non è una hardware/software house a cui manca esperienza nel campo della programmazione e dello sfruttamento diretto dell'hardware delle macchine.
E ti diro' di piu', anche l'audio fornito dall'YM2149, se usato con tracker appositi, dava soddisfazioni non indifferenti. Molti di questi davano la possibilita' di superare il limite delle onde quadre, proponendo anche delle onde a dente di sega e sega inversa, nonché delle triangolari. A tutto questo aggiungiamoci un controllo adsr evoluto per il volume, controllato anche tramite LFO seguenti le medesime forme, ma totalmente indipendenti, una modulazione FM!! ed una sorta di modulatore ad anello!! ed ecco fatto che si ottiene un sintetizzatore a tre canali (i sintetizzatori che hanno fatto la storia sono perlopiù monofonici) piu' uno PCM a 22Khz.
Prima di tutto devi considerare che tutto ciò comporta un notevole impegno della CPU.
Poi il PCM a 22Khz lo realizzi con una definizione di 4 bit: esattamente come avveniva col SID del C64.
In particolare, emulare il PCM a 22Khz vuol dire inserire "a mano" i valori a 4 bit 22 mila volte al secondo (praticamente un valore per ogni riga di raster): è un'operazione che richiede abbastanza tempo di calcolo per la CPU.
Il tutto, musicalmente parlando, non ha nulla e sottolineo nulla da invidiare alla sterile tecnologia PCM supportata dall'Amiga
Prima di tutto la "tecnologia PCM" ancora oggi è apprezzata e ricordata (cosa che non accade né col C64 né con l'ST), e definirla "sterile" per partito preso è una cosa che non ti fa onore.
Poi mi sembra che fra un "canale PCM" a 4 bit e uno (dei 4) a 14 (8 + 6) bit ci sia una LEGGERA differenza, non credi?

Tra l'altro, in questi giorni in cui ho dovuto sistemare un po' di roba a causa del trasloco, ho trovato una cosa interessante: il "vecchio" videopoker (quello coi "Jolly", della CMC), su cui ho lavorato tempo addietro. Usa l'A-Y-8190 (usato negli MSX), un equivalente dell'YM-2149. Chiunque abbia avuto l'occasione di giocarci o vederlo in azione, può capire capire la "qualità" e il tipo di suoni che era in grado di erogare. Ridicolo, paragonato a quello di un Amiga (che tanti hanno avuto l'occasione di provare).
Invito chi fosse interessato ad andare a controllare di persona.
(e non parlo di STE!!).
Che è certamente meglio di quello dell'ST, senza dubbio, ma sempre inferiore a quello dell'Amiga.
STE: 2 canali PCM a 8 bit.
Amiga: 4 canali PCM a 14 bit.
Se la matematica non è un'opinione, direi che c'è ben poco da discutere... E bada bene: sto parlando di canali PCM messi a disposizione dall'HARDWARE delle due macchine.
E non venirmi a parlare di CPU load, perche' hai ampiamente dimostrato di non capirci nulla, siamo sempre su carichi bassissimi come vedrai di seguito.
Il 20%, come riporti in seguito, è un carico "basso" secondo te?
Beh, col quasi 0% (ti ricordo che lo 0,16% è il tempo per suonare un modulo: impostare i dati di un canale audio richiede MOLTO MENO tempo) non c'è storia...
Hai di nuovo eluso la domanda. Come mai I recensori del tempo (ed anche dello stesso articolo portato da te), dicevano che i giochi 3d per ST, fossero sempre piu' fluidi rispetto alle controparti Amiga??
Non l'ho elusa: l'ho scritto chiaramente il perché.
Sono esterrefatto. Tuttavia temo che dovro' riproporti la domanda, visto che non l'hai capita o meglio, hai dato una risposta in stile microsoft: “perfettamente attinente alla domanda, assolutamente inappuntabile, che tuttavia non c'enta nulla con quanto richiesto e non spieghi un bel nulla".
Perche' la versione PAL aveva frequenze differenti da quella NTSC??
Dai che arriviamo ad una soluzione.
L'ST era sempre a 8..
Anche qui, mi sembra che ciò che ho scritto fosse piuttosto chiaro. Se gli altri capiscono e tu no, non è un certo un problema mio: la mia parte l'ho fatta, ed è stata anche apprezzata.
Praticamente quel che ho detto io, i chip custom da una parte erano uno sprint, dall'altra erano una strozzatura.
I chip custom non c'entravano con questa scelta che è stata fatta dai progettisti. Tant'è che tutte le schede di accelerazione lavoravano con clock asincrono rispetto a quello di sistema / chip custom, e subivano la stessa penalizzazione dell'ST per l'accesso alla memoria "condivisa".
Sull'ST era molto semplice, infatti, installare delle CPU a frequenze maggiori (12mhz in genere, per ragioni di costo) e la cpu e' molto piu' libera.
(Si' era ad 8Mhz anche quello dell'Amiga, dovresti saperlo, la sigla era MC68000P8 esattamente come quello dell'ST e del MAC. Non e' stato mai prodotto a 7,014Mhz, c'era anche a 4, 6, 10, 12, 12,5, 16 ecc.. ma niente numeri dispari.)
Lo so benissimo, e t'ho anche spiegato il perché. Per maggiori informazioni, puoi leggerti "Amiga Hardware Manual", dove è spiegato in maniera più dettagliata il perché di questa scelta, e in che modo lavoravano (in "sincronia") chip custom e 68000.
Appunto dipende dall'uso che se ne faceva. E sul 3D pesava eccome. Si vedeva tutta la leggerezza e sinergia del progetto e non solo quella percentuale di clock.
Era importante, sicuramente, ma t'ho già detto che nel 3D non era tutto, anzi. Hai idea di cosa voleva dire tracciare i bordi dei poligoni, per poi riempirli, con la grafica a bitplane? Fosse stata chunky, come quella dei PC (con VGA -> 256 colori), il discorso sarebbe stato abbastanza diverso e la CPU avrebbe avuto un ruolo molto più importante.
Non ho mai detto che fosse implementabile tanto facilmente come su Amiga, sia mai, ti ho solo detto che non e' vero quanto da te sostenuto precedentemente e cioe', che sull'ST non vi fosse overscan. C'era anche un programma di grafica che lo utilizzava, ma non ricordo il nome, senza contare gli innumerevoli giochi che posizionavano il pannello di controllo fuori schermo.
D'accordo, e infatti ti avevo detto che non mi risultava, non che non esistesse del tutto.
Questo, però, aveva un certo costo, ed era abbastanza pesante per la CPU, a seconda dell'uso che se ne faceva.
Infatti in quel documento che ti ho riportato si parla delle varie tecniche per ottenerlo, e di quanto incidessero.
Il vero problema dell'ST (ed anche nell'STE) nell'ambito dei giochi in bitmap consisteva proprio nell'assenza di un supporto HW per gli sprite, anche se il blitter poteva sollevare da questo compito la CPU. Giochi come Xenon2 (che non usava l'STE) o Wings of death, dimostravano come si potessero abbattere certi limiti.
Guarda, i limiti dell'hardware rimangono e basta: al più si impara a sfruttare meglio ciò che è disponibile. Cosa che, comunque, si è verificata anche con l'Amiga, che nonostante un hardware piuttosto ricco di funzionalità, è stato spremuto abbastanza.
L'ST suonava nei giochi a 8 bit e non a 4.. dovresti informarti un po' meglio prima. Non disponendo di convertitori DA, usava i 3 controllori di volume a 4 bit dell'YM2149 che potevano lavorare insieme dato che erano unificati e non separati.
Sono abbastanza informato, e non è affatto così. Dai datasheet di YM-2149 e A-Y-8910 (che è la stessa cosa) emerge chiaramente che questo chip dispone di 3 canali D/A a 4 bit E BASTA; D/A che non si possono "combinare" in nessun modo per ottenere fantomatiche risoluzioni a 8 bit del segnale.

Comunque non c'è problema: fammi vedere dal datasheet dove sta scritto ciò che dici, e non avrò difficoltà ad accettarlo pubblicamente.
Qui c'e' qualcosa comunque, anche se non si tratta di giochi.
http://home.earthlink.net/~chhome/tcbtracker.html

Si parla del 20% di CPU di un tracker (non un player) su un ST e non STE. Qui fa uso di un unico canale (l'ST era mono) suddiviso in 4.

Ti ricordo che si parla di ST e non STE.
Sì lo bene, e ti consiglio di leggere attentamente quella pagina: si parla del PLAYER non del TRACKER. Ti riporto la parte in questione:

"Well we now able to play one 8-bit channel but we need 4 “frequency independent” channels
Without using 100% CPU.[...]
The routine is using about 20% CPU and that is not to bad actually."

Comunque non sono d'accordo su quanto scrive l'autore a proposito degli 8 bit:

"You solve that by using the three 4-bit volume controls inside the YM2149 (The soundchip). By combining the three channels you almost get the performance of a 8-bit DA."

Per quanto ho già scritto sopra, dovrebbe dimostrarmi il perché delle sue parole: i proclami ingiustificati lasciano il tempo che trovano.
Aggiungerei inoltre che il DBE tracker usa 32 (TRENTADUE) canali su un STE. Questo significa che stando ai tuoi calcoli ESATTISSIMI perche' tu analizzi il codice (=D). Quel programma utilizza il .. 240% (DUECENTOQUARANTAPERCENTO) della CPU.

http://atari-ste.anvil-soft.com/html/archivapps.htm
Hai scaricato quel programma e letto la documentazione? Scommetto di no. Ecco qua cosa dice:

DBT_ENG.TXT
"It runs on all ATARI computers with a DMA chip. Yes, there are 32 voices on STE (of course, the quality suffers a lot).
-sound quality depends on 680x0 speed and the number of voices."

FUNCTION.TXT
"ALLOW BIG SAMPLE : allow samples bigger than 64Kb. Be careful, this option
| requires machine time, so you may have to kick display on STE. This option
| is redefined after the loading of a soundtrack. For the loading of a
| single sample, you have to set it manually.

And please do not criticize the sound quality in 16 or 32 voices on STE be-
cause all machine time is used and for an 8MHz machine, it remains a very good
result."

Come vedi, tutto ha un prezzo.

Ti faccio presente per l'n-esima volta che non ho mai detto che fosse impossibile riprodurre 8 (o più in questo caso) "canali PCM" con gli STE, ma soltanto che l'HARDWARE permette di averne soltanto 2 (pilotati dall'unico canale DMA).

Il prezzo da pagare per superare questi limiti, è costituito da due fattori:
1) il tempo di CPU (come vedi, viene "consumato" tutto per la riproduzione);
2) la qualità.

In particolare, il secondo punto è molto importante: ciò è dovuto al fatto che, miscelando più canali a 8 bit in uno a 8 bit da "spedire" al DMA, la qualità finale viene irrimediabilmente compromessa con l'aumentare delle voci.
Inoltre per ridurre il carico della CPU e rendere possibile la miscelazione dei canali, molto probabilmente sono stati costretti a ridurre la frequenza del DMA: se per 4 voci era di 50Khz e 25Khz per 8, probabilmente per 16 voci sono scesi a 12Khz e per 32 voci a 6Khz.
Qui poi in elenco c'e' l'audiosculpture, non c'e' scritto molto purtroppo ma lo definisce cosi':
“4 channel DMA sound, supports 16bit modification”.
Dunque stando ai tuoi calcoli l'audio dell'STE era a 8+16 bit.. Bella 'sta cosa e pensare che non la sapevo mica!!
Quali sarebbero i miei calcoli?

Comunque dovresti prestare più attenzione e riflettere meglio su ciò che leggi, perché poi lasci galoppare troppo la fantasia.
Su Amiga, AudioLab16 permetteva di manipolare suoni a 16 e 24 bit; li poteva anche riprodurre, ma sempre con l'hardware disponibile, che poteva dei precisi limit. Infatti poteva riprodurli a 8 bit, usando il DMA o a 14 bit controllando separatamente sample e volume. Ma non è che suonando sample a 24 bit l'audio dell'Amiga diventava a 24 bit: non esiste proprio.

Lo stesso vale per l'STE: è inutile che continui a cercare a destra e a manca informazioni per farmi vedere che poteva suonare a n voci: l'hardware rimane sempre quello, ed è limitato a 2 PCM a 8 bit e un canale DMA che ne trasporta i dati. Punto.
L'STE aveva anche L'ym2149, non vedo i problemi di compatibilita' in cosa sussistano.
Infatti se leggi meglio non parlavo di "problemi" di compatibilità, ma al contrario.
Io intendevo in ambito Atari, per fortuna ci fu chi lo programmo' molto meglio di come avresti saputo fare tu. Visto che non lo conosci affatto.
Sto imparando a conoscerlo (a basso livello). Comunque tu non puoi giudicarmi per due motivi: primo perché non mi conosci e secondo perché non sei un programmatore. Lascia che siano delle persone competenti a farlo.
Infatti si parla proprio del 30% della cpu .. nemmeno con l'ST sotto traker e non player (dunque con tanto di grafica) e' vera sta cosa, figuriamoci con l'STE in DMA!!
Ho parlato forse del 30%? Rileggeti bene quello che ho scritto, e aggiungici quanto ho riportato sopra. Mi sembra che sia piuttosto chiaro il mio pensiero in merito.
Non hai dimostrato nulla, hai solo fatto illazioni, sparando carichi d'utilizzo della CPU completamente casuali.
Non mettermi parole in bocca che non ho mai detto. I numeri li ho presi dai documenti dei programmi che hai citato anche tu, e che ho travato io: chiunque può esaminarli e accertare la veridicità delle mie affermazioni.
L'unica cosa che hai dimostrato, e' di non conoscere la macchina della quale parli.
A quanto pare la conosco molto meglio di te, e a me basta per sostenere questa discussione. Comunque se vuoi portare altra gente più esperta in materia che conosci, per me non c'è alcun problema. Meglio se sono programmatori che con l'ST/STE ci hanno lavorato.
**Some of the Amiga editors and players have been ported to the Atari.
Probably the most popular is the NoiseTracker which can be found on many ftp sites, among them RUS in /pub/soft/atari/sound/players.
You can also retrieve the sources for the NoiseTracker there and a NoiseTracker Compiler. This program converts the NST modules to SEGM files. These can then be played on any Atari with almost no CPU usage. The NoiseTracker package contains the editor and a re-play program.**
Viene da qui “ http://archive.cs.uu.nl/pub/MIDI/DOC/Music-Formats
Sparano un sacco di balle. Infatti ecco cosa suggeriscono di usare per l'ST:

"If you have an Atari with DMA chips (STe, TT or Falcon), there's one program you should get: Paula. Paula enables you to play MODs in the background while you work in another window. Paula uses the DMA to make all necessary MOD calculations, the CPU is not used. The quality of the output is ok."

Anche qui dicono che la CPU non viene usata, ma questo programmino è lo stesso su cui hai lanciato i tuoi strali e di cui ho esaminato sorgenti e documentazione, che dimostrano chiaramente che la CPU viene usata, eccome, e si mangia un bel 30% del tempo totale.

Le informazioni si devono verificare: non è che se trovi scritto qualcosa su internet diventa automaticamente vero. Al contrario, c'è un sacco di spazzatura. A me interessano i fatti: fatti che devono essere ampiamente documentabili e dimostrabili.

Tra l'altro guarda cosa dicono qui in merito alla differenza di velocità di riproduzione dei moduli:

"There's a host of other players, e.g. the Marx Tracker, but I only described the most important ones above. All of these players run on color monitors only. If you have a monochrome monitor, you're a bit out of luck: there are almost no MOD players for the high resolution. It is possible to run a color emulator and use e.g. the replay program included in the NST package, but the monochrome monitor plays sound data at 71 Hz, the color monitor at 50 Hz. Thus, all MODs will be played at an incorrect speed."

Anche qui, come vedi, parlano dei problemi dovuti alla riproduzione dei moduli, causata dalla diversa frequenza video. A conferma di quanto avevo già scritto in merito.
E qui “This version includes the version 3 of my Paula emulators
; It's totally rewritten and by combining several tricks
; I'm manage to do a 50kHz(!!!) replay routine that only
; takes around 30% and I'm not using any cheats like over-
; sample. This version is indeed four times faster than my
; first replay routine and I hope all you hackers out there
; will like my routine and would like to contact me”

Magari il tuo 30% lo hai pescato da qui, dal file che mi hai fatto scaricare. Ovviamente direi che non sia male per un Tracker con emulazione di un chip all'interno ed esecuzione a 50Khz!! Aggiungerei.. APPERO'!!
E che lo aggiungi a fare? Come vedi i numeri non me li sono inventati, e direi che si tratta di numeri piuttosto consistenti.

Poi se vogliamo essere precisi, non si tratta di un emulatore di Paula, ma di un player di moduli in formato ProTracker. Emulare Paula non è così semplice, anzi: dai un'occhiata ai sorgenti di UAE...
Sull'Amiga non potevi avere 1280*960, ma solo strambe risoluzioni video, che non erano meglio della tanto criticata (da quelli come te) “media” dell'ST.
Sull'Amiga, a partire dal chipset ECS, potevi programmarti le risoluzioni video come volevi (limitatamente all'hardware disponibile, chiaramente).
Non ci hai mai lavorato per ore davanti, non puoi capire cosa significhi usare quel monitor. Ci rimettevi gli occhi con l'interlacciata e con il costo del deinterlacciatore, ci prendevi una schedina video per ST da 900/1000 punti.
No, non ci ho lavorato. Mi sono limitato a riportare le informazioni disponibili in merito.
Vogliamo fare anche un elenco delle possibilita' via scheda d'espansione??
A che serve? Amiga 3000 e 4000 erano molto espandibili grazie agli slot Zorro II e III che permettevano di aggiungere altra memoria, mettere un VideoToaster, una scheda grafica professionale, una scheda DSP, ecc. ecc.
Mah!! E poi TT a 4Gb ne ho visti a palate e non a 2.. nemmeno a 32bit.. bella storia.
Leggi meglio: per "superare i 2GB", come avevo scritto, serve indirizzare la memoria a 32 bit. TT a 4Gb è possibile che tu ne abbia visti, visto che si tratta di 512MB di ram: una quantità notevole per i tempi, ma non impossibile da avere.
E questo dove lo hai letto?? su topolino dell'87??
Sono entrambi del novanta.
http://www.crowl.org/Lawrence/history/computer_list

Posso postartene altri se ne hai bisogno.
Fallo, visto che è una lista che presenta parecchi punti oscuri. Di molti computer non riporta la data, e dell'Amiga 3000 riporta 1990 e poi "Apr 1990".

Comunque mi riferivo all'introduzione dell'Amiga 3000 e del TT in Italia, che è avvenuta nelle date da me riportate.
Il falcon avrebbe dovuto integrare proprio il 68040 con 2 56001, che poi diventarono 030 con un solo DSP per ragioni economiche. Dunque ci e' arrivata eccome, dovresti sapere che fu presentato nell'89 (OTTANTANOVE) il 68040 (SESSANTOTTOMILAZEROQUARANTA).
Coi "se" e coi "ma" non si dimostra un bel nulla: macchine "di classe ST" con 68040 da parte di Atari non ne esistono e non sono state commercializzate. Questa è l'unica realtà tangibile che bisogna accettare.
Certo, il TT era una macchina da CAD, per grandi calcoli a risoluzioni alte e non stancanti, L'A3000 era votata alla grafica per il piccolo schermo. (ovviamente parlo di macchine lisce, senza schede prodotte da terzi).
Allora ti ricordo che l'Amiga3000 poteva lavorare a 640x480 a 60Hz senza interlace, e a 16 colori.
Ho parlato di tecnologia disponibile prodotta ed usata (gia' dall'87 -OTTANTASETTE-) (c'e' chi dice 88, ma sbaglia), dimostrando cosi' che il resto sono solo scelte.. peccato non ci fossi stato tu tra loro a consigliarli per il meglio.
Tecnologie diverse dagli Atari ST e scelte fallimentari. Passiamo avanti.
Stando percio' alle tue deduzioni (corrette), la meta' delle risoluzioni dell'Amiga, erano totalmente inutili al 99% degli utenti.
Indubbiamente. Ma c'erano, e chi voleva poteva utilizzarle.
Nulla.. proprio nulla, non ci capisci nulla ZERO.
Non serve miscelare due calali, non avviene alcuna miscelazione!! NESSUNA. L'STE ha due DAC capaci di convertire segnali ad 8bit a 50Khz. Se gli si richiede di riprodurre DUE segnali ad 8bit ciascuno, questi ne convertiranno uno per ogni ciclo, ovvero un Hz a suono, dedicando gli interi 8bit Ad OGNI canale riprodotto. La miscelazione avverrebbe SOLO qualora si volessero riprodurre due suoni contemporaneamente passando per lo stesso convertitore alla massima frequenza d'elaborazione, Dunque 50 per L'STE e 28 per Amiga. (Ventotto, non ventinove, non conosci bene nemmeno l'Amiga che hai programmato tanto.).
Rileggi meglio quello che ho scritto, perché è evidente che hai preso un granchio.
Quanto all'Amiga, lo conosco benissimo e torno a ripeterti che la massima frequenza riproducibile era di 29Khz. Anzi, fai una cosa: prenditi l'Amiga Hardware Manual pubblicato da Commodore e controlla nel capitolo dedicato all'audio qual è la frequenza massima impostabile PER IL DMA.
L'Amiga possedeva 4 convertitori digitale/analogico a 28Khz L'uno, questi potevano eseguire suoni ad un MASSIMO di 28Khz!!
Stai confondendo i convertitori D/A col DMA: era quest'ultimo a essere limitato a 29Khz.
Qualora si fossero voluti riprodurre suoni a 56Khz(che guarda caso e' il doppio di 28 e non 29), si doveva impegnare pesantemente il DMA,
Come t'avevo già scritto, per superare il limite dei 29Khz DEL DMA, bisognava impiegare la CPU (e non il DMA).
tanto da escludere alcune risoluzioni video ed appesantire notevolmente il computer.
Falso. AudioMaster, che ti ricordo essere stato il primo a introdurre questa possibilità, funzionava a 640x256 o 640x512 (interlacciato).

Il computer veniva appensantito, giustamente, ma rimaneva ampiamente utilizzabile.
Nessuno gioco intatti usava tali frequenze, cosa fatta solo da qualche programmino.
Appunto: i giochi non ne avevano bisogno.
Soltanto programmi di manipolazione audio professionali usavano questa tecnica.
Poi dovrei reperire uno schema tecnico del Paula, per stabilire se i 56 Khz fossero veri o solo interni.
Per quanto riguarda l'Amiga, come ti ho già detto, c'è l'Amiga Hardware Manual della Commodore che riporta anche l'automa a stati della sezione audio, per chi vuol sapere proprio tutto di come funziona.
Sull'ST (ST non STE) esistono dei programmi che suonano in PCM a 50Khz, ma non te li riporto in quanto altrettanto poco attendibili.
Magari era una sorta di oversampling.
No, era una tecnica simile a quella che hai riportato all'inizio, per riprodurre PCM a 22Khz: soltanto che, a frequenze così elevate, chiaramente richiede più potenza di calcolo.
Avendo invece DUE convertitori a 50 Khz, si poteva riprodurre del suono EFFETTIVAMENTE a 50 Khz.
L'YM-2149 ne ha 3 di convertitore D/A, a 4 bit, e la frequenza massima riproducibile era di circa di 120Khz.
Allora sommiamo pure i bit di controlo del volume destinalti ai canali dell'STE (gestito dal DMA o dalla CPU che sia), compresi quelli dell'YM2149.
Cosa intendi con ciò? Non è che puoi rozzamente prendere dei numeri e sommarli.
Qualcuno (pochi) dice che questo sia stato fatto, voglio proprio capire come si possano mescolare i bit del volume assieme a quelli dei DAC o usi i primi o i secondi.

In ogni caso, renderebbe il tutto inutilizzabile perche' a volumi fissi e troppo oneroso in termini di CPU/DMA. (qualora fosse possibile).
Per l'STE sicuramente: guarda qui http://atari-ste.anvil-soft.com/html/devdocu4.htm come si programmano DMA e chip di controllo dell'audio.
Con l'Amiga, invece, ogni canale audio è completamente indipendente: non solo ha un canale DMA "riservato", ma è possibile pilotare direttamente il DAC, spedendogli i dati, e controllando il volume in maniera completamente autonoma rispetto a tutti gli altri.
Non lo escludo completamente solo perche' il Pokey dell'Atari 800/400, poteva unificando a coppie i suoi canali, arrivare alla riproduzione a 16bit. Ma il Pkey non miscelava controlli d'ampiezza con bit di decodifica!!
Spiegati meglio.
Come ho gia' abbondantemente chiarito e documentato, esistono player trasparenti per la CPU anche per l'STE e mooolto leggeri per ST
Come ho già avuto modo di farti vedere, prendendo anche i programmi che tu stesso ai citato, le cose non stanno affatto così, e parte la CPU è presente anche un problema di qualità del segnale.
(e se solo usanti l'ym2149, assolutamente trasparenti).
Ma senza PCM...
Delle risoluzioni e frequenze ne abbiamo gia' parlato.
Ad ogni modo, l'Amiga dalla casa stessa (ed in praticamente tutte le schede tecniche) e dato per 4 canali a 8bit fino a 28Khz. Ci sara' un motivo.
Non so quante volte te lo dovrò scrivere: SE PILOTATI DAL DMA. Se usi la CPU puoi superare i 29Khz e controllare direttamente anche il volume.

Per maggior informazioni, nell'Amiga Hardware Manual ci sono tutte le informazioni su come funzionano i canali audio dell'Amiga, e su come è possibile riprodurre audio SENZA L'USO DEL DMA (per superare i limiti di cui sopra).
Seguiti a confondere i canali con i DAC, Il DMA poteva fornire dati per 50Khz (8bit) a ciascun DAC, che questi dati fossero di uno o due canali non cambia nulla di nulla.
Esattamente ciò che ho detto io: i DUE "canali PCM" sono collegati ai DUE convertitori D/A.
E poi la documentazione in nostro possesso, in ogni caso, non specifica assolutamente il numero di canali gestiti dal comparto DMA, ma solo il numero di convertitori finali.
No, è scritto chiaramente, invece, basta leggere: http://atari-ste.anvil-soft.com/html/devdocu4.htm

"DMA-Soundmode Register:

$FFFF8920 0 0 0 0 0 0 0 0 X 0 0 0 X X X X

Allows to toggle between several replay methods. Bit 7 switches Mono/Stereo (1 = Mono, 0 = Stereo),
[...]
! Stereo Samples have to be organized wordwise like Lowbyte -> right channel Hibyte -> left channel"
La tua abbondanza e' soggettiva, che va contro il dato oggettivo dell'esistenza di player quadrifonici a carico 0 per la CPU.
Sta di fatto, che come ti ho fatto vedere prima, su un normalissimo computer a 8Mhz, girava un tracker a 32 (TRENTADUE) tracce. (qui ti concedo un buon carico della CPU ;) )
Dato oggettivo che non esiste, come ho fatto vedere sopra: tutti i player hanno un prezzo, e piuttosto salato da pagare in termini di carico sulla CPU.
Male, avresti dovuto parlare di entrambi.
Non amo mischiare le cose, visto che si tratta di oggetti diversi.
La documentazione da te fornita non dice assolutamente questo ed anche se lo dicesse, non corrisponderebbe a verita', come visto.
La mia, con tando di funzionamento dell'hardware alla mano, dimostra ampiamente quanto ho già scritto: la tua manca del tutto.
Gia', forse avevi un ST un po' fiacchetto, perche' parrebbe che quelli degli altri ce la facessero. Ti hanno fregato dotto'!!
Dovresti leggere meglio quello che ho scritto: non ho mai negato che sia impossibile farlo. Infatti lo fanno, ma a che prezzo? Riducendo la frequenza di riproduzione. Non ti suona strano che si possano riprodurre 4 canali a 50Khz, ma se si passa a 8 diventano 22Khz? Chissà perché...
Le informazioni tecniche non sono mancate direi. Per il resto.. ti servirebbe orecchio e quello non te lo insegna nessuno.
Infatti le tue mancano del tutto. Per il resto, ribadisco: rigirare la frittata non serve a niente. Porta della documentazione tecnica in merito e ne riparliamo.
Diciamo che non sai programmare un ST.
Mi fai vedere il passaggio logico che, da quanto ho scritto io, porta a questa tua conclusione?
Sempre che tu non asserisca che i programmi da me citati non esistano o siano “finti”. :) Saresti capacissimo.
E' poi piantala con sta storia dei 4 a 56 Khz a costo ZERO.
Rileggi meglio: a 56Khz NON SONO A COSTO ZERO.
L'Amiga secondo la tua testa, poteva aumentare la frequenza a 56Khz (ed anche di piu'!!) per ogni canale a costo minimo, non e' affatto vero, pesava eccome.
Non ho detto che il costo era minimo: il confronto era piuttosto chiaro, mi sembra. Si riferiva alla visualizzazione di 512 colori con l'ST.
Voglio in ogni caso vedere proprio se fosse tecnicamente possibile. Mi faro' rimediare prossimamente il materiale tecnico da chi di dovere. Qualora i DAC fossero a 28 Khz, al massimo i 56 potevano essere emulati. Vedremo.
Non c'è problema: io sono qui che aspetto informazioni tecniche precise in merito da parte tua...
Considera anche pero', la memoria occupata da un suono a “14”bit e 56Khz (oltre al dispendio oneroso in termini di CPU/DMA), un Amiga standard poteva farci proprio pochino!!
Perché stai cercando di cambiare discorso? E' OVVIO che se vuoi ottenere di più devi pagarne lo scotto. Come per tutte le cose.
Piccole cazzate, pressoché inutili, che aumentavano il prezzo.. Siamo sempre lì.
Mi spieghi come facevano ad aumentare il prezzo?
L'Amiga utilizzava semplicemente l'interfaccia standard dei floppy: se questo ha un certo prezzo, è lo stesso per tutti quelli che ne fanno uso (ST, PC, Mac, ecc.)
Se poi gli altri, per qualunque motivo, "castravano" la possibilità di utilizzare fino a 4 drive, erano fatti loro.
Ho parlato piu' che di HW di un accessorio, visto il costo ridicolo e la componentistica interna praticamente assente. La versione per Amiga non era altrettanto veloce.
Stai parlando di un prodotto hardware, e basta: è inutile cercare di rigirare la frittata. Importa poco se la versione per Amiga era più o meno scarsa di quella ST.
Io ho sempre e soltanto parlato del drive in dotazione e del software per copiare i dischi: attieniti a questo discorso.
Sinceramente, puo' essere che mi ricordi male riguardo i 12 settori, anche se si poteva fare, sicuramente non era con l'fcopy.. Con il quale, tuttavia, si puo' giungere a 950k circa, cifra di tutto rispetto, soprattutto partendo da 720.. (senza contare le potenziali 86 tracce, discorso gia' fatto). Dovessi poi ricordarmi come formattavo a 12 settori, te lo faro' presente. Direi che qui possa finire il discorso, non vedendo una gran disparita', considerando anche che l'ST non necessitasse degli stessi quantitativi di memoria su disco dell'Amiga.
Anche per me il discorso finisce qui, in mancanza di documentazione tecnica in merito: non mi va di parlare di aria fritta. Questo vale anche per tutto il resto: nei prossimi messaggi eliminerò ogni riferimento a software o apparecchi hardware non forniti in dotazione.

Quanto alle minori esigenze di memoria su disco dell'ST, era dovuto principalmente ai seguenti fattori:
1) L'hardware più scarso richiedeva spazio minore per fare le stesse cose (es: schermo con al massimo 16 colori, la presenza dell'YM-2149 che non supportava sample, ecc.)
2) l'ST che ha venduto di più e che era il più diffuso è stato il 520, che aveva soltanto 512KB di ram e il drive da 360KB.

Le software house sviluppavano i giochi principalmente per il computer più diffuso, per cui era quello il target.

Per Amiga il target era l'Amiga 500, per lo più espanso a 1MB.
Comunque la tua ultima affermazione conferma la mia precedente. Per la maggior parte degli utenti, gestire 4 (costosi) floppy era pressoché inutile ed alzava solo il costo della macchina.
Non conferma niente perché sfugge del tutto il passaggio logico: mi dimostri, passo per passo, come arrivi a queste conclusioni?
Bilanciato non vuol dire scarso, vuol dire bilanciato. Scarso lo e' solo nella tua visione approssimativa.
Era scarso: è inutile girarci attorno.
Nel suo settore non e' campato meno dell'Amiga nel proprio.
Se ti riferisci alla musica sì. Per il resto, l'Amiga è campato molto più, non soltanto in settori di nicchia, e se vogliamo essere pignoli continua a campare ancora...
Parli di te qui vero?? perché parrebbe proprio che quello con conoscenze sbagliate ed approssimative sia tu, nemmeno l'HW dell'Amiga che hai tanto programmato conosci, hai lacune pesanti sia sull'audio ed il video.
Di cosa parli? Esempi PRECISI, per favore. Così vediamo una volta per tutte chi ricorda male e chi conosce veramente le cose di cui parla.
Non credo che tu possa dirmi come si acquisisca “la conoscenza”, vedi sopra.
Hai solo scritto qualche riga di programmazione piu' di me,
Perché, tu hai mai programmato in vita tua?
ma presenti voragini tecniche molto screditanti.
Come sopra: esempi concreti, per favore. Così vediamo come stanno le cose.
Almeno io non ho avuto la faccia di venir a dire di conoscere l'Amiga meglio di te, (cosa che invece sta emergendo).
Idem come sopra. Aspetto tue nuove in merito.
Avevi di meglio da fare.. Come vedi ritenevi e ritieni ancora, “meglio da fare” il dedicarsi all'Amiga, decisione rispettabile qualora si conoscessero entrambi gli HW e non solo uno (ed anche approssimativamente).
Per ignoranza si sostengono cose strane. :)
Le caratteristiche hardware di due sistemi le conoscevo prima, e adesso semplicemente li conosco nel dettaglio (lato ST chiaramente): ho fatto benissimo a evitare gli ST, perché come programmatore non erano stimolanti, con l'hardware obsoleto e scarso che si ritrovavano.
A sì?? e dove di grazia?? :-/
I player di moduli a costo zero, che non sono affatto a costo zero (e sono gli stessi autori dei programmi che tu hai citato a dirlo).
L'interfaccia MIDI pilotata dal DMA, che invece è una banale seriale programmata dalla CPU.
Per fare un paio di esempi macroscopici.

Altro? Non c'è bisogno che riprenda il thread dall'inizio e riporti punto per punto tutto ciò che hai scritto e tutto ciò che ho trovato che ti smentisce: è sufficiente rileggere...
Menomale che ci si sono messe mani piu' esperte delle tue e delle tue sorgenti “affidabili”.
Che sono anche le tue: il tracker a 32 voci l'hai tirato fuori tu, o vuoi negare anche questo?
Il link con le informazioni tecniche sull'audio dell'STE l'ho preso dallo stesso sito che hai riportato TU con l'elenco dei tracker.
Fatti un giretto per quei link che ti ho postato, magari trovi cose interessanti come dei player a 50Khz per ST.. ST non STE.
Già fatto, e reitero la domanda: a quale prezzo? Certamente non "aggratis", e questo sia in termini di CPU consumata sia in termini di qualità finale (e su questo l'YM-2149 è quello che è: ha 3 DAC a 4 bit, come quelli del SID del C64).
Cosi' leggiadro che rallentava la CPU stessa e gli scarti in talune operazioni erano ben maggiori della differenza di clock tra le CPU.
Fai degli esempi pratici, perché dell'aria fritta non me ne faccio niente: servono i fatti.

Amiga Hardware Manual alla mano, non ho difficoltà a farti vedere quanti cicli di clock richiedeva la programmazione di display, sprite, blitter, copper, canali audio, ecc.
Con la CPU che strillava pieta'
E' inutile cercare di rigirare la frittata: l'Amiga POTEVA FARLO. ST, Mac, e tantissimi altri computer NO.

Poi è chiaro se lanciavi due istanze di Sculpt 4D ad effettuare il rendering di una scena 3D col raytracing, la macchina s'inchiodava. MA ALMENO LO POTEVI FARE.

Come potevi benissimo lanciare player, editor di testo, compilatori, programmi di grafica, ecc. tranquillamente, usando il sistema fluidamente.
e quello sputo di RAM con la quale veniva venduto quel computer, che non poteva permettersi di certo piu' applicazioni contemporaneamente. La sinergia ed il bilanciamento, non erano certo doti Commodore.
Se parli del primo Amiga, il 1000, sì. Con Amiga 500 e 2000, la situazione è cambiata.
Come no, ho giocato proprio ieri a Doom 3 su Amiga!! :))
Questo non dimostra nulla. E comunque Doom e Quake per Amiga esistono, come pure il MAME (e questo è il più recente): perché perdere tempo con una piattaforma "morta"? Perché vuol dire che morta non è ancora.
Poi sindacherei sul “presto”, visto che se da te prospera (forse) un Amiga impolverato, da me prospera un Falcon vivo e lustro, che mi manda avanti tutta la mia strumentazione da anni ed anni senza essersi mai rotto o aver dimostrato limiti di sorta. Come da te c'e' (forse) un'Amiga ancora “vivo”, ci sara' da altri. Come da me C'E' l'Atari, ci sara' anche da altri.
Un computer è "vivo" se viene ancora sviluppato hardware e/o software (a pagamento in particolare). Entrambe le cose sono vere per l'Amiga. Entrambe le cose sono false per gli ST, Falcon incluso.
Quindi il DMA dell'ST era decisamente piu' indipendente dalla CPU.
Lo era quanto quello dell'Amiga: se il sistema era bloccato e il DMA era impostato, potevi continuare ad ascoltare la riproduzione dei sample.
Infatti avresti dovuto parlarne (e due),
Come ho già detto sopra, non amo mischiare capre e cavoli: parlo sempre delle cose giuste nel giusto contesto.
ma ora che ho dimostrato che la gestione di 4 ch DMA sull'STE e' praticamente free, il discorso si puo' concludere.
Non hai dimostrato proprio nulla, e tutti gli esempi che hai portato sono stati smentiti dalle stesse fonti.

Fammi vedere come è TECNICAMENTE (leggi: documentazione dell'hardware alla mano) possibile riprodurre più di 2 canali PCM con l'hardware dell'STE, come posso fare tranquillamente io con l'Amiga, e ammetterò pubblicamente che hai ragione.
In mancanza, continui ad avere torto. E te lo ripeto, nel caso continuassi a "dimenticarlo": non informazioni sul software, ma sull'hardware.
La pubblicita' diceva il vero, i canali DMA PCM erano 4 e senza CPU,
Completamente falso.
discorso valido anche per quelli dell'YM2149f.
Anche questo è completamente falso:
1) non avevana NESSUN canale DMA;
2) non aveva "canali PCM";
3) aveva soltanto 3 DAC (a 4 bit).
Dunque sono 8 ch gratis!! (Pare una tele promozione per un decoder satellitare =D ).
Completamente falso. Ti stai arrampicando inutilmente sugli specchi: io non mollo. O mi porti la documentazione TECNICA su questo discorso, o sei soltanto un bugiardo.
Gia' te l'ho spiegato, ma lo rifaccio, due e' meglio di una. La miscelazione sul fronte dei bit avviene SOLO qualora non vi fosse abbastanza capacita' d'elaborazione da parte dei DAC, altrimenti si alternano i cicli degli stessi senza mescolare in alcun modo i suoni. Ergo, demoltiplicando le frequenze dei segnali, si puo' avere un aumento dei canali senza la perdita di mezzo bit di dinamica. (perdita che avverrebbe in frequenza, ripeto SOLO qualora si volesse superare il limite fisico dei DAC).
Falso, privo di fondamento e va contro la più banale logica. La moltiplicazione dei pani e dei pesci riusciva soltanto a qualcuno...

Se ho due canali a 8 bit indipendenti (ognuno collegato al proprio DAC), in uscita avrò due segnali distinti.

Se ho due canali a 8 bit che vengono miscelati in uno, tramite una qualche operazione, avrò comunque perso parte del segnale originale.
Esempio: come operazione per miscelare i canali, scelgo la media (la più usata in questi casi): sommo i due campioni a 8 bit, dalla somma ottengo un valore a 9 bit (questa è pura matematica), divido per due e ottengo nuovamente un valore a 8 bit (anche questa è matematica).
Cosa ho perso? Sicuramente le frequenze alte dei due segnali, che fanno parte del bit meno significativo di entrambi, che in questo caso è stato praticamente scartato.

Questo è quel che avveniva coi player che utilizzavano la miscelazione. Ti piace come dimostrazione rigorosa di come vanno veramente le cose?
Ovviamente la miscelazione, quando richiesta, ad esempio volendo riprodurre piu' canali alle frequenze massime dei DAC, comporta una perdita di qualita' dipesa in linea di massima dalla qualita' della miscelazione fatta dalla CPU. Questo discorso e' RARO, nonché valido per entrambe le piattaforme.
Vedi sopra: la CPU non c'entra proprio nulla. La perdita di qualità / precisione dei segnali originali è insita nel meccanismo stesso di miscelazione, come ho dimostrato (rigorosamente) sopra.

Se sei capace di darmi una dimostrazione altrettanto rigorosa che smentisca la mia, fatti pure avanti.
Vedo che hai capito tutto. Non ne dubitavo. Comunque se avessimo un dac a qualche Ghz, direi proprio di sì.
Anche se avessi un DAC simile, l'operazione di miscelazione dei campioni è un'operazione che di per sé porta via qualità e precisione: al DAC arrivano delle informazioni GIA' CASTRATE. Ed è esattamente quel che succedeva e che ho dimostrato (rigorosamente).
Oh, ma guarda cosa leggono i miei occhi!! =D
Prima fai lo sborone portando l'esempio del laser, per lasciar intendere che fosse una cosa richiedente qualita' audio “eccezionali”, poi dici “4 BIT POSSONO NON BASTARE” :) Che duci ca si' Dotto'.
**QUATTRO bit POSSONO non bastare, DUNQUE potrebbero anche BASTARE**, siamo lì lì.. Non va bene come esempio!!
Come prima, è inutile che cerchi di rigirare la frittata: il mio discorso era piuttosto chiaro. Dipende tutto dall'ambito applicativo, come dicevo. Se per fare un certo lavoro mi bastano 4 bit di risoluzione, anche i DAC dell'YM-2149 dell'ST possono andare bene. Se mi servono 8 bit, è chiaro che non basteranno. Semplice. Logico. Ovvio. Lapalissiano.
Gli 8 bit PCM dell'YM2149f bastano di sicuro!!
8 bit PCM? E dove sarebbero? Non esistono: quel chip ha 3 DAC a 4 bit.
Sei di coccoarmato!! il mio intento era quello di dimostrarti COME NON SOLO IO ABBIA IPOTIZZATO UN'EVOLUZIONE DI QUEL PROCESSORE. Te l'ho dimostrato,
Dobbiamo ridere o piangere? Il fatto che qualcun altro abbia avanzato certe ipotesi, cosa dimostra? NULLA. Con la fantasia siamo tutti bravi a viaggiare, è quando ci si scontra con la realtà (leggi: i limiti della tecnica) che arrivano le batoste.
dato che tu mi hai contrastato dandomi del incompetente
Perché, non è forse vero? Hai competenze in materia? Non sai come funziona internamente un 68000, figuriamoci un x86 moderno o un Power: puoi soltanto giocare con la fantasia, non affrontare un discorso sul piano rigorosamente tecnico (e quindi confrontandosi con la realtà).

Dovresti essere abbastanza maturo per riconoscere le tue competenze, e quindi ciò per cui vale la pena spendersi e parlare, e quello che è meglio evitare.
e dicendolo impossibile.
Come ho già ripetuto più volte, NON METTERMI IN BOCCA COSE CHE NON HO MAI DETTO.
Mi fai vedere dove l'avrei detto? La prossima volta invece che citare qualcosa che poi non esiste, RIPORTA INTEGRALMENTE LE FRASI. Così evitiamo di ricadere negli stessi errori.
Ti ho dimostrato che ci sono altri “ignoranti” e visionari come me. PUNTO fine dell'argomento!!
OK, questo è assodato e non ne parliamo più.
I problemi si sarebbero potuti risolvere.. lo 060 docet.. completamente diverso dallo 040
Ancora? Ma non avevi finito con quest'argomento? Ti ho già spiegato come stanno le cose TECNICAMENTE: o lo capisci e allora dovresti chiuderlo qui, oppure non lo capisci e lo chiudi per una questione di buon senso, visto che sarebbe inutile continuare perché non sei in grado di sostenere una discussione tecnica su questo punto.
Quando il PC si diffuse grazie alle VGA era messo meglio dell'Amiga, del C64 e dell'ST messi insieme.
Non te lo lascio proprio dire. E comunque stai parlando di un periodo in cui C64 e ST erano morti, e l'unico che poteva e ha continuato a competergli per un bel po' di tempo, è stato proprio l'Amiga. Questo riviste di computer e di videogiochi dell'epoca alla mano, ovviamente.
Tutto sbagliato, non ricordi una sola data corretta. Forse sei uno dei pochissimi a non ricordare The Secret of the Monkey Island 2 a 256 colori sul pc.. Non era il 96, bensì il 91!! Sai quella cifra con prima il NOVE e poi L'UNO?? ecco, quella!!
Appunto, vedi sopra.
Parentesi: TUTTI quei giochi, da maniac mansion a zak mckracken, da future war ad Indiana Jones, usavano l'MT 32 sull'ST.. dal quale oltre alla musica, uscivano fuori i vari suoni, tipo passi, bussate ecc.. il tutto con 32 toni di polifonia. (era tanto per citare il fatto che nessuno lo usasse).
E chi poteva farne uso? Soltanto quelli che avevano l'MT32, appunto, ossia una sparuta minoranza considerando il parco dei videogiocatori.
Sempre nel 91 circa arrivarono le SB16..
Proprio la stessa cosa dell'audio dell'Amiga... Di più aveva soltanto il supporto ai campioni a 16 bit: ottima cosa dal punto di vista della qualità del segnale, ma per riprodurre più di due canali doveva miscelarli... come con l'STE. Quindi consumava potenza di calcolo della CPU.
e nel 93 sul pc si poteva giocare a Doom, evoluzione di Wolfenstein 3d disponibile gia' da molto tempo prima e chi non aveva un PC, poteva solo “rosicare”.
Per Amiga sono usciti parecchi titoli che utilizzavano grafica 3D texture mapped, con correzione prospettica, ecc: mai sentito parlare di Breathless, Gloom, ecc.? E sono arrivati anche Doom e Quake, come dicevo. Roba del genere sull'ST s'è mai vista? No. Era già morto... mentre l'Amiga era l'unico a continuare a competere col PC. Prendi le riviste dell'epoca, visto che le hai citate, e dagli un'occhiata...
E lo confermo, sei tu che non capisci il senso dei discorsi. Quando scrivevo “parli dell'96 o dell'86” ero ironico, visto che il panorama che descrivi sembrerebbe sfasato di quasi 10 anni.
Non sono nella tua testa, non usi faccine né strumenti linguistici per far trasparire la tua ironia: la prossima volta sii più chiaro.
Ti ho spiegato cosa non mi piaccia di Wikipedia, ovvero l'inattendibilita' delle fonti, che possono essere giuste quanto possono non esserlo. Se tu scrivessi un articolo per loro relativamente all'ST/STE, la gente riceverebbe un'informazione incompleta ed errata.
Continui a rigirare la frittata, ma con me non attacca: aspetto ancora una tua risposta. Se consideri Wikipedia inaffidabile, quando l'hai citata a sostegno delle tue idee, stai dimostrando che erano basate sul nulla. E quindi false. Rispondi una buona volta e dacci un taglio: ritieni che quel che TU hai riportato da Wikipedia sia inattendibile? Non ci vuol molto: basta un sì o un no.
Ed a quanto pare pure se lo scrivessi riguardo l'Amiga, stando alle ultime battute.
Idem come sopra: è inutile che cerchi di rigirare la frittata.

Quel che so e ho riportato sull'Amiga trova ampia conferma, anche e soprattutto nella documentazione tecnica della Commodore.
Che risposta vuoi??
Vedi sopra: visto che sono contrastanti, ritieni wikipedia oppure l'altro sito inaffidabile? In base alla tua risposta, dedurrò che una delle due informazioni che hai riportato prima è falsa.
Grazie per la traduzione, ma non mi serve. Quando tu dicesti “come e' stato emulato il Jaguar, possono EMULARE anche il Falcon, io risposi dicendo che non esiste un emulatore Jaguar funzionante come si deve. E' la verita'. Punto.
E' vero che l'emulazione del Jaguar pecca, perché debbono aggiungere ancora delle cose: io avevo provato soltanto Alien contro Predator e andava bene. Ciò non toglie la validità di ciò che avevo scritto: l'emulazione (perfetta) di Falcon si può realizzare, purché ci sia qualcuno che ci dedichi tempo.
Il punto e' proprio questo, non viene emulato il computer, ma il suo comportamento, troppo spesso le applicazioni escono dal sistema operativo e vanno a colloquiare con l'HW. E' un concetto sballato, quelle macchine erano belle per questo, perche' le “tiravi”, se gli togli questa prerogativa, tanto vale tenersi un pc.
Come ti ho detto sopra, è soltanto una questione di trovare qualcuno che sia disposto a perderci tempo.
L'emulazione dell'Amiga è pressoché perfetta, sebbene il funzionamento dell'hardware sia alquanto complesso: le macchine vengono emulate al ciclo di clock, quasi come se fossero vere. La compatibilità infatti è elevatissima, con qualunque tipo di software, anche se sconfina con l'hardware e fa delle porcate.
Eppure travisi troppe cose (e non ho detto tante, ho detto troppe).
Non mi pare proprio: di tutti quelli che seguono il thread, nessuno si è lamentato, anzi.
A quanto pare, le conosco meglio di te 'ste due macchine. Chissa' come si spiega questo. La piu' grossa differenza tra me e te, consiste nel fatto che io le conoscevo tutte (qualcuna piu' qualcuna meno), compreso l'archimedes e so pregi e difetti di ognuna di esse. Non mi limito a bollarne una senza averci mai messo le mani per piu' di 30 secondi, dicendo inesattezze e pretendendo di imporle come vere.
Anch'io le conosco (anche l'Archimedes e le varie evoluzioni), ma che tu utilizzi o meno una macchina, se l'hardware funziona in un certo modo non puoi scappare: i limiti sono noti e non ci puoi fare niente.
Guarda, io senza argomenti non ci resto MAI, non parlo di cose che non conosco. Non provare a dire simili cavolate, non ci fai bella figura.
Vogliamo ricominciare dal 68000 a 16 bit? Mi sembra evidente che tu i computer li abbia soltanto usati, e invece io mi sono documentato sul loro funzionamento: non puoi pretendere di dirmi come funzionano raccontando delle storielle. Servono i fatti, ampiamente documentabili, e di carattere tecnico.
Una persona e' fatta di cio' che ha vissuto, di cio' che ha studiato, di cio' che ha dimostrato. (e ti prego non sindacare riguardo le reciproche dimostrazioni, perche' sai come andrebbe a finire).
C'è poco da sindacare: tu non di dimostrazioni non ne hai fornito neppure una finora.
Il mio e' un parere insindacabile, dettato dal mio gusto e quello di chi come me, ti vede parato dietro lo scudo del tuo “titolo” (nemmeno fossi un libro ;) ).
Come t'ho già scritto parecchie volte, è inutile cercare di rigirare la frittata. Piuttosto salta la frase e non rispondere, che è meglio. Altrimenti sarà costretto a chiederti nuovamente la stessa cosa:

"Se è insindacabile, non capisco il motivo delle tue considerazioni: è una contraddizione in termini. "
Ogni volta ti posto link su link e spiego tutto cio' che dico TUTTO, tu seguiti a dire che questo non sia vero.. A me non piace perdere tempo. Fermo restando che chi legge sa che il tuo dire “non hai dimostrato”, non fa testo quando e' in presenza delle dimostrazioni stesse.
Veramente sono gli stessi link che riporti che dimostrano la falsità delle tue affermazioni che dovrebbero supportare. Di questo ne ho già parlato sopra, comunque.
Ma sì, parliamone cosi' emerge ancora meglio come tu non sappia leggere (o se ti offende, dico “capire”, ti do la possibilita' di scegliere)..
Né l'una né l'altro: ho padronanza di entrambe le cose. Ti ho già detto di evitare di spostare la discussione sulle offese: se continui sarà costretto a richiedere l'intervento del moderatore.
All'inizio del thread, cosi' come in altre 6000 occasioni prima e dopo la creazione dello stesso, ho detto CHIARAMENTE, di non aver MAI paragonato un 486 ad un 68000, questa e' stata SOLO la tua scusa per attaccarmi all'inizio e fare il superfico dei miei stivali, dunque se giudichi una cazzata paragonare quelle due CPU,
Come ho già fatto altre volte, ti ricordo che questo:

"un motorola 68000 a 16 bit a 8mhz ha il potenziale di un 486 a 32bit a 66mhz"

l'hai scritto tu e non io.
ti informo felicemente che lo hai fatto TU!! lo hai fatto anche con confronti tecnici. Non girare a me le tue cazzate, grazie.
OK, fammi vedere dove e cosa avrei fatto.
Io dissi semplicemente che l'efficenza di vecchi sistemi come l'Atari e l'Amiga spesso, fosse maggiore di quella delle architetture basate su CPU x86. Portati diversi esempi di programmi che sull'ST a 8 Mhz (che tutto il mondo tranne te, definisce ad 16 bit), dovettero aspettare dei 486 a 66 Mhz per girare allo stesso modo (ed alcuni addirittura dovettero aspettare CPU superiori al Ghz).
A me sembra che la frase di cui sopra dica qualcosa di ALQUANTO DIVERSO.

Quanto ai programmi, ti ho già risposto sull'argomento: non puoi confrontare capre e cavoli.
Questo non significa che io ritenga il 68000 piu' potente di un 486, significa solamente che l'architettura PC-Compatibile, e' (e soprattutto era) una vera cagata.
Idem come sopra: quella frase dice TUTT'ALTRO. E anche quest'ultima che hai scritto, è stata già smentita nel corso del thread.
Non significa nemmeno che quello che poteva fare un PC basato su 486, potesse essere rifatto da un computer basato du 68000.
Adesso stai parlando di interi computer: prima parlavi soltanto dei singoli processori.
Odio dire le cose due volte, ma mille e' proprio inutile. Tanto traviserai anche questa volta. Ridarai tutta la colpa all'opinabilita' delle mie affermazioni
Non c'è bisogno: le tue affermazioni si commentano da sole. Quella tua frase è stata piuttosto infelice: faresti bene ad ammettere di aver detto una balla colossale e a chiuderla qui.
(come se non lo si sapesse quanto il cubase su pc abbia avuto seri problemi precisione) ed a (improbabili) problemi di “porting”.. anche per programmi e versioni mai scritte per 68000 (per rimanere in tema, vedi il VST che presentava i medesimi problemi).
Idem come sopra: ti ho già detto come stanno le cose. I problemi di porting ci sono da sempre.
Il cubase Audio del mio Falcon gestisce 160 (CENTOSESSANTA) canali midi (e non e' il suo massimo teorico) e suona i sample in RAM a 16bit (fino a 50Khz) con latenza pressoché zero. Senza l'ausilio di schede separate da 250€ MINIMO (oggi, al tempo milioni su milioni). E con 4 mega di RAM!!
Fallo fare ad un 386 a 16 Mhz del tempo (e magari limitiamone pure il costo alla parita'). Ci sarebbe da ridere.... e non poco.
Idem come sopra: non puoi confrontare capra e cavoli, e tirando fuori anche il 56000 di Motorola, che è un signor DSP. Prima di tutto c'è una disparità di hardware (il DSP, appunto, assente in quei PC), e poi i programmi sono diversi. Pilotare una MIDI (che è una semplice seriale), come ti ho già detto, è una banalità.
Portarmi un DOCUMENTO, rappresentante la fantasia di un paio di progettisti, non e' una gran prova di nulla.
I PROTOTIPI da me citati erano funzionati (avevano addirittura gia' il case per la commercializzazione) e prodotti nel periodo di floridita' delle due case in questione.
Quelle macchine furono “lasciate” in cambio di migliori compromessi tra qualita', leggerezza de sistema, tecnologia disponibile (perche' non basta avere tre super chip per fare un super computer) e prezzo.
Da uno nacque l'STE, mentre l'altro spiano' la strada al Falcon. Uscito, vivo e vegeto. Gli esempi che ti ho fatto non sono assolutamente Casuali come invece lo e' il tuo.
Infatti io ti ho detto e ti continuo a ripetere di parlare sempre e soltanto di modelli regolarmente commercializzati. Punto.
In una moltitudine di occasioni che per ovvie ragioni non mi metto a ricercare, ma tranquillo, io non me la prendo, dovresti avere un peso perche' questo possa accadere. In fin dei conti sono solo un troll, non ti capisco nemmeno. ;)
OK, allora vuol dire che non sei in grado di dimostrarlo.
Beh, se proprio vogliamo ammettere l'ipotesi che tu sappia leggere a questo punto comincia anche a “saper capire”(come ipotizzato poc'anzi). Perche' se io scrivo A e tu poi dici che dico cazzate perche' ho detto B, non dai l'impressione di saper capire/leggere bene.
Idem come sopra: evita l'offesa, perché la prossima volta richiederò l'intervento dei moderatori. Attieniti alla discussione tecnica: se non sei in grado di farlo, non scrivere.
Un bacio ai pupi.

Matteo.
Idem come sopra.

Inoltre dal prossimo messaggio taglierò tutte le parti in cui disquisisci sul software senza portare link con documentazione TECNICA, e risponderò sempre allo stesso modo: richiedendo queste informazioni.

Con te ho perso anche troppo tempo.

[cdimauro]

Vero. :)

Hai programmato giochi per Amiga e/o altre piattaforme?

[Marco71]

Pensi Dr. Di Mauro che nel 1990 all'esame orale della maturità all'I.T.I.S locale qui di Lucca quando dissi al presidente di commissione (esterna all'ora) che avevo due Amiga 500 (ed ho tuttora) mi disse che il progetto "Lorraine" era molto migliore di quello su cui erano basati gli Atari ST...
A proposito ST oppure come acronimo S.T ?
Grazie.

Marco71.

[shodan]

Ciao cdmauro,

volevo farti una domanda: a quale/quali risoluzioni un'amiga 500 poteva utilizzare 4096 colori? Questi colori potevano essere visualizzati tutti insieme oppure si poteva solo scegliere alcuni colori (256 ad esempio) su una palette di 4096?

Ciao grazie. :)

[Mark0]

Se posso permettermi, visto che passo di qua...

Con l'OCS (il chipset canonico dei 500/200) in 320x256 e 320x512 interlacciato (più le relative versioni overscan).
Tutti i 4096 colori erano utilizzabili contemporaneamente, ma con qualche vincolo, in modalità HAM (Hold And Modify). HAM consentiva di realizzare l'effetto utilizzando solo 6 bitplane, quindi 6 bit per pixel anzichè i 12 che sarebbero stati necessari normalmente (suppongo che Denise supportasse solo 6 bitplane, per cui...).
I primi 2 bit costituivano un selettore che indicava cosa rappresentavano gli altri quattro, ovvero:
- un colore da una palette di 16
- una delle 3 componenti cromatiche (RGB); in questo caso le altre 2 venivano ereditate dal pixel precedente (da qui il perchè di HAM)

Per quanto sopra HAM era perfetto per immagini statiche (fotorealistiche, rendering, etc.), mentre presentava qualche ovvia complicazione nel caso di animazioni (o, meglio, modifiche / manipolazioni).

Il tutto se la fallace memoria non m'inganna (nel caso sono sicuro che cdimauro chiarirà opportunamente)! :)

Aprofitto per i complimenti a quest'ultimo per la competenza ma, soprattutto, la pazienza nel ribattere con le necessarie precisazioni tecniche punto per punto nelle ultime tot pagine! :D :D

Bye!

[LordPBA]

:D
Che diatribra ragazzi! Mi riporta indietro nel tempo ai primi numeri di TGM!! Che tempi... nostalgia :cry: ehehe

[cdimauro]

Pensi Dr. Di Mauro
Cesare, semplicemente Cesare: altrimenti dovrei chiamarTi Ing. Marco, no? :p
che nel 1990 all'esame orale della maturità all'I.T.I.S locale qui di Lucca
Anch'io mi sono diplomato nel '90, ma all'ITIS di Siracusa. :)
quando dissi al presidente di commissione (esterna all'ora) che avevo due Amiga 500 (ed ho tuttora) mi disse che il progetto "Lorraine" era molto migliore di quello su cui erano basati gli Atari ST...
Beato tu. Quando ho cominciato a parlare di Amiga e lanciare strali contro i PC, e gli Olivetti in particolare, non feci una buona impressione: un membro della commissione era di Ivrea... :asd: :)
A proposito ST oppure come acronimo S.T ?
Grazie.

Marco71.
Francamente non so.

[cdimauro]

Amiga, Cd 32 con devel board (che ho ancora in casa.. ;) ).
Beato tu. :) Il mio rammarico è di non aver potuto finire i test sulla porta seriale, ma soprattutto di non aver mai programmato per il CD32 (Akiko m'interessa molto, e in particolare la conversione chunky-to-planar). :(
A proposito.. mi interessa quella tecnica del mod player tramite copper.. :)..come avevi fatto?
Il problema principale che volevo risolvere col mio player era di non legarlo troppo alla CPU, obbligandola ad aspettare una determinata riga di raster per impostare i canali audio.

Questo perché, come sai, quando ci sono dei cambiamenti da effettuare per un determinato canale audio che è già attivo, dopo aver bloccato il canale DMA, bisogna aspettare almeno una riga di raster per poterne impostare i nuovi valori (la logica di controllo dell'audio effettua il fetch dei dati all'inizio di ogni riga di raster).

Quindi, a parte la classica elaborazione che avveniva ogni frame (come tutti i player), dovevo:
- aspettare sempre una determinata riga;
- bloccare il DMA dei canali che hanno subito dei cambiamenti e "stoppare l'audio";
- aspettare la riga successiva;
- impostare i nuovi dati.

Gli altri player risolvevano col polling (obbligando la CPU a controllare il pennello elettronico) o con gli interrupt (facendo generare al Copper un interrupt per ogni riga per cui si doveva fare quanto sopra).

Io ho risolto costruendo dinamicamente la copper list, inserendo una CWAIT all'inizio della prima riga, poi una serie di CMOVE per bloccare l'audio, un'altra CWAIT per aspettare la riga successiva, e infine i CMOVE necessari che impostavano i nuovi valori per i corrispondenti canali audio.

Questo perché, fortunatamente, i registri dell'audio facevano parte del range indirizzabile dal Copper (i primi registri dei chip custom non lo erano).

In questo modo ho ridotto al minimo il consumo di CPU per la gestione dei canali audio, ma soprattutto ho svincolato la CPU da questi compiti.

Quest'ultimo punto era molto importante per me, perché nei giochi che ho sviluppato non potevo avere la certezza che la CPU fosse sempre disponibile all'inizio di ogni riga interessata, in quanto poteva trovarsi in mezzo a un'operazione (anche pesante) del Blitter, che la lasciava senza alcun ciclo di clock disponibile fino al completamento dell'operazione di blitting, e quindi introducendo qualche volta delle distorsioni nell'audio.

Infine il polling avrebbe consumato troppa potenza di calcolo inutilmente e gli interrupt non li avrei potuti comunque utilizzare (nel codice finale impostavo sempre il puntatore allo stack supervisore a un indirizzo inesistente e dispari, in modo da spedire al creatore l'intero sistema nel momento in cui qualche furbo dotato di Action Replay avesse premuto il tasto di freeze per dare un'occhiata al mio codice... :asd: :)).

Una curiosità: a quali giochi hai lavorato? Sono stati commercializzati?

x Mark0: grazie per l'apprezzamento. :) La pazienza comunque non è infinita, e ripetere le stesse cose mi scoccia, per cui in futuro i miei interventi potrebbero ridursi notevolmente...

[cdimauro]

Hummm.. il player che utilizzavo di solito era in sync con il raster, al momento del blank per il ritorno del pennello, veniva lanciata la routine di esecuzione del player. Poi siamo passato a un player svincolata dalla frequenza del refresh, ma utilizzando i timer interni, in modo che anche sul mercato americano non ci fossero problemi.
Noi invece abbiamo sviluppato esclusivamente per il mercato europeo e avendo come riferimento le macchine PAL.

Supportare anche NTSC sarebbe stato un problema notevole, perché c'avrebbe obbligati a ridimensionare tutta la grafica. Principalmente perché per muovere la stessa quantità di grafica CPU e Blitter non avrebbero avuto abbastanza tempo per portare a termine il loro lavoro prima dell'inizio del frame successivo.

La musica, invece, avrebbe richiesto il "solo" riadattamento degli "spartiti".
Ovviamente sono + cpu consumer, un approcio come il tuo mi fa' venire in mente un problema, se vuoi gestire l'effettistica (vibrato, portamento etc) devi comunque fare gestire il tuttto alla cpu che sulla base dei pattern ti genera la copperlist adatta con i volumi e i toni corretti.
Sì, infatti, questo era l'unico problema, ma usando sempre le copper list era facile da risolvere, e soprattutto la CPU non doveva caricarsi di questo compito (usando gli interrupt venivano consumati troppi cicli di clock)
Ho lavorato su due giochi: Dangerous street che usci in bundle con il CD32, e Rally Championship commercializzati entrambi dalla Microvalue-Flair.
Non ci posso credere!!! Eravate i nostri concorrenti negli stessi settori: picchiaduro e corse automobilistiche! :)
La vita riserva strane sorprese... :p
Parlando del CD32 Akiko era un cessetto.. :). Oddio avrebbe aiutato se il processore fosse stato almeno un 68030. Il problema e' che akiko era una semplice rete latch che routava di 90 gradi un pattern di longword in modo da ottenere una distribuzione planare di una bitmap chunky. Solo che il latch non era una scheggia. Tant'e che soluzioni software su 68030/40/60 erano un tocco piu' veloci. Se avessero implementato akiko in DMA allora forse avrebbe apportato un bel vantaggio in termini prestazionali. Akiko invece era CPU driven.. :(
E' un vero peccato. Non mi sono perso niente allora... ;)

[Crisp]

E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486... ;)


Sulla carta lo 060 potrebbe essere paragonabile ad un Pentium 60, ma in pratica un 486dx2 era decisamente superiore.
Superiore mica come archiettettura o caratteristiche :O

Il software scritto per 68060 (AmigaOS) era talmente scritto con in piedi e con l'uso di compilatori scadentessimi (SAS/C) che gia c'era pochissia differenza tra 68040 e 68060 e peggio ancora con un x86 come i 486, dove il codice era altamente otimizzato per quel processore. ;)

avevo un 486dx2 a fianco di un Amiga1200 68040/40 mhz e ho visto bene il massacro che la cpu x86 faceva contro la cpu 68k (e lo 040 aveva una fpu simil risc, e pipelined).
E ho pure fatto fare qualche prova a chi aveva un 68060 per vedere altre deficienze del software 68k amigaos.

Cmq sia il 68060 era superiore a tutti i 486 nell'esecuzione di brani mp3 a 44k, stereo, 128 kbit.

[^TiGeRShArK^]

spettakolare l'assembly 68000...
c'erano istruzioni ke definire complesse è un eufemismo! :D

[cdimauro]

Il software scritto per 68060 (AmigaOS) era talmente scritto con in piedi e con l'uso di compilatori scadentessimi (SAS/C) che gia c'era pochissia differenza tra 68040 e 68060 e peggio ancora con un x86 come i 486, dove il codice era altamente otimizzato per quel processore. ;)
Non te lo lascio dire. Tant'è che quando arrivò il Pentium si vide che le raccomandazioni di Intel per ottimizzare il codice per farlo girare meglio su quest'architettura, sortivano inaspettati e notevoli benefici anche per i 486...
avevo un 486dx2 a fianco di un Amiga1200 68040/40 mhz e ho visto bene il massacro che la cpu x86 faceva contro la cpu 68k (e lo 040 aveva una fpu simil risc, e pipelined).
E ho pure fatto fare qualche prova a chi aveva un 68060 per vedere altre deficienze del software 68k amigaos.
Che dire: dipende dal software. Tanti, come diceva giustamente W4rfoX, programmavano in assembly, ottimizzando "a mano" il codice, e in questi casi il 68060 era un vero mostro macina-numeri.

x ^TiGeRShArK^: il bello è che la famiglia 680x0 non è che avesse tante istruzioni... Poche ma buone e con tante modalità d'indirizzamento che facevano la gioia dei programmatori a basso livello... L'impostazione dell'architettura faceva il resto... :p

[Marco71]

Ben ritrovato Dr. Di Mauro...innanzi a tutto le auguro buone vacanze ovunque lei si trovi...
Come "innamorato" della famiglia 68000 poi non posso che genuflettermi di fronte alla sua esperienza e capacità...
L'unica cosa che rimprovero a Motorola è di avere risparmiato sul numero di transistor proprio nei "blocchi" che più mi interessavano allora ed adesso: nella unità f.p.u...
Quando su un numero di "Bit" di allora lessi che non avevano implementato le funzioni trascendenti mi misi a piangere "interiormente" dato che purtroppo la vita esige molto spesso il mascherare ed il dissimulare ciò che realmente si prova (come dicono nei forum...I.M.H.O).
Mi dice, non avrebbe una fotografia del silicio dell'MC68040 (o meglio di 68000, 68020,68030 ecc.) ?
La ringrazio e continuo a "stare alla finestra" della vostra discussione...
Grazie.

Marco71.

[Crisp]

Non te lo lascio dire. Tant'è che quando arrivò il Pentium si vide che le raccomandazioni di Intel per ottimizzare il codice per farlo girare meglio su quest'architettura, sortivano inaspettati e notevoli benefici anche per i 486...


si, ok come il caso di Quake :)
Ma non fu voluto però, è stato chi lo ha programmato ad essere davvero bravo :)

Però l'abilità dei programmatori su pc si vedeva, guarda il caso di Screamer Rally, di DarkForces, di Duke Nukem 3D che giravano bene anche su 486dx2.
Il 68040 e il 68060 era pienamente in grado di far girare questi titoli forse meglio della cpu x86 che in confronto alle cpu Motorola era davverò senza confronto eppure..

Apple ha messo in pensione le cpu 68k appena gli è stato possibile, non gli è manco interessato provare il 68060 e già su 040 si riuscivano a fare cose che sullo stesso 040 su amiga era impossibile.
Ah ecco un caso di pessima programmazione Amiga 68k: Emulatore Megadrive :)
Su 486sx33 emulazione perfetta, su amiga almeno un PowerPC :)
Froto su 060 e scheda grafica è lentissimo, per emulare un C64, ma quello è colpa dei programmatori, perchè lo stesso frodo su un Mac emulato da uno 040 con shapeshifter fa grirare Frodo al 100% :)

Quindi le cpu 68k erano ottime cpu e i programmatori sembrano aver fatto di tutto per abissarle..:(
Basta vedere le stesse applicazioni su amigaOS e MacOS..

[cdimauro]

Ben ritrovato Dr. Di Mauro...innanzi a tutto le auguro buone vacanze ovunque lei si trovi...
ARGH. Perché mi dai sempre del lei? :(

Comunque auguri anche a te agli altri: sono appena rientrato dalle ferie... :p
L'unica cosa che rimprovero a Motorola è di avere risparmiato sul numero di transistor proprio nei "blocchi" che più mi interessavano allora ed adesso: nella unità f.p.u...
Quando su un numero di "Bit" di allora lessi che non avevano implementato le funzioni trascendenti mi misi a piangere "interiormente" dato che purtroppo la vita esige molto spesso il mascherare ed il dissimulare ciò che realmente si prova (come dicono nei forum...I.M.H.O).
Anch'io ho storto un po' il naso quando, col 68040, Motorola eliminò buona parte di quelle istruzioni dell'FPU 68882. Poi, però, vedendo che con l'apposita libreria giravano del 50% più velocemente a parità di clock (prendendo 68030 e 68882 come riferimento), mi sono in parte ricreduto.

Dico in parte, perché capisco che un processore come il 68040 (e peggio ancora il 68060) è particolarmente complicato (a livello implementativo). Ma una cosa che non ho mai digerito di Motorola è il fatto di avere cambiato l'ISA della modalità utente.
Passi per quella supervisore, che è dominio del "sistema operativo" e dove giustamente col tempo subentrano parecchie modifiche (es: la MMU si è evoluta molto col tempo, dal 68020 / 68851), ma non sono mai riuscito ad accettare la "castrazione" di alcune istruzioni nella modalità utente.

Questo è accaduto per le funzioni trascendentali col 68040, e con la MOVEP e LMUL / LDIV (se non ricordo male) col 68060. Anche se la MOVEP, ad esempio, è stata usata MOLTO raramente (a parte con gli ST :asd: ), non vedo il motivo per cui doveva essere eliminata, visto che faceva parte dell'ISA fin dal 68000... :(
Mi dice, non avrebbe una fotografia del silicio dell'MC68040 (o meglio di 68000, 68020,68030 ecc.) ?
C'era su qualche numero di MC MicroComputer del '90, se non erro, ma ormai da qualche mesetto sono seppelliti nel garage di mio padre... :p
La ringrazio e continuo a "stare alla finestra" della vostra discussione...
Grazie.

Marco71.
Non hai di che ringraziare nessuno: qui è un dare e un avere. Leggo con piacere i tuoi interventi nel campo dei dischi rigidi... :)

Ciao
Cesare

[cdimauro]

si, ok come il caso di Quake :)
Ma non fu voluto però, è stato chi lo ha programmato ad essere davvero bravo :)
Veramente io ricordo che quella notizia non fu legata a Quake o a qualche altro software, ma saltò fuori poco tempo dopo la presentazione del primo Pentium. Comunque è passato parecchio tempo, e può darsi che la mia memoria faccia cilecca... :p
Però l'abilità dei programmatori su pc si vedeva, guarda il caso di Screamer Rally, di DarkForces, di Duke Nukem 3D che giravano bene anche su 486dx2.
Il 68040 e il 68060 era pienamente in grado di far girare questi titoli forse meglio della cpu x86 che in confronto alle cpu Motorola era davverò senza confronto eppure..
Stai parlando di titoli 3D, quindi che utilizzavano la modalità chunky pixel delle VGA e delle "moderne" schede grafiche in generale. La modalità a bitplane utilizzata da Amiga, Atari STx, ecc. mal si prestava per il 3D, se non realizzato "alla vecchia maniera", con poligoni al più retinati (e usando il Blitter).
Apple ha messo in pensione le cpu 68k appena gli è stato possibile, non gli è manco interessato provare il 68060 e già su 040 si riuscivano a fare cose che sullo stesso 040 su amiga era impossibile.
Ah ecco un caso di pessima programmazione Amiga 68k: Emulatore Megadrive :)
Su 486sx33 emulazione perfetta, su amiga almeno un PowerPC :)
Froto su 060 e scheda grafica è lentissimo, per emulare un C64, ma quello è colpa dei programmatori, perchè lo stesso frodo su un Mac emulato da uno 040 con shapeshifter fa grirare Frodo al 100% :)

Quindi le cpu 68k erano ottime cpu e i programmatori sembrano aver fatto di tutto per abissarle..:(
Basta vedere le stesse applicazioni su amigaOS e MacOS..
Dipende dalle applicazioni. Come tu stesso hai riportato con quegli esempi, è evidente che spesso ci si è trovato davanti a problemi dovuti a cattiva programmazione, non a carenze architetturali (fatta eccezione per il 3D, per cui vale quanto scritto sopra).

[Mark0]

Mi dice, non avrebbe una fotografia del silicio dell'MC68040 (o meglio di 68000, 68020,68030 ecc.) ?
Io ho trovato queste: Molecular Expressions: Chip Shots - Motorola Integrated Circuits (http://micro.magnet.fsu.edu/chipshots/motorola/)

Bye!

[Marco71]

...in precedenza avevo utilizzato proprio questo sito che raccoglie fotografie S.E.M per delle micro-foto dei processori Intel...in "falsi colori"...

Marco71.

[Crisp]

Poi, però, vedendo che con l'apposita libreria giravano del 50% più velocemente a parità di clock (prendendo 68030 e 68882 come riferimento), mi sono in parte ricreduto.

Con Oxyronpatcher le istruzioni emulate dell'882 giravano molto ma molto di più del 50%. :D
Con un 68040 40 mhz + oxypatcher il confronto con lo 030 50 mhz, spariva definitivamente a favore dello 040 ;)
E la combo 060 + Oxypatcher era :sofico:

Poi ovviamente il software scritto con in piedi non c'era niente da fare, però le applicazioni che usavano la fpu in maniera intensiva lo 040 era un siluro, e oxypatcher ti faceva vedere ogni volta che un programma accedeva alla 68040.library tutte le istruzioni 882 emulate...

Su 040 mancava l'istruzione Fint e Fintrz, istruzioni usate moltissimo da tutte le applicazioni fpu su amiga :(
Istruzioni reimplementate poi su 060, gurada caso :eek:

[cdimauro]

Non ho mai avuto uno 040 o uno 060 :cry:, per cui non posso giudicare.
Cercando in giro ho trovato questo: http://66.249.93.104/search?q=cache:wtn5WJnvmFoJ:www.youngmonkey.ca/nose/articles/NewTekniques_9902/ImprovingPerformance/+Oxyron+patcher&hl=it e non mi sembra che queste patch diano risultati eccezionali.

Comunque, era tutto grasso che colava... :D

P.S. Bello il tuo nick, se ha il significato che immagino... ;)

[Crisp]

no, il nick è il nome con attaccato la sigla della provincia :D

E' proprio oxypatcher :)
Cmq l'accelerazione c'è con i programmi che usano la fpu in maniera intensiva.

queste sono le istruzioni supportate:

The OxyPatcher supports the following integer instructions:
MULU.L
MULS.L
DIVU.L
DIVS.L
MOVEP
CMP2

and the following FPU instructions:
FMOVECR (all const.)
FDBcc (all Condition-Codes)
FScc (all Condition-Codes)
FSIN
FCOS
FATAN
FLOGN
FLOG2
FLOG10
FTAN
FETOX
FTWOTOX
FTENTOX
FETOXM1
FLOGNP1
FCOSH
FSINH
FASIN
FACOS
FTANH
FATANH
FGETEXP
FGETMAN
FINTRZ
FINT
FSINCOS
FSCALE
FMOD
FREM

The Data.X FFP-Format, e.g.:
FMOVE.X #Data,FPn
FCMP.X #Data,FPn
FSIN.X #Data,FPn
FMOD.X #Data,FPn

e queste invece non sono supportate:
CAS2
CHK2

avrai visto di alcune istruzioni intere perchè lo 060 deve emulare pure delle istruzioni intere che gli sono state tolte e senza oxypatcher perde quyalcosa anche nella applicazioni che non usano la cpu..

andiamo avanti:

The following table will show the speed of the OxyPatcher:

For the 68040 Processor:
------------------------

Program unpatched patched
===================================================

MaxonC4D_V4.0
-------------
Scene1 00:07:52 00:02:52
Scene2 00:21:37 00:09:21
Scene3 01:04:36 00:32:56

WCS_V2.04
---------
Scene1 00:13:00 00:05:28
Scene2 01:25:23 00:42:41

Lightwave_V5.0
--------------
Scene1 00:21:39 00:17:45
Scene2 01:32:38 01:20:28

SceneryAnimator_V4.0
--------------------
Scene1 00:03:31 00:02:09
Scene2 00:03:16 00:01:46

Reflections_V3.05
-----------------
Scene1 00:03:21 00:02:38
Scene2 00:18:43 00:15:06
Scene3 00:13:53 00:04:29

Real3D_V3
---------
Scene1 00:56:04 00:37:16

Fractuality_V1.10d
------------------
UrApfel/640*512
DoubleFP/It.max=128 00:06:44 00:00:53




For the 68060 Processor:
------------------------

Program unpatched patched
===================================================

MaxonC4D_V4.0
-------------
Scene1 00:10:58 00:01:13
Scene2 01:14:32 00:04:38
Scene3 05:56:03 00:16:58

WCS_V2.04
---------
Scene1 00:10:13 00:02:02
Scene2 01:13:36 00:18:08

Lightwave_V5.0
--------------
Scene1 00:17:57 00:06:03
Scene2 01:24:06 00:26:31

SceneryAnimator_V4.0
--------------------
Scene1 00:19:24 00:01:23
Scene2 00:13:26 00:01:07

Reflections_V3.05
-----------------
Scene1 00:02:10 00:01:07
Scene2 00:11:18 00:06:17
Scene3 00:04:02 00:01:40

Real3D_V3
---------
Scene1 00:34:14 00:14:51

Fractuality_V1.10d
------------------
UrApfel/640*512
DoubleFP/It.max=128 00:06:59 00:00:18


********************************************************************************

4.4 Tested Systems
----------------------

The OxyPatcher has been tested on the following configurations:

-A1200/Blizard1260/48MB-FastRAM/SCSI-Controller
-A1200/Apollo1240-40MHz/16MB-FastRAM
-A1200/Apollo1260/16MB-FastRAM
-A4000/Apollo4060/Picasso4/40MB-FastRAM
-A4000/Cyberstorm-MK2/Picasso4/32MB-FastRAM
-A4000/Cyberstorm-MK2/Cybervison/112MB-FastRAM


come avrai letto, alcune applicazioni hanno avuto un incremento enorme (sopratutto su 060) altre meno.
In generale si un incremento dal 5 al 40% di velocità tra una cpu 040/060 di base e patchata.
Dipende dal software e da come è scritto.

Poi c'è un'altra patch: FastExec per spostare in fast ram l'Exec e muovere in fast l'SSP che su 040 e 060 da ulteriori incrementi.

Somma oxypatcher e fastexec e si ottiene un buon boost :)

La mia era l'apollo 1240 40 mhz 32 MB e prima avevo uno 030/50 16 MB, quindi ho avuto modo di vedere le differenze.
Cmq in generale c'è stato più incremento di velocità tra un 1200 di base e uno 020 28 Mhz che tra un 68040 e un 68030 :(

[Crisp]

MaxonC4D_V4.0
-------------

Scene3 01:04:36 00:32:56

Scene3 05:56:03 00:16:58




come si vede qui nel rendering della 3° scena lo 060 è addiritura più lento dello 040 senza usare la patch, mentre con la patch si recupera mezzora su 040 e 5 ore su 060...

Se tra senza patch e patch c'è un simile divario, usare queste cpu con oxypatcher migliorava ancora di più il divario con lo 030.

Se invece usavano istruzioni native era ancora più veloce e non c'era bisogno della patch..
Molti binari per 040 emulano a nastro instruzini 882

[cdimauro]

Non c'è che dire: impressionanti questi risultati, specialmente con lo 060. :eek:

[Marco71]

..per caso le prime versioni di MC68060 erano in contenitore ceramico rosso-fegato con la scritta "060" ?
In pratica lo stesso contenitore dell'MC68040...
Quando la famiglia 68000 era sul "trono" veniva molto utilizzata anche in ambito (sigh!) militare con versioni particolari schermate per le radiazioni ionizzanti e non presenti nello spazio "esterno".
Il 68050 (mai entrato in produzione) fu per me il vero "canto del cigno" della più che gloriosa famiglia 68000 (sigh!)...
Esponenti più o meno illustri 68xxx sono ancora impiegati in utilizzi "embedded" oltre che in ambito automotive...
Grazie.

Marco71.

[cdimauro]

Peccato che stiano scomparendo a favore di soluzioni basate su core ARM...

[cdimauro]

Già, e la cosa mi dispiace, perché anch'io ritengo l'architettura 680x0 molto, ma molto più semplice da programmare rispetto a un ARM.

Sì, il primo ARM era davvero molto semplice: constava di 25 mila transistor. Nonostante tutto era mostruosamente veloce, rispetto a un 68000, che ne contava ben 68000... Semplicità che si pagava, ad esempio, col fatto che architetturalmente non era in grado di indirizzare più di 64MB di memoria.
Fortunatamente questi limiti sono stati rimossi dalle successive versioni.

Trovo molto interessante l'introduzione dell'ISA Thumb: semplice, potente quel che basta e molto compatto. Una bella trovata della Acorn, non c'è che dire.
Peccato che nessuno abbia pensato di realizzare un processore ARM funzionante soltanto in modalità Thumb: dovrebbe essere più semplice da realizzare, produrre, e spingere a frequenze più elevate.

[Gica78R]

Ehm... :stordita: Scusate se mi intrometto... Ho letto tutto fino a pag. 6, poi ho pensato al suicidio. :)
In realta' mi sono imbattuto in questo thread solo perche' cercavo informazioni sul Motorola 68000, in particolare circa lo spazio di indirizzamento... Su un vecchio libro ho letto una cosa strana, di cui riporto uno stralcio:
Il 68000 e' un processore con architettura 16/32 bit avente un bus dati di 16 bit e un bus indirizzi di 23 bit non multiplexati.
[...] il 68000 possiede registri da 16/32 bit e un registro contatore di programma di 32 bit. Di quest'ultimo, sul bus indirizzi ne vengono pero' riportati soltanto 23, ottenendo cosi' una capacita' di indirizzamento di 16 MB.
La cosa mi e' parsa subito assurda, e leggendo nel thread e in alcuni links ho avuto la conferma che il bus indirizzi e' di 24 bits (senno' come ci arriva a 16MB???)... E' cosi', vero? Il bello e' che nel libro la faccenda dei 23 bit e' ripetuta diverse volte :confused: Che faccio, lo brucio?

Grazie :)

[cdimauro]

Ehm... :stordita: Scusate se mi intrometto... Ho letto tutto fino a pag. 6, poi ho pensato al suicidio. :)
:p E' ancora presto: prima devi finore di leggerti tutto il thread... :asd: :D
In realta' mi sono imbattuto in questo thread solo perche' cercavo informazioni sul Motorola 68000, in particolare circa lo spazio di indirizzamento... Su un vecchio libro ho letto una cosa strana, di cui riporto uno stralcio:

La cosa mi e' parsa subito assurda, e leggendo nel thread e in alcuni links ho avuto la conferma che il bus indirizzi e' di 24 bits (senno' come ci arriva a 16MB???)... E' cosi', vero? Il bello e' che nel libro la faccenda dei 23 bit e' ripetuta diverse volte :confused: Che faccio, lo brucio?

Grazie :)
No, anche se vecchio, glielo tornerei indietro e mi farei ridare i soldi (con gli interessi :D): quelle informazioni sono palesemente false / errate.

P.S. Tra l'altro coi 68000 si potevano indirizzare fino a 64MB di memoria, ma capire come fare te lo lascio come esercizio, visto che sei in vena di studii... :fiufiu: :nonio: :Perfido:

[Gica78R]

Bus indirizzi a 23 bit nel 68000: svelato l'arcano!

Sempre sul famoso libro/manuale, e' riportata la piedinatura del 68000, ed anche in questo caso le linee per il bus indirizzi sono 23, e sono numerate da A1 a A23. Gironzolando in rete, ho trovato un documento che dice quanto segue:
Il processore 68000 dispone di:

16 bit di bus dati;
24 segnali di indirizzo, che permettono di disporre di uno spazio di indirizzamento pari a 16 MB di memoria esterna. Solo 23 segnali sono disponibili (A1-A23), mentre il segnale A0 e' usato internamente dal processore per pilotare i segnali UDS e LDS. I livelli dei segnali sono controllati dallo stato del segnale interno A0: se e' richiesto l'indirizzamento di un byte, A0 e' usato per accedere alla locazione di memoria (pari/dispari) opportuna. Un accesso a word ingnora lo stato del segnale A0.

Cmq non ho ancora capito come indirizzare 64MB con questo processore... :confused:
Pero' continuo a pensarci :)

Edit: non e' che posso usare quei due piedini GND che stanno vicino ai piedini del bus indirizzi? Tanto di GND ce ne stanno quattro! :p

[cdimauro]

Bus indirizzi a 23 bit nel 68000: svelato l'arcano!

Sempre sul famoso libro/manuale, e' riportata la piedinatura del 68000, ed anche in questo caso le linee per il bus indirizzi sono 23, e sono numerate da A1 a A23. Gironzolando in rete, ho trovato un documento che dice quanto segue:
Sì, però la spiegazione l'hai trovata in rete e non sul libro... :p

Comunque, sì, il 68000 non ha un piedino A0, ma due per poter scegliere il tipo e quale dato leggere dal bus, che è sempre a 16 bit...
Cmq non ho ancora capito come indirizzare 64MB con questo processore... :confused:
Pero' continuo a pensarci :)

Edit: non e' che posso usare quei due piedini GND che stanno vicino ai piedini del bus indirizzi? Tanto di GND ce ne stanno quattro! :p
No, quella è la massa: non provare a collegarla a qualcos'altro!!! :D

Prova per esclusione: elimina i piedini di cui già conosci il significato / funzionamento... Te ne rimangono altri: fra questi ce ne sono alcuni "strani"... :p

[Gica78R]

No, quella è la massa: non provare a collegarla a qualcos'altro!!! :D
Beh, ma i piedini per la massa servono proprio tutti e quattro?
Se cosi' non fosse, e se potessero essere controllati in qualche modo, si potrebbero collegarne due ad altre due linee di un ipotetico bus indirizzi a 26 bit... :mc:

Prova per esclusione: elimina i piedini di cui già conosci il significato / funzionamento... Te ne rimangono altri: fra questi ce ne sono alcuni "strani"... :p
Ok, credo di aver capito... Grazie del suggerimento!

[Marco71]

...i piedini di massa elettrica multipli servono solo ed esclusivamente per meglio instradare il riferimento elettrico circuitale "massa" appunto (che molti confondono troppo spesso con il concetto di "terra")...
Non possono essere utilizzati come piedini di segnale "logico" e a maggior ragione come segnali per il bus indirizzi (che ad esempio nel 80486 a causa dello snooping delle memorie cache interne è bidirezionale).
In epoca di Commodore 64 e poi anche 128 era in largo uso l'utilizzo della tecnica del "bank switching" per superare i limiti "fisici" dei vari Rockwell 6502/6510 e derivati.
Grazie.

Marco71.

[Masmo]

Ciao a tutti,
ho seguito con passione le vostre discussioni e volevo anche io dire
la mia sull'argomento.

Riguardo all'Atari st e Amiga erano entrambi dei bei computer, ogniuno
con i suoi pregi e i suoi difetti.

Io ho avuto un atari st dal 1990 al 1994, avevo entrambi i monitor e
devo dire che la configurazione con monitor a colori era essenzialmente
+ adatta al gioco, mentre con il monitor b/w le cose cambiavano di molto.

Un mio amico si prese il Mega ST 2 con Hd da 30Mb e stampante laser.
Bene, con questa configurazione, lui che era patito di desktop publishing,
poteva tranquillamente rivaleggiare con pc dal costo ben superiore. Aveva
Calamus come software per lavorare e devo dire che era veramente bello.

Io che studiavo informatica, lavoravo principalmente con il Borland turbo c ma
imparai anche ad utilizzare il devpac per l'assembler e il gfa basic.

Devo dire che con il monitor b/w era veramente un altro mondo, anche altri
ragazzi che studiavano con me all'università, patiti dei pc, quando videro
la configurazione b/w rimasero veramente stupefatti.

Considerate che in quel periodo li, i pc con i 286 costavano già parecchio
di + di quanto spesi io per comprarmi l'atari st (1.400.000).

Per quanto riguarda l'Amiga, non mi posso pronunciare + di tanto visto
che non l'ho mai avuto, ma credo che fosse una macchina stupenda
visto l'hardware che montava.

Io credo che per i giochi l'amiga fosse migliore dell'atari st, magari
su tanti giochi la differenza era minima, ma per quanto riguarda
la grafica e il suono era sicuramente superiore. L'atari st non aveva
grandi qualità grafiche e sonore, il processore audio era lo stesso
dell'msx, quindi non il top per quel periodo.

Io non credo che nell'amiga avessero messo tutti quei chip custom per
rallentarlo!! Siamo seri...

E' ovvio che poi magari in qualche gioco l'atari poteva essere un pochino +
veloce. Io mi ricordo alcuni demo (ce ne sono a bizzeffe vedi
http://www.lysator.liu.se/~celeborn/sync/page3.html e il demo
The dark side of the spoon ) le cose che riuscivano a fare con l'atari
erano impressionanti, se si pensa che l'atari non aveva alcun chip
custom di aiuto per la grafica.

Penso proprio che questi due computer abbiano fatto storia come a
suo tempo il c64/msx/vic20 ecc...

Per quanto riguarda 68000 vs 80486 mi sembra un pochino fuori
luogo confrontare cpu nate con 10 o + anni di differenza (non mi ricordo).

Semmai se proprio dovete confrontare qualcosa, fatilo fra il 68000 e
il 80286...

Quanto studiavo informatica, ero appassionato di benchmark (be, in effetti
lo sono tutt'ora http://themasmo.interfree.it) e ci divertivamo a creare
dei piccoli benchmark in assembler per 286 o 68000 e poi confrontare le velocità (sempre con quei ragazzi che adulavano i pc).

Be, le conclusioni furono queste:

L'80286 in effetti era + veloce nell'eseguire le istruzioni, però non era
il vincitore e vi spiego anche il perchè.

Il 68000 aveva 8 registri dati (d0-d7) e 8 registri indirizzi (a0-a7) di cui uno
(a7) usato per lo stack.

Tutti i registri erano a 32 bit, il fatto di avere il bus dati a 16 bit voleva dire
dire poco o nulla. Il 286 era un 16bit quindi tutte le operazioni di calcolo
interne erano su registri di 16bit e non di 32bit.

Se nel 68000 si voleva eseguire una moltiplicazione, il risultato andava
sempre su un singolo registro, mentre sul 286, dovevano essere utilizzati
2 registri per il risultato visto che un singolo registro poteva al massimo
contenere 16bit.

Vi sembra poco? Ma non finisce qui:

Il 68000 utilizzava 14 modi di indirizzamente, 7 di + del 286, nel 90% delle
istruzioni si potevano utilizzare qualsiasi registro a disposizione. Non c'erano
registri fissi per fare moltiplicazione/divisioni ecc.

Guardate questo codice qui di seguito:

MOMEM.L D3-D7,-(SP)
MOVE.L D1,D6
MOVE.L D2,D7
MOVE.L D1,D3
MOVE.L D1,D4
SWAP D4
MOVE.L D2,D4
SWAP D5
MULU D2,D1
MULU D4,D2
MULU D5,D3
MULU D5,D4
SWAP D1
ADD D2,D1
CLR.L D5
ADDX.L D5,D4
ADD D3,D1
ADDX.L D5,D4
SWAP D1
CLR D2
SWAP D2
CLR D3
SWAP D3
ADD.L D3,D2
ADD.L D4,D2
TST.L D7
BPL.S CHECKD6
SUB.L D6,D2
CHECKD6
TST.L D6
BPL.S DONE
SUB.L D7,D2
DONE
MOVEM.L (SP)+,D3-D7
RTS

Bene, questa routine calcola una moltiplicazione 32x32 bit..
Moltiplicatore in D2 e moltiplicando in D1, il prodotto viene
restituito in D1 (32bit bassi) e D2 (32 bit alti).

Non notate niente di strano?

Non accede mai alla memoria, usa solo i registri.... vi rendete conto
cosa vuol dire a livello di velocità?

Provai a fare la stessa routine su un 286.. un incubo, con quei pochi
registri dovevo fare sempre accesso alla memoria per salvare i dati
temporanei dei calcoli con il risultato che andava + lenta che non nel 68000.
Quelle cpu non avevano le cache delle cpu odierne!!!

Quindi il 68000 era veramente una cpu stupenda, si imparava a programmare
in pochi giorni e metteva a disposizione dell'utente istruzioni di una potenza
fuori dal comune per quei tempi.

E' ovvio che oggi solo quelli un poco fuori di testa si mettono a programmare
in assembler, al massimo si possono fare alcune routine ottimizzate per
sfruttare a pieno le capacità della cpu, poi si utilizzeranno sempre linguaggi
ad alto livello tipo C/Delphi/Basic Vari ecc...

Non 'ho + altro da aggiungere.

Anzi una cosa la voglio dire...

Io non tornerei mai indietro, i computer di oggi sono spaventosi anche se
non sfruttati al 100% come lo erano quelli di una volta.
Con un athlon 64 3500+ e un semplice visual basic si riescono a fare
cose impensabili per quei tempi.

Ciao
Massimo

[Marco71]

...hai ragione su "quasi" tutto...
Però ricorda che bisogna contestualizzare il livello di tecnologia disponibile ad un dato tempo...
Il Motorola 68000 "traslato" al livello tecnologico attuale del silicio e dei semiconduttori in genere, si papperebbe allegramente qualsiasi processore x86...
Come un ipotetico supercomputer futuro, basato su elementi logici ottici si papperebbe pure esso allegramente l'attuale BlueGene/L.
E' vero che oggi nessuno si accotenta più di nulla..vedo troppi ragazzini under 18 che maneggiano potenze di "calcolo" appunto impensabili per un disgraziato come me che all'epoca di "I Like Chopin" programmava il suo Sharp Pocket Computer PC1245 con 2.2 diconsi 2200 bytes di memoria utente....
Sono poi daccordo che il confronto non è "paritetico": un 68000 sarebbe da confrontare con un 80286 come detto...
Un 80486 integrava un nucleo potenziato 80386 + un coprocessore 80387 I.E.E.E 754/854 + 8 KBytes di memoria cache associata al cache memory controller 802385 per 1.2 milioni di transistor "equivalenti"...
Forse il 68040 nè aveva meno proprio anche a causa della mancanza del supporto in hardware alle funzioni trascendenti.
Grazie.

Marco71.

[Masmo]

Ciao,
giusto Marco, io ho sempre pensato che se il 68000 avesse eseguito
la maggior parte delle sue istruzioni in un solo colpo di clock e
avesse avuto una frequenza di almeno 2Ghz sarebbe stato veramente
stupendo come processore per i tempi moderni.

Però è anche vero che le cpu attuali sono spaventose, non sottovalutiamole
troppo.

Forse il loro unico problema è che in una maniera o nell'altra sono legate
sempre a quella architettura di fine anni '70 del 8086 ecc...

Io credo che la gente non sappia apprezzare quello che ha, ai tempi
in cui frequentavo l'università dovetti dare un esame di programmazione
di assembler su un 8086, non ti dico come era lavorare su quei computer
(tutti Ibm ovviamente) ma a quanto ho capito lo dovresti sapere anche te...

Io ti sto rispondendo al messaggio mentre mi sta girando sotto il demo
Dark side of the spoon su SainT, scarico da rete a 120Kb e dalla scheda
satellitare a 4Mb/s !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Vi rendete conto della potenza necessaria per fare queste cose?!?!?
E la macchina mi sta sfruttando solo il 35% della Cpu!!!!!
La cosa bella è che sono su un semplice Pentium 4 3Ghz, quindi
nemmeno al top della tecnologia attuale.

Io credo che si dovrebbe un pochino tutti riflettere su quello che uno ha a
disposizione oggi, te ne che ne pensi?

Ciao
Massimo

[Marco71]

...pensa che io ho sostenuto "Fondamenti di Informatica I" programmando in Pascal sul mio piccolo Amiga 500 con molti salti mortali.
Vedo che sei molto entusiasta riguardo a ciò che allo stato attuale è disponibile al grande pubblico quanto a microprocessori ecc.
Io ho ben chiaro e presente quale sia oggi la potenza "di calcolo" a disposizione dei processori (a prescindere dalla architettura)...il problema è che oggi c'è troppa "assuefazione"...
Troppi GHz e bit sprecati per non parlare delle "tonnellate" di memoria centrale e di massa...
Non mi spiegherò (o meglio me lo spiego con la impossibilità tecnologica) mai come mai quei "spaienti" Re magi alla Intel abbiano fatto a meno delle strutture logiche "barrel shifter" nelle A.L.U del Pentium 4 fino al nucleo Northwood compreso...
Il tanto vituperato core Prescott almeno lo ha reintrodotto in una delle A.L.U double "pumped"...
Grazie.

Marco71.

[cdimauro]

Ok, credo di aver capito... Grazie del suggerimento!
Allora diccelo, no? ;)

[cdimauro]

Io mi ricordo alcuni demo (ce ne sono a bizzeffe vedi
http://www.lysator.liu.se/~celeborn/sync/page3.html
Se conosci i creatori del sito, chiedigli di sistemare quanto meno il frame di sinistra perché è praticamente illegibile... :(
Per quanto riguarda 68000 vs 80486 mi sembra un pochino fuori
luogo confrontare cpu nate con 10 o + anni di differenza (non mi ricordo).
Concordo... :)
Semmai se proprio dovete confrontare qualcosa, fatilo fra il 68000 e
il 80286...
Direi di no: c'è troppa differenza fra i due processori a livello di architetturale.

Il 68000 è un processore con ISA a 32 bit: aveva soltanto il bus dati esterno "castrato" a 16 bit, ma per il resto tutto era a 32 bit...

L'80286 era, sì, il successore dell'8086, ma aveva pur sempre un'ISA a 16 bit. La modalità protetta non portava nulla di particolare rispetto all'8086: i programmatori continuavano a sbattere la testa con segmenti / selettori e offset.

Se ci pensi bene, è come se volessimo confrontare un 6502 col suo "successore", il WD65816: non ci sarebbe storia.

Gli unici confronti che avrebbero senso, IMHO, sarebbero 68020/30 con 80386, ecc.

[cdimauro]

Ciao,
giusto Marco, io ho sempre pensato che se il 68000 avesse eseguito
la maggior parte delle sue istruzioni in un solo colpo di clock e
avesse avuto una frequenza di almeno 2Ghz sarebbe stato veramente
stupendo come processore per i tempi moderni.
Se hai letto bene tutto il thread, non si può dire, anzi: l'ISA 680x0 è troppo complessa da implementare e portare a frequenze così elevate.

Ogni famiglia di processori, in base alla tecnologia costruttiva utilizzata per i transistor, ha raggiunto dei limiti precisi, e la cosa non è certo casuale...
Forse il loro unico problema è che in una maniera o nell'altra sono legate
sempre a quella architettura di fine anni '70 del 8086 ecc...
Direi di no: un 386, a parte la "compatibilità" con l'8086, ha poco da spartire con i suoi predecessori.
Situazione "peggiorata" con gli x86-64, che ha in modalità nativa hanno fatto fuori la compatibilità con l'ISA a 16 bit, la segmentazione e tante istruzioni legacy...
Io credo che si dovrebbe un pochino tutti riflettere su quello che uno ha a
disposizione oggi, te ne che ne pensi?

Ciao
Massimo
Che la maggior parte delle persone se ne fa poco della potenza dei computer moderni...

[Masmo]

Ciao,
lo so che sarebbe quasi impossibile avere un 68000 con quelle caratteristiche,
ma io sognavo...

Io onestamente non capisco tutte le critiche per l'attuale tecnologia.

Con 1.400.000 lire degli anni 90 mi ci comprai qusto computer:

68000
1Mb ram
32Kb video
Floppy disk
Scheda video 512 colori 320x200 ecc.
Audio 3 canali
Monitor b/w 640x400

Oggi con 700 Euro (che non sono 1.400.00 del '90 ma ben meno)
ti ci puoi comprare dei computer veramente spaventosi che niente
hanno a che vedere con quelle macchine.

Anche se non vengono sfruttati al 100% che ve ne frega, hanno potenza
in esubero per qualsiasi applicazione.

Mi ricordo che una volta installai un cad 3d sull'st, bene, la cosa
divertente era vederlo renderizzare... un vero incubo se visto con i tempi
di oggi.

Oggi non esiste un software che non possa funzionare (e benino) anche
su macchine entry level.

Ho un portatile con un p4 3ghz che fa paura in velocità.

Non parliamo poi delle unità di massa, con l'st usavo il floppy, al
massimo trovavi un hd da 30Mb!!!

Oggi il mio portatile ha un hd da 60Gb!!

Posso essere daccordo con voi quando vedo programmi che per
essere installati richiedono 1,5 Gb di spazio su disco, ma è anche vero che
un hd da 80Gb costa meno di 60€...

Insomma, non vi sembra di essere un poco esagerati? Ma che volete?

Io vi farei lavorare per 1 settimana sui vecchi 8086 o atari/amiga e poi
vorrei sentire le vostre impressioni...

La gente è buffa, non gli va mai bene nulla.

Quando comprai il mio primo pc, un P100 con 16mb di ram, per espanderlo
a 24Mb spesi 300.000 £ !!!!!!

Ultimamente ho espanso il mio pc da 512 a 1gb e ho speso 72,93 € !!!

Il pc con cui lavoro, un athlon 64 3500+ lo tengo a 1.2Ghz invece che a
2.2Ghz tanto è veloce uguale non ho alcun tipo di rallentamento nemmeno
con i giochi. Lo porto a 2.2ghz solo quando devo fare Divx.
L'altro giorno ho fatto un filmato di 3,5Gb (un temporale) e l'ho convertito
in divx senza il minimo problema a 1,2Ghz. Queste cose NON le avrei potute
fare a quei tempi, non'è che sarebbero state + lente, proprio non le avrei
potute fare.

Io sono contento cosi, non vorrei niente di + di quello che c'è attualmente
sul mercato.

Forse sbaglierò (non voglio dire che questa è la ragione) o forse vedo
le cose da un punto diverso dal vostro.

Ciao.

P.S. No, non li conosco quelli che hanno fatto quel sito, secondo me devono
avere almeno 20/10 di vista, io nel menu a sx non leggo nulla!!! bo...

[Marco71]

Ciao,
lo so che sarebbe quasi impossibile avere un 68000 con quelle caratteristiche,
ma io sognavo...

Io onestamente non capisco tutte le critiche per l'attuale tecnologia.

Con 1.400.000 lire degli anni 90 mi ci comprai qusto computer:

68000
1Mb ram
32Kb video
Floppy disk
Scheda video 512 colori 320x200 ecc.
Audio 3 canali
Monitor b/w 640x400

Oggi con 700 Euro (che non sono 1.400.00 del '90 ma ben meno)
ti ci puoi comprare dei computer veramente spaventosi che niente
hanno a che vedere con quelle macchine.

Anche se non vengono sfruttati al 100% che ve ne frega, hanno potenza
in esubero per qualsiasi applicazione.

Mi ricordo che una volta installai un cad 3d sull'st, bene, la cosa
divertente era vederlo renderizzare... un vero incubo se visto con i tempi
di oggi.

Oggi non esiste un software che non possa funzionare (e benino) anche
su macchine entry level.

Ho un portatile con un p4 3ghz che fa paura in velocità.

Non parliamo poi delle unità di massa, con l'st usavo il floppy, al
massimo trovavi un hd da 30Mb!!!

Oggi il mio portatile ha un hd da 60Gb!!

Posso essere daccordo con voi quando vedo programmi che per
essere installati richiedono 1,5 Gb di spazio su disco, ma è anche vero che
un hd da 80Gb costa meno di 60€...

Insomma, non vi sembra di essere un poco esagerati? Ma che volete?

Io vi farei lavorare per 1 settimana sui vecchi 8086 o atari/amiga e poi
vorrei sentire le vostre impressioni...

La gente è buffa, non gli va mai bene nulla.

Quando comprai il mio primo pc, un P100 con 16mb di ram, per espanderlo
a 24Mb spesi 300.000 £ !!!!!!

Ultimamente ho espanso il mio pc da 512 a 1gb e ho speso 72,93 € !!!

Il pc con cui lavoro, un athlon 64 3500+ lo tengo a 1.2Ghz invece che a
2.2Ghz tanto è veloce uguale non ho alcun tipo di rallentamento nemmeno
con i giochi. Lo porto a 2.2ghz solo quando devo fare Divx.
L'altro giorno ho fatto un filmato di 3,5Gb (un temporale) e l'ho convertito
in divx senza il minimo problema a 1,2Ghz. Queste cose NON le avrei potute
fare a quei tempi, non'è che sarebbero state + lente, proprio non le avrei
potute fare.

Io sono contento cosi, non vorrei niente di + di quello che c'è attualmente
sul mercato.

Forse sbaglierò (non voglio dire che questa è la ragione) o forse vedo
le cose da un punto diverso dal vostro.

Ciao.

P.S. No, non li conosco quelli che hanno fatto quel sito, secondo me devono
avere almeno 20/10 di vista, io nel menu a sx non leggo nulla!!! bo...

Scusami se ti darò del "tu"...
Non sono daccordo sulla tua affermazione in cui dici che la "potenza" è in esubero per "qualsiasi" applicazione...non è assolutamente vero...
Ti potrei elencare una marea di algoritmi (escludo apriori il settore giochi che non mi è mai interessato e per il quale sarebbe meglio che si evitassero le sovrapposizioni che ci sono oggi: console, computer "personali" ecc.) che non trovano adeguata rispondenza nelle risorse di calcolo disponibili anche a livello di "singolo" utente senza scomodare supercomputer, N.A.S.A e quanto di altro...
Un solo esempio che proviene dalla teoria dei numeri, per la verifica della primalità di un numero primo in forma di Mersenne come quello che darebbe al suo scopritore oltre alla fama ed alla "gloria" matematica e che deve avere come minimo 10 milioni di cifre decimali....
Ebbene per un processore Pentium 4 alla frequenza di 3GHz servirebbe oltre un anno di calcolo ininterrotto (ed attualmente ci sono molti "volontari" che con Prime95 stanno attaccando tale tipo di problema)....e potrei continuare...
Ricorda che tutto è relativo...
Quello che voglio dire io è che ci sono precedenti illustri di processori come l'80386 che hanno "faticato" non poco per essere utilizzati appieno vuoi per la mancanza cronica di s.o adeguati (escludendo i molteplici dialetti di Unix dell'epoca)...
Oggi il trend è ancora "peggiore"...c'è troppo spreco ...
I ragazzi con poco più che due lustri sulle spalle sono assuefatti a livelli di potenza "media" di calcolo molto superiore a quelli disponibili in passato...
Ma ripeto è tutto relativo...
Grazie.

Marco71.

[Gica78R]

Allora diccelo, no? ;)
:stordita: :what:
Che dire... di piedini "strani" non ne vedo, pensavo si potessero sfruttare quei segnali usati per l'interfacciamento del 68000 con i circuiti della serie 6800 (se non ho capito male quel che ho letto :rolleyes: ), vale a dire i piedini E (enable), VPA e VMA... Cmq questo e' solo un tentativo di uno che non conosce minimamente il 68000... e nessun altro processore :(

Se non ci ho "beccato", e se la soluzione non e' troppo tecnica, me lo potreste spiegare voi?


Grazie,

Gica

[cdimauro]

La soluzione sta nei 3 piedini FC0-2 (Function Code): i 680x0 li usano per specificare, quando si fa un accesso in memoria, anche il tipo di accesso:
- se si tratta del fetch di un'istruzione o di un dato;
- se si tratta di un'operazione nello spazio utente o supervisore.

4 combinazioni -> 2 "bit" che si possono andare ad "aggiungere" agli altri 24 per indirizzare 2^26 = 64MB di memoria. :)

E' una cosa che probabilmente non ha usato nessuno, ma che a partire dal 68010 sarebbe stata interessante, visto che in modalità supervisore è possibile impostare i quali valori di FC usare per accedere alla memoria con un'istruzione privilegiata (che è stata introdotta con questo processore: è necessaria, ad esempio, per far sì che un kernel o periferica possa accedere ai dati di un'applicazione che gira nello spazio utente).

x Masmo: la penso come te. Per me i computer di oggi non sono affatto da denigrare, anzi... :D

[Marco71]

...giù il cappello a lei, Dr. Di Mauro...
Infatti il 68010 (che io gelosamente conservo...lo acquistai per sostituirlo ad un mio Amiga 500 con poco vantaggio dato soprattutto dal sistema di "auto-loop" che aveva) abbinato ad una unità M.M.U esterna era in grado (ed in alcuni modelli di workstation di allora fu utilizzata) di poter gestire un certo ammontare di memoria "virtuale"...
Cmq. io ho sempre avuto la "bava" alla bocca per quei magici quadrati con placca dorata che si chiamavano 68030 e 68882 (oppure anche per i fratellini 68020 e 68881)...
Mi dice Dr. Di Mauro, i coprocessori matematici Motorola 68881/2 utilizzavano il sistema CO.R.DIC per le funzioni trigonometriche ?
Grazie ancora.

Marco71.

[Gica78R]

La soluzione sta nei 3 piedini FC0-2 (Function Code): i 680x0 li usano per specificare, quando si fa un accesso in memoria, anche il tipo di accesso:
- se si tratta del fetch di un'istruzione o di un dato;
- se si tratta di un'operazione nello spazio utente o supervisore.

4 combinazioni -> 2 "bit" che si possono andare ad "aggiungere" agli altri 24 per indirizzare 2^26 = 64MB di memoria. :)

E' una cosa che probabilmente non ha usato nessuno, ma che a partire dal 68010 sarebbe stata interessante, visto che in modalità supervisore è possibile impostare i quali valori di FC usare per accedere alla memoria con un'istruzione privilegiata (che è stata introdotta con questo processore: è necessaria, ad esempio, per far sì che un kernel o periferica possa accedere ai dati di un'applicazione che gira nello spazio utente).

x Masmo: la penso come te. Per me i computer di oggi non sono affatto da denigrare, anzi... :D

Grazie mille per la spiegazione :)
Sara' ora che mi metta a studiare sul serio... :muro:

Gica

[Bscity]

http://wuarchive.wustl.edu/aminet/pix/real3/Bowling.jpg

Meglio di windowx xp !!!

http://www.meicky-soft.de/amiga-magazin/magazin/a07-04/amigaone/wbkomplett.jpeg




http://www.homecomputer-collection.de/pic/kick31.gif


MITICA !!!

[cdimauro]

...giù il cappello a lei, Dr. Di Mauro...
Infatti il 68010 (che io gelosamente conservo...lo acquistai per sostituirlo ad un mio Amiga 500 con poco vantaggio dato soprattutto dal sistema di "auto-loop" che aveva) abbinato ad una unità M.M.U esterna era in grado (ed in alcuni modelli di workstation di allora fu utilizzata) di poter gestire un certo ammontare di memoria "virtuale"...
Cmq. io ho sempre avuto la "bava" alla bocca per quei magici quadrati con placca dorata che si chiamavano 68030 e 68882 (oppure anche per i fratellini 68020 e 68881)...
Che dire: condivido in pieno tutto...

Il 68010 è un capriccio che sfortunatamente non mi sono mai potuto permettere quando avevo il mio (prima) amatissimo Amiga 2000... :(
Mi dice Dr. Di Mauro, i coprocessori matematici Motorola 68881/2 utilizzavano il sistema CO.R.DIC per le funzioni trigonometriche ?
Grazie ancora.

Marco71.
Di niente: è un piacere rinvangare il passato e scambiare quattro chiacchere con gente in gamba... :mano:

Non ho informazioni in merito: penso che usassero il CO.R.DIC, come la stragrande maggioranza di FPU in circolazione all'epoca, visto che richiedeva piccole tabelle di interpolazione per i dati e soltanto somme/sottrazioni e shift per le operazioni usate nelle iterazioni.

[cdimauro]

Grazie mille per la spiegazione :)
Sara' ora che mi metta a studiare sul serio... :muro:

Gica
Mah, non so: idee perverse :p come quella vengono fuori più che altro lavorando per un po' di tempo con queste macchine, piuttosto che dal semplice studio.

Meglio studiare cose più utili, di questi tempi (mi sembra di averne già parlato con te o sbaglio? Boh).

[Marco71]

Dr. Di Mauro ben ritrovato...
Il 68010 costava pochissime "vecchie" lirette...proprio poche...
Se non mi ricordo male non arrivai (in contrassegno) alle 30000 lire...
Purtroppo c'erano dei problemi a causa della esecuzione di alcune istruzioni e del modo "supervisore"...sigh!...
Per caso si ricorda il programma "Gomf 3.0" che intercettava le cause delle frequenti "guru meditations"...?
Io lo acquistai originale e conservo ancora il floppy disk nella scatola...
In campo x86 il passaggio da algoritmo CO.R.DIC ad algoritmo S.R.T per le istruzioni f.p.u "trascendenti" si ebbe con Pentium...
Per caso non avrebbe qualche file pdf sul controllore A.P.I.C Intel 82489DX ?
Era un controllore di interruzioni programmabile avanzato che serviva sia in ambito multiprocessore sia in ambito "single c.p.u" da controller I/O-A.P.I.C.
Grazie della cortese attenzione.

Marco71.

[cdimauro]

Dr. Di Mauro ben ritrovato...
Il 68010 costava pochissime "vecchie" lirette...proprio poche...
Se non mi ricordo male non arrivai (in contrassegno) alle 30000 lire...
Per un ragazzino squattrinato non erano poche, ai tempi... :p
Purtroppo c'erano dei problemi a causa della esecuzione di alcune istruzioni e del modo "supervisore"...sigh!...
Già. Colpa di Motorola comunque, che ha commesso un errorino non da poco con la MOVE SR.
Per caso si ricorda il programma "Gomf 3.0" che intercettava le cause delle frequenti "guru meditations"...?
Io lo acquistai originale e conservo ancora il floppy disk nella scatola...
Lo ricordo, ma non l'ho mai usato per ovvi motivi... :)
In campo x86 il passaggio da algoritmo CO.R.DIC ad algoritmo S.R.T per le istruzioni f.p.u "trascendenti" si ebbe con Pentium...
Sinceramente da tempo non mi interesso più degli algoritmi usati nelle FPU: la S.R.T. mi è nuova...
Per caso non avrebbe qualche file pdf sul controllore A.P.I.C Intel 82489DX ?
Era un controllore di interruzioni programmabile avanzato che serviva sia in ambito multiprocessore sia in ambito "single c.p.u" da controller I/O-A.P.I.C.
Grazie della cortese attenzione.

Marco71.
Mi spiace, non ti posso esser d'aiuto...

[FiorDiLatte]

Non capisco il senso del thread, so solo che un ignorante (PCista, pure snobb!!) paragonerebbe un MC68000 ad un Intel 80486, cioe' processore del tutto piu' recente rispetto al Motorola.
Il paragone era MC68040 vs I80486, entrambi i processori erano i primi CISC che integravano al proprio interno CPU/FPU/MMU, il Motorola vinceva per una maggiore (di poco) velocita' nel calcolo in virgola mobile.

Chi vi parla e' un ex-amighista convinto, ex-possessore di un Amiga 500 (accelerato con una scheda dell'Hardital col 68030+68882 a 25 mhz [Il mitico Ing. Bianco, ve lo ricordate!? Che copiava le schede GVP ben piu' costose e performanti, per crearne di economiche ma pur sempre potenti.]), poi di un 2000 (tenuto 3 mesi), ed infine passato al 4000. Un 486 non poteva emulare un Amiga, per l'assenza dei chipset custom, che i pc dell'epoca si sognavano, per non parlare del Sistema Operativo (realmente) Multitasking (altro che Win'9x/ecc. e Unix) funzionante su SOLI 512 Kbyte di RAM............

byezzz

[Marco71]

Questo era il rapporto di forza tra il 68040 in versione MC (cioè quella "finale" con integrata la f.p.u) e l'80486 Intel su test I.E.E.E non coinvolgenti istruzioni trascendenti tipo SIN,COS,LOG,LN ecc.
Quindi mi sembra un netto divario...
"FiorDiLatte", mi potresti spiegare meglio la "questione" Hardital dato che ho ancora uno dei miei due Amiga 500 con scheda acceleratrice BigBang 020-881 a 16MHz...
Cosa scandalosa è che utilizza un XC68020 ed un 68881 a 12MHZ cioè in pratica come si direbbe oggi era "over" specifiche...
Tra l'altro anche se esistesse ancora la suddetta Hardital non compererei più nienete dato che mi fecero penare una eternità per avere la scheda...scheda che aveva una enormità di problemi hardware di funzionamento...
Le schede acc. di oltre oceano erano una anltra cosa...
Grazie.

Marco71.

[Dobermann75]

http://wuarchive.wustl.edu/aminet/pix/real3/Bowling.jpg

Meglio di windowx xp !!!

http://www.meicky-soft.de/amiga-magazin/magazin/a07-04/amigaone/wbkomplett.jpeg




http://www.homecomputer-collection.de/pic/kick31.gif


MITICA !!!

M I T I C O !!! :D
Peccato che non ho più il mio vecchio A2000...
ciao
Dob

[Dobermann75]

Non capisco il senso del thread, so solo che un ignorante (PCista, pure snobb!!) paragonerebbe un MC68000 ad un Intel 80486, cioe' processore del tutto piu' recente rispetto al Motorola.
Il paragone era MC68040 vs I80486, entrambi i processori erano i primi CISC che integravano al proprio interno CPU/FPU/MMU, il Motorola vinceva per una maggiore (di poco) velocita' nel calcolo in virgola mobile.

Chi vi parla e' un ex-amighista convinto, ex-possessore di un Amiga 500 (accelerato con una scheda dell'Hardital col 68030+68882 a 25 mhz [Il mitico Ing. Bianco, ve lo ricordate!? Che copiava le schede GVP ben piu' costose e performanti, per crearne di economiche ma pur sempre potenti.]), poi di un 2000 (tenuto 3 mesi), ed infine passato al 4000. Un 486 non poteva emulare un Amiga, per l'assenza dei chipset custom, che i pc dell'epoca si sognavano, per non parlare del Sistema Operativo (realmente) Multitasking (altro che Win'9x/ecc. e Unix) funzionante su SOLI 512 Kbyte di RAM............

byezzz
Perfettamente d'accordo, aggiungo che il motorola 68000 è da paragonare all'80.86 e al max ad un 2.86.

Per inciso, era meglio un C64 di un pc 8086...
ciao
Dob

[cdimauro]

Un 486 non poteva emulare un Amiga, per l'assenza dei chipset custom, che i pc dell'epoca si sognavano,
Eppure la prima volta che ho visto l'UAE (Unusable Amiga Emulator) è stato proprio su un 486...
per non parlare del Sistema Operativo (realmente) Multitasking (altro che Win'9x/ecc. e Unix) funzionante su SOLI 512 Kbyte di RAM............

byezzz
Già, ma qualcosa è rimasto: http://www.aros.org/ ;)

[cdimauro]

Perfettamente d'accordo, aggiungo che il motorola 68000 è da paragonare all'80.86 e al max ad un 2.86.
Come dicevo prima, non ha senso nemmeno questo tipo di paragone: 68000 e 80x86 (fino al 286) sono TROPPO diversi.

I confronti li comincerei a fare a partire dal 386, ma usando il 68030 a questo punto.
Per inciso, era meglio un C64 di un pc 8086...
ciao
Dob
Mah. Insomma. Anche questo è abbastanza discutibile: bisogna vedere l'hardware in dotazione al PC con l'8086, la sua frequenza di lavoro e il tipo di applicazioni da testare.
Tra l'altro un PC con 8086 può emulare un C64, ma il contrario non è vero.

[Marco71]

:ave: :ave: :ave: :ave: :ave: :ave:

Marco71.

[cdimauro]

A parte il fatto che mi farai morire prima o poi (e mia moglie non potrà godersi la pensione :asd: ), non ho capito se è per quello che ho scritto o per la recente modifica alla mia firma... :D

[shodan]

Come dicevo prima, non ha senso nemmeno questo tipo di paragone: 68000 e 80x86 (fino al 286) sono TROPPO diversi.

I confronti li comincerei a fare a partire dal 386, ma usando il 68030 a questo punto.

Mah. Insomma. Anche questo è abbastanza discutibile: bisogna vedere l'hardware in dotazione al PC con l'8086, la sua frequenza di lavoro e il tipo di applicazioni da testare.
Tra l'altro un PC con 8086 può emulare un C64, ma il contrario non è vero.

Ciao cdmauro,
come mai un C64 con il suo CMOS 6502 non poteva emulare un 8086?
Per problemi di performance o gli risulta proprio impossibile emulare l'isa x86?

Ciao grazie. :)

[Marco71]

A parte il fatto che mi farai morire prima o poi (e mia moglie non potrà godersi la pensione :asd: ), non ho capito se è per quello che ho scritto o per la recente modifica alla mia firma... :D

E' solo per manifestare il mio assenso con quello che lei dice Dr. Di Mauro...ci mancherebbe pure...
Se la avessi "sottomano" le "succhierei la linfa intellettual-vitale" come in "Space Vampires"..piccolo scherzo...
Per il confronto io opterei per un Motorola 68020 contro un Intel 80386 come del resto sulle riviste (sigh!) d'epoca avveniva sovente.
Su un numero di B.i.t che gelosamente ancora conservo c'era il confronto 68040 vs. 80486...
Grazie.

Marco71.

[Gica78R]

[...] recente modifica alla mia firma... :D
:eek:

:sob:

Nessuno e' perfetto... :D

[FiorDiLatte]

Questo era il rapporto di forza tra il 68040 in versione MC (cioè quella "finale" con integrata la f.p.u) e l'80486 Intel su test I.E.E.E non coinvolgenti istruzioni trascendenti tipo SIN,COS,LOG,LN ecc.
Quindi mi sembra un netto divario...
"FiorDiLatte", mi potresti spiegare meglio la "questione" Hardital dato che ho ancora uno dei miei due Amiga 500 con scheda acceleratrice BigBang 020-881 a 16MHz...
Cosa scandalosa è che utilizza un XC68020 ed un 68881 a 12MHZ cioè in pratica come si direbbe oggi era "over" specifiche...
Tra l'altro anche se esistesse ancora la suddetta Hardital non compererei più nienete dato che mi fecero penare una eternità per avere la scheda...scheda che aveva una enormità di problemi hardware di funzionamento...
Le schede acc. di oltre oceano erano una anltra cosa...
Grazie.

Marco71.


Il problema delle schede acceleratrici fu accentuato quando quei polli della motorola cambiarono il set d'istruzioni del 68030 rispetto al 68000/68020, quindi si creo' una incompatibilita' a livello software, gia' il 68040 era piu' compatibile verso il 68000 del 68030. Cmq tutte queste schede servivano solo ad aumentare la potenza di calcolo, che allora veniva sfruttata per velocizzare i primi software di rendering 3D di cui l'Amiga era pioniere (nessuno di Voi e' mai stato al Bit Movie a Riccione o ricorda la bbs Amiga3000+BBS!?).
Io sul 500 avevo una scheda col 68030+68882 a 25 mhz (se non ricordo male!!) montata internamente, sicuramente le GVP erano un'altra cosa, ma ti ricordi il prezzo che avevano!? Si parlava di due/tre milioni (GVP Great Valley Product se non erro, pian piano i ricordi riaffiorano!!) per scheda, che avevano a bordo sì 4/8 mega di memoria che facevano volare le prestazioni, pero' erano sempre soldi, l'Hardital ci fece un gran servizio, e penso che ci guadagno' parecchio ;) .

L'Hardital ancora oggi la si trova alle varie fierie dell'elettronica in giro per il nostro paese, e' ancora a Milano vende PC, e fa prezzi sempre molto buoni, da quello che sento da amici.


byezzz

[FiorDiLatte]

Eppure la prima volta che ho visto l'UAE (Unusable Amiga Emulator) è stato proprio su un 486...

Già, ma qualcosa è rimasto: http://www.aros.org/ ;)

Ma l'emulazione era sicuramente una ciofeca, una cosa era emulare un (cesso!!) Mac dell'epoca, che non era altri che un PC/Intel con un sistema operativo ed una cpu diversa, cioe' esistevano gia' all'epoca schede di emulazione che montavano le rom degli apple su Amiga, quest'ultimo in emulazione batteva a livello prestazionale i Mac, che dire, l'Amiga era TROPPO avanti, ed i vari PCisti "mentecatti" :D che la cosa gli bruciava parecchio, si inventavano strane frottole del genere "ma a me usare il mouse non mi piace" e poi "con tutti quei colori, mi sembra troppo giocattoloso", beh, lasciamo perdere la stupidita' umana non e' mai stata seconda a nessuno. :p

byezzz

[FiorDiLatte]

Come dicevo prima, non ha senso nemmeno questo tipo di paragone: 68000 e 80x86 (fino al 286) sono TROPPO diversi.

I confronti li comincerei a fare a partire dal 386, ma usando il 68030 a questo punto.

Mah. Insomma. Anche questo è abbastanza discutibile: bisogna vedere l'hardware in dotazione al PC con l'8086, la sua frequenza di lavoro e il tipo di applicazioni da testare.
Tra l'altro un PC con 8086 può emulare un C64, ma il contrario non è vero.

Secondo me Tu sei un po' troppo di parte, e' risaputo che le cpu Motorola all'epoca dei Cisc erano il top della tecnologia per il mercato di massa in commercio o quantomeno erano alla pari con quelle Intel, le cpu Intel erano SOLO le piu' vendute.

byezzz

[FiorDiLatte]

Per il confronto io opterei per un Motorola 68020 contro un Intel 80386 come del resto sulle riviste (sigh!) d'epoca avveniva sovente.
Su un numero di B.i.t che gelosamente ancora conservo c'era il confronto 68040 vs. 80486...
Grazie.

Marco71.

Mi sa che il confronto non regge, io ho sempre saputo che il rivale del 386 fosse il 030 non il 020, lo 020 fu forse il "colpo d'incontro di Motorola" se non erro usci' prima del 386, quindi di rivali non ne aveva. :rolleyes:

http://www.windoweb.it/edpstory_new/eh1980.htm leggete a fondo pagina ;) (e' cmq una guida di parte, se non parli di 68030/040, ecc. significa che non li hai apprezzati)

byezzz

[cdimauro]

Ciao cdmauro,
come mai un C64 con il suo CMOS 6502 non poteva emulare un 8086?
Per problemi di performance o gli risulta proprio impossibile emulare l'isa x86?

Ciao grazie. :)
Secondo me è difficile per un processore che arriva a indirizzare 64KB provare a emularne uno che ne arriva a indirizzare 1024KB. :p

Questo escludendo ipotetiche espansioni di memoria, tecniche di bank switching et similia per cercare di eliminare o attutire i limiti intrinseci di un'architettura... ;)

Ciao e di niente. :)

[cdimauro]

E' solo per manifestare il mio assenso con quello che lei dice Dr. Di Mauro...ci mancherebbe pure...
Se la avessi "sottomano" le "succhierei la linfa intellettual-vitale" come in "Space Vampires"..piccolo scherzo...
ARGH! :D
Per il confronto io opterei per un Motorola 68020 contro un Intel 80386 come del resto sulle riviste (sigh!) d'epoca avveniva sovente.
A livello di ISA magari sì, ma il confronto sarebbe impari IMHO: il 68020 ne uscirebbe perdente.

L'80386 è "contemporaneo" del 68030, ed entrambi utilizzano diverse tecniche per migliorare i tempi di esecuzione delle istruzioni, l'accesso alla ram (implementano il burst mode, se non erro), e inoltre integrano on-chip una PMMU per la traslazione degli indirizzi virtuali (molto più efficiente del 68451, se non ricordo male il numero).

Quindi il confronto lo farei fra 386 e 030.
Su un numero di B.i.t che gelosamente ancora conservo c'era il confronto 68040 vs. 80486...
Grazie.

Marco71.
Io ricordo ancora (con piacere :D) l'anteprima di Andrea De Prisco sul numero di MC MicroComputer con l'anteprima del 68040, e le diverse "stoccate" che dava all'80486, di cui era stata pubblicata l'anteprima qualche numero addietro... :D

[cdimauro]

:eek:

:sob:

Nessuno e' perfetto... :D
Non ti preoccupare: prima o poi troverai anche tu la via della verità e della vita... :asd: :) :mano:

[cdimauro]

Il problema delle schede acceleratrici fu accentuato quando quei polli della motorola cambiarono il set d'istruzioni del 68030 rispetto al 68000/68020, quindi si creo' una incompatibilita' a livello software, gia' il 68040 era piu' compatibile verso il 68000 del 68030.
Non esiste nessuna incompatibilità fra 68020 e 68030 a livello di istruzioni.

L'unica differenza è che la PMMU 68451 che veniva usata dal 68020 (quando era presente, chiaramente) aveva un'ISA diversa dalla PMMU integrata nel 68030, ma stiamo parlando sempre a livello supervisore: niente a che vedere con le "classiche" applicazioni, che giravano in modalità utente.

[cdimauro]

Ma l'emulazione era sicuramente una ciofeca,
Se permetti io l'ho visto a lavoro e posso parlare. ;)

Anche se era a livello embrionale, l'AmigaOS partiva e gli schermi si trascinavano: segno che l'emulazione dei chip custom qualcosa riusciva a farla. Anche qualche demo funzionava.

Certo, era un po' lento perché era scritto tutto in C e per niente ottimizzato: nulla a che vedere con le versioni più recenti di UAE, che non a caso cambiò il nome in Unix Amiga Emulator (vuol dire che non era più "Unusable" ;))
una cosa era emulare un (cesso!!) Mac dell'epoca, che non era altri che un PC/Intel con un sistema operativo ed una cpu diversa,
Guarda che Mac e PC all'epoca potevano avere soltanto i chip della ram in comune... ;)
cioe' esistevano gia' all'epoca schede di emulazione che montavano le rom degli apple su Amiga, quest'ultimo in emulazione batteva a livello prestazionale i Mac,
Lo so: perché usava il Blitter per tutte le operazioni grafiche. Beh, e questo cosa dimostra? Semplicemente che il Mac era semplice da emulare per l'Amiga (e per l'ST).
che dire, l'Amiga era TROPPO avanti,
Fino a un certo punto. Già con l'arrivo della VGA e della SoundBlaster qualcosa cominciò a muoversi. Poco ci fu il sorpasso, grazie alla "forza bruta" del PC e la latitanza della Commodore e di Motorola...
ed i vari PCisti "mentecatti" :D che la cosa gli bruciava parecchio, si inventavano strane frottole del genere "ma a me usare il mouse non mi piace" e poi "con tutti quei colori, mi sembra troppo giocattoloso", beh, lasciamo perdere la stupidita' umana non e' mai stata seconda a nessuno. :p

byezzz
Su questo concordo al 100%...

Un mio amico mi prendeva in giro perché usavo nomi di file molto lunghi, quando invece lui adorava il DOS che gli permetteva di tirare fuori la sua "creatività" inventandosi dei nomi che stessero negli 8 + 3 caratteri che gli permetteva.
Salvo poi, passando poi a Linux, prendermi in giro perché con AmigaOS ero "limitato a soli 30 caratteri" e lui arrivava a usarne quasi 255... :asd: :p

[cdimauro]

Secondo me Tu sei un po' troppo di parte, e' risaputo che le cpu Motorola all'epoca dei Cisc erano il top della tecnologia per il mercato di massa in commercio o quantomeno erano alla pari con quelle Intel, le cpu Intel erano SOLO le piu' vendute.

byezzz
Secondo me tu non mi conosci affatto: l'Amiga, AmigaOS e i Motorola 680x0 sono stati i miei computer, s.o, e processori prediletti, rispettivamente. ;)

Ciò non toglie che quando si devono fare delle valutazioni si devono mettere da parte i sentimenti (se ancora ne sono rimasti, a parte i ricordi ;)) e utilizzare logica e razionalità.

Ancora oggi a me piace l'architettura 680x0, ma non è sopravvissuta alla corsa ai Mhz: era troppo complicata (internamente) da permettere di rimanere competitiva. E la potenza bruta, alla fine, ha avuto la meglio.

[cdimauro]

Mi sa che il confronto non regge, io ho sempre saputo che il rivale del 386 fosse il 030 non il 020, lo 020 fu forse il "colpo d'incontro di Motorola"
Cosa vuoi dire con ciò?
se non erro usci' prima del 386, quindi di rivali non ne aveva. :rolleyes:
Ovvio: il 286 non era paragonabile né al 68000 né tanto meno al 68020. Erano troppo diversi.
http://www.windoweb.it/edpstory_new/eh1980.htm leggete a fondo pagina ;) (e' cmq una guida di parte, se non parli di 68030/040, ecc. significa che non li hai apprezzati)

byezzz
E' solo una rozza bozza di storia: non puoi pretendere che riporti tutto e in maniera precisa.

Il 68020, ad esempio, aveva 192mila transistor e non 256mila... ;)

[Marco71]

ARGH! :D

A livello di ISA magari sì, ma il confronto sarebbe impari IMHO: il 68020 ne uscirebbe perdente.

L'80386 è "contemporaneo" del 68030, ed entrambi utilizzano diverse tecniche per migliorare i tempi di esecuzione delle istruzioni, l'accesso alla ram (implementano il burst mode, se non erro), e inoltre integrano on-chip una PMMU per la traslazione degli indirizzi virtuali (molto più efficiente del 68451, se non ricordo male il numero).

Quindi il confronto lo farei fra 386 e 030.

Io ricordo ancora (con piacere :D) l'anteprima di Andrea De Prisco sul numero di MC MicroComputer con l'anteprima del 68040, e le diverse "stoccate" che dava all'80486, di cui era stata pubblicata l'anteprima qualche numero addietro... :D



...fu introdotto da Intel per la prima volta con la generazione di processori 80486 per il "riempimento a raffica" della memoria cache da 8KBytes condivisa tra dati ed istruzioni...
Il Motorola 68030 aveva già architettura Harvard con cache memory dati ed istruzioni e modalità burst.
Concordo sul parere espresso riguardo al 68020.
Dr. Di Mauro, per caso non avrebbe una microfotografia del 68030 ?
Quella del 68020 la ho su un manuale della Jackson...
Grazie.

:ave: :ave: :ave: :ave: :ave: :ave: :ave: :ave:

Marco71.

[cdimauro]

...fu introdotto da Intel per la prima volta con la generazione di processori 80486 per il "riempimento a raffica" della memoria cache da 8KBytes condivisa tra dati ed istruzioni...
Ricordavo diversamente... La mia memoria ha fatto cilecca... :p
Il Motorola 68030 aveva già architettura Harvard con cache memory dati ed istruzioni e modalità burst.
L'80386 non aveva nemmeno la cache istruzioni. :D

Però ricordo che l'accesso alla memoria fosse molto veloce. Boh. Ricordi.
Concordo sul parere espresso riguardo al 68020.
Dr. Di Mauro, per caso non avrebbe una microfotografia del 68030 ?
Ho seppellito tutto in garage...
Quella del 68020 la ho su un manuale della Jackson...
Jackson... :bleah: Ricordo ancora con orrore le sue traduzioni... :(
Grazie.

:ave: :ave: :ave: :ave: :ave: :ave: :ave: :ave:

Marco71.
:rotfl: L'ho detto: mi farai morire prima o poi...

[Marco71]

..l'accesso alla memoria da parte dell'80386 era veloce grazie ad una particolare modalità "a canalizzazione" (pipelined) che era comunque disabilitabile.
Non si ricorda Dr. Di Mauro se per caso anche i 68030 o 68040 utilizzassero un barrel shifter per le operazioni sugli interi e logiche oltre che naturalmente di shift in senso stretto ?
Francamente sono rimasto molto deluso dal fatto che Intel (per suoi dichiarati motivi tecnologici) nei core Willamette e Northwood abbia tolto tale importante struttura hardware...
Nel Prescott è stato re-inserito in una delle A.L.U double pumped...
Forse uno dei pochi vantaggi di questo tanto bistrattato nucleo...
Grazie.

P.S: Per questa volta le risparmio le genuflessioni multiple...eh,eh,eh...

Marco71.

[cdimauro]

..l'accesso alla memoria da parte dell'80386 era veloce grazie ad una particolare modalità "a canalizzazione" (pipelined) che era comunque disabilitabile.
L'ho confusa con il burst mode... :doh:
Non si ricorda Dr. Di Mauro se per caso anche i 68030 o 68040 utilizzassero un barrel shifter per le operazioni sugli interi e logiche oltre che naturalmente di shift in senso stretto ?
68030, 68040 e 68060 dovrebbero usare tutti quanti i barrel shifter.
Adesso non ricordo se anche il 68020 ne era dotato; penso di sì: occupa parecchio spazio su chip / transistor, e può darsi che dei circa 125mila trnasistor in più rispetto al 68000 una buona parte potrebbero appartenervi
Francamente sono rimasto molto deluso dal fatto che Intel (per suoi dichiarati motivi tecnologici) nei core Willamette e Northwood abbia tolto tale importante struttura hardware...
Idem.
Nel Prescott è stato re-inserito in una delle A.L.U double pumped...
Ma è ancora abbastanza castrato. Infatti l'operazione più "pericolosa" per i Prescott in LongMode mi sembra sia proprio lo shift...
Forse uno dei pochi vantaggi di questo tanto bistrattato nucleo...
Grazie.
Indubbiamente ha recuperato molto. E considerati i 31 stadi di pipeline di questo processore, debbo dire che Intel ha fatto un buon lavoro...
P.S: Per questa volta le risparmio le genuflessioni multiple...eh,eh,eh...

Marco71.
:p :p :p

[shodan]

Secondo me è difficile per un processore che arriva a indirizzare 64KB provare a emularne uno che ne arriva a indirizzare 1024KB. :p

Questo escludendo ipotetiche espansioni di memoria, tecniche di bank switching et similia per cercare di eliminare o attutire i limiti intrinseci di un'architettura... ;)

Ciao e di niente. :)

Ehm, già... dimenticavo questo piccolo particolare! :p

In ogni caso se ben ricordo come "potenza bruta" il chip CMOS 6502 (1-2 Mhz) era superiore a un 8086 (6-8Mhz se ben ricordo).

Ricordo infatti che per usare discretamente C64S per DOS (un emulatore C64 per chi non lo sapesse) era consigliato un 386; non so però se tutta questa potenza "sovrabbondante" servisse ad emulare qualche chip custom del commodore64 (ne aveva uno per la gestione degli sprite,se non erro).

Però sono solo vaghi ricordi... potrei sbagliarmi! :oink:

Ciao. :)

[cdimauro]

In ogni caso se ben ricordo come "potenza bruta" il chip CMOS 6502 (1-2 Mhz) era superiore a un 8086 (6-8Mhz se ben ricordo).
Dipende dalle applicazioni.

Il 6502 è processore molto efficiente, impiega da 2 a 7 cicli di clock per eseguire le sue istruzioni. Invece l'8086 impiega anche diverse decine di cicli di clock per eseguirle.

Però c'è da dire che le istruzioni del 6502 sono poche, piuttosto semplici, lavorano a 8 bit, e che ha pure pochi registri, mentre per l'8086 è l'esatto contrario, e lavora a 16 bit.

Quindi è tutto da vedere.
Ricordo infatti che per usare discretamente C64S per DOS (un emulatore C64 per chi non lo sapesse) era consigliato un 386; non so però se tutta questa potenza "sovrabbondante" servisse ad emulare qualche chip custom del commodore64 (ne aveva uno per la gestione degli sprite,se non erro).

Però sono solo vaghi ricordi... potrei sbagliarmi! :oink:

Ciao. :)
Non sbagli: il 6510, per quanto molto efficiente, è pur sempre un processore che lavora 1Mhz, per cui non richiede molta potenza di calcolo. Tra l'altro i 64KB di ram stanno tutti dentro un solo segmento dati dell'8086.

Però, appunto, c'è da emulare i chip custum: VIC-II, SID e CIA non sono roba di poco conto. Inoltre c'è anche da gestire il bank switch (la ram è 64KB, ma ci sono circa 20KB di ROM mappati nella zona alta).

Più precisa vuoi ottenere l'emulazione, più complesse diventano le routine. Ad esempio alcune demo per C64 richiedono che il 6510 sia emulato alla perfezione: perfino la pipeline del processore dev'essere emulata in maniera precisa. Puoi immaginare cosa voglia significare questo... :p

[shodan]

Dipende dalle applicazioni.

Il 6502 è processore molto efficiente, impiega da 2 a 7 cicli di clock per eseguire le sue istruzioni. Invece l'8086 impiega anche diverse decine di cicli di clock per eseguirle.

Però c'è da dire che le istruzioni del 6502 sono poche, piuttosto semplici, lavorano a 8 bit, e che ha pure pochi registri, mentre per l'8086 è l'esatto contrario, e lavora a 16 bit.

Quindi è tutto da vedere.

Non sbagli: il 6510, per quanto molto efficiente, è pur sempre un processore che lavora 1Mhz, per cui non richiede molta potenza di calcolo. Tra l'altro i 64KB di ram stanno tutti dentro un solo segmento dati dell'8086.

Però, appunto, c'è da emulare i chip custum: VIC-II, SID e CIA non sono roba di poco conto. Inoltre c'è anche da gestire il bank switch (la ram è 64KB, ma ci sono circa 20KB di ROM mappati nella zona alta).

Più precisa vuoi ottenere l'emulazione, più complesse diventano le routine. Ad esempio alcune demo per C64 richiedono che il 6510 sia emulato alla perfezione: perfino la pipeline del processore dev'essere emulata in maniera precisa. Puoi immaginare cosa voglia significare questo... :p

Mmm... vediamo di mettere in ordine tra i miei ricordi!
VIC-II e SID dovrebbero essere rispettivamente i chip in carico alla gestione video e audio... il chip CIA però non ricordo proprio cosa fosse! :stordita:
Relativamente all'emulazione, non pensavo ci fossero applicazioni che richiedono un livello di precisione (e sincronizzazione con i chip custom, immagino) tale. Come mai è necessario essere così maniacali?

Ciao grazie come al solito! ;)

[cdimauro]

Mmm... vediamo di mettere in ordine tra i miei ricordi!
VIC-II e SID dovrebbero essere rispettivamente i chip in carico alla gestione video e audio... il chip CIA però non ricordo proprio cosa fosse! :stordita:
Sono due in realtà, e si occupavano dell'I/O e dei timer di sistema.
Relativamente all'emulazione, non pensavo ci fossero applicazioni che richiedono un livello di precisione (e sincronizzazione con i chip custom, immagino) tale. Come mai è necessario essere così maniacali?
Fortunatamente erano pochissime. :) Erano tecniche adottate da alcuni programmatori "estremi" che amavano giocare l'hardware.
Sono quelle che possono mettere in ginocchio un emulatore, se non fornisce un'emulazione "cycle exact" (com'è definita in gergo) del sistema e che richiede una notevole potenza di calcolo.
Ciao grazie come al solito! ;)
Di niente. :)

[Marco71]

:ave:

Marco71.

[shodan]

Sono due in realtà, e si occupavano dell'I/O e dei timer di sistema.

Fortunatamente erano pochissime. :) Erano tecniche adottate da alcuni programmatori "estremi" che amavano giocare l'hardware.
Sono quelle che possono mettere in ginocchio un emulatore, se non fornisce un'emulazione "cycle exact" (com'è definita in gergo) del sistema e che richiede una notevole potenza di calcolo.

Di niente. :)

Quindi si occupavano delle porte joystick, del datassette, del 1541/1541II e delle cartucce... mi sfugge qualcosa? :fagiano:
Per timer intendi il timer interno che scandiva fino a 1/60 di secondo vero? Quanti accidenti gli ho mandato per non usare un sistema decimale (che so, 1/10, 1/100, ecc.). :p

Ciao. :)

[shodan]

:ave:

Marco71.

Ehm... ci sono anche altre faccine, sai? :sofico: :fagiano: :doh: :ciapet:

[Marco71]

:sbav: :sbav: :sbav:
Pendo dalle sue labbra Dr. Di Mauro per tutto quello che sa in fatto di c.p.u ecc.
Se avessi un poco di posto rimetterei in sesto il mio Philips CM 8833 con annesso A500...con dicasi 2, 2MBytes di memoria "Fast" e 512KBytes di "Chip" indirizzabile da FatAgnus 8370 ...
Viva "Lorraine" !
Grazie.

Marco71.

[FiorDiLatte]

:sbav: :sbav: :sbav:
Pendo dalle sue labbra Dr. Di Mauro per tutto quello che sa in fatto di c.p.u ecc.
Se avessi un poco di posto rimetterei in sesto il mio Philips CM 8833 con annesso A500...con dicasi 2, 2MBytes di memoria "Fast" e 512KBytes di "Chip" indirizzabile da FatAgnus 8370 ...
Viva "Lorraine" !
Grazie.

Marco71.


Beh, era meglio il mio A4000/040 a 25 mhz con revisione 011 del SuperBuster per sfruttare al meglio gli slot Zorro III !! :D :oink:

byezzz

ps= avevo una scheda video della Macrosystem la Retina BLTZ3, mai utilizzata, perche' non riuscii a comprare/trovare un monitor Multiscan (decente) che la supportasse (avevo il Commodore 1960 che a + di 72 hz a 800*600 non faceva).

pps= Superbuster sostituitomi in garanzia nel centro assistenza Commodore GLV Elettronica di Pisa ;) , l'integrato era un SMT.

[Marco71]

...sigh...ma ahimè sono sempre stato a corto di soldi in tutte le fasi della mia vita...
Anche all'epoca mi sarebbe piaciuto un A2000 con ben altre doti di espandibilità ma..sigh mi dovetti accontentare di un A500.
Spero che non esista un altro pianeta abitato da vita intelligente (per come la classifichiamo noi) nel "nostro" oppure in uno degli infiniti Universi-bolla in cui tutto sia basato sul denaro sia esso "tangibile" in carta oppure "etereo" e viaggiante nella miriade di computer dedicati al mondo della finanza...
Scusate l'off-topic.
Grazie.

Marco71.

[cdimauro]

Quindi si occupavano delle porte joystick, del datassette, del 1541/1541II e delle cartucce... mi sfugge qualcosa? :fagiano:
Sì, che le cartucce erano collegate direttamente al bus del processore. :)

Per il resto è tutto ok.
Per timer intendi il timer interno che scandiva fino a 1/60 di secondo vero? Quanti accidenti gli ho mandato per non usare un sistema decimale (che so, 1/10, 1/100, ecc.). :p

Ciao. :)
Invece di lamentarti avresti potuto riprogrammartelo il timer... :sofico:

A parte gli scherzi, i CIA non erano vincolati al 1/60 di secondo, ma erano programmabili e avevano un'ottima risoluzione. Era dei buoni chio, e infatti ce li siamo ritrovati anche nell'Amiga... :D

[cdimauro]

:sbav: :sbav: :sbav:
Pendo dalle sue labbra Dr. Di Mauro per tutto quello che sa in fatto di c.p.u ecc.
Se avessi un poco di posto rimetterei in sesto il mio Philips CM 8833 con annesso A500...con dicasi 2, 2MBytes di memoria "Fast" e 512KBytes di "Chip" indirizzabile da FatAgnus 8370 ...
Viva "Lorraine" !
Grazie.

Marco71.
Purtroppo il mio Amiga 1200 ha ormai tutte le uscite video defunte. :cry:

L'ho conservato per una questione affettiva, e per poter usare a pieno titolo le rom del Kickstart col WinUAE... :)

P.S. Beati voi...

[shodan]

Sì, che le cartucce erano collegate direttamente al bus del processore. :)

Per il resto è tutto ok.

Invece di lamentarti avresti potuto riprogrammartelo il timer... :sofico:

A parte gli scherzi, i CIA non erano vincolati al 1/60 di secondo, ma erano programmabili e avevano un'ottima risoluzione. Era dei buoni chio, e infatti ce li siamo ritrovati anche nell'Amiga... :D

Azz, vedi quante cose si imparano dopo 10 anni che ti servivano... :sofico:

Ciao grazie! :)

[Dobermann75]

Come dicevo prima, non ha senso nemmeno questo tipo di paragone: 68000 e 80x86 (fino al 286) sono TROPPO diversi.

I confronti li comincerei a fare a partire dal 386, ma usando il 68030 a questo punto.

Mah. Insomma. Anche questo è abbastanza discutibile: bisogna vedere l'hardware in dotazione al PC con l'8086, la sua frequenza di lavoro e il tipo di applicazioni da testare.
Tra l'altro un PC con 8086 può emulare un C64, ma il contrario non è vero.
mi ero perso il post...

Si,ti do' ragione...
[ot on]
purtroppo confrontavo tra i ricordi dei "bei tempi" ,ormai offuscati :( ,
l'immagine del mio primo pc (c64,biscottone) con schermo a colori (per il quale avevo trovato un antenato del cad, che se non ricordo male si caricava via cartuccia) e quello del mio vecchio, un ibm con fosfori verdi...che usava per lavorare con lotus e wordstar...e che con i giochini o programmi con grafica era un vero bidone...
mentre a scuola avevamo gli apple IIe,IIc e IIgs
un'altro pianeta ricordo il suo 2.86 con scheda vga 256colori, dove vidi girare il primo autocad di autodesk...
Non so se ricordi la pubblicità dell'86/87 di commodore: rendi un rospo e ti diamo un principe (o qualcosa del genere) ti supervalutavano e ritiravano il vecchio c64 se acquistavi un Amiga500... Dovrebbero fare un tread di vecchi ricordi informatici ;)
[ot off]
ciao

[cdimauro]

No, quella pubblicità non la ricordo proprio...

Beh, se ti leggi il thread, vedrai che abbiamo trattato parecchio vintage... :p

[Marco71]

mi ero perso il post...

Si,ti do' ragione...
[ot on]
purtroppo confrontavo tra i ricordi dei "bei tempi" ,ormai offuscati :( ,
l'immagine del mio primo pc (c64,biscottone) con schermo a colori (per il quale avevo trovato un antenato del cad, che se non ricordo male si caricava via cartuccia) e quello del mio vecchio, un ibm con fosfori verdi...che usava per lavorare con lotus e wordstar...e che con i giochini o programmi con grafica era un vero bidone...
mentre a scuola avevamo gli apple IIe,IIc e IIgs
un'altro pianeta ricordo il suo 2.86 con scheda vga 256colori, dove vidi girare il primo autocad di autodesk...
Non so se ricordi la pubblicità dell'86/87 di commodore: rendi un rospo e ti diamo un principe (o qualcosa del genere) ti supervalutavano e ritiravano il vecchio c64 se acquistavi un Amiga500... Dovrebbero fare un tread di vecchi ricordi informatici ;)
[ot off]
ciao

...io ricordo...
Il mio "piccolo" A500 delle prime versioni con soli 512KBytes (i ragazzi di oggi di 20 o meno anni dovrebbero riflettere...) l'ho preso tramite corriere a Torino proprio con quella permuta...
Ave Dr. Di Mauro :ave: :ave: :ave: :ave:

Marco71.

[cdimauro]

Io ho dovuto vendere il mio amatissimo Commodore 128 per poter comprare l'Amiga 2000. :cry:

[yossarian]

E' una semplicità che si paga (a seconda dell'architettura) in termini di non pochi transistor, però: un conto è "biforcare" la pipeline a uno stadio avanzato (e quindi condividendo gran parte della logica), suddividendo l'esecuzione delle istruzioni "intere" da quelle "FP", e tutt'altra cosa è farlo già dopo pochi stadi d'esecuzione soltanto per i salti (per poi suddividersi nuovamente).

Diciamo che ogni scelta è sempre frutto di compromessi: ha poco senso farlo per architetture con pipeline corte, dove l'impatto prestazionale è più limitato, mentre diventa importante con quelle dotate di diversi stadi di pipeline, che soffrono parecchio se devono svuotare la pipeline dopo parecchi cicli di clock.

Esatto. I processori di oggi sono dotati di buoni predittori di salto (siamo intorno al 95%).



non so quanto sia vecchio questo thread (l'ho trovato per caso, non me ne vogliate :mc: ).
In realtà, le cose, con il branching dinamico, sono un po' più complesse. In un'architettuta a pipeline, in cui vi siano più unità di calcolo in parallelo (che è ormai la norma di tutte le cpu o gpu che dir si voglia), un errore di misprediction costa un numero di cicli circa pari (leggermente superiore) a 3 volte la lunghezza delle pipeline. Questo perchè tali architetture lavorano su un certo valore di "coerenza" di dati in input che solitamente è pari al numero di elementi contemporaneamente elaborabili all'interno del chip. Quindi, il dispositivo di branch prediction si articola in più elementi: un'unità centrale, posta all'inizio del gruppo di pipeline, che raccoglie i dati di tutte le elaborazioni e li confronta con quelli della "previsione" (non mi addentro sui vari tipi di dynamic branching e, quindi, sull'architettura più o meno complessa, di queste unità) e delle unità periferiche, poste in fondo alle pipeline, ognuna delle queli raccoglie i dati dell'ultima elaborazione effettuata e li invia all'unità centrale per il controllo.
Il funzionamento, di conseguenza, è il seguente:
l'unità centrale effettua un confronto tra i dati in memoria (frutto della precedente o delle n precedenti elaborazioni), con quelli ottenuti dall'ultima elaborazione effettuata. Se la previsione è corretta, l'elaborazione prosegue (perchè, nel frattempo, dando per buona la precedente previsione, le pipeline sono state riempite con i dati "presumibilmente corretti", man mano che si svuotava), altrimenti si deve svuotare la cache, si devono svuotare le pipeline, si deve nuovamente riempire la cache e, di conseguenza, le pipeline, con i dati, questa volta corretti.
Questo significa dover effettuare:
un riempimento della pipeline con dati "presumibilmente giusti"
uno svuotamento della cache
uno svuotamento delle pipeline
un riemprimento della cache
un riempimento delle pipeline
questo senza tener conto che anche l'aggiornamento dei dati all'interno del dispositivo di branching richiede, nella migliore delle ipotesi, 2 o 3 cicli di clock).
Ad esempio, una pipeline a 31 stadi (o giù di li) tipo quella del Prescott, in caso di misprediction fa perdere oltre un centinaio di cicli di clock solo per le operazioni di svuotamento e riempimento (2 volte) della pipeline (non a caso, nel Prescott hanno ampliato la L2, anche per ridurre l'impatto di una misprediction).

:)

[cdimauro]

Meglio tardi che mai: sarebbe stato bello averti fra noi fin dall'inizio. :)

Grazie per le puntuali precisazioni: davvero molto interessanti.

[fantoibed]

In realtà, le cose, con il branching dinamico, sono un po' più complesse. In un'architettuta a pipeline[.....]Molto interessante! :p
Sarebbe bello se ci fosse un bel thread sticky sulle architetture dei processori da poter consultare e dove potersi confrontare sui pro e i contro di una particolare scelta architetturale piuttosto che un'altra nell'affrontare questa o quella classe di problemi... :fiufiu:

[yossarian]

Meglio tardi che mai: sarebbe stato bello averti fra noi fin dall'inizio. :)

Grazie per le puntuali precisazioni: davvero molto interessanti.


doppio

[yossarian]

Meglio tardi che mai: sarebbe stato bello averti fra noi fin dall'inizio. :)

Grazie per le puntuali precisazioni: davvero molto interessanti.


figurati, mi sono trovato a "passare" veramente per caso, ho iniziato a leggere il thread, l'ho trovato interessante e sono andato avanti per un bel po' (ma non ce l'ho fatta a finirlo) :)

Molto interessante! :p
Sarebbe bello se ci fosse un bel thread sticky sulle architetture dei processori da poter consultare e dove potersi confrontare sui pro e i contro di una particolare scelta architetturale piuttosto che un'altra nell'affrontare questa o quella classe di problemi... :fiufiu:


vero :fiufiu: :D

[fantoibed]

vero :fiufiu: :DHahaha! :rotfl: :rotfl: :rotfl: Ho capito l'antifona! Beh, c'ho provato! :D Tentar non nuoce...

[DioBrando]

Molto interessante! :p
Sarebbe bello se ci fosse un bel thread sticky sulle architetture dei processori da poter consultare e dove potersi confrontare sui pro e i contro di una particolare scelta architetturale piuttosto che un'altra nell'affrontare questa o quella classe di problemi... :fiufiu:

in effetti sarebbe un'ottima idea, anche per evitare le solite domande cicliche "ma è meglio un P4 o un athlon 64?" oppure tra X64 e itanium o + in generale com'è tornata in voga di recente tra RISC e CISC :D


Spiegare le scelte, i pro ed i contro di un'archittettura rispetto ad un'altra consentirebbe anche di avere + chiari poi i risultati in termini prestazionali IMHO nei confronti di una o + cpu comparate tra loro.

[DioBrando]

vero :fiufiu: :D

magari ho capito male, ma tento di rendere esplicito il msg subliminale di faintobed.


"Sarebbe bello che qlc lo provasse a farlo, ad es. yossarian" :asd: :D
( chiaramente arricchito dagli spunti di altri, fonti letterarie, siti ecc.) :p

[fantoibed]

"Sarebbe bello che qlc lo provasse a farlo, ad es. yossarian" :asd: :D
( chiaramente arricchito dagli spunti di altri, fonti letterarie, siti ecc.) :p
Penso che abbia capito il messaggio subliminale ed abbia risposto (sempre in via subliminale) "certo sarebbe bello se qualcuno con le mie (di yossarian) conoscenze sull'argomento avesse tempo e voglia di svilupparlo in un thread appositamente creato... :fiufiu: ..."

;) :p

[cdimauro]

Servirebbe una "Knowledge Base", da consultare per chiunque abbia anche problemi con l'hardware, prima di scrivere l'n-esimo post sulla stessa cosa.

Qualcosa di facilmente e velocemente consultabile.

[Marco71]

:ave: :ave: :ave: :ave:

Marco71.