READY: thread sul retrocomputing

Tech Zone
41
è abbastanza buona l'uscita anche se c'è un po di banding, già a cambiare cavo fai il salto
42


wtf?
fammi capire, dato che è il thread giusto: in soldoni hai collegato il C128 all'oscilloscopio, che ipotizzo ti abbia restituito un onda, in qualche modo hai avuto la possibilità di filtrare l'onda estraendone la componente LUMA (non so cosa sia) digitalizzandone le informazioni , e dandole in pasto ad uno script in Python che pressapoco recita "punto x,y, if onda > 0 then punto bianco su x, y, else punto nero su x, y, end if, x++, prosegui" ... corretto?
43



in sostanza hai capito esattamente, anzi hai anche anticipato una cosa che intendo fare, ma che non ho ancora implementato.


la LUMA e' la luminanza, che assieme alla crominanza permettono di determinare che colore dare ad ogni pixel. in pratica, invece di dare i valori di R (red), G (green) e B (blue) dello spazio RGB, puoi usare tre valori Y (lumiunanza), Cr e Cb (le due componenti della crominanza), tali che
Y=R+G+B
Cb=B-Y
Cr=R-Y
a volte un segnale di questo tipo e' chiamato YCbCr e molti TV hanno degli ingressi dedicati. Questo modo di gestire i colori ha alcuni vantaggi, tra cui quello che le TV in bianco e nero potevano considerare solamente il segnale Y, che in pratica rappresenta l'immagine in scala di grigi.
https://it.wikipedia.org/wiki/Crominanza


i C128 (e anche i C64 da una certa data in poi), hanno direttamente 2 uscite dedicate a luminanza e crominanza per collegarsi ai monitor. oltre a questa opzione avevano anche un uscita composite video (che e' una combinazione di luma e croma in un unico segnale, con deperimento della qualita') e l'uscita per il sintonizzatore TV


in pratica io ho collegato il pin 1 e il ground all'oscilloscopio ed ho campionato un intero frame (circa 20 ms). I moderni oscilloscopi in realta' sono dei veri e propri ADC che campionano il segnale e lo memorizzano nella memoria interna, che viene continuamente sovrascritta. Pero' puoi "congelare" un acquisizione e salvarla su chiavetta USB come file di testo (con qualcosa come 10 milioni di linee )

poi in pyton vai ad elaborare il segnale: in pratica l'ho spezzato in tanti file, uno per ogni riga dell'immagine, l'ho ripulito con un filtro passa basso, e ho spezzato ogni riga in pixel visto che so quando comincia il segnale video e quanto dura ogni pixel in millisecondi: deve rispettare lo standard PAL
http://martin.hinner.info/vga/pal.html
isible_area" target="_blank">https://codebase64.org/doku.php?id=baseisible_area

per ora non ho discretizzato i colori, cioe' ogni pixel ha un valore analogico continuo ed infatti sono tutti di intensita' un po' diverse tra di loro, anche se dello stesso colore (l'uscita del C64 e' molto rumorosa). siccome pero' il C64 ha solo 16 colori provero' a fare delle finestre ed attribuire un colore ad ogni pixel a seconda di a quale intervallo appartiene. l'idea e' poi implementare il tutto in un microcontrollore o una FPGA per creare uno scatolotto da mettere tra il C64 e il TV per ottenere un'immagine pulita.



Solo che non sono nemmeno al 10% del percorso mi ci vorra' piu' di un anno, ammesso che non perda interesse prima Tra l'altro il prossimo passo sarebbe decodificare la componente "croma" del segnale, che e' molto piu' difficile
44
passo di qui solo per palesare la mia stima.
Complimenti per lo sbatta Algorab
45
grazie, mi sto divertendo altrimenti in lockdown mi annoio tra l'altro sto imparando un sacco di cose tra cui python, che non conoscevo e devo dire e' una figata incredibile, soprattutto con la libreria scipy


edit: anzi, programmare in pyhon, che e' un linguaggio interpretato, concettualmente e'simile a programmare il c128 o il c64 in basic, solo che e' mille volte piu' moderno e migliore sotto praticamente tutti i punti di vista
46
il c64 d'oggi è un Raspberry Pi 400 e il basic è python
47


ok, mi son ricordato che effettivamente già sapevo della questione YCbCr con le varie sottrazioni da Y per ricavare green, in ogni caso mi levo il cappello pure io e continuo a seguire
48
forse vi potrebbe interessare questo progetto è una fpga che sniffa i segnali direttamente dal chip VIC-II e li converte in YPbPr/RGB

https://github.com/c0pperdragon/C64-Video-Enhancement
49
e' stato proprio guardando quel progetto che mi e' venuto in mente di fare quello che sto facendo quel metodo li' e' incredibile, sniffare i segnali del VIC per ricreare l'immagine con una FPGA e' geniale. il risultato che si ottiene e' semplicemente perfetto, letteralmente. Ci sono tre problemi pero':
1) non funziona sul C128, che ha una versione del VIC leggermente diversa
2) richiede una modifica harware abbastanza invasiva se si vuole inglobare l'FPGA dentro il C64, altrimenti devi uscire con un ribbon di cavi abbastanza orrendo
3) mentre leggevo l'articolo che ne parlava e pensavo che forse sarebbe stato meglio fare nel metodo che sto seguendo io, ho letto un commento del creatore di quella modifica che diceva che in pratica lui aveva provato a semplicemente ripulire l'immagine dentro un upscaler ma che era impossibile perche' l'uscita video del C64 e' troppo rumorosa. Al che ho pensato, con molta poca umilta', "invece secondo me si puo' fare" ed ho cominciato a buttare via un sacco di ore dietro questo progetto dall'utilita' discutibile e dal risultato incerto
https://hackaday.com/2019/03/10/component-video-for-the-commodore-64/
50
devi vedere se genera latenza poi sull'output tra le varie conversioni calcoli e riconversioni.
51
e' vero, ci sono un sacco di incognite e non so mica se arrivero' in fondo.


Se e' vero che il segnale del C64 e' troppo rumoroso, per esempio, tra poco incontrero' una battuta d'arresto definitiva, cercando di ricostruire il colore esatto dei pixel in python. Ammesso che ci riesca, poi si trattera' di implementare la cosa in hardware, e vedere quanta latenza si introduce. Io un po' di esperienza coi microcontrollori Arduino, ed oggi ci sono alternative molto piu' potenti che forse potrebbero andare bene. Pero' sospetto che per aver poca latenza bisognera' usare un FPGA, che io non ho mai utilizzato.

In pratica mi fa piacere intraprendere questo progetto perche' e' un'ottima scusa per giocare un po' con questi strumenti (python, FPGA, microcontrollori) che mi incuriosiscono ma che non trovo mai modo di usare.
52
meanwhile c'è chi applica Raytracing in tempo reale sullo SNES



53
Col NES erano riusciti a fare anche di più perché puoi comunicare direttamente con la PPU

54
ma perchè questo post sta in questa sezione???

me lo ero totalmente perso
55
Non so se conoscete Byuu l'autore di bsnes un emulatore per SNES che faceva dell'accuracy il suo cavallo di battaglia, da poco si è ritirato ( ho notato una certa amarezza in questo gesto ) e lo vedevo su twitter postare aggiornamenti su un suo hack/traduzione di Bahamut Lagoon mai avrei immaginato tanta dedizione.

https://twitter.com/BahamutLagoon25/status/1341411106200412162
56
un piccolo aggiornamento sul mio progetto: ho fatto qualche piccolo passo in avanti sulla decodifica della luminanza ed sto tentando di decodificare la crominanza, che non ha la minima intenzione di collaborare
questa la luminanza e poi la crominanza (sono in falsi colori)


qualunque cosa provo sulla crominanza non migliora i risultati, sara' durissima
57
uhm
se provassi manualmente a forzare la correzione del pixel?
tipo non so, basandomi sui colori falsi dell'esempio "se il pixel sembra essere giallo ma dopo c'è una fila di blu, il pixel deve essere rappresentato blu"
58
mi sembra una buona idea ma preferirei partire da dei dati piu' "puliti" di cosi' prima di applicare delle logiche simili, perche' ho paura che con un segnale cosi' disturbato finiro' per avere molti errori alla fine. spulciando internet ho scoperto che a quanto pare il segnale di crominanza ha un leggero ritardo rispetto a quello della luminanza, forse e' quello il problema in quanto io non ne ho tenuto conto. in piu' e' strano che se ingrandisci molto il cursore sembra esserci un comportamento diverso una riga si' ed una no
59
ah la questione del ritardo é interessante, e trova conferma nel tuo screen, allora il calcolo dovrebbe essere luminanza - crominanza del "pixel"(o di x pixel) precedente.
Ipotizzo che Cr e Cb siano allineati nel ritardo
60
speriamo di si