Menù principale
 Notizie
 Grafica
 Forum
 Links
 Retro Trailer
 Recensioni
 Modelli Amiga
 Storia Amiga
 Retro-Gamers
 Lista Utenti
 Contatti
 Policy sito
Ricerca Google

Login

Nick


Password


Comandi

[b]-[/b]
Attiva/disattiva il neretto

[i]-[/i]
Attiva/disattiva l'italico

[br]
Inserisce un a capo

[p]
Inserisce un interruzzione di paragrafo

[center]-[/center]
Attiva/disattiva allineamento centrato

[justify]-[/justify]
Attiva/disattiva allineamento giustificato

[box]-[/box]
Apre/chiude una tabella

[boxcell] o [boxcell=n]-[/boxcell]
Apre/chiude una cella

[boxrow]-[/boxrow]
Apre/chiude una linea di celle

[quote]-[/quote]
Crea un box per quotare commenti.

[quote=titolo]-[/quote]
Come Quote ma con titolo.

[size=valore]-[/size]
Imposta la grandezza del carattere

[color=valore]-[/color]
Imposta il colore del testo.

[url=indirizzo]-[/url]
Attiva una porzione di testo

[img]indirizzo[/img]
Visualizza l'immagine indicata in 'indirizzo'.

[img;w=px;h=px;mini=%]indirizzo[/img]
Come sopra, w ed h sono base e altezza in pixel o mini è la percentuale di riduzione dell'immagine. Con mini=std l'immagine avrà una grandezza predefinita

Rispondi ad un commento
Regolamento Commenti e Topic

Tutti gli utenti che usufruisco di questo servizio sono pregati di rispettare poche semplici regole:

- Non e' possibile inserire commenti/topic contenenti volgarita', torpiloquio e/o offese di vario genere.

- E' assolutamente vietato inserire immagini e/o link a sfondo pornografico.

- Sarebbe preferibile evitare commenti mirati alla polemica e alla provocazione.

- Si ricorda che per netiquette, scrivere maiuscolo equivale a "URLARE", non va quindi bene scrivere tutto un post in maiuscolo.

- E' necessario ricordare che non e' bene fare commenti sprezzanti riguardo argomenti quali: religione, politica e la multietnia

- Non sono molto tollerati commenti/topic con eccessive abbreviazioni stile SMS.

- Eventuali critiche all'operato dei moderatori saranno punite a discrezione degli stessi.

- E' consigliabile rileggere sempre i commenti/topic prima di postarli, onde evitare lo spopolare di commenti ricchi di errori che potrebbero anche essere fraintesi o non compresi da utenti non italiani che sono alle prime armi con la lingua.

- E' buona cosa inserire i Topic nelle corrette sezioni, nell'indice delle stesse e' presente una breve descrizione sul contenuto, in caso di errore i Topic possono essere spostati nella sezione corretta dagli admin (Mak73) I commenti/topic che non rispettano tali regole verranno eliminati.

I gestori del sito non si assumono nessuna responsabilita' sul contenuto dei commenti riportati.

Risposta

Stile Testo
Dimensione:  Colore:  Allinea: 

Altri comandi
Emoticons
Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando.
:) :( :D ;) :P Oo -.- :O :ok: :pugni: :sedia: :tsk: :morto: :vietato: :superman: :sbav: :guardati: :rolleyes: :ghgh: :asd: :specchio: :migira: :incazz: :svitato: :sese: :° :uhm: :eheh: :fii: :muro: :goccia: :clap: :wuatta: :boom: :angelo: :brill: :mhua: :rotfl: :huh: ^^ :nono: :rosso: :azz: :lol: :dmon: :dance: :cool: :bleah: :...: :cuori: :yeah: :alien:
Testo
formattazione
   

31 Gennaio 2020 Postato da: AMG_Novice_Usr
Risoluzioni video, palette, Denise e ... HAM
Buonasera,
ho una domandina di cultura generale sul mondo Amiga:

ho letto che su Amiga (questo è un discorso molto generale, non so scendere in dettagli e distinguere fra OCS, ECS, AGA, e le rispettive Denise) il sistema riesce a stampare a video un certo sub-set di colori, ad esempio 16 colori (è solo un esempio), attinti da un super-set di 4096 colori (quindi una palette completa a 12 bit).

Se aumento la risoluzione, passando per esempio da 320 x 256 a 640 x 512, il sistema non è più in grado di stampare un massimo di 16 colori per ciascun pixel, ma al massimo ne può stampare 8 (è solo un esempio).

Ecco, vorrei capire anzitutto il motivo di questa cosa.

Io, che possiedo una quantità di nozioni tendente a zero, provo a fare un ragionamento a spanne/a buon senso … ditemi e, soprattutto, correggetemi:

mettiamoci sotto le ipotesi più semplificative possibili, per non appesantire inutilmente la discussione e centrare subito il cuore di tutto.

Le ipotesi sono:
1 – possiamo trascurare l’overscan, e tutto ciò che ne consegue, quindi non preoccupiamoci dei front e back porch sia lungo H che lungo V, facciamo finta che le tempistiche di scansione del pennello elettronico all’interno dei front e back porches sia trascurabili … contano solo le tempistiche dei pixels visibili, quindi tutto si svolge dentro il canvas visibile;
2 – nessun interlacciamento, quindi abbiamo 50 schermi al secondo di frame-refresh;
3 – il frame-rate deve sempre essere costante, pari a 50Hz (quindi ogni 20ms abbiamo un frame), a prescindere dalla risoluzione: che sia 320 x 256 oppure 640 x 512, il frame-rate rimane sempre 50Hz.

Bene, detto ciò, ecco l’idea che mi sono fatto:

con una risoluzione bassa, ovvero 320 x 256, abbiamo N pixels di cui il pennello elettronico, insieme al clock che dalla porta RGB-DB23 va verso il CRT, si deve occupare: il pennello elettronico deve sedersi su ciascuno di questi N pixels, qualcuno deve “generare” (Denise? Vero?) le 3 tensioni analogiche RGB sui 3 piedini RGB analog della porta RGB-DB23, questo durante un dot-clock-periodo, poi abbiamo un altro dot-clock-periodo, durante il quale queste 3 RGB-tensioni devono spegnersi (immagino che vadano a GND tutte e 3 … o no?), per poi riaccendersi con la configurazione propria di questo pixel successivo, per poi essere latchate, ecc … ecc … (correggete le inesattezze … ce ne saranno tante!).
Diciamo che il tempo che il pennello elettronico può dedicare ad ogni pixel è circa 20ms/N.

In questi 20ms/N, Denise deve:

1) accedere, tramite uno dei 25 canali DMA messi a disposizione da FatAgnus, alla corrente locazione di chip-ram nella quale è scritto il pixel corrente appunto, quello che sta per essere stampato su CRT (magari detto così è forviante, direi che Denise non accede, forse è il canale DMA di FatAgnus ad accedere, come “source” avrà la locazione del pixel attuale in chip-ram, come “destination” avrà l’opportuno registro dentro Denise);
2) dare in pasto la parola RGBxyz (RGB444? RGB565? La palette di 4096 colori suggerirebbe RGB444 …) ai 3 DAC interni a Denise;
3) dare il tempo ai DAC di generare stabilmente le tensioni cromatiche;
4) chissà cos’altro ...

Bene, se adesso abbiamo una alta definizione, supponiamo di 640 x 512, vuol dire che abbiamo 4 volte i pixels di prima, quindi il pennello può stare seduto su ciascun pixel per un tempo pari a circa 20ms/4N.
Dato che il pennello deve sbrigarsi su ogni pixel, forse alcune operazioni, che consentirebbero di produrre 16 colori presi dalla palette di 4096, devono essere svolte in modo diverso, più asciutto, da qui la possibilità di produrre meno colori (es: 8, 4 … non so).

Vorrei sapere come stanno davvero le cose …

Ultimo punto:

mi sembra di aver capito (magari anche qui sbaglio) che esiste una tecnica inventata da Jay Miner, chiamata HAM, ovvero Hold and Modify, grazie alla quale è possibile (non so a che definizioni, o se a tutte le definizioni) attingere a tutta la palette di 4096 colori, per ciascun pixel, forse con qualche limitazione (il pixel k+1-esimo non può avere un colore del tutto scorrelato dal colore del pixel k-esimo). È giusto? Questa limitazione forse è figlia del concetto di “mantieni e modifica”? Ma cosa viene mantenuto e soltanto modificato? Le 3 RGB-tensioni non vengono spente nel passaggio da un pixel al successivo, subiscono solo un mascheramento dentro Denise, quindi una modifica? Cosa sono esattamente HAM6, HAM8 ecc … ?

Grazie in anticipo a chi vorrà illuminarmi/illuminarci 😊


Commenti: 12  Aggiungi  - Leggi

utente amiga quadratico medio

Post inviati: 701

Visulizza profilo Messaggio Personale
79.51.61.*** Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Commento
AMG_Novice_Usr 1 Febbraio 2020    12:51:30
Ciao,
si, ho letto la spiegazione su HAM (HAM6 per OCS ed ECS, HAM8 per AGA) fornita da Wikipedia … il concetto del pixel di "base", lungo una certa linea
orizzontale, che imposti in questo modo (HAM6):
2 bit di controllo / 4 bit di dati-colore
Facciamo un esempio:
voglio colorare il primo pixel in alto a sinistra, quindi il primo pixel della prima riga.
Credo che sia Denise/Lisa a ricevere, tramite un canale DMA messo a disposizione da Agnus/Alice, un byte proveniente dal frame-buffer grafico,
che si trova in chip-ram … un byte siffatto:
binario: xx00/CCCC
xx = don't care;
00 = comando di "attingi ad uno dei 16 colori di base", in questo caso il colore è "CCCC";
CCCC = uno dei 16 colori di base.
Per cui abbiamo quel certo colore CCCC sul primo pixel: il pixel di base (che da inizio ad un segmento di una riga), a mio parere, ha una forza
ed una debolezza: la "forza" consiste nel decidere lo "stampo", la "linea guida" del segmento-sfumatura da lui iniziato, è lui a dare un primo
imprinting cromatico al segmento di linea (giusto?), però ha anche la "debolezza" rappresentata dal fatto che quel pixel può attingere ad una
tavolozza di soli 16 colori … è un pixel grezzo.
Adesso voglio colorare il pixel immediatamente contiguo, successivo al primo.
Denise riceve il byte:
xx01/BBBB
01 = è un comando che impone a Denise di lasciare, sul secondo pixel (il pixel dove attualmente si è spostato il pennello elettronico),
inalterate le componenti RG del colore "grezzo" del pixel precedente, e di modificare solo la componente blu, con un valore:
BBBB
Quindi il secondo pixel ha anche lui una forza ed una debolezza:
la forza è che possiamo attingere, su quel secondo pixel, ad una tavolozza di 256 colori … giusto? 16 x 16 … io se voglio sul secondo pixel una
particolare sfumatura di rosa, posso colorare il byte 1, in chip-ram, che ospita appunto il primo pixel, con uno dei 16 colori che "meglio avvia"
quel particolare rosa che ho in animo di ottenere sul secondo pixel (quindi il primo pixel è propedeutico per il secondo), e poi devo colorare il
byte 2, in chip-ram, contiguo come address al primo byte, con una particolare modifica blu del primo colore-pixel, quindi torna che sul secondo
pixel posso scegliere fra 256 colori? Fra 16 colori di base (primo pixel), ciascuno dei quali può essere sottoposto a 16 blu-sfumature diverse …
fanno 256 scelte possibili per il secondo pixel.
La debolezza è che se ho una necessità cromatica imperativa sul primo pixel, il secondo ne è schiavo (correlato al primo).
il rebus è che questo ragionamento porterebbe a contare più di 4096 colori …
Andiamo avanti:
ora passiamo al terzo pixel:
Denise riceve:
xx10/RRRR
quindi sul terzo pixel conserva le componenti GB, mentre cambia quella R, scegliendo fra 16 livelli di rosso … quindi partendo come previsione di scia
cromatica dal primo pixel, scia poi B-rettificata un po' sul secondo pixel, poi R-rettificata un po' sul terzo pixel, sul terzo pixel abbiamo
una scelta di 16 x 16 x 16 = 4096 colori.
Aspetta un attimo … io avrei detto di arrivare a 4096 al quarto pixel, ovvero:
xx00/ABCD - pixel base
xx01/ABCD - secondo pixel, prima sfumatura
xx10/ABCD - terzo pixel, seconda sfumatura
xx11/ABCD - quarto pixel, terza sfumatura
Invece arrivo a 4096 al terzo pixel, seguendo il mio ragionamento … devo aver travisato qualcosa … cosa?
Domanda:
le sfumature possono continuare?
Voglio dire:
dopo il quarto pixel, ormai i colori sono finiti, quindi propongo quelli che avrei già potuto avere nei pixel precedenti (la tavolozza potenziale è
terminata), però posso comunque andare avanti con le sfumature, quindi applicare altre RGB-sfumature, pixel dopo pixel, fino a fine riga …
è corretto?
Poi se voglio, ad un certo punto della riga, avere un salto cromatico drastico (l'immagine/il gioco ne ha bisogno), quindi non un gradiente, allora
è sufficiente stampare lì un pixel di base con il comando 00.
Ben gradite spiegazioni, rettifiche ... tutto ciò che illumini …







A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541

Utenti Online
Utenti registrati: 1206 dal 1 Gennaio 2006
di cui online: 1 registrati - Amy - Mor -
29 non registrati

Benvenuto all'ultimo utente registrato: zulu

Buon Compleanno a funkytarro87 - 

© Amigapage 1998 - 2007 - Sito italiano dedicato alla piattaforma Amiga ed evoluzioni varie.
Struttura del sito interamente ideata e realizzata da Marco Lovera e Alessandra Lovera - Tutto il materiale inserito all'interno del sito è dei rispettivi autori/creatori.
E' assolutamente vietata la riproduzione o la manipolazione di tutti i contenuti o parte di essi senza l'esplicito consenso degli amministratori e degli autori/creatori.

Eseguito in 0.15569996833801 secondi