di  -  mercoledì 16 giugno 2010

Alcuni termini ricorrono spesso nella letteratura informatica, specialmente per i sistemi più datati dove il contatto diretto con l’hardware era ordinaria amministrazione, e non c’erano diversi strati software che si frapponevano col codice delle applicazioni.

Se di DMA, ad esempio, abbiamo sentito parlare diverse volte (ancora oggi il termine fa capolino ogni tanto quando viene recensito qualche dispositivo che ne fa uso), davanti a riga di raster si comincia un po’ a storcere il naso, anche se la traduzione letterale aiuta un po’ chi ha avuto a che fare con immagini bitmap. Color clock, però, può lasciare letteralmente basiti.

Il motivo è semplice: si tratta di termini tecnici legati alla generazione delle immagini (e non) di dispositivi hardware che dalla seconda metà degli anni ’70 fino alla seconda metà degli anni ’90 hanno letteralmente dominato la scena. Di color clock, tra l’altro, si parla in una remota e oscura sezione dell’Amiga Hardware Manual (anche se il concetto sarà stato probabilmente presente in altre macchine), quindi è altamente specifico.

Quello che bisogna tenere a mente in questi casi è un fatto ben preciso: a regolare il funzionamento della piattaforma era il “video” (notare le virgolette), e più precisamente l’apposito clock che serviva al chip che si faceva carico di generare correttamente l’output (tenendo conto degli standard televisivi dell’epoca: NTSC, PAL e SECAM).

Tutto si riassumeva, quindi, nelle immagini che venivano visualizzate, e misurate in fotogrammi al secondo, anche se è più corretto parlare di quadri e semiquadri visualizzati nell’arco di un secondo (userò comunque i termini in maniera intercambile). A discriminare fra semiquadro e quadro era l’uso della modalità interlace (interlacciamento) o meno, di cui però preferisco parlare più avanti, in chiusura. Al momento tratterò il segnale non interlacciato e in questo contesto per quadro intendo grossolanamente un fotogramma visualizzato.

Per il nostrano segnale PAL avremo pertanto 50 quadri al secondo generati, e parleremo di “immagini a 50Hz”, termine questo molto in uso a cavallo fra gli anni ’80 e ’90: “quel gioco è a 50Hz!” (e a seguire la faccia meravigliata con la mascella da raccogliere da terra) significava che visualizzava 50 immagini al secondo; di conseguenza un “gioco a 25Hz” ne visualizzava 25 al secondo, anche se in realtà i quadri erano sempre 50, e semplicemente due di fila ripetevano a video la stessa immagine.

Il termine più appropriato sarebbe quello di fotogrammi al secondo (FPS), che è in uso oggi e deriva dal fatto che, passando dai giochi 2D a quelli 3D, è difficile riuscire a renderizzare i fotogrammi impiegando lo stesso tempo o, comunque, a generare sempre l’immagine prima che la circuiteria video ricominci a leggerne i dati. Non mi addentrerò nello specifico perché non è l’argomento dell’articolo, per cui ritorno ad assumere che le immagini generate siano sincronizzate col famigerato pennello elettronico.

Sì, perché se oggi si può smanettare con le impostazioni del gioco o della scheda video per impostare il famigerato vsync, a quei tempi il suo uso era assolutamente la norma, pena il presentarsi di fastidiosi sfarfallamenti delle immagini (leggasi: quel gioco “faceva schifo”) che in gergo vengono chiamati anche tearing (se è visibile un “taglio” dell’immagine) o flickering (se la scena ha poco o nessun movimento dello scenario, mentre oggetti come i personaggi si muovono).

Per la precisione e per chi non lo sapesse, questo difetto si verifica nel momento in cui il pennello elettronico sta disegnando il fotogramma attualmente elaborato, e durante il suo lavoro di aggiornamento dello schermo la grafica viene alterata coi dati del fotogramma successivo. In pratica il video presenta due zone orizzontali distinte: quella superiore che visualizza la grafica dell’attuale fotogramma, e di quello successivo quella inferiore. Questo “scollamento” viene percepito dall’occhio e genera quel fastidioso effetto che è tanto più marcato quanto più movimento e/o diverse risultano le due zone.

Tutto ciò permette di entrare nello specifico sul funzionamento del segnale video e su come veniva generata dalle applicazioni la grafica e “data in pasto” al chip video per visualizzarla. Tornando al concetto di quadro / fotogramma, l’obiettivo è di visualizzare un’immagine bitmap, quindi costituita da un certo numero di righe, a loro volta divise in colonne, con un determinato colore.

E’, quindi, intuitivo pensare che il chip video debba leggere queste righe, e passarle in qualche modo al pennello elettronico della TV (o del monitor), ovviamente sincronizzando opportunamente le operazioni e facendo sì che la prima riga non risulti visualizzata in fondo allo schermo o, peggio ancora, che una parte sia visualizzata sulla destra, e la rimanente a sinistra.

La sincronizzazione avviene usando un clock “comune” e alcuni segnali che il circuito video del sistema genera per “pilotare” la TV e dirle cosa deve fare. L’operazione di disegno di una riga a video è semplice: il pennello elettronico preleva i dati sul colore da visualizzare, e pixel dopo pixel provvede, da sinistra verso destra, a renderli a video.

Una volta giunti alla fine della riga bisogna passare all’inizio della successiva, e a ciò serve il cosiddetto periodo di horizontal retrace; si tratta di un tempo “morto” (non viene visualizzato nulla) necessario al pennello elettronico per spostarsi da destra a sinistra, arrivando al contempo alla riga successiva. Al completamento dello spostamento si può, quindi, procedere con la visualizzazione dei colori dei pixel della nuova riga, e così via fino a quando non viene resa l’ultima riga.

A questo punto il pennello elettronico ha completato il tracciamento dell’immagine che gli era stato sottoposto, e deve tenersi pronto per quella successiva. A tale scopo provvede la fase di vertical retrace, cioè lo spostamento del pennello elettronico dall’angolo in basso a destra in cui si trova, a quello in alto a sinistra. Si tratta, quindi, di un altro “tempo morto” in cui non risulta visualizzato nulla a video (è il classico “bordo”). La seguente immagine riassume questo funzionamento:

Tutta l’area che riguarda la visualizzazione di una riga dell’immagine, ivi compreso l’intervallo di horizontal retrace associato (dall’estrema sinistra verso il centro per posizionare il pennello elettronico sui nuovi dati da visualizzare, mentre dalla fine della riga visualizzata fino all’estrema destra per farlo spostare verso la nuova riga; in parole povere: i due bordi, sinistro e destro) viene chiamata “riga di raster” e copre proprio il periodo per le tre operazioni.

Parlo di periodo non a caso perché innanzitutto richiede un ben preciso tempo (63,7us) per realizzare tutto ciò che nell’Amiga viene misurato in color clock (chiamato anche memory cycle), appunto, e la cui singola unità (280ns) corrisponde esattamente a uno “slot” utilizzabile dal chipset oppure dalla CPU (quest’ultima ha la priorità minima, ma ne parlerò meglio in futuro), e poi perché era considerata l’unità di misura delle prestazioni dai programmatori (anche di questo ne parlerò in futuro).

Per slot s’intende un accesso alla memoria (16 bit; in lettura o scrittura), e corrisponde a due cicli del clock principale di una macchina a 7Mhz (Amiga 1000, 500, 500+, 600; tralasciando al momento le altre, 3000, 1200 e 4000, per non complicare il discorso) utilizzabili a seconda del contesto.

Una riga di raster è costituita da 227 color clock (pari, quindi, a 454 cicli del clock “principale”) per il segnale PAL, che scandiscono in maniera precisa tutte le fasi che portano dalla generazione del bordo sinistro, alla grafica, al bordo destro, passando anche per audio, disco, refresh della memoria e ovviamente gli sprite. Tutti questi elementi hanno degli slot assegnati (anche questo lo vedremo meglio in un prossimo articolo), e si capisce quindi perché all’inizio ho affermato che era il video a regolare il funzionamento di tutto.

Abbiamo, quindi, che un quadro (completo) è costituito da 625 righe di raster, che moltiplicate per 25 quadri fanno 15.625 righe al secondo. In termini di color clock ne abbiamo 15.625 * 227 = 3.546.875, che sono pari a 7.093.750 cioé circa 7,09Mhz del clock principale. Per gli altri segnali televisivi il concetto è simile (tranne per l’NTSC dove c’è un’alternanza di righe di raster di 228 e 227 color clock).

Le 625 righe riguardano, però, un quadro completo, come detto, perché si fa sempre riferimento a un’immagine interlacciata. Infatti il segnale PAL è normalmente interlacciato e provvede a visualizzare due semiquadri di 312,5 righe, ciascuno che concorre alla formazione del risultato finale.

Più precisamente, lo schermo prevede 625 righe (di cui quelle visualizzabili sono di meno a causa del vertical retrace) che devono essere disegnate, ma il pennello elettronico ne traccia soltanto la metà ogni volta, perché lavora sempre su un semiquadro, quindi nel primo semiquadro disegna le righe pari e nel secondo quelle dispari; l’occhio umano fa il resto “fondendole” e ricevendo l’immagine completa.

Di giochi interlacciati per Amiga, però, non se ne ricorda nessuno (per lo meno io non ne ricordo, a parte le splendide immagini introduttive dei livelli usate in Agony, ad esempio) e le retine degli occhi, infatti, ringraziano; inoltre 25 quadri completi portano a pensare che questo fosse il limite massimo in termini di frequenza (di visualizzazione) dei giochi, mentre sappiamo che il Santo Graal è stato sempre rappresentato dal gioco che girava a 50Hz (o FPS che dir si voglia).

Il “trucco” per non usare l’interlace e disporre di 50, diverse, immagini al secondo visualizzabili era quello di sfruttare solamente semiquadri “pari”, quindi non visualizzando mai quelle dispari (che rimangono ovviamente nere), e ottenendo quello che in gergo viene chiamato effetto scanline:

Questo si ottiene non inviando al pennello l’elettronico un apposito segnale che gli indica di passare alle righe dispari, e pertanto, continuerà pedissequamente a disegnare sempre e soltanto quelle pari. L’effetto scanline rimane un artefatto visivo, ma diverse generazioni di giocatori sono sopravvissute a esso e, anzi, viene particolarmente apprezzato.

Tornando ai famigerati giochi a 25Hz vale esattamente lo stesso, nel senso che il segnale generato non è certo interlacciato, ma continuano a essere visualizzati sempre e soltanto semiquadri pari, anche se a due a due vengono visualizzate esattamente le stesse immagini. L’unica differenza (non da poco), rimane quindi nella fluidità del gioco, che risulta nettamente inferiore.

Per il momento è tutto. Questi elementi sono indispensabili per capire meglio come funzionava l’Amiga (ma anche altre macchine, siano essi home computer, console o coin-op, il meccanismo era simile o addirittura lo stesso), di cui parleremo in maniera molto più approfondita (e di più basso livello) più avanti, quando vedremo in che maniera grafica, audio, disco, sprite, Blitter, Copper e CPU si “spartivano” gli slot disponibili per i loro compiti.

48 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    amitv
     scrive: 

    Ciao Cesare come sempre ottimi articoli sull’amiga!!! complimenti ;)

    Ti aspetto nel nostro forum: http://amiga.ikirsector.it/index.php
    per un saluto

    ciao

  • # 2
    TheKaneB
     scrive: 

    Bell’articolo :-)

    E’ curioso notare come nelle console portatili su cui ho avuto modo di programmare (Nintendo DS in primis), viene “emulato” il sistema di disegno dei display a tubo catodico, introducendo artificialmente dei periodi morti di retracing, con tanto di interrupt di HBlank e VBlank, che ti consentono di applicare “vecchi trucchetti” anche sulle nuove console (come il palette switching on-the-fly durante il periodo di HBlank per le modalità Hi-Color, o come lo switching della matrice di rotoscaling del background per gli effetti pseudo-3D in Mode 7 sul SuperNES).

    Vecchie tecniche ma sempre apprezzate anche su nuovi dispositivi :-)

  • # 3
    Lorenzo
     scrive: 

    @theKaneB

    anche gli emulatori odierni per ricreare l’effetto CRT presentano filtri che ad occhio fanno lo stesso lavoro (e senza i quali la resa di un vecchio coin op su un moderno LCD è terribile)

  • # 4
    Z80Fan
     scrive: 

    Ottimo articolo, ma non ho capito bene una cosa: i “giochi a 50Hz”, elaboravano e disegnavano 50 volte al secondo solo le 312,5 righe pari (lasciando nere le altre righe e causando l’effetto scanline), mentre i “giochi a 25 Hz”, elaboravano solo 312,5 linee, ma disegnavano tutte le 625 linee “reali”, inviando per le linee dispari lo stesso segnale inviato alle linee pari (quindi, praticamente, mostravano pixel alti il doppio) ?

  • # 5
    G
     scrive: 

    con l’amos era d’obbligo il comando wait vbl per scene animate con linee, poligoni, cerchi ecc ecc…

    comunque giochi interlacciati ce n’erano… l’avventura grafica darkseed!

  • # 6
    Cesare Di Mauro (Autore del post)
     scrive: 

    @TheKaneB: questa sorta di emulazione è comoda proprio perché permette di dare libero sfogo alle idee dei programmatori. :P

    @Z80Fan: i giochi a 50 e 25Hz utilizzavano sempre e soltanto i semiquadri delle righe pari, lasciando quindi vuote (e nere) le righe dispari (da cui l’effetto scanline, appunto).

    La differenza è che con quelli a 25Hz venivano sempre riprodotte 2 immagini identiche in due semiquadri di seguito, per cui il pennello elettronico ridisegnava esattamente la stessa scena sulle stesse righe (pari).

    Il risultato è che, pur essendo visualizzati sempre 50 semiquadri al secondo, le animazioni (e la conseguente fluidità del gioco) viaggiavano a velocità dimezzata.

    Discorso diverso per i giochi interlacciati, che erano sempre a 25Hz, ma disegnavano prima le righe dispari e poi le righe pari, col risultato finale di ottenere un’animazione sempre a 25Hz, ma col doppio della risoluzione verticale (non c’erano righe dispari sempre nere).

    @G: francamente non me lo ricordo. Comunque per un’avventura l’interlace poteva anche avere un senso, perché non richiedeva parecchie animazioni, per cui le immagini erano abbastanza stabili.

  • # 7
    Rocco
     scrive: 

    Caspita quanti ricordi, e quanto codice 68000, le notti insonni per capirci di piu’ sull’hardware manual…

    Un tuffo nel passato !
    Bell’articolo. Grazie.
    soprattutto perche’ da quando ti leggo sono felice di ricordare…

    …mi viene quasi voglia di rimontare l’ A4000 in casa svuotando un po’ della cantina.

  • # 8
    Darkman^RJ
     scrive: 

    Ricordo i vecchi tempi quando facevo demo per amiga e conoscevo come le mie tasche tutti i segreti di raster e chipset.

  • # 9
    Z80Fan
     scrive: 

    @Cesare:
    Ah, ora ho capito, grazie :D

  • # 10
    sandro
     scrive: 

    ciao Ragazzi.

    mi stavo domandando se l’amiga500 fosse uscita con 16k di fast dedicati al 68000 e qualche KByte di chache per i chip custom,la velocita’ poteva esser dobbia.voi che ne pensate??

    ciao
    Sandro

  • # 11
    Beetlejuice
     scrive: 

    a Sandro

    Munire l’A500 e simili di quella cache che tu dici avrebbe portato, non tanto per il lato cpu ma chipset, a complicazioni hardware e di timing inaccettabili dal lato del costo e della compatibilita’. Non si trascuri che la cache deve essere riempita ed i complessi timing o meglio le interdipendenze dal clock principale avrebbero reso i circuiti aggiuntivi non economicamente convenienti, per l’epoca, oltre a generare problemi di compatibilità con quanto già c’era (A1000 in primis). Saluti!

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    La questione è complessa. A parte i costi (notevoli), bisogna anche contestualizzare.

    Una cache fa comodo con CPU come le nostre, dove l’accesso alla memoria è enormemente più lento rispetto all’accesso a una cache.

    Per il 68000 non c’erano questi problemi: per leggere o scrivere una locazione impiegava 2 cicli di clock, che se confrontati col tempo richiesto dall’istruzione più veloce (la NOP, 4 cicli di clock) era decisamente ottimo.

    Quindi non aveva senso aggiungere cache, nemmeno per i chip custom che avevano le stesse possibilità (2 cicli per accesso alla memoria).

  • # 13
    sandro
     scrive: 

    ciao a tutti

    il mio discorso e’ solo ipotetico.lo so’ che la cache sarebbe stata costosta,ma sicuramente un aiuto per la banda passante,vero tallone di achille di Amiga.poi il 68000k con “soli” 16k di fast ram tutta per lui,sarebbe potuto andare sempre al massimo,senza doversi dividere i cicli con gli altri canali DMA.

    ciao
    Sandro

  • # 14
    Cesare Di Mauro (Autore del post)
     scrive: 

    Una cosa del genere si poteva fare se l’Amiga fosse stata una console, ma in ogni caso il collo di bottiglia queste macchine era generalmente la chip ram e la relativa banda annessa.

    Quindi per i giochi 2D ti dico che la presenza di vera fast ram avrebbe inciso poco.

    Sarebbe stata utile per quelli 3D, visto che era la CPU a dover eseguire diversi calcoli, e farli in maniera indipendente avrebbe fatto comodo, ma l’Amiga non era nato per il 3D e giochi di questo tipo non erano i più diffusi.

    Per le applicazioni, magari la fastram avrebbe inciso, ma da utente comune non avrei avuto interesse; da professionista sì e ma quelli la fastram compravano “a chili”.

  • # 15
    sandro
     scrive: 

    ciao Mauro

    vero quello che dici,ma un po’ piu’,magari avrebbe aumentato la longevita’ della nostra amata macchina.secondo te,quale sarebbe potuto esser un buon modo per aumentare la potenza dell’A500(Ham e sprite pure in High-res),senza aumentare troppo i costi??

    ciao
    Sandro

  • # 16
    Cesare Di Mauro (Autore del post)
     scrive: 

    Proprio per questo ti dico che avrei preferito la chipmem: è l’unica memoria sulla quale potevano starci grafica, sprite, audio, ecc., cioè i dati accessibili dai chip custom.

    Sembrerà una sciocchezza, fra un Amiga dotato di:

    – 1MB di chipmem
    – 512KB chipmem + 512KB di fastram
    – 512KB chipmem + 512KB di slowmem

    io preferivo nettamente la prima soluzione, che per giochi et similia era di gran lunga preferibile alle altre (l’ultima, che poi era la più diffusa, anche la più stupida e priva di senso).

  • # 17
    sandro
     scrive: 

    so cosa intendi,ma da sviluppatore,avrei preferito meno limitazioni HW.tipo il blitter troppo lento e cose del genere..
    quindi un po’ piu’ di attenzione non avrebbe guastato..lo so che sembro ridondante,ma immagina se si sarebbe potuto caricare una copper list in una chache,sai i cli disponibili per il blitter e compagnia..

    ciao
    Sandro

  • # 18
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sandro, lo capisco, ma cerca di contestualizzare: siamo nel 1985, il 68000 era un gigante mostruosamente costoso che conteneva ben 68000 transistor (da cui il nome): anche una piccola cache avrebbe richiesto migliaia di transistor, e in più avrebbe introdotto problemi di coerenza con la memoria (se scrivo sulla copperlist in memoria, poi che succede con quella cachata?)

  • # 19
    sandro
     scrive: 

    capisco cosa dici…

    che ne pensi se si fosse usanto un clock piu’ alto(tipo 10-14 mhz)
    questo avrebbe aiutato le performance(calcolando che il blitter e penso gli altri DMA erano influenzati dal clock)??

  • # 20
    Cesare Di Mauro (Autore del post)
     scrive: 

    Solo se fosse stato aumentato a tutto il sistema, quindi sia alla CPU che ai chip custom (d’altra parte l’Amiga è un sistema sincrono).

    L’unico problema sarebbe stato la memoria: non so quanto sarebbe costata a 10-14Mhz (richiedendo sempre 2 cicli di clock per l’accesso).

  • # 21
    sandro
     scrive: 

    wow!

    sai,parlerei ore di queste cose.”purtroppo” :) ho ancora una forte passione per Amiga,e poi avendone vissuto gli anni bui…
    volevo chiederti una cosa,ai tempi dell’ECS,diciamo un po’ prima,lessi un’itervista di un tizio di Commodore Tedesca,che parlava di un blitter x bit-plane,piu’ altre features potenziate riguardanti proprio l’ecs,erano vere ste notizie??

  • # 22
    Cesare Di Mauro (Autore del post)
     scrive: 

    Mi sembrano delle balle, perché nemmeno l’AAA poteva vantare un blitter per bitplane: dubito che lo potesse avere l’ECS…

  • # 23
    jpx
     scrive: 

    Il mito del “blitter per bitplane” deriva dalle idee originali dell’Amiga 2000 (quello concepito da Jay Miner, non quello commercializzato dalla CBM).
    Correva voce che il buon Jay volesse realizzare una workstation low-cost basata su 020 e chipset con i controcaXXi già nel 1987 (chunky pixel, 256 colori a schermo e i famigerati 8 blitter per la modalità a 8 bitplane). Come ebbe a dire Haynie, non sapremo mai fin dove arriva la realtà e inizia la fantasia, perché di quei progetti non esiste manco un foglietto sbiadito…

  • # 24
    sandro
     scrive: 

    be vediamola cosi’ l’Amiga ancora fa’ parlare,segno che qualcosa ci ha lasciato..cmq volevo dirvi che lo sviluppo di IK+ procede bene,almeno a livello di programmazione.verso l’estate,anche il grafico,dovrebbe esser piu’ operativo,speriamo bene..

    ciao
    Sandro

  • # 25
    Beetlejuice
     scrive: 

    Ricordo però che ebbe un discreto successo, tra gli appassionati squattrinati, una schedina con cpu 68000 con clock appena sopra i 14 MHz e una piccola cache da 16 K se non erro (la mia memoria cede!) gestita da una circuiteria minimale. Si inseriva al posto del 68000 nell’Amiga 2000 e 1000, non ricordo se andasse fisicamente anche nel 500. Il guadagno di velocità era spesso quasi doppio, si poteva però ricondurre al clock nominale e senza cache con un interruttore in caso di incompatibilità o comunque di problemi. Che tempi!

  • # 26
    sandro
     scrive: 

    ben detto Beetlejuice!!

    bei tempi,con poco sforzo e spesa in piu’ si poteva aver una macchina davvero insuperavile!!e’ vero che una piccola fast di 16k avrebbe fatto la maggior differenza in ambito 3d.ma pensiamo ache a questo:se il 68000 poteva rullare alla massima potenza,avrebbe potuto dar una mano al blitter a disegnare,utilizzando suddetta ram..pensate anche ad applicazioni tipo Deluxe Paint e soci…

    ciao
    Sandro

  • # 27
    Cesare Di Mauro (Autore del post)
     scrive: 

    Conoscendo bene sia il 68000 che il Blitter, è meglio che il primo continui a fare il suo lavoro e non cercare di imitare il secondo. ;)

  • # 28
    sandro
     scrive: 

    avendoli programmati entrambi,li conosco bene pure io…
    pero’ sai,in determinati ambiti,un aiutino.. :)

    ma come sta’ andanto con il nuovo XA1000??

  • # 29
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non lo so: quello non è un Amiga, e non ne seguo gli sviluppi. :P

  • # 30
    sandro
     scrive: 

    ormai L’Amiga nn c’e’ piu’ da un pezzo :(
    purtroppo una macchina come l’Amiga non ne vedremo piu’…
    qual’e’ la demo 2D piu’ impressiva fatta su Amiga OCS??non ho mai seguito la scena molto..

  • # 31
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non ti so dire. Non ho mai apprezzato le demo…

  • # 32
    jpx
     scrive: 

    @Sandro
    http://ada.untergrund.net/ e ti farai un’idea. ;)
    Io personalmente ritengo molte demo dei Sanity, Kefrens e Silents come le cose più “spinte” viste su OCS/ECS, più qualche gemma rara qua e là di altri gruppi, tipo TotalTripleTrouble, ad esempio.
    Per il resto è questione di gusti, ma se parli di tecnica pura lì troverai il massimo! :)

    @Cesare
    Dimenticavo: bell’articolo! (ma c’erano dubbi in proposito?) ;)

  • # 33
    sandro
     scrive: 

    ragionando a ritroso,e riguardando L’hardware manual di Amiga.sei poteva far i registri interni a 32 bit,tipo 68000,in questo modo ci sarebbe stata la possibilita’ di leggere una longword,sempre tipo 68k.in questo modo il tutto sarebbe stato piu’ veloce,sempre tipo 68k,dove leggere una longword invece di 2 words era molto piu’ veloce.e non stiamo parlando di una modifica ENORME..

    ciao
    Sandro

  • # 34
    Cesare Di Mauro (Autore del post)
     scrive: 

    Potresti essere un po’ più chiaro? Non ho capito l’esempio.

    Anche perché il 68000 aveva un bus esterno a 16 bit…

  • # 35
    sandro
     scrive: 

    cioe’ il 68k aveva un bus esterno a 16bit,ma potevi caricare una longowd in un colpo al costo di meno cicli di 2 words.mi sembra erano 6 invece di 8 cicli..la stessa cosa potevano implementare i progettisti di Amiga…

  • # 36
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, il 68000 richiedeva almeno 2 cicli di clock per leggere una word (16 bit), e il doppio per una longword.

    Lo stesso valeva per i chip custom (il bus rimaneva quello per tutti).

  • # 37
    sandro
     scrive: 

    sono sicuro di quello che dico,una longword in lettura era sempre piu’ veloce di 2 words in lettura dalla ram,ne ho fatti di test.posso metterci la mano sul fuoco…

  • # 38
    Cesare Di Mauro (Autore del post)
     scrive: 

    Io anche ne sono sicuro, e di codice ne ho scritto anch’io a vagonate (anche automodificante). :)

    Facendo un bel po’ di ricerche ho trovato i tempi di esecuzione delle istruzioni. Trovi l’archivio zio qui: http://emureview.ztnet.com/sega/FileBin/TechBin/68khtml.zip

    Per la MOVE trovi i dati nel file TIMMOVE.HTM.

    Come puoi vedere, per trasferire i dati da un registro a un altro, di qualunque dimensione, il 68000 impiega 4 cicli di clock.

    Se invece deve trasferire una word (16 bit), si aggiungono 4 cicli di clock, arrivando a 8.

    Infine per trasferire una long (32 bit), servono ulteriori 4 cicli (rispetto alla word), arrivando a 16.

  • # 39
    sandro
     scrive: 

    non contesto questi dati,li conosco,il fatto e’ che sono nominali..quando provi su strada le cose cambiano.. :)
    cmq viva il nostro Amato Amiga..volevo chiederti se ci sono aggiornamenti riguardate il futuro di Amiga…e le nuove piattaforme in arrivo

  • # 40
    Cesare Di Mauro (Autore del post)
     scrive: 

    Al momento no. Dovrei provare AROS, ma non ho trovato il tempo per comprare una microSD per installarlo sulla (pseudo) chiavetta USB.

    Comunque ti assicuro che di test ne ho fatti, e i riscontri sono quelli che ho fornito. Il 68000 era troppo lento per gestire le long, e cercavamo di evitarle il più possibile (in giro trovi un po’ di materiale proprio sull’argomento).

  • # 41
    sandro
     scrive: 

    b’e’ al peggio ai una istruzione in meno..il che nn e’ male.. :)
    ma la comunita’ Amiga come e’ messa??sono anni che nn ci sto’ piu’ dietro,c’e’ qualcosa di nuovo che bolle in pentola??

  • # 42
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ci sono dei nuovi modelli che portano quel nome, ma sono basati su PowerPC. Personalmente non m’interessano.

    E’ interessante AmigaOS 4.1, ma è solo per macchine PPC, appunto.

  • # 43
    sandro
     scrive: 

    hehehe

    e quando mai un PowerPC e’ stato un Amiga??come ai ben detto Amiga = 68K e chip custom..peccato che nn e’ piu’ possibile…insomma ormai e’ rimasto solo un BEL ricordo del passato..

  • # 44
    sandro
     scrive: 

    una cosa nn ho be capito,come mai ci sono solo 227 cicli di clock per linea…

  • # 45
    Cesare Di Mauro (Autore del post)
     scrive: 

    Perché quella è la frequenza (più precisamente è un multiplo) utilizzata nei segnali PAL e NTSC.

  • # 46
    sandro
     scrive: 

    quindi era praticamente impossibile aumentare i cicli disponibili,l’unica cosa da fare e’ aumentare la velocita’ di trasferimento dati…

  • # 47
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ne parlo meglio domani, visto che proseguo con l’argomento. Abbi fede. O:-)

  • # 48
    sandro
     scrive: 

    ottimo,non vedo l’ora…

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.