READY: thread sul retrocomputing

posto un piccolo aggiornamento, perche' sono ancora lontano dall'ottenere un risultato accettabile ma ho fatto qualche progresso nel ricostruire il segnale video del C128 (che e' uguale a quello del C64). Fin'ora e' stato abbastanza divertente, ma per migliorare ancora ho capito che devo studiare un sacco di roba sul bastardissimo standard PAL e quindi d'ora in avanti i progressi avverranno piu' lentamente, temo
Comunque sono riuscito a decodificare i colori in un certo qual modo ancora approssimativo: per testare l'algoritmo di decodifica ho generato col C128 delle barre colore e poi come al solito ho acquisito il segnale video con l'oscilloscopio e l'ho decodificato in python

la palette e' ancora piuttosto approssimata ma per ora e' piu' importante separare correttamente i colori. Purtroppo nei transitori sbaglio anche quello basta vedere gli errori all'inizio delle barre

cio' nonostante ho provato ad applicare l'algoritmo ad un immagine e come si poteva immaginare il risultato fa abbastanza cagare (le lettere dovevano essere di verde chiaro ) ma e' un buon passo in avanti per me

per indagare le magagne mi sono scritto un tool che mi permette di analizzare le componenti dell'immagine separatamente, graficando i valori riga per riga, e conferma che la componente di luminanza la gestisco abbastanza bene, la chroma mica tanto, soprattutto la fase, che e' la componente piu' importante, ma credo di decodificarla male perche' lo standard PAL fa dei magheggi che non sono sicuro di aver ancora capito bene

comunque e' incredibile il materiale che si trova a proposito del C64: generazioni di hacker hanno spaccato il capello in 4 e analizzato ogni singolo aspetto di quel computer, il 90% delle volte scopro che mi ero dovuto ricavare dati gia' belli e pronti e disponibili su internet, come le componenti YUV della palette del C64 per esempio
https://www.pepto.de/projects/colorvic/2001/
mi sarei risparmiato un sacco di lavoro se avessi scoperto prima questa pagina, ma dopotutto l'importante e' il viaggio, non la destinazione
quindi sincronizzare il ritardo di Cr e Cb con Y non è stato sufficiente ?
domanda; ma cosa sono "modulo Chroma" e "fase chroma" ? non sono nomi alternativi per Cr e Cb, vero? e come li ricavi?
altra domanda; mi sono accorto solo ora che nell'immagine che hai linkato in precedenza, https://i.imgur.com/PWmSv9z.gif, il chroma signal output è in un unico pin, il 6. Cr e Cb vengono trasmessi da questo unico pin? come funziona, vengono trasmessi alternati ? (tipo non so, un segnale 1010102122 diviso in due segnali 11122 e 00012)
per ora non ho introdotto sfasamenti artificiali per far tornare le cose, sto scrivendo un software che in pratica replica quello che succede dentro un televisore quando riceve un segnale "S-video" analogico (non e' un segnale digitale fatto di 1 e 0), perche' ci sono ancora delle cose che non mi tornano e voglio per prima cosa capire cosa succede

il fatto e' che nel sistema "S-video" la luma ha un pin dedicato ed e' un segnale molto semplice da interpretare perche varia in ampiezza durante ogni linea e l'intensita' rappresenta direttamente il valore di luminanza istante per istante (e quindi, discretizzando, pixel per pixel).
la chroma invece ha 2 componenti (diciamo Cr e Cb, ma ho scoperto che possono essere codificate in molti altri modi equivalenti) che viaggiano sullo stesso cavo (un unico pin) anche loro in modo analogico, per cui sono codificate in modo molto piu' complesso della luma utilizzando la QAM (https://it.wikipedia.org/wiki/Quadrature_amplitude_modulation): in parole povere si prende una funzione sinusoidale con frequenza abbastanza alta (la cosiddetta "portante"), se ne ottiene il coseno e si modulano le ampiezze di seno e coseno, istante per istante, in funzione di Cr e Cb; poi si sommano le due onde e voilat, si trasmette il segnale. Il fatto che si riescano poi a ricostruire Cr e Cb da un segnale generato cosi' e' a mio parere una delle tante dimostrazioni del fatto che la matematica sia in realta' una forma di magia ma tutto sommato fino a qui ci sono arrivato, e' abbastanza semplice alla fine. Il problema e' che il sistema PAL comporta anche tutta una serie di segnali di sincronizzazione e accorgimenti volti a ridurre eventuali disturbi che non sono banali: bisogna conoscere bene il lato tecnico di quello standard li' per decodificare Cr e Cb, perche' per esempio il segnale NTSC usato in America e' diverso e si usano formule diverse.

modulo e fase della crominanza li ottieni rappresentando Cr e Cb in un grafico cartesiano: Cr rappresenta un valore in x, Cb in y. Per ogni valore di crominanza ottieni un punto sul piano che, se combinato con la luminanza (che potrebbe essere rappresentata sull'asse z) identifica un particolare colore. se invece di considerare la crominanza in modo cartesiano la consideri in modo polare (modulo e fase rispetto all'asse x), avrai che il modulo rappresenta la "Saturazione" e la fase rappresenta la "Hue" di quel colore. E' un modo piu' intuitivo di gestire questa informazione perche' ho scoperto che tutti i colori del C64 tranne i grigi hanno la stessa saturazione. Cioe' nel C64 la saturazione puo' avere solo due valori: zero oppure il valore massimo.




edit: ok, finalmente sto cominciando a capire come funziona la codifica-decodifica dei colori secondo lo standard PAL: bisogna mediare due righe consecutive per ottenere i valori corretti; si tratta di una tecnica che permette di ridurre i disturbi sulla tonalita' del colore a scapito della risoluzione verticale del colore, infatti si vede che al passaggio da una riga alla successiva i colori non sono esatti, perche' sono una via di mezzo col colore della riga precedente



questa cosa mi complica ulteriormente la vita, mannaggia al PAL
il nickname dell'NTSC era Never Twice Same Color il PAL sui colori è un upgrade
non sapevo di questo nomignolo comunque si, visto che in questi giorni mi sono studiato un po' il PAL, era stato inventato per superare i problemi dell'NTSC. Fu inventato da degli ingegneri della Telefunken.

Scienza, NON Fantascienza !!
qui spiega bene pure la storia dei 29.97fps insieme alle differenze tra NTSC e PAL




https://hackaday.com/2020/12/30/amiga-now-includes-hdmi-by-way-of-a-raspberry-pi-daughterboard/


sembra che le latenze siano molto basse
che figata, c'e' sempre di mezzo c0pperdragon, quello che ha fatto la modifica al c64 che avevi postato qualche giorno fa. Il metodo direi che e' lo stesso, i risultati pure: eccezionali!
sarebbe un sogno per me arrivare a fare una cosa che vada bene un 10% di quello tra l'altro i menu' osd sono proprio come me li ero immaginati io anche se a dire il vero al giorno d'oggi sono convinto che ci vorrebbe una app sul cellulare che comunica via bluetooth con l'upscaler (in questo caso il pi). non sapevo che esistesse il progetto RGBtoHDMI, di hoglet67: mi sembra molto molto utile. Sta gente e' fenomenale




il PETSCII
Non ho mai capito come funzioni il PETSCII . Non è semplice ASCII art, giusto? Da alcuni esempi su internet mi è sembrato di capire che si possono ruotare e spostare i caratteri rispetto alla loro posizione e orientamento originale. È così o ho compreso male?
1 Like
è una variante dell'ASCII sviluppata da Commodore. Supporta alcune funzionalità non standard. Che io sappia, i caratteri non ruotano.
https://github.com/ytmytm/c64-bitcoin-miner

Il bitcoin miner per c64

"A C64 would need 337 years and 10 months to reach this result"
Figata


SMW in vero wide screen






https://github.com/VitorVilela7/wide-snes

ecco la patch
FIXING the ENTIRE SM64 Source Code (INSANE N64 performance)






Quest'uomo é un pazzo
incredibile il risultato, incomprensibile il come abbia fatto deve essere uno stregone o giu' di li'
Volevo segnalare questo tributo a Jeff Minter dal canale di Kenobisboch con Riccardo Albini, Top Editore

Lo Scumm Bar in 3D con una mod per ScummVM

1558076988438761472https://twitter.com/mausmoto/status/1558076988438761472?s=20&t=shLwilbE-E0TYfuoWlck2g
figata

Sent from my SM-S908B using Tapatalk
Eye of the Beholder on Commodore 64

https://www.timeextension.com/news/2022/10/new-eye-of-the-beholder-c64-port-will-let-you-play-the-game-with-dual-monitors





la versione per il C128 supporta il dual monitor