Più Di 8 Sprite Contemporaneamente (multiplexing)

[eregil]

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

[DAN]

 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.

[eregil]

 Il "ragionamento puro" come lo chiami tu ti è già stato descritto in questo thread.
 

[iAN CooG]

 

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.

[eregil]

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

[DAN]

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

[mces]

 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.

[eregil]

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.

[Raffox]

 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.) e n° 63 (pag. 55 e succ.): 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.