Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: DAN - 23 Settembre 2008, 13:50:02
-
Ho sempre letto che il C64 poteva gestire al massimo 8 sprites però guardando le foto del gioco Blinky's Scary School, mi sembra di contarne qualcuno in più. Qualcuno con un occhio più esperto può spiegarmi come stanno le cose (o come dovrebbero stare) ?
- usare titoli descrittivi fa bene alla pelle - Admin
-
La tecnica utilizzata per visualizzare più di 8 sprite, tra l'altro molto adoperata sul C64 (vedi Turrican, Commando, Moonshadw, Catalypse oltre che numerose demo...), è comunemente nota come sprite multiplexing (http://codebase64.org/doku.php?id=base:sprite_multiplexing).
Se ne parla a grandi linee anche a pag. 10 di questo paper (http://isg.cs.tcd.ie/scollins/papers/8bit.pdf).
-
Ho provato a leggere sta roba ma non credo di aver capito molto bene il succo... qualcuno che sappia spiegarmelo meglio ? thx
-
Ho provato a leggere sta roba ma non credo di aver capito molto bene il succo... qualcuno che sappia spiegarmelo meglio ? thx
In pratica il VIC compone l'immagine sullo schermo linea per linea.
Se tra una linea e l'altra riprogrammi il VIC puoi visualizzare altri 8 sprite e così fino alla fine dello schermo.
E questo è anche il motivo per cui con questa tecnica si possono avere molti sprite ma non più di 8 sulla stessa linea.
Più o meno questo è il succo o almeno e così che so io.
-
Vediamo di rendere l'argomento un pò più chiaro senza essere troppo tecnici.
Il pennello ottico (raster) consiste in un raggio luminoso che, spostandosi a velocità elevata (misurata in hz), crea l'immagine in un televisore o monitor.
Il suo movimento è continuo, da sinistra a destra e dall'alto in basso dello schermo.
Una volta raggiunto il fondo ritorna in cima e ricomincia allo stesso modo. Sostanzialmente quest'operazione accade 60 volte al secondo, di qui la definizione 60hz.
Ogni computer trasmette un segnale al video tramite il pennello ottico, indispensabile alla formazione e al controllo dell'immagine che si percepisce.
Il C64 permette d'intervenire direttamente sul raster, fermandolo e facendolo ripartire a piacimento. Ecco perchè è possibile, ad esempio, avere lo schermo diviso orizzontalmente in due o più parti (split screen), ogniuna delle quali può visualizzare una risoluzione grafica diversa (hi-res, bitmap, multicolor...).
E' facilmente intuibile che, effettuando uno split screen, ogni porzione di schermo diventa indipendente rispetto alle altre e, se abbiamo 8 sprite disponibili mentre lo schermo è diviso in 2 porzioni, questi 8 sprite possono essere 'clonati'e visualizzati in entrambe le aree di schermo diventando così 16.
Poi, più lo schermo viene diviso, più aumenta il numero delle copie di sprite visualizzabili. Ad esempio: schermo diviso in 3 parti = 3x8 sprite visualizzabili contemporaneamente sullo schermo.
12345678 <---- porzione di schermo N°1 (con 8 sprite visualizzati)
------------- <---- split-screen
12345678 <---- porzione di schermo N°2 (con 8 sprite visualizzati, cloni dei primi 8)
------------- <---- split-screen
12345678 <---- porzione di schermo N°3 (con 8 spirte vsiualizzati, cloni dei primi 8)
Ciò vuol dire in sostanza che, ad esempio, lo sprite N°1 può essere duplicato per 3 volte e ciascuna copia è esclusivamente visualizzabile (e animabile) in una
delle tre aree in cui si è diviso lo schermo.
Quindi avremo lo sprite N°1 visualizzato per 3 volte sullo schermo, ma ogni clone può assumere colore e forma diversi a patto che non vada a superare la linea raster poichè ciò ne provoca la scomparsa.
Un fitto utilizzo di questo effetto raster, come in Turrican o Catalypse, è il 'trucco' impiegato per poter visualizzare end boss di grosse dimensioni.
-
Bella spiegazione, thx. A naso mi ricorda una storia simile per avere più colori sull'atari lynx.
Mi sorge però un dubbio sulla memoria a disposizione: uno sprite clonato due volte raddoppia il consumo di memoria ? E poi di quale memoria stiamo parlando ? Ram o eventualmente una VRAM del Vic ?
-
uno sprite clonato due volte raddoppia il consumo di memoria ? E poi di quale memoria stiamo parlando ? Ram o eventualmente una VRAM del Vic ?
Gli sprite non vengono clonati. Vengono solo spostati. Mentre la parte alta dello schermo viene disegnata, sono posizionati in alto. Quando questa e' disegnata, e prima che si inizi a disegnare la parte bassa, vengono spostati in basso.
Il VIC accede alla stessa RAM a cui accede la CPU.
-
Grazie fab per la precisazione.
Ribadisco che la mia spiegazione è stata volutamente semplificata per rendere l'argomento più comprensibile ai meno esperti e pertanto ben si presta ad approfondimenti e puntualizzazioni (che spero seguano numerose).
Da notare che il termine clonare da me adottato è stato inizialmente chiuso tra virgolette proprio per sottolinearne l'adattamento al caso...
-
Quindi noi quando vediamo lo schermo vediamo in realtà un collage composto fino a 60 fotogrammi sovrapposti ?
-
Quindi noi quando vediamo lo schermo vediamo in realtà un collage composto fino a 60 fotogrammi sovrapposti ?
La tua affermazione potrebbe essere interpretata correttamente a patto di non confondersi tra frequenze di aggiornamento delle immagini e frequenze di aggiornamento del raster.
Infatti la frequenza di aggiornamento delle immagini, misurata in fotogrammi per secondo o 'fps' è quasi sempre 25 (PAL) o 30 (NTSC) anche se più moderni standard per la trasmissione digitale prevedono valori di 50 o 60 fps: raddoppiando i frame per secondo e visualizzando prima le righe pari, seguite dalle dispari (interlacciamento) si risolve il problema dello sfarfallio.
Altra cosa è invece la frequenza di aggiornamento del raster, cioè le righe orizzontali dette anche 'scan line' dei televisori o dei monitor. Nei vecchi monitor e televisori dotati di tubo catodico (CRT = Cathode Ray Tube) la frequenza andava da 60hz a 100hz circa. Con i più moderni supporti di visualizzazione a cristalli liquidi (LCD = Liquid Crystal Display) si è arrivati a 200hz.
-
No, vediamo un'immagine di 312 linee, che possono essere disegnate ciascuna indipendentemente dall'altra. Entro dei limiti: il tempo in cui ciascuna linea e' disegnata e' limitato, 1 linea in 1/50/312 di secondo. Per questo, e' in realta' piu' comune raggruppare linee orizzontali consecutive in un gruppo, di fatto dividendo lo schermo in settori orizzontali. Tipicamente, quando si inizia a disegnare la prima linea del gruppo, si dispongono i registri del VIC cosi' come devono essere per l'intero gruppo, poi si compiono tutte le altre azioni (controllare il joystick, suonare la musica...). In questo tempo, normalmente molte linee sono state disegnate: bisogna assicurarsi di non essere arrivati alla fine del gruppo.
-
Scusate la pignoleria:
sistema PAL: 25 quadri al secondo scansionati da due semiquadri interlacciati per una frequenza di rinfresco quindi di 50Hz (ogni riferimentoa 60Hz è relativo al sistema americano NTSC).
Il sistema PAL ha 625 linee lorde per il quadro completo e quindi la frequenza di ripetizione delle righe è di 25*625=15625Hz (il fischio fastidioso che si sente in alcuni vecchi televisori).
L'interallacciamento (cioè l'intercalamento geometrico delle linee "pari" con quelle dell'altro SEMIquadro "dispari") avviene grazie alla presenza all'inizio del semiquadro di una riga dimezzata che sposta in verticale il raster del 50% dello spazio inter-riga posizionandolo geograficamente quindi nel vuoto lasciato da due righe del semiquadro precedente.
Il C64 NON interlaccia i semiquadri, questo porta a vedere gli spazi vuoti tra le linee sui televisori a grande schermo, in quanto il semiquadro dispari si sovrappone perfettamente a quello pari senza coprirne i vuoti.
Le righe attive di un semiquadro sono circa 288, quelle attive del vic 200, lla differenza viene riempita con le bande superiore e inferiore.
-
Il C64 permette d'intervenire direttamente sul raster, fermandolo e facendolo ripartire a piacimento.
Frena, il raster non si puo' fermare. Puoi solo chiedere "per favore VIC-II, generami un IRQ alla tal linea che poi ci penso io a gestirla" e controllare a che linea e' arrivato. L'unico modo per fermare il raster e' spegnere il C64.
L'argomento fu trattato qua (http://ready64.org/smf/index.php?topic=629.0) con tanto di esempi e discussione filosofica
-
Le righe attive di un semiquadro sono circa 288, quelle attive del vic 200, lla differenza viene riempita con le bande superiore e inferiore.
hmm, guarda che i bordi nel C64 ci sono solo per contenere l'area sfruttabile dal modo testo e bitmap, i bordi si possono levare "semplicemente" e ci puoi far viaggiare raster colorati, sprites e anche bitmap realizzati scrivendo in uno specifico byte, ovvero l'ultimo del banco da 16kb visibile dal VIC-II correntemente selezionato tramite la locazione $dd00. Quindi non e' che sono attive per il VIC-II solo quelle in mezzo =)
-
Forse con un paragone si può facilmente spiegare il concetto alla base del multiplexing delle sprite...
Ricordiamoci che sullo schermo l'immagine viene dipinta per righe successive dall'alto verso il basso, ora immaginiamo che un pittore voglia disegnare la facciata di un palazzo partendo dall'alto del quadro per disegnare piano per piano fino al basso della tela.
Ipotizziamo pure che otto amici burloni si divertano ad affacciarsi alle finestre di un piano proprio quando questo viene osservato e pitturato dall'artista.
Se i burloni riescono a mantenere il passo con il disegnatore quello che verrà fuori sono un numero di persone affacciate di 8xquantipianisono.
Rende l'idea?
Grazie al fatto che si possano generare interrupt legate alla posizione del pittore.... em..... del raster dello schermo, si riesce a "spostare" le sprite (e i dati a cui vengono puntate) dalla zona già disegnata (e impressa sulla persistenza del monitor) alla zona di prossima disegnatura, e così via.
Nessuno sfarfallamento: ogni volta che il raster passa per la porzione di schermo dove vogliamo far comparire la sprite lei sarà lì pronta per essere disegnata.
E' un processo SW costoso in termini di percentuale di uso della macchina, ma il gioco spesso vale la candela!
-
Grazie iAN CooG/HF per la precisazione dei bordi, io l'avevo saltata e per semplicità espositiva mi ero limitato al modo operativo "normale".
Mi ricordo che sfruttando l'apertura del bordo inferiore, definendo degli sprite a grandezza raddoppiata, riuscii a fare del C64 una macchina titolatrice tipo "serpentone".
Un esempio lo trovi su questo seteeso sito:
http://ready64.org/articoli/_files/048_filmati.rar (http://ready64.org/articoli/_files/048_filmati.rar)
(filmato "coda")
il link fa parte dell'articolo
http://ready64.org/articoli/leggi/idart/48...er-commodore-64 (http://ready64.org/articoli/leggi/idart/48/scheda-di-acquisizione-video-per-commodore-64)
di cui mi fregio di essere l'autore, anche se lo feci in tenera età
(che bello, gongolo tutto!!!!)
-
Il sistema PAL ha 625 linee lorde per il quadro completo e quindi la frequenza di ripetizione delle righe è di 25*625=15625Hz
625/2=312,5. Tra questo e 312 c'è una differenza di 0,5 righe, e gli ingegneri approssimano.
Per il fotogramma n, il VIC disegna 312 righe. Il televisore le visualizza, lasciando 1 riga di spazio tra l'una e l'altra. 1/50 di secondo dopo, inizia il fotogramma n+1. Il VIC disegna altre 312 righe, e il televisore le visualizza nelle righe lasciate vuote nel fotogramma precedente (interlacing).
In pratica, ciò che il televisore mostra ogni 1/25 di secondo è una serie di righe
n
n+1
n
n+1
...
-
nel sistema televisivo nessuna approssimazione:
Ogni riga non è perfettamente orizzontale ma piega appena verso il basso di uno spazio che intercorre tra una riga e la successiva, pensa che la ritraccia, ovvero il rapido riposizionarsi del raster dalla fine di una riga all'inizio di una successiva prende un tempo che è meno di un 10% del tempo della riga stessa.
Lo spostamento verticale del raster invece è continuo, quindi la fine di una riga è all'altezza (in prima approssimazione) dell'inizio della successiva.
La presenza di 1/2 riga in ogni semiquadro fa si che il raster cominci sempre cambiando la sua posizione verticale (ad ogni semiquadro) del 50% di uno spostamento verticale legato ad una linea completa, questo fa sì che ogni semiquadro si trovi esattamente a disegnare negli spazi interlinea lasciati vuoti dal semiquadro precedente.
1/2 riga = interlacciato
no 1/2 riga = non interlacciato!
Se non ricordo male il VIC non opera interlacciato e quindi non genera le "mezze righe", come già detto questo comporta la visione degli spazi vuoti di interlinea nei televisori di una certa dimensione (sopra i 17..21pollici?) specie se televisori in B/W, visto che quelli a colori hanno la maschera INVAR per la sintesi dei colori che "mischia" un pò le carte in tavola.
Le righe video del C64 erano visibili su un buon monitor B/W da 11 pollici! (questione di fuoco, contrasto e luminosità...)
-
Ammazza quanta roba da una così semplice domanda. Ci sarebbe da scrivere un libro solo su questo argomento.
Infatti pensandoci mi stava proprio venendo il dubbio di chiedere per quanto tempo una linea di sprite doveva essere "ridisegnata" sullo schermo affinché l'occhio umano non percepisse qualcosa di strano.
-
Lo sprite viene disegnato esattamente nello stesso momento che il raster passa per le aree dello schermo che i registri del VIC indicano, il VIC si occupa di questo lavoro ed infatti le sprite sono il frutto di un "accelleratore grafico" in quanto le informazioni grafiche contenute vengono posizionate sullo schermo ad opera del VIC e NON ad opera della CPU che si limita, tramite registri, ad indicare dove prendere i dati per la sprite e dove posizionarla (coordinate in pixel) sullo schermo.
Proviamo a immaginare cosa sarebbe del C64 se il VIC non avesse questa funzione di "motore grafico": bisognerebbe continuamente ridisegnare in HI-RES qualunque oggetto in movimento......
Il C64 non avrebbe avuto la fortuna che ha avuto!
Dall'esperienza cinematografica deriva che la minima frequenza possibile per far apparire una proiezione pressochè stabile sia di 36 "illuminazioni" al secondo, mentre per la fluidità dei movimenti si può scendere fino a 18 variazioni al secondo.
Questo si traduce, per i minimi termini, a proiettare un film (pellicola) a 18 fotogrammi/secondo con due chiusure di otturatore (una per cambiare fotogramma, l'altro "dummy") in modo da rispettare quanto detto sopra.
Al cinema lo standard è 24 fotogrammi al secondo, sempre con doppia illuminazione del singolo fotogramma (48Hz).
Curiosità: per l'adattamento televisivo la proiezione viene accellerata da 24 a 25 fot/sec portando il film in TV a durare un pò meno dello stesso film al cinema!
-
Direi che la teoria di base c'è tutta, adesso sarebbe bello trovare dei programmi e commentarli riga per riga (soprattutto perchè l'assembly non è proprio una gioia per gli occhi)
-
soprattutto perchè l'assembly non è proprio una gioia per gli occhi
Ah perche' il basic invece... :lol:
Fatti bastare il sorgente di Alberto nel thread linkato, e' gia' commentato abbastanza. Le istruzioni non commentate sono banali, per chi mastica gia' asm, se tu devi ancora imparare le basi puoi sempre commentartele mentre studi.
-
Non ci sarebbe qualcosa in più banale C ? :lol:
-
Inutile nascondersi dietro un dito: se ti interessa realmente imparare a programmare il C64 a questi livelli, devi farlo in assembly. Se non sei disposto a compiere questo passo puoi anche lasciar perdere.
-
Inutile nascondersi dietro un dito: se ti interessa realmente imparare a programmare il C64 a questi livelli, devi farlo in assembly. Se non sei disposto a compiere questo passo puoi anche lasciar perdere.
Concordo e rilancio dicendo che per scrivere in C su C64 occorre saper fare le stesse cose in asm, risulta talmente complicato farlo in C che per me non vale la pena. Se vuoi dare un occhio ad un demo realizzato in C, prego, ci sono i sorgenti da esaminare.
http://noname.c64.org/csdb/release/?id=56368 (http://noname.c64.org/csdb/release/?id=56368)
-
Cosiglierei il "grande passo" di rimboccarsi le maniche ed iniziare ad imparare a programmare in assembler, non tanto per il fine in se stesso, ma perchè costringe la persona a considerare come lavora dentro (e fuori) una CPU, una ALU, ecc.. tutti concetti di fondo comuni a TUTTI i calcolatori esistenti: una bella apertura mentale e, tecnicamente parlando, culturale.
Insomma se credi che il gioco nel suo totale valga la candela......
-
ok, capisco e concordo ma il punto è che attualmente non sono ancora al livello di lanciarmi in una simile impresa quindi cerco qualcosa, chiamatelo come volete, io dico una testa di ponte con quello che posso attualmente capire. Per me l'asm è attualmente arabo (ed il fatto che sia specializzato per una macchina morta di certo non mi aiuta in questo momento a riservargli del tempo ad hoc), nel tempo libero quando ho esaurito molte altre alternative ci può stare ma non di più.
In fin dei conti più che del sorgente in asm stretto per c64 mi interessa capire quali algoritmi si usavano su sistemi così vetusti visto che non c'erano GeForce 9600 per disegnare due righe.
-
Guarda, secondo me stai facendo un minestrone.
La gestione del raster richiede che si conosca il funzionamento del VIC-II e degli interrupt (e quindi del 6510). L'algoritmo viene dopo: in fin dei conti a livello software si tratta di scrivere determinati valori in registri del VIC-II e locazioni di memoria.
In soldoni, se non ti interessa programmare effettivamente il C64, conoscere l'algoritmo ti è inutile: ti interessa di più sapere che scrivere un numero di riga in un registro del VIC-II fa sì che venga generato un interrupt quando il raster raggiunge quel numero di riga dello schermo. Sapendo ciò, sai che il programmatore farà puntare l'interrupt dove vuole lui in modo che venga eseguita la routine che sposta gli sprite. Gli algoritmi non contengono nulla di realmente più interessante di quanto ti è stato spiegato. O almeno, non quelli di esempio.
Se ti interessa programmare, viceversa, ribadisco che - dal momento che senza assembly non vai lontano per questo genere di cose - è il momento di iniziare dalle basi dell'assembly. Prima impara a correre, poi impara a volare.
Per quanto riguarda le GeForce, bisogna dire che - per quanto ci sia stato un aumento della complessità delle architetture di CPU e GPU - lo stesso principio rimane valido: un algoritmo preso da un videogioco ti dice poco se non conosci le primitive del layer (OpenGL, DirectX, ecc.) su cui è basato (e così via scendendo di livello fino al sistema operativo), in quanto spesso gli algoritmi non sono altro che dei "metti questo valore qui, il puntatore a questi dati lì, e il risultato di questo calcolo là" - solo, le variabili in gioco nell'hardware di oggi sono in numero maggiore. :)
-
Guarda, per me il concetto di algoritmo non si limita al crudo "leggi variabile, scrivi variabile, punta a indirizzo" ma ad un ragionamento più elevato in quanto, tra i due, il secondo si può riciclare su qualsiasi sistema che non preveda per forza la presenza di un 6510 o un VicII.
E' un po il concetto che passa tra uno che sa calcolare una derivata perchè esistono delle regole da seguire ed un altro che invece ne ha capito il reale significato matematico.
-
si può riciclare su qualsiasi sistema che non preveda per forza la presenza di un 6510 o un VicII.
lascia perdere, evidentemente NON vuoi imparare a programmare su c64.
-
@ DAN
No, tu non hai capito. La possibilità di sfruttare il raster per visualizzare più sprite in multiplexing non dipende dall'algoritmo adottato, bensì dal funzionamento stesso dell'hardware.
Il software non fa altro che impostare nei registri giusti i valori giusti al momento giusto, e non è qualcosa di riutilizzabile a prescindere dalla presenza di un 6510 e un VIC-II.
Infatti, va da sé che anche riportando lo stesso algoritmo su un Plus4, non per questo il Plus4 diventi capace di visualizzare 9 sprite (neanche uno, se è per quello).
C'è insomma una differenza fondamentale che corre tra un algoritmo di puro calcolo (pensa: software matematico o gestionale) e uno di interfacciamento con l'hardware (pensa: driver di periferica).
Il tuo paragone con le derivate semplicemente non calza.
-
Continui a non capire. Io sto parlando di ragionamento, astratto finchè si vuole ma sempre ragionamento. Il C64 non era l'unico sistema a 8 bit del pianeta e di sicuro non ha inventato cose che altrove, per i contemporanei erano impensabili. Altri sistemi avranno utilizzato altri componenti, altri processori, ma anche loro tiravano fuori cose che sulla carta non erano possibili.
Io più che imparare il "sessantaquattrese stretto" voglio espandere la mia conoscenza ad una visione più comune delle cose. Francamente nel 2008 non me ne faccio niente di come il Vic faceva in modo tutto suo lo sprite multiplexing ma fatemi il favore di non venire a raccontare che il vic era l'unico a poter pensare di fare qualcosa di simile. Ci saranno stati tanti altri sistemi capaci di ottenere lo stesso risultato, ma al di sopra delle righe di asm personalizzate per raggiungere lo scopo in oggetto, sono sicuro che il vero ragionamento d'origine è comune a tutti ed è quello che voglio capire.
-
Il "ragionamento puro" come lo chiami tu ti è già stato descritto in questo thread.
-
Francamente nel 2008 non me ne faccio niente di come il Vic faceva in modo tutto suo lo sprite multiplexing
E allora cosa ci fai su questo forum?
Ora finiamola qua, o si parla di C64 o si va da un'altra parte.
-
Vabe' Ian, lui inizialmente ha chiesto del VIC-II, e riguardo il VIC-II ha avuto le risposte che ha chiesto.
Per quanto riguarda la sua ultima frase:
Ci saranno stati tanti altri sistemi capaci di ottenere lo stesso risultato, ma al di sopra delle righe di asm personalizzate per raggiungere lo scopo in oggetto, sono sicuro che il vero ragionamento d'origine è comune a tutti ed è quello che voglio capire.
posso aggiungere una precisazione, per chi ha la pazienza di seguirmi.
Il problema è che si chiede un algoritmo (software) dove la soluzione è di tipo hardware, e quindi non si dovrebbe parlare in termini di algoritmi ma di circuiti.
Per fare un paragone, immaginiamo che il problema sia non la visualizzazione di sprite, ma un calcolo matematico, ad esempio l'estrazione di una radice quadrata.
Se stiamo programmando una CPU generica, il problema può essere affrontato via software. La "soluzione software" consiste nello scrivere un algoritmo per la nostra CPU generica, come può essere il 6510 o un moderno processore x86.
Esiste poi la possibilità di adottare una "soluzione hardware", che invece consiste nella progettazione e costruzione di una circuiteria che, preso in ingresso (input) un numero, restituisca in uscita (output) la sua radice quadrata.
In quest'ultimo caso, quando un ipotetico programma (software) esterno, che giri su un computer che monti una CPU generica e il nostro ipotetico chip "radice quadrata", tutto quello che il software per la CPU dovrà fare sarà impostare opportunamente i registri input del chip e poi leggere i registri output del chip (per semplicità tralasciamo la distinzione tra funzionamento sincrono e asincrono).
Abbiamo parlato di una cosa simile quando abbiamo trattato il chip video del C128, l'integrato 8563 (link al thread (http://ready64.org/smf/index.php?topic=2410.0)), e lo stesso principio è alla base - per fare un esempio in informatica più "recente" - della differenza fra giochi in 3D gestito via software e giochi in 3D facenti uso di schede grafiche 3D (sono esistiti anche titoli che prevedevano le due modalità).
Bene, il problema del quesito di DAN è che la visualizzazione di sprite avviene con una "soluzione hardware" (il chip esterno, il VIC-II), ma si continua a chiedere l'algoritmo (software) cercandolo nel codice scritto per il C64, in pratica come se lo sprite fosse gestito dal 6510.
Se il funzionamento che interessa è quello del VIC-II, oltre un certo livello esso non si approfondisce più con codice assembly, BASIC o C (come è stato chiesto) per il C64 (6510). Invece è questo fantomatico codice che viene chiesto.
E se ciò che interessa realmente è come fa il VIC-II a disegnare lo schermo dati i suoi registri e il contenuto della RAM, esuliamo dal campo del software per C64. La risposta sta altrove e (come già fatto notare) richiede la conoscenza dell'hardware.
Il punto di vista del VIC-II nel multiplexing è quello di sprite che, in parole povere, si muovono più rapidamente del raster: mentre il VIC-II sta disegnando la parte alta dello schermo, gli sprite sono nella parte alta dello schermo; mentre il VIC-II sta disegnando la parte bassa dello schermo, gli sprite sono nella parte bassa dello schermo... ma gli sprite sono sempre 8. E il disegno dello schermo avviene sempre nello stesso modo che senza multiplexing.
Il VIC-II insomma determina, riga per riga, pixel per pixel, i segnali da inviare in output (es. al monitor), in base al proprio stato e alla RAM, indifferentemente che si usi il multiplexing oppure no (a parte il discorso sugli interrupt generati dal raster, ovviamente). E lo fa indipendentemente dal 6510.
-
Visto che fai tanta differenza tra le cose ma sono convinto che non è così (solo nelle barzellette sui "veri programmatori" si ragiona da subito in termini di indirizzi senza passare da una via più umana), facciamo finta che un simile lavoro lo debba svolgere la cpu. Quale sarebbe un sorgente che una mente umana può ragionare per gestire un simile carico ?
Anzi no, prima che mi spari qualcosa in asm, quale sarebbe un algoritmo inteso come flowchart che spieghi come funziona la cosa ?
(adesso capisco perchè crisys spacca un sistema in sli...)
-
E' vero che un algoritmo esprime la strategia con cui il risultato viene ottenuto e non è crudo ed ermetico come l'assembler, ma ricordiamoci che sarebbe l'algoritmo per arrivare a quei risultati SOLO se lo implementi sul C64, e quindi ritorni a legarti ad una macchina di un quarto di secolo fà.
Solo il VIC ha i registri del VIC con le caratteristiche del VIC, se ti serve per applicazioni pratiche oggi, o le applichi su un vecchio C64, o su un buon simulatore.
Se lo scopo è storico-didattico a metà tra uno speciale di Piero Angela e "impariamo i rudimenti: come facevano le macchine dell'età della pietra a far funzionare un accelleratore grafico? impariamo i principi base di rappresentazione dell'immagine e sua manipolazione", allora quanto detto nei post credo che possa essere sia abbastanza esteso che esaustivo.
Comunque, per quel che posso, rimango a disposizione.
-
facciamo finta che un simile lavoro lo debba svolgere la cpu. Quale sarebbe un sorgente che una mente umana può ragionare per gestire un simile carico ?
Faccio notare che, se tutto il lavoro sopra descritto fosse a carico del 6510, non si potrebbe parlare di sprite multiplexing nei termini in cui l'abbiamo fatto, e l'intera tua domanda - dall'inizio del thread - diventerebbe insensata.
Infatti, tutte le tecniche descritte in questo thread presuppongono l'esistenza del VIC-II con i suoi sprite hardware. Se non ci fosse il VIC-II, gli sprite sarebbero software e non avresti la limitazione a 8 sprite dovuta al fatto che il VIC-II ha registri per soli 8 sprite.
Il lavoro del VIC-II ti è già stato descritto, sia pure a grandi linee, l'ho fatto anche nel mio post precedente.
Per ogni riga, determina il colore di ogni pixel in base al proprio stato (registri, RAM video, set di caratteri, ecc.).
Quindi, determina ed emette in output un segnale che possa poi essere convertito per il monitor o per il televisore.
Cosa dovrebbe fare la CPU se fosse lavoro suo? Per semplicità tralasciamo il bordo, le modalità multicolor, e altre cose che complicherebbero il discorso, ok?
Siamo al pixel 0,0. Se ci troviamo in modalità grafica, preleva dalla RAM video gli attributi colore "acceso" e "spento" per la cella corrispondente a 0,0. Controlla se il pixel è acceso o spento; determina quale colore utilizzare per 0,0 in base allo stato del pixel. Se invece siamo in modalità testo, preleva il carattere presente nella cella corrispondente, determina se il pixel è acceso o spento in base al set di caratteri, determina il colore in base al registro di colore di sfondo (pixel spento) oppure alla memoria colore per la cella corrispondente (pixel acceso). Poi controlla se in questa locazione si trova uno sprite, determina quale pixel dello sprite si trova a 0,0 e determina se è acceso o spento. Se è acceso, cambia il colore del pixel con quello dello sprite.
Ripeti per tutti i pixel dello schermo.
Senza il VIC-II, ripeto, tutti gli sprite sarebbero software, e il problema del multiplexing non si porrebbe perché non dovresti combattere con la limitazione del VIC-II per la quale ci sono registri per soli 8 sprite.
DAN, se ti interessano l'elettronica digitale e l'architettura degli elaboratori, cercati dei libri o della documentazione, siediti e studia. Se non ti interessano, neanche ti deve interessare come funzionano i chip, a questo livello di dettaglio. Non te lo si può spiegare prescindendo da delle conoscenze di base.
E per una conoscenza "alla Piero Angela", ti è già stato detto tutto, come ha detto mces.
-
A proposito del multiplexing, e per completezza, varrebbe la pena dare uno sguardo a due listati pubblicati rispettivamente su C.C.C. n° 50 (pag. 69 e succ.) (http://ready64.org/ccc/50/069.jpg) e n° 63 (pag. 55 e succ.) (http://ready64.org/ccc/63/055.jpg): anche se non sono adeguatamente approfonditi per chi cercava esempi di codice commentato e quindi rivolti ad utenti più esperti, potrebbero comunque rivelarsi interessanti da leggere.