Confronto fra i486 e Motorola 68000

[^TiGeRShArK^]

Originariamente inviato da MadRat

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]

Originariamente inviato da cdimauro

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/backforthe...ianoframe.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.

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.

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.

[fantoibed]

Originariamente inviato da fek

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

[cdimauro]

Originariamente inviato da fantoibed

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]

Originariamente inviato da cdimauro

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]

Originariamente inviato da cdimauro

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?

Originariamente inviato da cdimauro

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?

Originariamente inviato da cdimauro

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...cle-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]

Originariamente inviato da Marco71

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/program...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]

Originariamente inviato da Marco71

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]

Originariamente inviato da fantoibed

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...cle-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]

Originariamente inviato da 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" ?

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..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Se per te 7 milioni di dollari nell'80 sembrano pochi..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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/backforthe...ianoframe.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.

Originariamente inviato da cdimauro

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?? ) )

Originariamente inviato da cdimauro

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??

Originariamente inviato da cdimauro

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..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

Gli ST solo nel MIDI.

Nel Midi, nel calcolo, nel costo e nell'affidabilita' ecc..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Bella risposta del c.. 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!! ) 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!!

Originariamente inviato da cdimauro

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

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.

Originariamente inviato da cdimauro

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..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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!!

Originariamente inviato da cdimauro

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??

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Come vedi tu forse.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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'.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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'.

Originariamente inviato da cdimauro

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).

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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'.

Originariamente inviato da cdimauro

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).

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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!!

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

Questo è avvenuto coi PC, non con altre piattaforme.

Idem come sopra..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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..

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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')

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Senta, ho un dolorino da una parte..

[fek]

Originariamente inviato da 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.

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]

Originariamente inviato da MadRat

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/amigare....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:A...sh_Desktop.png
GEM avevo ripreso dei concetti, ma era più scarsa della GUI di MacOS.
Infatti qui: http://en.wikipedia.org/wiki/History...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.. 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!! ) 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...
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/amigare...agonslair1zzap

"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/antspant...o/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:A...orkbench_2.gif
Nel 1993, con Amiga 1200 e 4000 arrivò la versione 3.0:
http://en.wikipedia.org/wiki/Image:A...orkbench_3.gif
E poi la 3.5/3.9:
http://en.wikipedia.org/wiki/Image:A..._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.

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... 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...
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

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]

Originariamente inviato da Marco71

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...

[MadRat]

Originariamente inviato da Marco71

Comunque a mio parere un confronto tra Atari ST ed Amiga appare un poco fuori topic o sbaglio ?

Originariamente inviato da cdimauro

Se è per questo neppure Cell, PPC970, Xenon, ecc. c'entravano col topic...

Almeno quei due computer hanno un 68k, in qualche modo c'entrano..ma il Cell appunto??
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.