NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak podłączyć komputer z wyjściem MDA do nowoczesnego monitora VGA/HDMI?
Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next
Dariusz Dorochowicz
Guest
Guest
Fri May 20, 2016 2:17 pm
W dniu 2016-05-20 o 15:39, Jarosław Sokołowski pisze:
Quote:
Pan Dariusz Dorochowicz napisał:
Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz
w MDA, oba zegary Ci się rozjadą.
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.
Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar,
wtedy niedokładności przestają mieć aż takie znaczenie.
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ł.
Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz
w MDA, oba zegary Ci się rozjadą.
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.
Bodaj Waldek już o tym pisał: trzeba dać parę razy szybszy zegar,
wtedy niedokładności przestają mieć aż takie znaczenie.
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ł.
No i do tego służy właśnie próbkowanie kilka razy szybciej. To
przesunięcie czasowe nie jest niczym innym przecież.
I niekoniecznie aż 8 razy, w sumie to niekoniecznie nawet musi być
całkowity mnożnik. Kwestia jak bardzo chce się bawić w wymyślanie
algorytmów.
Pozdrawiam
DD
Guest
Fri May 20, 2016 2:19 pm
W dniu czwartek, 19 maja 2016 23:43:54 UTC+2 użytkownik jacek pozniak napisał:
Quote:
Czy powyższa wypowiedź ma jakikolwiek sens, czy też rozmawiam całkiem od
rzeczy?
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.
Bez przesady.
rzeczy?
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.
Bez przesady.
Starczy te bajty wypchac gdzieś gdzie podepniemy się przeglądarka i wczytywac będziemy bitmape.
I tu jedna malina sampluje (pewnie dropując niektóre ramki) a druga montuje z danych bmp/jpg i wystawia przez apache...
Tyle że problem bedzie z tym złapaniem, zmontowaniem bitmapy i jej oddaniu do zaserwowania...
No, w sumie teraz tylko zacząć próby
Guest
Fri May 20, 2016 2:22 pm
W dniu czwartek, 19 maja 2016 19:03:04 UTC+2 użytkownik Mateusz Viste napisał:
Quote:
On 19/05/2016 18:05, Mateusz Viste wrote:
wyprowadzam wtedy 8 linii do ATtiny 2313, i tam czytam bajt po bajcie
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
wyprowadzam wtedy 8 linii do ATtiny 2313, i tam czytam bajt po bajcie
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
Zacznij od razu od płytek uruchomieniowych atmega lub xmega.
Kosztowac będzie nieduzo:
http://allegro.pl/modul-prototypowy-x3-dil64-atxmega-xmega-128a3u-au-i6061007147.html
http://allegro.pl/leon-modul-x3-dil64-premium-xmega-atxmega-avr-i6008470217..html
plus jakies dodatkowe komponenty. Zmiescisz sie w 200pln za wszystko (plus jakis breadboard, zasilacz itp.).
Nie ma co sie szczypać z attiny
Dariusz Dorochowicz
Guest
Guest
Fri May 20, 2016 2:46 pm
W dniu 2016-05-20 o 16:11, Mateusz Viste pisze:
Quote:
On 20/05/2016 15:39, Jarosław Sokołowski wrote:
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
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?
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
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?
Nie. Monitory muszą się dostosować do użyszkodnika (tak naprawdę do
karty też, ale na innym poziomie). Sprawę załatwia się ramką wokół
wyświetlanego obrazu, potencjometrami do regulacji w pionie i
poziomie... Monitorowi tak naprawdę lata - on musi się zsynchronizować z
kartą na impulsach pionu i poziomu, a potem mu to wisi czy coś będzie
szybciej czy wolniej. Monitor CRT nie wyświetla pikseli. No, w kolorowym
można jeszcze pod piksele jakoś podciągnąć, ale też działa to trochę
inaczej.
Co innego LCD, dlatego są z nimi cyrki typu łapanie fazy jak "zasilasz"
go z VGA. W CRT przy przesunięciu fazy jedyne co się dzieje, to przesuwa
się obraz. W LCD ... no właśnie o tym pisałem, że warto nadpróbkować.
Pozdrawiam
DD
JarosĹaw SokoĹowski
Guest
Guest
Fri May 20, 2016 2:56 pm
Pan Mateusz Viste napisał:
Quote:
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
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...
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
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...
Rejestry przesuwające, bo o tej idei teraz mowa, robi się też dłuższe niż
osiem bitów. Nie doradzę konkretnego układu, bo tego nie praktykowałem,
ale być może da się znaleźć nawet scalony rejestr 1024-bitowy. Słowa do
guglania to "shift register", "serial-in", "parallel-out", "NNN-bit".
Quote:
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.
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.
Nie ma potrzeby włączania za każdym razem motoru, wystarczy puścić
sprzęgło. Czyli otworzyć bramkę puszczającą takty zegara dalej. Zegar
może być N razy szybszy, a za nim zerowany dzielnik przez N -- wtedy
faza się zsynchronizuje. Z tym że w stabilność impulsów synchronizacji
poniżej szerokości piksela, to ja nie mam wiary.
Quote:
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).
oscylatora karty? Teraz niestety jest trochę za późno (o 30 lat).
Nie wiem czy o tym napisałem, czy tylko pomyślałem. Gdyby wyprowadzić
zegar karty na złącze, to by było dużo łatwiej. No ale znów ten
konserwator zabytków, drań jeden i służbista. A dlaczego nie zrobiono
tego 30 lat temu? Nikt nie podejrzewł, że będzie komuś potrzebne.
Quote:
Zaczynam rozumieć problem. Jak to rozwiązują same monitory? Wszak one
w jakiś sposób muszą dopasować się do karty?
w jakiś sposób muszą dopasować się do karty?
Na ten tor też próbowałem skłonić. Scalone kontrolery paneli LCD pędzone
sygnałem VGA powinny dać radę po niewielkim przestrojeniu. Warto przejrzeć
dejtaszity. W końcu z czegoś te monitory MDA po 500 euro robią. Tam w sumie
chodzi głównie o takie rejestry przesuwne, w dużej mierze robione sprzętowo.
--
Jarek
J.F.
Guest
Guest
Fri May 20, 2016 4:35 pm
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnju9d8.4dg.jaros@falcon.lasek.waw.pl...
Pan Mateusz Viste napisał:
Quote:
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
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...
Rejestry przesuwające, bo o tej idei teraz mowa, robi się też dłuższe
niż
osiem bitów.
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
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...
Rejestry przesuwające, bo o tej idei teraz mowa, robi się też dłuższe
niż
osiem bitów.
Jesli kolega chce do to uC wprowadzic, to wiekszy nie ma sensu.
Chyba, ze ma 16 czy 32 bitowa magistrale do dyspozycji.
Predzej tu sie jakies bajtowe FIFO przyda.
J.
J.F.
Guest
Guest
Fri May 20, 2016 4:48 pm
Użytkownik "Mateusz Viste" napisał w wiadomości grup
On 20/05/2016 15:39, Jarosław Sokołowski wrote:
Quote:
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
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...
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
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...
Chcesz to zrobic bardzo dobrze, czy byle jak, byle dzialalo ?
Jak bedziesz probkowal 2-3 razy szybciej, to efekt na ekranie bedzie
IMO niezly, a czasu na przetwarzanie nadal 3-4 razy wiecej.
Jak bedziesz probkowal nieco szybciej, np 17MHz, to niektore
piksele/linie pionowe sie pogrubia - i z tym mozna zyc.
Gorzej, ze moga byc poszarpane ... z tym tez mozna zyc.
Choc w szczegolnym przypadku moga chyba cos zgubic, wiec chyba lepiej
z 1.5x raza szybciej.
Jesli ma byc lepiej, to trzeba PLL, i to ambitniejsze, bo trzeba sie
zsychronizowac ze zmiennym sygnalem.
Quote:
Zaczynam rozumieć problem. Jak to rozwiązują same monitory? Wszak one
w jakiś sposób muszą dopasować się do karty?
w jakiś sposób muszą dopasować się do karty?
Oprocz tego PLL i automatycznego rozpoznawania ilosci cykli na linie
miewaja ustawienia w menu pozwalajace skorygowac czestotliwosc/podzial
i faze.
Szczesliwie - oscylator w MDA jest jeden i w miare stabilny, trzeba
tylko jakos do niego dostroic, a mamy na to multum czasu i cykli, bo
wszak jak monitor przez sekunde bedzie czarny, to klient nawet sie nie
zdazy oburzyc :-)
J.
J.F.
Guest
Guest
Sat May 21, 2016 7:02 am
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
J.
Mateusz Viste
Guest
Guest
Sat May 21, 2016 2:40 pm
On 20/05/2016 16:56, Jarosław Sokołowski wrote:
Quote:
Nie ma potrzeby włączania za każdym razem motoru, wystarczy puścić
sprzęgło.
sprzęgło.
Sprytnie! Tylko gdzie ja znajdę oscylator na wielokrotność 16.257 MHz ?
Quote:
Nie wiem czy o tym napisałem, czy tylko pomyślałem. Gdyby wyprowadzić
zegar karty na złącze, to by było dużo łatwiej. No ale znów ten
konserwator zabytków, drań jeden i służbista.
zegar karty na złącze, to by było dużo łatwiej. No ale znów ten
konserwator zabytków, drań jeden i służbista.
Niestety, pan Heniu faktycznie nie dopuści. Taki dostał prikaz.
Quote:
Na ten tor też próbowałem skłonić. Scalone kontrolery paneli LCD pędzone
sygnałem VGA powinny dać radę po niewielkim przestrojeniu.
sygnałem VGA powinny dać radę po niewielkim przestrojeniu.
Dość długo zajęło mi znalezienie odpowiednich zaklęć by wyszukiwarka
zrozumiała czego szukam - najwyraźniej chodzi o "graphic digitizer".
Znalazłem dwa takie cuda u TI:
http://www.ti.com/lit/ds/symlink/tvp7002.pdf
http://www.ti.com/lit/ds/symlink/tvp70025i.pdf
Oczywiście żaden z datasheetów nie mówi wprost o kompatybilności z MDA,
HGC, czy czymkolwiek czego mógłbym się chwycić, ale oba podają
interesujące zakresy pixel clock.. Szczególnie tvp70025i:
"9-MHz to 90-MHz Pixel Clock Generation From HSYNC Input"
Na ibeju widzę można dostać taki magiczny chip za bardzo rozsądne
pieniądze (ok. 10 Eur włącznie z przesyłką). Inna sprawa że uruchomienie
tego wygląda przerażająco: musiałbym dodać MCU który zaprogramuje przy
starcie rejestry tego TVP za pomocą I
Mateusz Viste
Guest
Guest
Sat May 21, 2016 4:13 pm
On 21/05/2016 09:02, J.F. wrote:
Quote:
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Co ciekawe, znalazłem skan herculesowego klona na którym kwarc jest...
równiutko 16 MHz, zamiast przykazanych 16.257 MHz.
http://i65.tinypic.com/2lcuzwh.jpg
Mateusz
J.F.
Guest
Guest
Sat May 21, 2016 4:34 pm
Dnia Sat, 21 May 2016 18:13:52 +0200, Mateusz Viste napisał(a):
Quote:
On 21/05/2016 09:02, J.F. wrote:
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Hm, dziwne - o ile pamietam, to EGA miala cos 21kHz odchylania
poziomego.
Ale to nie tlumaczy do czego ten kwarc :-)
Quote:
Co ciekawe, znalazłem skan herculesowego klona na którym kwarc jest...
równiutko 16 MHz, zamiast przykazanych 16.257 MHz.
http://i65.tinypic.com/2lcuzwh.jpg
równiutko 16 MHz, zamiast przykazanych 16.257 MHz.
http://i65.tinypic.com/2lcuzwh.jpg
To nawet nie jest 2% roznicy, monitor sie dopasuje :-)
J.
RoMan Mandziejewicz
Guest
Guest
Sat May 21, 2016 5:00 pm
Hello J.F.,
Saturday, May 21, 2016, 6:34:00 PM, you wrote:
Quote:
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Hm, dziwne - o ile pamietam, to EGA miala cos 21kHz odchylania
poziomego.
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Hm, dziwne - o ile pamietam, to EGA miala cos 21kHz odchylania
poziomego.
Ale miała tylko 640 a nie 720 punktów.
[...]
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)
JarosĹaw SokoĹowski
Guest
Guest
Sat May 21, 2016 5:55 pm
Pan Mateusz Viste napisał:
Quote:
Nie ma potrzeby włączania za każdym razem motoru, wystarczy puścić
sprzęgło.
Sprytnie! Tylko gdzie ja znajdę oscylator na wielokrotność 16.257 MHz ?
sprzęgło.
Sprytnie! Tylko gdzie ja znajdę oscylator na wielokrotność 16.257 MHz ?
Sprytne i przebiegłe. W pecetologii stosowanej już na etapie i486
opanowano technikę mnożenia częstotliwości -- zewnętrzny zegar
procesora ma ileś megaherców, a w środku wszystko mnożone jest
N razy. Ponadto ludzkość dorobiła się metod syntezy częstotkiwości.
Ot, biorąc choćby radiowy odbiornik FM kupiony za kilkanaście
złotych, można zeń wydłubać częstotliwość przestrajaną w zakresie
98,7-118,7 MHz. Nawet miernika nie potrzeba, bo radio pokazuje
cyferki na wyświetlaczu. A że wyjdzie dzielenie przez 7? Może
głupio wygląda, ale liczba jak każda inna.
Quote:
Nie wiem czy o tym napisałem, czy tylko pomyślałem. Gdyby wyprowadzić
zegar karty na złącze, to by było dużo łatwiej. No ale znów ten
konserwator zabytków, drań jeden i służbista.
Niestety, pan Heniu faktycznie nie dopuści. Taki dostał prikaz.
zegar karty na złącze, to by było dużo łatwiej. No ale znów ten
konserwator zabytków, drań jeden i służbista.
Niestety, pan Heniu faktycznie nie dopuści. Taki dostał prikaz.
Wiem. Nawet koperta na parapecie niczego nie zmieni. Służbista.
Quote:
Na ten tor też próbowałem skłonić. Scalone kontrolery paneli LCD
pędzone sygnałem VGA powinny dać radę po niewielkim przestrojeniu.
Dość długo zajęło mi znalezienie odpowiednich zaklęć by wyszukiwarka
zrozumiała czego szukam - najwyraźniej chodzi o "graphic digitizer".
Znalazłem dwa takie cuda u TI:
http://www.ti.com/lit/ds/symlink/tvp7002.pdf
http://www.ti.com/lit/ds/symlink/tvp70025i.pdf
Oczywiście żaden z datasheetów nie mówi wprost o kompatybilności z MDA,
HGC, czy czymkolwiek czego mógłbym się chwycić, ale oba podają
interesujące zakresy pixel clock.. Szczególnie tvp70025i:
"9-MHz to 90-MHz Pixel Clock Generation From HSYNC Input"
Na ibeju widzę można dostać taki magiczny chip za bardzo rozsądne
pieniądze (ok. 10 Eur włącznie z przesyłką). Inna sprawa że uruchomienie
tego wygląda przerażająco: musiałbym dodać MCU który zaprogramuje przy
starcie rejestry tego TVP za pomocą I2C, nie wspominając o tym że samo
polutowanie takiego 100-pinowego SMD może być dla mnie nie lada wyzwaniem
pędzone sygnałem VGA powinny dać radę po niewielkim przestrojeniu.
Dość długo zajęło mi znalezienie odpowiednich zaklęć by wyszukiwarka
zrozumiała czego szukam - najwyraźniej chodzi o "graphic digitizer".
Znalazłem dwa takie cuda u TI:
http://www.ti.com/lit/ds/symlink/tvp7002.pdf
http://www.ti.com/lit/ds/symlink/tvp70025i.pdf
Oczywiście żaden z datasheetów nie mówi wprost o kompatybilności z MDA,
HGC, czy czymkolwiek czego mógłbym się chwycić, ale oba podają
interesujące zakresy pixel clock.. Szczególnie tvp70025i:
"9-MHz to 90-MHz Pixel Clock Generation From HSYNC Input"
Na ibeju widzę można dostać taki magiczny chip za bardzo rozsądne
pieniądze (ok. 10 Eur włącznie z przesyłką). Inna sprawa że uruchomienie
tego wygląda przerażająco: musiałbym dodać MCU który zaprogramuje przy
starcie rejestry tego TVP za pomocą I2C, nie wspominając o tym że samo
polutowanie takiego 100-pinowego SMD może być dla mnie nie lada wyzwaniem
Nawet by mi do głowy nie przyszło, aby robić wszystko od zera. Raczej
o wzięcie gotowego monitora, zajrzenie co on tam wew środku ma, i ocenę
na podstawie dejtaszitów, czy by jakoś tego nie udało się dostosować do
potrzeb. Byle nie trafić na jakiś mocno zabytkowy monitor, bo pan Heniu...
--
Jarek
ACMM-033
Guest
Guest
Sun May 22, 2016 2:51 pm
Użytkownik "RoMan Mandziejewicz" <roman@pik-net.pl.invalid> napisał w
wiadomości news:514534047.20160521190009@pik-net.pl.invalid...
Quote:
Hello J.F.,
Saturday, May 21, 2016, 6:34:00 PM, you wrote:
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Hm, dziwne - o ile pamietam, to EGA miala cos 21kHz odchylania
poziomego.
Ale miała tylko 640 a nie 720 punktów.
Saturday, May 21, 2016, 6:34:00 PM, you wrote:
A propos - skad ten kwarc 16257.00 kHz ?
Do czego jeszcze ta czestotliwosc sluzyla ?
Wygląda na to że EGA też z tego korzystała:
https://upload.wikimedia.org/wikipedia/commons/6/6b/IBM_EGA_card.jpg
Hm, dziwne - o ile pamietam, to EGA miala cos 21kHz odchylania
poziomego.
Ale miała tylko 640 a nie 720 punktów.
Problem jakiś? Y też miała 350, a to, że X zamiast 720 będzie 640, raczej
zbytnio częstotliwości odchylania chyba nie zmieni (chyba, że obie
naraz...)? Po prostu kropki rzadziej będą... Wykorzystałem takie "zjawisko"
w zwykłym 15-calaku VGA kinolowym monitorze, który ma Y 1024... Dał się
popędzić z Y 1080 (ale z 1200 już nie) i nawet zbytnio nie płakał, a
zagęszczenia kropek z 1280 do 1920 nawet nie zauważył. Tylko obraz był taki
anamorficzny, ale to szczegół, przeżyję.
Pamiętam, że do kontroli zegarynki miałem w pracy starego 386, z kartą i
monitorem EGA. Którą dało się popędzić jako Hercules. Nawet karta i monitor
wydawały się być zadowolone z tego trybu, jedynie co, to ciut panoramicznie
to wyświetlały. Ale absolutnie stabilnie i wyraźnie.
--
Wyindywidualizowaliśmy się
z rozentuzjazmowanego tłumu
prestidigitatorów.
Mateusz Viste
Guest
Guest
Sun May 22, 2016 4:30 pm
On 20/05/2016 15:39, Jarosław Sokołowski wrote:
Quote:
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*.
ma 882 piksele, to przy dokładności lepszej od 0,1% da się bezbłędnie
ją spróbkować. Problemem jest *faza*.
Czytając datasheet TVP7002, i starając się zrozumieć jak mądrzy ludzie z
teksasu zdołali wymyślić taką magię, natknąłem się na zdanie:
"(...) contains a complete horizontal phase-locked loop (PLL) block to
generate a pixel clock from the HSYNC input."
Po kilkudziesięciu ślepych poszukiwaniach w czeluściach internetu
doszedłem do tego że istnieją sprytne chipy o nazwie "PLL Clock Multiplier".
Z tego co rozumiem, dysponując takim wynalazkiem byłbym w stanie
podłączyć mu HSYNC na wejście, ustawić mnożnik x882, i na wyjściu
otrzymałbym kopię zegara na karcie MDA (16.257 MHz lub 16 MHz), i to bez
potrzeby użycia swojego własnego kwarcu. Co więcej, zegar ten byłby w
fazie z tym po drugiej stronie (PLL), dzięki czemu odchodzą wszelakie
kombinacje z łapaniem wielokrotnie częstszych sampli i zgadywanie co
jest czym.
"Jedyny" znaleźć taki PLL Clock Multiplier z ustawialnym mnożnikiem
(do tej pory widziałem tylko takie z wybieranym mnożnikiem spośród
narzuconych kilku, a do tego z minimalnym f na wejściu rzędu kilku MHz..).
Mateusz
elektroda NewsGroups Forum Index - Elektronika Polska - Jak podłączyć komputer z wyjściem MDA do nowoczesnego monitora VGA/HDMI?