Jak podłączyć komputer z wyjściem MDA do nowoczesnego monitora VGA/HDMI?

Thu May 19, 2016 1:33 pm   

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnjrfig.o8s.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:

Teoretycznie sie z Toba zgadzam, a jednak IBM w owych czasach robil
inaczej.
A VGA byly drogie (6 bitow to juz nie takie pare) ..


Dzis tez tak zle nie jest, trzeba byc duzym, aby przepchnac nowy
"standard".


Trudno aby zaczeli od stawiania laboratorium LCD.
Zauwaz, ze czestotliwosci jednak nieco inne - i nie wahali sie ich
zmieniac coraz bardziej.

Tak nawiasem mowiac - telewizyjne kineskopy kolorowe sie niemal nie
nadawaly do uzytku - tylko w niskiej rozdzielczosci.
Trzeba bylo poczekac na monitory VGA i malymi otworkami w masce.
Tak wiec ta CGA wcale taka zla jak piszesz nie byla ... to MS-DOS byl
zly, bo kiepsko pracowal na 40 znakach szerokosci :-)

J.

Thu May 19, 2016 2:09 pm   

Pan J.F. napisał:


Sześciobitowa drabinka nie jest wielkim wyzwaniem. To też tylko
teoretycznie musi być sześciobitowym przetwornikiem, dokładne być
nie musi, takie tam zgrubne robienie woltów z bitów.


Jak potrzebowałem rozdzielczości pionowej 1035 (czy coś koło tego),
bo mi się Ważny Program na ekranie nie mieścił, to sobie zmieniłem
modeline. I karta, i monitor łyknęły. A to było wczoraj, może nawet
przedwczoraj. Z czasem wszystko stało się bardziej elastyczne.


Ale tylko nieco. Tolerowane przez podzespoły telewizyjne. Dla MDA
amerykanie zaimportowali nawet europejskie 50 Hz.

--
Jarek

Thu May 19, 2016 4:05 pm   

On 19/05/2016 12:48, J.F. wrote:

Po internecie czytałem ludzi którzy twierdzili że udało im się robić PWM
rzędu 40 MHz na Pi2... Oczywiście może to być bujda i legendy :)


I to jest właśnie ten szczegół który mi umknął: możliwość składania
bajtu z ośmiu różnych linii w hardware, jednym taktem CPU. Z początku
przyjąłem że na mikrokontrolerze da się tylko odczytywać pojedynczy stan
on/off każdej linii z osobna, dlatego nie rozumiałem dlaczego mógłbym
być zainteresowany wykorzystaniem 8x 2MHz zamiast 1x 16 MHz. Teraz
rozumiem że na MCU mogę doprowadzić 8 linii TTL, i MCU mi to odczyta
całym bajtem w jeden takt.

Sądzę że będę kombinował zatem w tym kierunku:

MDA wysyła mi sygnał TTL 16 MHz, odbieram go na 74hc595 (ten podpięty
pod oscylator 16 MHz, tzn. dokładnie tyle ile ma MDA), z 74hc595
wyprowadzam wtedy 8 linii do ATtiny 2313, i tam czytam bajt po bajcie
(czyli grupami po 8 pixeli) z szybkością 2 MHz (do dostrojenia za pomocą
odpowiedniej ilości NOPów w ASM).

Każdy odczytany w ten sposób bajt ATtiny wrzuca natychmiast w kolejkę
SPI, za którą czeka RPi, któremu zostaje tylko malować piksele w swoim
framebufferze (tutaj zakładam że buforowanie SPI jest wystarczający by
pokryć brak obsługi w realtime na RPi). W jakiś jeszcze nieokreślony
sposób będę musiał sprawić by 74hc595 reagował na HSYNC, aby wiedział
kiedy dokładnie łapać sznurek bitów (no i AVR zresztą też bedzie musiał
znać HSYNC żeby wiedzieć kiedy zacząć odczytywać swój 8bitowy rejestr, a
także VSYNC by móc sygnalizować RPi początek każdej ramki).

Czy powyższa wypowiedź ma jakikolwiek sens, czy też rozmawiam całkiem od
rzeczy?

Dla uproszczenia postanowiłem zignorować na razie linię "intensity" z
MDA, i polować na samo monochromatyczne wideo. Jeśli cokolwiek z tego
wyjdzie, zawsze będzie czas szukać ulepszeń.

Mateusz

Thu May 19, 2016 5:03 pm   

On 19/05/2016 18:05, Mateusz Viste wrote:

Ten szczegół może jednak do poprawki właśnie spostrzegłem się że
ATtiny 2313 ma tylko jeden interfejs ośmiobitowy ("PB"), a ten
współdzieli piny z interfejsem SPI, więc odpada. Wyszukam więc inny
model AVR który może korzystać z SPI i portu 8bit jednocześnie.

Mateusz

Thu May 19, 2016 9:43 pm   

Zapomnij o prostym wykorzystaniu jakiegoś RPi czy innego arduino. Jak któryś
z kolegów zauważył, najlepiej jakieś rozwiązanie z licznikami i pamięcią
RAM.
Generacja sygnału video banalna nie jest a przechwytywanie tegoż; jeszcze
gorsze. Jednym słowem: raczej nie dasz rady. No chyba że się zaweźmierz na
maxa.


jp

Fri May 20, 2016 10:12 am   

W dniu 2016-05-19 o 18:05, Mateusz Viste pisze:

Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz w MDA, oba
zegary Ci się rozjadą.

--
AWa.

Fri May 20, 2016 10:32 am   

Pan Andrzej W. napisał:


16,257 MHz, tak dokładnie. Dzielone na 882 piksele w linii (widoczne
i niewidoczne) oraz 369 linii (łącznie z powrotnymi). To daje
częstotliowść ramki 49,95 Hz. Łatwo do tych danych dotrzeć. Zrobić
realną analizę żywego sygnału nieco trudniej.

--
Jarek

Fri May 20, 2016 11:08 am   

On 20/05/2016 12:12, Andrzej W. wrote:

Trochę uprościłem z tym 16 MHz - w praktyce jak najbardziej byłoby to
dokładnie tyle co napisane na oscylatorze który mam na karcie MDA, czyli
16.257000 MHz.

Mateusz

Fri May 20, 2016 12:36 pm   

On 19/05/2016 23:43, jacek pozniak wrote:

Ano, z łapaniem 16 Mhz rozumiem że może być trudno, ale łapanie 2 MHz za
pomocą ATMegi z taktowaniem 20 MHz już chyba powinno być realistyczne?

Stąd ten cały 74hc595 właśnie, za wskazówkami przedmówców dot.
wykorzystania rejestru przesuwającego.

Pomysł z RPi na samym końcu jest o tyle kuszący, że umożliwia w pełni
programowe malowanie ekranu, cała elektronika już jest, i to całkiem
przyszłościowo (hdmi) - a gdyby wykorzystać RPi Zero to i cenowo zaczyna
być bardzo interesująco. Fakt, że RPi może mieć problemy komunikacyjne
związane z brakiem obsługi realtime, ale to można (?) wyrównać za pomocą
odpowiednio dużych buforów na wejściu SPI po stronie RPi.

Czyli generalnie mamy 3 bloki:
* rejestr przesuwny SIPO zaciąga sznurek bitowy od MDA z częstotliwością
16.257 MHzi wystawia po 8 równoległych bitów
* ATMega48 odczytuje z rejestru ośmiobitowe bloczki (8 pikseli na raz)
starając się utrzymać częstotliwość 2.03 MHz (być może odczyty
wywoływane jakimś interruptem sterowanym z tych 16.257 MHz po dzielniku
/8... do zbadania), i wysyła osmio-pikselowe bloczki po SPI
* RPi odbiera piksele z SPI i maluja na swoim framebufferze

Jedyny "podejrzany" etap to komunikacja między rejestrem przesuwającym a
ATMegą, ale skoro to "tylko" 2 MHz, to jakaś nadzieja chyba jest...

Praktyka na pewno zweryfikuje mój optymizm :)

Mateusz

Fri May 20, 2016 12:40 pm   

W dniu 2016-05-20 o 13:08, Mateusz Viste pisze:

Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar, wtedy
niedokładności przestają mieć aż takie znaczenie.
A jak z RPi (albo czegoś innego podobnego) wywalisz Linuxa to może być
trochę łatwiej (nie wiem czy się da). Trzeba by popatrzeć na to czym
programować na odpowiednim poziomie i jak szybko peryferia potrafią
działać.
I poszukaj 595 trochę szybszej serii - HC to przeżytek straszny.

Pozdrawiam

DD

Fri May 20, 2016 1:39 pm   

Pan Dariusz Dorochowicz napisał:


Wystarczającą dokładność *częstotliwości* osiągnąć łatwo. Skoro linia
ma 882 piksele, to przy dokładności lepszej od 0,1% da się bezbłędnie
ją spróbkować. Problemem jest *faza*. I tu dobrym podejściem (o czym
też chyba ktoś pisał), jest odczyt 16257000 *bajtów* na sekundę, w ten
sposób, że każdy bit jest brany z pewnym przesunięciem czsowym (da się
je zrobić rejestrem lub nawet analogowo). Wtedy mamy gwarancję, że
można wskazać *bit*, który w ciągu *bajtów* pokaże prawidłowy obraz
wyświetlanych punktów. Ale który to bit? Ano ten, który ma takiego samego
młodszego i starszego sąsiada w każdym bajcie.

Wiem, niczego odkrywczego nie napisałem. Ale to jest jakaś wskazówka,
jak może dziłać prosty i klarowny algorytm poszukiwanie prawdy o tym,
co by monitor wyświetlał, gdyby wyświetlał.

--
Jarek

Fri May 20, 2016 1:45 pm   

On 20/05/2016 14:40, Dariusz Dorochowicz wrote:

Tak tak, to jest jasne. Ale wtedy nie było (jeszcze) mowy o rejestrze
SIPO, rozmowa dotyczyła bezpośredniego zbierania 16.257 MHz na MCU.

Teraz sytuacja jest nieco inna - odkryłem (dzięki uprzejmości grupy) że
istnieje coś takiego jak "rejestr przesuwający", i wykorzystując ten cud
technologiczny jestem w stanie zbić transmisję monobitową 16 MHz do
zaledwie 2 Mhz (x8 bitów). A z punktu widzenia 2 MHz, to taktowanie
ATMegi48 spełnia warunek "parę razy szybsze" (20 MHz). Pytanie ile
instrukcji potrzeba aby odczytać bajt z rejestru, i ten sam bajt wrzucić
natychmiast do SPI. Nie sprawdzałem, ale domniemywam że pewnie ze 3 albo
4. Aby uzyskać dokładny timing myślałem jeszcze by podpiąć moje 16.257
MHz do dzielnika częstotliwości 1:8, i wynik wyprowadzić na przerwanie
ATMegi - wtedy musiałbym tylko odczytać 1 piksel w ramach obsługi
przerwania, i dokładność zapewniona. Aczkolwiek nic nie wiem o ATMedze,
więc może istnieją jakieś twarde limitacje związane z przerwaniami, to
się okaże w praniu.


Da się, i to temat który już oglądałem. Brzmi niby zachęcająco, bo boot
trwa sekundę lub dwie, ale problem w tym że to wymaga napisanie swoich
sterowników do GPU i SPI, a to już znów podwyższa poprzeczkę.

Ostatecznie, przy moim obecnym schemacie nie mam już potrzeby aby RPi
działało ponadprzeciętnie szybko, bo i tak żadnego bit bangingu nie ma
uprawiać, tylko czytać po kolei to co przychodzi via buforowane SPI i
wrzucać na ekran. Nie oczekuję 100% frame rate, jeśli od czasu do czasu
zgubi się kilka ramek to dla mnie bez znaczenia.


Za to tanie a datasheet twierdzi że mogę oczekiwać gwarantowanego
działania do 30 MHz (w zależności od serii do 100 MHz) - czyli więcej
niż potrzebuję.

Mateusz

Fri May 20, 2016 2:11 pm   

On 20/05/2016 15:39, Jarosław Sokołowski wrote:

Hola hola, pomysł spoko, ale to mnie znów kieruje na tor łapania 16.257
MHz bezpośrednio na MCU, a to mi wcale nie po drodze Idea zbijania
częstotliwości do 2 MHz bardzo mi się spodobała...

Policzyłem że każdy piksel wychodzący z MDA trwa 61.5 ns - czyli tyle
czasu ma rejestr 74HC595 żeby przechwycić stan linii. Sam 74HC595
taktowany jest oscylatorem 16.257 MHz, więc wszystko sprowadza się do
problemu "jak sprawić aby mój oscylator zaczął drgać w tym samym
momencie co oscylator po stronie MDA?"... I to jak sądzę jest to co
nazywasz fazą. Mógłbym np. włączyć mój oscylator w momence kiedy znika
mi HSYNC, ale z tego co czytam w datahseetach oscylatorów, ich czas
włączenia i stabilizacji liczy się w milisekundach, więc odpada.
Dlaczego nikt nie wpadł na to by na jednym z pinów MDA wyprowadzić stan
oscylatora karty? Teraz niestety jest trochę za późno (o 30 lat).

Zaczynam rozumieć problem. Jak to rozwiązują same monitory? Wszak one w
jakiś sposób muszą dopasować się do karty?

Mateusz

Fri May 20, 2016 2:13 pm   

W dniu 2016-05-20 o 15:45, Mateusz Viste pisze:

Ale chodzi o to, żeby ten rejestr puścić parę razy szybciej. W kablu nie
masz prostych zboczy. Na wyjściu masz tak naprawdę impulsy trochę
rozmyte. Może się okazać, że przy próbkowaniu z tym samym zegarem co
wejście będzie kłopot z łapaniem niektórych pikseli. Próbkując kilka
razy częściej masz dużo większą szansę na poprawną detekcję. No i nie
musisz mieć wtedy dokładnej częstotliwości.
A jak nic o atmedze nie wiesz, to bierz się od razu za atxmegę. Podobny,
a równocześnie zupełnie inny układ. Dużo więcej może i szybszy jest.
Jedyny minus to 3.3V, ale z tym idzie zadziałać. Nie to, że na pewno
potrzebujesz, ale po co uczyć się starego układu? A puścisz go dwa razy
szybciej niż zwykłą atmegę.


Gorzej jak uda Ci się uzyskać efekt mory. Może być męczący.


No więc o to chodzi, żeby się nie bawić w HC tylko wziąć np VHC. Różnica
w cenie jest....

Pozdrawiam

DD

Fri May 20, 2016 2:17 pm   

W dniu czwartek, 19 maja 2016 18:05:32 UTC+2 użytkownik Mateusz Viste napisał:

To zupełnie inny mechanizm.

malina moze robic za nadajnik fm (i to w naszym aktualnym FM czyli również okolice 100MHz).
Ale to nie w ta stronę