Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormarkit
   • CommentTime18 Jan 2024 14:01 zmieniony

    
   Cześć, dziś prezentuję mój drugi projekt.
   
   
   Prawie dokładnie rok temu gdy stałem się na powrót posiadaczem Atari 65XE po podłączeniu do TV LCD przeżyłem niemałe rozczarowanie. Obraz był tragiczny. Brakowało mi rozwiązań na wzór Amigowego RGB2HDMI a VXBE nie wchodziło w grę.
   Postanowiłem zmierzyć się z tematem generowania obrazu cyfrowego wprost z tego co wychodzi z GTIA. W Internetach piszą że wszystkie sygnały wychodzące są cyfrowe.
   A są to sygnały LUMA i CHROMA (aka COLOR) oraz CSYNC i pozostałe zegarowe.
   Tak narodził się projekt GTIA2DVI. Dzięki zastosowaniu RP2040 i biblioteki PicoDVI ilość dodatkowych elementów elektronicznych jest zredukowana do absolutnego minimum. W prototypie znajdują się 1 IC jako bufor konwertujący poziomy 5V->3V3 oraz 8 rezystorów i złącze wideo. Być może na wzór PicoCart'a można zrezygnowac nawet z układu konwertującego poziomy napięcia. Przy takiej konfiguracji sprzętowej generowanie sygnału mono pochzodzącego tylko z LUM0-LUM3 oraz CSYNC daje obraz cyfrowy 800x480px 60Hz w jakości "jak z emulatora"
   Trochę gorzej jest w przypadku sygnału CHROMA. Moim założeniem jest dekodowanie go w 100% programowo.
   Podstawowym problemem jest zależność charakterystyki tego sygnału od położenia potencjometru regulacyjnego na płycie Atari. Uniemożliwia to w praktyce przenoszalność konfiguracji z 1 egzemplarza do innego. Rozwiązanie nie jest obecnie plug and play i wymaga kalibracji do konkretnego egzemplarza.
   Dodatkowo widoczne jest "pływanie" parametrów tego sygnału w czasie (prawdopodobnie z nagrzewaniem się GTIA) występujące w pierwszych minutach po uruchomieniu.
   Występują także pewne artefakty o różnym pochodzeniu z których część prawdopodobnie uda się usunąć w nowszych wersjach. Artefakty występują głównie na granicy czerni i koloru oraz kolorów odległych od siebie w palecie GTIA.
   W sygnale chroma widoczna jest także odświeżanie pamięci DRAM.
   
   W pierwszej wersji prototypu rezultaty odtwarzania obrazu w kolorze są dobre. Myślę że trochę da się to jeszcze poprawić.
   

   
   
   

   • IMG_9093 (2).jpg
     
     
     
     
2. • 2:
      
     CommentAuthorjhusak
   • CommentTime18 Jan 2024 14:01

    
   No ładne cacko :) Widać jeszcze kolorowe artefakty na Drunk Chessboard, ale to pewnie do łatwego ogarnięcia :). 3mam kciuki!
3. • 3:
      
     CommentAuthorsun
   • CommentTime18 Jan 2024 14:01

    
   No no, fiu fiu.
4. • 4: CommentAuthorVLX
   • CommentTime18 Jan 2024 14:01

    
   Brawo!
   Już teraz wygląda to świetnie.
5. • 5: CommentAuthormarkit
   • CommentTime18 Jan 2024 14:01 zmieniony

    
   @jhusak ten efekt wynika z pojedyńczego bufora ekranu oraz różnicy częstotliwości ramki 50->60Hz. Rozwiązaniem na to byłoby w ogóle zrezygnowanie z buforowania ramki i przetwarzanie wszystkiego "w locie". Z tym że przy tym trzeba zsynchronizowac częstotliwość ramki Atari i odbiornika z dokładnośćią do linii. To może być wykonalne ale mam to w planie trochę dalej na roadmapie.
6. • 6: CommentAuthorCharlieChaplin
   • CommentTime18 Jan 2024 15:01 zmieniony

    
   Looks great!
   
   Hopefully THIS is the inexpensive HDMI solution we all want... or to say it with the words of Pink Floyd: [I have] High Hopes !
7. • 7: CommentAuthormarkit
   • CommentTime18 Jan 2024 15:01

    
   @CharlieChaplin I plan to open source this as a DIY device. Due to the use of RPi Pico, from an engineering point of view the device does not meet the criteria for a commercial device . If it has to be cheap, so let's stick to the DVI format ;)
8. • 8:
      
     CommentAuthorPeri Noid
   • CommentTime18 Jan 2024 15:01

    
   Kapitalny pomysł, gratuluję. Tylko 60Hz na wyjściu dla Atari w PAL-u to... No, słabo to brzmi...
9. • 9: CommentAuthorpin
   • CommentTime18 Jan 2024 17:01

    
   @Peri Noid - obstawiam, że wszystko co jest "skrolowane" płynnie zwłaszcza w poziomie będzie skakać, no i rozlecą się wszystkie tryby z przeplotem, oraz nasycenie barw w owych trybach. W tym względzie oceniam, że jednak vbxe jest bezkonkurencyjne.
10. • 10:
       
      CommentAuthorPeri Noid
    • CommentTime18 Jan 2024 18:01 zmieniony

     
    O to mi chodzi. Mam do Amigi upscaler (bo to nie jest scandoubler), który wypluwa zawsze 60Hz na HDMI. I niestety, to nie jest to. Dlatego obawiam się, że tutaj może być podobnie. W tym miejscu Medusa jest nie do pobicia chociaż problemem staje się monitor potrafiący odpowiednio szybko reagować na zmiany w sygnale.
11. • 11: CommentAuthormarkit
    • CommentTime18 Jan 2024 20:01

     
    Potwierdzam scrolle w 50Hz wyglądają znacznie lepiej. Jednak to wiąże się ze zmianą rozdzielczości na 768x576p co doda na telewizorach 16:9 ramki na górnej i dolnej krawędzi ekranu. Tryb 480p był pod tym względem lepszy gdyż max rozdzielczość pionowa Atari x2 wpasowywała się na wysokość całego ekranu. W obu rozdzielczościach występuje ramka po bokach. Przeskalowanie całego obrazu o ułamkowy współczynnik nie wchodzi w grę. Coś za coś. Zostawię tryb 50Hz jako default.
    
    Co do odniesienia do vbxe to jest to rozwiązanie zupełnie innej
    klasy o nieporównywalnie większych możliwościach.
12. • 12:
       
      CommentAuthorAlex
    • CommentTime19 Jan 2024 00:01 zmieniony

     
    Wygląda obiecująco :) Ale koniecznie musi być 50Hz. Czarne paski na telewizorze to pikuś. Z resztą nowoczesne telewizory pozwalają zmienić tryb wyświetlania lub przybliżyć obraz.
13. • 13: CommentAuthorpin
    • CommentTime19 Jan 2024 00:01

     
    50hz to połowa sukcesu, bo bez pal blending nie wyobrażam sobie życia w świecie Atari ;)
14. • 14:
       
      CommentAuthorKrótki
    • CommentTime19 Jan 2024 01:01

     

    markit:

    Potwierdzam scrolle w 50Hz wyglądają znacznie lepiej. Jednak to wiąże się ze zmianą rozdzielczości na 768x576p co doda na telewizorach 16:9 ramki na górnej i dolnej krawędzi ekranu. Tryb 480p był pod tym względem lepszy gdyż max rozdzielczość pionowa Atari x2 wpasowywała się na wysokość całego ekranu.

    
    To nieprawda że maksymalna rozdzielczość pionowa Atari to 240 linii. Ani w PAL, ani w NTSC. Więc zmiana rozdzielczości na 768x576 jest tym bardziej pożądana.
15. • 15: CommentAuthormarkit
    • CommentTime19 Jan 2024 11:01 zmieniony

     

    Krótki:

    To nieprawda że maksymalna rozdzielczość pionowa Atari to 240 linii. Ani w PAL, ani w NTSC. Więc zmiana rozdzielczości na 768x576 jest tym bardziej pożądana.

    
    Słuszna uwaga będzie wyświetlane 288 lini z Atari.
    
    

    pin:

    bez pal blending nie wyobrażam sobie życia w świecie Atari ;)

    
    pal blending nie mogę obiecać. Niestety brakuje trzeciego core'a na RP2040. I tak już jest przetaktowany ponad 200% względem specyfikacji. Obecna implementacja mieszcząca się "na styk" w ramach czasowych linii jest zoptymalizowana tak że wyklucza pal blending.
    Na tym polu mogą się wykazać VBXE i Sophia2.
16. • 16:
       
      CommentAuthorPeri Noid
    • CommentTime19 Jan 2024 12:01

     
    Sophia też nie umie.
17. • 17: CommentAuthorPeterKaczorowski
    • CommentTime19 Jan 2024 13:01

     
    @markit,
    
    Fajne. Gratulacje.
18. • 18: CommentAuthormono
    • CommentTime19 Jan 2024 13:01 zmieniony

     
    @markit: Czy tryb z naprzemiennymi liniami trybów 9 i 11 się wyświetli poprawnie? Tam jest przesunięcie cyklu koloru co w połączeniu z pal-blendingiem powoduje że da się uzyskać 9*16=144 kolory w 160x96.
    
    To są tryby:
    * HIP: ->link<- - demo ->link<-
    * RIP: ->link<-
    * TIP: ->link<- - demo ->link<-
    
    Poza tym jest jeszcze inny ciekawy tryb - SHIMC: ->link<- Nie wiem czy ten trick nie bazuje na nieregularnych kształtach sygnału zegara w niektórych Atarkach - edytor z obrazkami tu ->link<- i tu ->link<-
    
    Edit: W sumie to może Rocky albo Tebe niechby się wypowiedzieli na temat jak to działa to 640px.
19. • 19:
       
      CommentAuthorjhusak
    • CommentTime19 Jan 2024 14:01

     
    @markit, chodzi mi o te kolorowe artefakty, takie tęczowe mrugnięcia. 50->60 Hz to inna sprawa.
20. • 20: CommentAuthorRocky
    • CommentTime19 Jan 2024 14:01 zmieniony

     
    Tryby interlace w przypadku Atari raczej odeszły do lamusa, gdyż niewiele jest wyświetlaczy (innych niż CRT) zdolnych do poprawnego wyświetlenia przeplotu.. nawet na emulatorach z uwagi na 60Hz standard monitorów jest z tym problem..
    Byłaby szansa dla trybu i480 (działa praktycznie jak w Amidze) pod warunkiem, że rozwiązałoby się problem braku oznaczania kolejności ramek przez Atari.. aktualnie mógłby pomóc mały kalibrator z kontrolnym obrazkiem oraz możliwością przełączenia kolejności ramek.
    
    Co do trybu 640px w poziomie, to dwa obrazy 320px wyświetlane na zmianę.. ciekawy efekt mógłby być w połączeniu z i480..
21. • 21: CommentAuthormarkit
    • CommentTime19 Jan 2024 14:01

     

    jhusak:

    @markit, chodzi mi o te kolorowe artefakty, takie tęczowe mrugnięcia. 50->60 Hz to inna sprawa.

    Te kolorowe artefakty są wynikiem braku synchronizacji między ramkami. Występują także przy 50Hz. Powodem jest to, że tworzenie obrazu polega na sekwencyjnym wysyłaniu danych do trzech buforów R, G i B. Przy szybkich zmianach kolorów np z czarnego na biały i braku synchronizacji może się zdarzyć że w tym samym czasie (pracują 2 rdzenie MCU) piszemy dane tej samej linii i kopiujemy do bufora wyjściowego. W takim przypadku wystąpią przekłamania np. Bufor R, G zostanie wysłany z zerami a B już będzie wypełniony kolorem i na ekran trafi niebieski zamiast białego. Wyeliminowanie tego wymaga precyzyjnej synchronizacji ramek tak aby dane obrazu tej samej linii były zapisane w całości przed rozpoczęciem jej wyświetlania. To postaram się rozwiązać w pierwszej kolejności.
    
    

    mono:

    @markit: Czy tryb z naprzemiennymi liniami trybów 9 i 11 się wyświetli poprawnie? Tam jest przesunięcie cyklu koloru co w połączeniu z pal-blendingiem powoduje że da się uzyskać 9*16=144 kolory w 160x96.

    
    projekt nie jest jeszcze na odpowiednim etapie do pracy z tymi trybami. Obecnie do wyeliminowania są artefakty na podstawowych trybach graficznych. Jakość sygnału chroma generowana przez GTIA może być niewystarczająca do tego by przetwarzać ją cyfrowo z dokładnością do pojedyńczego pixela.
    Dodatkowo te tryby polegają na pal blendingu, którego dotyczył mój poprzedni komentarz.
    
    Dekodowanie koloru jest jeszcze w fazie eksperymentalnej. Czekam na płytki do drugiej wersji prototypu. Jak tylko go uruchomię i potwierdzę działanie na drugim egzemplarzu Atari, opublikuję projekt.
22. • 22: CommentAuthormono
    • CommentTime19 Jan 2024 15:01

     

    Rocky:

    Co do trybu 640px w poziomie, to dwa obrazy 320px wyświetlane na zmianę.. ciekawy efekt mógłby być w połączeniu z i480..

    No dobrze, ale dlaczego tam się wyświetla 640 pikseli w poziomie zamiast 3-kolorowego zwykłego hiresu 320px? O mechanizm powstawania większej rozdzielczości mi chodzi. Co więcej wydaje mi się też że ten efekt jest obserwowalny lokalnie i jest zależny od kolorów jakich się używa, bo jak się pozmienia kolory w linii to gdzieniegdzie jest 320px.
23. • 23:
       
      CommentAuthorpirx
    • CommentTime19 Jan 2024 18:01

     
    ładne cacko!
24. • 24:
       
      CommentAuthorpancio
    • CommentTime19 Jan 2024 18:01

     
    Bardzo obiecujące! Czy przewidujesz podzielić się projektem z użytkownikami albo wykonać partię dla zainteresowanych?
    
    Jesteś w stanie określić jakie opóźnienie jest wprowadzane podczas przetwarzania sygnału z Atari?
25. • 25: CommentAuthormarkit
    • CommentTime19 Jan 2024 21:01

     

    pancio:

    Bardzo obiecujące! Czy przewidujesz podzielić się projektem z użytkownikami albo wykonać partię dla zainteresowanych?

    
    Projekt będzie otwarty. Znajdzie się na githubie. Czekan ma nowe płytki prototypowe. Będę miał 3 wolne egzemplarze które mogę przesłać trzem chętnym osobom w kolejności zgłoszenia.
    
    
    

    pancio:

    Jesteś w stanie określić jakie opóźnienie jest wprowadzane podczas przetwarzania sygnału z Atari?

    
    
    Obecnie brak jest dokładnej synchronizacji wyświetlanych linii. Przez co opóżnienie jest zmienne i wynosi max. 1 ramkę, czyli 20ms. Docelowo planowana jest dokładna synchronizacja każdej linijki i opóźnienie będzie dużo mniejsze.
26. • 26:
       
      CommentAuthorpancio
    • CommentTime19 Jan 2024 21:01

     
    Chętnie potestuję prototyp jeśli będziesz zainteresowany :-)
27. • 27: CommentAuthormarkit
    • CommentTime19 Jan 2024 22:01 zmieniony

     

    pancio:

    Chętnie potestuję prototyp jeśli będziesz zainteresowany :-)

    
    jasne. Jak będę miał płytkę umówimy się na wysyłkę.
    
    Gwoli ścisłości: to będą 3 gołe płytki pcb do własnoręcznego zmontowania (elementy trzeba samodzielnie skompletować) :)
28. • 28: CommentAuthorkkrys
    • CommentTime19 Jan 2024 23:01

     
    Ja też bym chętnie potestował
29. • 29: CommentAuthorpin
    • CommentTime20 Jan 2024 02:01

     

    Rocky:

    Tryby interlace w przypadku Atari raczej odeszły do lamusa, gdyż niewiele jest wyświetlaczy (innych niż CRT) zdolnych do poprawnego wyświetlenia przeplotu..

    
    
    Urządzenia w rodzaju Framemaister, ossc, czy Meduza + prawie dowolny wyświetlacz z hdmi poradzi sobie z poprawnym wyświetleniem takich rzeczy. Jak się postarasz, to idzie to nawet zgrabować na żywo do PC.
30. • 30: CommentAuthorw1k
    • CommentTime21 Jan 2024 16:01

     
    very nice project
31. • 31: CommentAuthorRocky
    • CommentTime22 Jan 2024 09:01

     
    mono:
    
    Generujesz obrazek 640px i tworzysz z niego dwa obrazy 320px z parzystych i nieparzystych kolumn... i nimi naprzemiennie migasz.. ot cała magia..
    Kolory w hires tworzy się z wykorzystaniem artefaktów. Dostajemy zółć lub niebieski w zależności, który pojedynczy piksel hires użyjesz z pary.. oba naraz dają biały.. dlatego też czcionka Atari z natury jest podwójnej szerokości.. czcionki np. z ZX nie wyglądają zbyt dobrze.
32. • 32: CommentAuthormarkit
    • CommentTime27 Jan 2024 17:01

     
    projekt został właśnie opublikowany ->link<-
    
    ciągle jest to wersja prototypowa.
    Obecnie działa w 100% plug and play DVI monochromatyczne.
    Dekodowanie chromy wymaga kalibracji i jej rezultat zależy od temperatury GTIA. Nad poprawą tego pracuję.
    
    Jeżeli komuś udałoby się zbudować i uruchomić wdzięczny będę za feedback. Obecnie mam to uruchomione tylko na 2-óch maszynach.
33. • 33: CommentAuthormarkit
    • CommentTime29 Jan 2024 10:01

     
    Druga wersja prototypu w towarzystwie Ultimate 1MB.

    • IMG_9119.jpg
      
      
      
      
34. • 34: CommentAuthorzaxon
    • CommentTime30 Jan 2024 17:01

     
    Trzeba będzie podłączyć ;) Fajny projekt. Nie masz gotowego wsadu UF2 ? Troche by mi to przyspieszyło testy ;)
35. • 35: CommentAuthormarkit
    • CommentTime30 Jan 2024 22:01

     
    @zaxon wsad jest w Releasach w repo ->link<-
36. • 36: CommentAuthorzaxon
    • CommentTime1 Feb 2024 14:02

     
    A , dzięki, to w weekend zasadzę u siebie. A tak z innej beczki. Doradzać w robocie nie bede bo sie na tym nie znam ale do Zx Spectrum mamy taki moduł , też na Pico ->link<- i on dosyć dobrze działa. Może po przeprogramowaniu go zadziałał by i z Atari ?
37. • 37:
       
      CommentAuthorsun
    • CommentTime1 Feb 2024 16:02

     
    o ciekawe, @zaxon masz to dostępne jak coś?
38. • 38: CommentAuthorgrzybson
    • CommentTime1 Feb 2024 17:02

     
    @zaxon ciekawe czy ten wynalazek AleksaEKB dałby radę z VBXE. Nie wiem jak wygląda RGB w Spectrum.
39. • 39: CommentAuthormarkit
    • CommentTime1 Feb 2024 18:02

     
    Z linka wrzuconego przez @zaxon wynika że są tam 3 sygnały: R, G i B. Sygnał jest binarny co w sumie daje 8 kolorów. To zupełnie inne podejście niż CHROMA w Atari. W sumie to bardziej działa podobnie jak LUMA - też sygnał binarny, tyle że na 4-ech liniach co daje 16 poziomów jasności.
    Kolor w Atari to dwie linie: PAL i COLOR które na wyjściu GTIA są sygnałem prostokątnym o f= ok. 4,4MHz a za wartość koloru odpowiada przesunięcie fazy.
    Obecnie pracuję nad bardziej wydajnym algorytmem liczenia tego "w locie" tak aby zredukować artefakty na granicy dwóch kolorów i wyeliminować kalibrację.
40. • 40:
       
      CommentAuthorsun
    • CommentTime1 Feb 2024 18:02

     
    @grzybson:chyba lepiej pójść w rgb2hdmi w tym wypadku.
41. • 41: CommentAuthorzaxon
    • CommentTime2 Feb 2024 09:02

     
    @grzybson, nie da rady bo on ma swoją paletę od ZX-a
    
    @markit , chodziło mi raczej o użycie samego urządzenia i płytki z innym (twoim) firmware. Płytka ma bufor, ma gniazdo HDMI ...
    
    RGB2HDMI też w sumie mam, VBXE mam, podłącze na dniach i zobacze .
42. • 42: CommentAuthormarkit
    • CommentTime2 Feb 2024 20:02

     
    mój firmware nie pójdzie na niczym innym niż RP2040 bo wykorzystuje specyficzne dla tego MCU ficzery np PIO i interpolator
43. • 43:
       
      CommentAuthorpancio
    • CommentTime2 Feb 2024 20:02

     
    Hejka,
    
    Dziękuję za płyteczki. Jedna leci do KKRYS-a a ja czekam na breadboardy z HDMI pod RP2040.
    
    W takim razie mam pytanie, czy mówiąc "nic innego niż RP2040" masz na myśli tylko oryginalne PI?
44. • 44: CommentAuthormarkit
    • CommentTime2 Feb 2024 23:02

     
    @pancio na innych płytkach też powinno działać jeżeli jest tam mikrokontroler RP2040. Zakładając że producenci tych płytek wkładają tam to co deklarują w specyfikacji to powinno być ok.
    Inną sprawą jest to, ze oryginalne mikrokontrolery bez problemów podkręcają sie nawet na 250% oficjalnego zegara (133MHz). Generowanie obrazu cyfrowego wymaga w tym przypadku 285MHz i na takiej częstotliwości obecnie działa prototyp. Jeżeli na nieoficjalnych płytkach montowane są kiepskie podróby to może być słabo.
    Ja na razie testowałem tylko oficjalne.
    Kod na pewno nie zadziała na żadnej płytce Raspberry PI (nie Pico) Tam siedzi procesor o innej architekturze. Ale niewykluczone że na tę platformę ktoś kiedyś napisze emulator pico.
45. • 45: CommentAuthorzaxon
    • CommentTime3 Feb 2024 14:02

     
    @markit ale to Alexa rgb2hdmi jest na normalnym, prawdziwym pico własnie.Dlatego sugerowałem czy by sie go nie dało użyć.

    • 20230708_070628.jpg
      
      
      
      
46. • 46: CommentAuthormarkit
    • CommentTime3 Feb 2024 15:02

     
    @zaxon, coś sorry źle zrozumiałem.
    Tak, dałoby się po niewielkich modyfikacjach uruchomić mój soft na tej płytce. Drobnej zmiany wymagałby firmware bo inaczej podłączone jest złącze video. Również jedno połączenie sygnałowe na płytce trzeba by dodatkowo pociągnąć do pico i 74LVC245. Ale ogólnie schematy obu urządzeń są bardzo podobne.
47. • 47: CommentAuthorzaxon
    • CommentTime3 Feb 2024 15:02

     
    Więc w sumie prościej zrobic nową płytkę niż przerabiać to co już jest ;)
48. • 48: CommentAuthorst_man
    • CommentTime22 Feb 2024 00:02

     
    To mój pierwszy post na tym szacownym forum więc witam Was wszystkich :)
    
    Markit, gratuluję pomysłu - jest po prostu świetny :)
    
    Mam już płytkę RP PICO i połączyłem to na razie z gniazdem DVI .
    
    Od razu powiem, że to moje pierwsze eksperymenty z Rp Pico i moja wiedza na ten temat jest póki co mizerna :)
    Wrzucałem tam różne video demo z plików UF2 i część działa a część nie w sensie tego, że jest sygnał na HDMI lub nie- nie mam pojęcia dlaczego. Plik gtia2dvi-v0.0.1-alpha.uf2 oczywiście też wrzuciłem i przetestowałem tak na szybkiego - zwarłem GP8 z masą i podpiąłem zasilanie do PICO. Menu konfiguracyjne pojawiło się więc jest ok.
    
    Nie montowałem jeszcze płytki dla GTIA i PICO ale w miarę wolnego czasu zabiorę się za to i chyba zrobię to na płytce uniwersalnej.
    I jeśli będzie taka potrzeba chętnie podzielę się moimi spostrzeżeniami, w szczególności z autorem. Mam też dostęp do
    dwukanałowego oscyloskopu jakby co :)
    
    
    Pierwsze co mnie trochę martwi to fakt, że obraz z PICO poprzez kabel HDMI mam tylko na monitorze komputerowym Asus. Ale ani na smart TV Philipsa z przed 3 lat ani na plazmie Toshiby z 2013 roku obrazu nie ma - jest brak sygnału na HDMI i tyle.... A marzy mi się dobry obraz z Atari na dużych TV. Mam nadzieję, że to tylko kwestia jakichś zmian w sofcie dla PICO . Jak myślicie - w czym problem ? Wszystkie testy zarówno z monitorem jak i telewizorami robiłem na tym samym kablu HDMI .
    Markit - testowałeś swoje rozwiązanie czy działa na jakimś
    TV z HDMI ?
    
    Wiem, że w tej chwili najważniejsze dla autora projektu jest dopracowanie wszystkiego co związane z finalnym efektem obrazu poprzez DVI. Ale zapytam Markita tak na przyszłość - czy widzisz możliwość poszerzenia Twojego projektu tak aby przez HDMI było też przesyłane audio ?
    
    I jeszcze przed montażem mojej płytki mam pytania co do schematu:
    
    a) do czego jest 5-pinowe złącze opisane jako PWR_AN ?
    Co do pinu 1 oraz 5 - wiadomo co oznaczają.
    A linie A0, A1 i A2 ? Czy chodzi o połączenie z liniami
    AN0, AN1 i AN2 ANTICA jak sugeruje opis tego złącza ?
    b) i tak na wszelki wypadek - czy dobrze rozumiem, że IC4
    symbolizuje punkty lutownicze bądź podstawkę po wyjętym GTIA z
    płyty Atari a IC5 to GTIA przeniesione
    na płytkę GTIA2DVI ? ( lub odwrotnie :) ) .
    Pytam, bo ktoś może pomyśleć "a po co tam dwa GTIA ?" ;)
    
    
    Pozdrawiam :)
49. • 49: CommentAuthormarkit
    • CommentTime23 Feb 2024 13:02

     
    @st_man, dziękuję za feedback. Fajnie że pokusiłeś się o zmontowanie tego.
    Na razie nie potrzebuję oscyloskopu. Wystarcza mi Rpi pico które robi za analizator stanów logicznych (8 kanałów f=285 Mhz)
    Co do TV to jest pewnie efekt trochę niestandardowej geometrii obrazu którą zmodyfikowałem względem standardu aby uzyskać lepszą synchronizację ramek z Atari. Testuję to obecnie na TV LCD marki LG i u mnie jest ok. Przyjrzę się temu w przyszłości. Być może w menu pojawi się opcja do konfiguracji obrazu.
    
    Ten projekt nie wspiera technologi HDMI ze względów licencyjnych. Sygnał audio nie jest standardem w DVI.
    
    
    ad a) Złącze PWR_AN znalazło się na płytce na wypadek zmiany koncepcji przetwarzania sygnału. Rozważałem także samplowanie sygnału analogowego COLOR. Z tego powodu na płytce wszystkie 3 wejścia analogowe RP2040 zostały wystawione przez dzielnik rezystorowy. Obecny firmware tego nie wspiera.
    
    ad b) dokładnie tak, jedno z tych oznaczeń odnosi się do podstawki dla GTIA, drugie do złącza do wpięcia w płytę główną Atari w miejsce GTIA.
    
    Na koniec dodam jeszcze że pracuje nad nową wersją softu.
    Celem jest poprawa jakości wyświetlanych kolorów oraz pozbycie się niepraktycznej kalibracji. Pracuję nad tym aby urządzenie wyświetlało prawidłowy obraz kolorowy już po wpięciu w Atari.
50. • 50: CommentAuthorst_man
    • CommentTime24 Feb 2024 01:02

     
    @markit - trzymam kciuki aby dopracowanie softu się powiodło :)
    
    Póki co rozwiązałem problem braku obrazu na moich TV.
    Podłączyłem RPi pico pod jeszcze jeden TV - taką Mantę 22" . I tam zadziałało wszystko jak należy. Doszedłem więc do wniosku, że jest to problem sprzętowy. W standardzie HDMI jest tak, że urządzenie odbiorcze ( TV, monitor ) sprawdza czy na pinie 18 złącza HDMI jest napięcie +5V ( dopuszczalny zakres 4,7v do 5,2V ). Jeśli go tam nie ma, to nie nastąpi inicjalizacja transmisji danych cyfrowych i w konsekwencji brak obrazu na ekranie. Dołożyłem więc przewód z +5V na złącze DVI - i BINGO ! Mam obraz i na monitorze i na dowolnym TV :) A na Twoim schemacie zauważyłem potem, że jest tam przewidziane dzielone pole do zalutowania w celu podłączenia tego napięcia do złącza DVI.
    Dlaczego bez tego napięcia jest obraz na monitorze Asusa i TV Manta ? Mam na to dwie teorie. Pierwsza taka, że przez jakiś rezystor jest to wewnętrznie podciągnięte do +5V w tych urządzeniach. A druga, że odbiornik HDMI ma tam firmware który olewa fakt braku tego napięcia. I wydaje mi się, że bardziej prawdopodobna jest ta pierwsza teoria. Trzeba by zmierzyć na kablu HDMI podłączonym do TV czy jest tam to napięcie - może kiedyś sprawdzę :)
    Tak czy inaczej - jeden problem z głowy .
    
    W moich TV jest tak , że jak wybierze się wejście HDMI to nie ma możliwości korzystania z sygnału audio z wejść analogowych - audio musi być też z HDMI. No cóż - trzeba będzie podłączyć jakieś aktywne głośniczki i gitara :) Tyle, że więcej gratów do rozkładania. No i druga opcja - jakiś monitor z wbudowanymi głośnikami, za którym powoli się rozglądam. Ale na githubie gdzieś mi tam chyba mignęło, że jest jakaś biblioteka do obsługi dźwięku
    poprzez DVI w RPi pico. No ale skoro "święte" względy licencyjne są tak surowe no to cóż ..... ;)
    
    A pomysł z 8-kanałowym analizatorem stanów logicznych na RPi też bardzo ciekawy - w jaki sposób odczytujesz wyniki pomiarów ( wykres na ekranie, plik z danymi ..) ? Sam stworzyłeś soft czy jest jakiś gotowiec w sieci ?