Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a majinga [quote=majinga] Troppo complicato per me, magari aspetta qualche programmatore amiga, loro sicuramente te lo spiegano meglio. Ma in genere lemoria video è fissa. Se aumenti la risoluzione aumenti il numero di pixel di cui devi salvare le informazioni, e quindi te ne resta di meno per cose come i colori. Anche sull'HAM, qualcuno ti risponderà meglio di me. Ma ricordo di aver letto qualcosa a riguardo. Miner aveva in mente un normale segnale video NTSC, dove si hanno due segnali, la luminanza, che indica quanto il pixel deve essere brillante, e la crominanza che indica il colore, in un segnale video del genere, basta variare nel tempo il solo parametro cambiare colore al pixel. In un segnale RGB invece devi cambiare l'intensità di tutti e tre i colori per generare il colore che desideri, quindi devi modificare tre valori, uno per il rosso uno per il verde e uno per il blu. Almeno questa è la parte che ricordo io. Magari faccio anche confusione. La differenza è proprio nell'hardware che genera il segnale video, e come lo genera. Ci sono trucchi abbastanza bizzarri sulle schede video di una volta, i computer inizialmente lavoravano tutti basandosi su segnali video abbastanza standard. Se ti fai una ricerca sulle vecchie schede CGA è incredibile cosa riuscivano a tirare fuori sfruttando il modo in cui venivano interpretati e mescolati i colori nello standard NTSC. [/quote] formattazione A sinistra Giustificata Nessuna

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

Post inviati: 1588	Commento majinga 31 Gennaio 2020    20:27:25
	Troppo complicato per me, magari aspetta qualche programmatore amiga, loro sicuramente te lo spiegano meglio. Ma in genere lemoria video è fissa. Se aumenti la risoluzione aumenti il numero di pixel di cui devi salvare le informazioni, e quindi te ne resta di meno per cose come i colori. Anche sull'HAM, qualcuno ti risponderà meglio di me. Ma ricordo di aver letto qualcosa a riguardo. Miner aveva in mente un normale segnale video NTSC, dove si hanno due segnali, la luminanza, che indica quanto il pixel deve essere brillante, e la crominanza che indica il colore, in un segnale video del genere, basta variare nel tempo il solo parametro cambiare colore al pixel. In un segnale RGB invece devi cambiare l'intensità di tutti e tre i colori per generare il colore che desideri, quindi devi modificare tre valori, uno per il rosso uno per il verde e uno per il blu. Almeno questa è la parte che ricordo io. Magari faccio anche confusione. La differenza è proprio nell'hardware che genera il segnale video, e come lo genera. Ci sono trucchi abbastanza bizzarri sulle schede video di una volta, i computer inizialmente lavoravano tutti basandosi su segnali video abbastanza standard. Se ti fai una ricerca sulle vecchie schede CGA è incredibile cosa riuscivano a tirare fuori sfruttando il modo in cui venivano interpretati e mescolati i colori nello standard NTSC.