Dzięki RZóG-owi mam to w rękach od jakiegoś czasu. Obraz wygląda super, ale są niewielkie błędy w emulacji GTIA (bo FPGA na płytce "GTIA Digitizer" emuluje GTIA. Miałem pisać o tym wcześniej, ale nie miałem zgranych jeszcze filmów aby pokazać jak to wygląda. Postaram się nagrać video aby było można ocenić samemu, dodam tylko że samo RGB2HMI oparte na PiZero z wyjściem HDMI generuje idealny obraz, w dodatku pixel perfect i ultra smooth. Cały pomysł z LumaCode jest świetny. Mam w rękach kilka rozwiązań:

1) S-Video + RetroTink 2x
2) GBS-8200 + VBXE + GBS Control
3) OSSC + VBXE 1.x
4) RGB2HDMI + GTIADigitizer

W chwili obecnej mogę powiedzieć tyle że jeżeli autor rozwiązania poprawi emulację GTIA to będzie to najbardziej odpowiadające mi rozwiązanie.

pozostałe rozwiązania preferuję w następującej kolejności:

1) S-Video + RetroTink 2x
2) VBXE + OSSC
3) VBXE + GBS-8200 z GBS control

poniżej fotki zarówno płytki GTIA digitizer jak RGB2HDMI wraz z Pi-Zero:

Near co prawda nie sprawdzałem, ale jeżeli chodzi o scrolling to wszystko jest ultra płynne. Są pewne problemy z grafiką Player-Missile, ale to są drobnostki do poprawienia, na pewno autor rozwiązania dostanie dokładny raport aby mógł poprawić co trzeba.

Zaprezentowałbym wyniki działania już dawno, ale na YT nie da się obecnie wrzucić tego materiały tak aby nie psuł on jakości, zapewne udostępnię pliki .mkv na pigwie abyście mogli sami ocenić jak to wygląda. W dodatku mój tani chiński grabber przy 50fps pozawala tylko na przesyłanie obrazu do komputera z kompresją MJPEG o też powoduje pewne pogorszenie jakości.

Wrzucę filmy to sam zobaczysz (ew. wpadnij do mnie i sam się przekonaj). Dlaczego sądzę że to emulacja GTIA? Bo np. kolory które wychodzą z nałożenia się grafiki PMG na "playfield" (w bardzo konkretnych przypadkach) wychodzą inaczej niż w przypadku bezpośredniego wyjścia z GITA, albo pozycje obiektów PMG np. w przypadku pierwszej części "Revenge of Magnus" (sinus scroll w hi-res + tło na PMG w górnej połowie ekranu) potrafią być inne niż w przypadku wyjścia z GTIA... efekt jest taki że obraz gwiazdek w tle jest poprzesuwany albo wręcz pozycje obiektów drżą o jedną linię skaningową.

Sądzę że autorowi prościej było wykonać emulację GTIA niż bawić się z precyzyjnym dekodowaniem sygnału "COLOR" z czym jak widać problem ma również autor projektu GTIA2DVI.

C0pperdragon ma doświadczenie w te klocki, a świadczą o tym chociażby jego pozostałe projekty (chociażby pełna emulacja VIC-II z wyjściem RGB, etc.). Mam również VIC-II digitizer, ale przyznaję że jeszcze nie zdążyłem go przetestować.

Samego RGB2HDMI używałem również z innymi maszynami i byłem bardzo zadowolony z rezultatów, jak tylko zobaczyłem że
c0pperdragon wypuścił pierwsze wersje swoich digitizerów z "lumacode" to od razu postanowiłem to przetestować. Czekam jeszcze na TIA digitizer i na pewno nie omieszkam zamieścić tutaj swoich doświadczeń z tymże również.

Jeden myk jest fajny z tym lumacode, tak jak pisał autor używa on 2-bitów do opisania stanu wyjścia/linii transmisyjnej... a więc mamy 4 możliwe stany do zakodowania na jednym drucie, całość protokołu pomyślana jest tak że tworzy on sygnał zbliżony do analogowego sygnału video (jeden ze stanów ma poziom "sync", pozostałe 3 stany służą do enkodowania transmitowanych bitów luminancji i chrominancji... a to powoduje że jak taki sygnał lumacode podepniesz do czegoś dekodującego composite video to widać obraz, co prawda nie jest to odwzorowanie właściwe, ale możesz dzięki temu zobaczyć że "digitizer" działa, oto przykład wyjścia z digitizera podpięty do "RetroTink 2x":

ekran Atari BASIC:

intro do gry Ballblazer:

a tutaj przykładowy "atari control picture", wyjście z GTIA_digitizera podpięte do RGB2HDMI:

screen z dema "Equation of Time / Our 5oft", w odpalonym menu RGB2HDMI:

Alex... przecież RGB2HDMI i jego "pokładowy" soft obsługuję masę maszyn, rozwiązań... to nie jest tylko do GTIA digitizera wersja. Tam ustawisz wszystko... i są profile dla wielu maszyn (np/ Amiga, Atari ST, Acorn, Amstrad) ... to naprawdę wspiera wiele maszyn. LumaCode jest jedną z opcji i pojawiła się niedawno (w sofcie w wersji BETA). GTIA jest potrzebna chociażby po to aby generować kolizje i video na standardowym wyjściu monitorowym. Moim zdaniem GTIA digitizer tylko sobie słucha tego co nadchodzi do GTIA i tego co generuje GTIA na wyjściach ANx, także słucha sobie magistrali danych aby pobrać informację o grafice PMG (kiedy ANTIC wystawia odpowiednie adresy) ... no ale skoro mi nie dowierzasz ... po prostu napisz do autora rozwiązania.

A co do tego że GTIA digitizer tylko słucha i że był już wcześniej problem z nazwijmy to "emulacja GTIA" zacytuję samego autora rozwiązania;

Należy tylko dodać że projekt GTIA digitizera nie jest otwarty (i nie wiem czy będzie) i na razie można go jedynie kupić na w sklepie Tindie u CopperDragon.

a co do:

Jestem w trakcie formułowania opisu problemów które zauważyłem, więc liczę że autor dokona poprawek i będzie to rozwiązanie idealne :D

@grzybson: ależ to żaden offtopic! dzięki za info! 

Ja mogę dodać tylko że c0opperDragon zrobił również "ULA Digitizer", można go znaleźć również w jego sklepie Tindie. Nie podaję linków aby nie było że coś reklamuję i promuje, każdy możne znaleźć na własną rękę. Jeżeli chodzi o "ULAdigitizer" to nie testowałem tego i za mało znam się na ZX spectrum więc trudno mi się nawet na ten temat wypowiedzieć.

Ale nawiązując do tematu który poruszyłeś, to podobny projekt (w sensie użycia RPi Pico) o nazwie GTIA2DVI powstaje dla Atari: https://github.com/maaakit/GTIA2DVI.  Człowiek o pseudonimie "markit" zaprezentował go na AoL w tym wątku: GTIA2DVI.

Ja się bardzo cieszę że jest tyle możliwości do wyboru i w dodatku że MarkIt zrobił ten projekt w pełni otwarty! (Open Hardware/Software). Takich projektów nam potrzeba na scenie! :)

@seban czytam AOL, tamten projekt wygląda obiecująco, przynajmniej w kategorii "low-cost" :)

@willy ... dla mnie wprost przeciwnie. Idea pomysłu (lumacode) jest taka że taki sygnał połączasz sobie zamiast sygnału RF z modulatora i nie wiercąc żadnej dziury w obudowie masz z danej maszyny wyprowadzony sygnał który potem podpinasz sobie jednym kablem ze złączem RCA do RGB2HDMI. Montaż w komputerze też może obyć się bez lutowania (o ile masz podstawkę pod GTIA). Tylko tyle i aż tyle. Dla mnie pomysł zacny i zamierzam niektóre swoje maszyny (GTIA/TIA/VIC-II/ULA) przerobić tak aby zamiast RF miały lumacode. Jednym HDMI2RGB obskoczę wszystko w dodatku dzięki profilom w RGB2HDMI mogę mieć pixel perfect odwzorowanie obrazy z tych maszyn na dowolnym monitorze czy TV z HMDI. Ustawione raz w taki sposób jaki mi odpowiada.

Ale zgadzam się... każdy może mieć swoją opinię o tym projekcie. Ja zaprezentowałem swoją, dość entuzjastyczną ale przedstawiłem też pewne niedociągnięcia i wady o których napisałem wyżej, mimo wszystko cieszę że ten projekt powstał i mogę sobie wybierać z wielu rozwiązań dostępnych obecnie dla różnych maszyn. Jeżeli preferujesz inne rozwiązania to ja doskonale to rozumiem i w żaden sposób nie zabraniam korzystania z nich.

LumaCode nie jest żadnym regenerowanym chroma... możesz porównać to do kodowania np. sygnałów LUMA i CHROMA za pomocą 2-bitowych sekwencji [chroma, luma, luma], to wszystko po to aby cały ten sygnał w formie cyfrowej transmitować jedno-przewodową linię transmisyjną. Wszystko to wyjaśniono na stronie projektu (github): GTIAdigitizer (for Atari 8bit).

cytat z powyższego linku:

@willy: spoko nic się przecież nie stało! nie ma za co przepraszać! Przecież spokojnie sobie wymieniamy poglądy i dyskutujemy. Mi też chwilę zajęło zanim zrozumiałem po co i dlaczego c0pperDragon wymyślił sobie owe "lumacode", jak już załapałem i wiedziałem jaki obraz potrafi generować RGB2HDMI to nie mogłem się doczekać aż zobaczę to na własne oczy. Na szczęście RZóG-owi udało się to kupić gdy tylko się pojawiło w sklepie i miałem możliwość przetestowania tego rozwiązania.

A co do Twojego rozwiązania, faktycznie teraz pamiętam jak o tym pisałeś... ale przyznam szczerze, wtedy sądziłem że używając FIQ będzie ciężko to  samplować precyzyjnie beż żadnego dodatkowego sprzętowego FIFO... chyba koniec końców doszedłeś do podobnych wniosków i porzuciłeś projekt?

W przypadku RGB2HDMI mają dodatkowe CPLD które umożliwia samplowanie z rozdzielczością chyba coś około 10ns. Nie dokopałem się chyba nigdy (nie miałem potrzeby) jak dalej przenoszą ten sygnał, ale gdzieś coś mi mignęło w użwają do tego celu GPU z maliny... nie wiem tylko jak, ew. źle zrozumiałem co co kiedyś przeczytałem i mogę bredzić :)

@alex: ale wiesz że link do repo który zapodałeś to tylko taki dev-board z MAX10 (od Altera/Intel) + transceiver HDMI i nic poza tym? tam nie nic poza upscalerem na FPGA, to jest platforma testowa na której c0pperdragon sobie robił development i test dla danej platformy. Albo jestem ślepy albo nie widzę nic poza tym co zostało napisane w readme: D-Video board - Read Me. Reasumując nie ma tam żadnego kodu HDL-owego który by cokolwiek czytał z GTIA czy magistrali danych JIL. Ale może jestem ślepy i nie widzę?

@seban Mniejwiecej tak było.
FIQ są wystarczająco szybkie i bez problemu da się samplować naprawdę szybko. Problemem było to ze układ graficzny odłączał procesor od szyny na czas dostępu do pamięci. Wyłączając ekran nie gubiłem ani jednego bitu. 3,5MHz to w sumie niewiele. Po kilku próbach jakoś nie chciało mi się tego ciągnąc. Moze dało by się to np przez DMA zrobić lub jakoś inaczej angażując hardware typu SPI. Rozważałem tez zastosowanie rejestru z szeregowym wejściem i  równoległym wyjściem (jakby nie patrzeć to jest FIFO) i jeszcze kilka innych pomysłów. Sporo się wtedy nauczyłem o architekturze ARM, wszystko pisałem w asemblerze.

@lopez - Na przykład tutaj - https://www.tindie.com/products/c0pperd … digitizer/

Jak przeskalujesz na FullHD i zakodujesz H.265 to YT nie powinien za wiele mieszać. Jeśli używasz OBS i masz w miarę współczesną kartę nVidii to polecam sprzętowy kodek H.265 oferowany przez karty serii GTX i RTX.