Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>>>>> Tym niemniej - EGA cyfrowa, CGA cyfrowa, MDA/Hercules cyfrowy
>>>>>> - chcesz wyskoczyc z analogowa karta do wspolpracy z monitorami
>>>>>> EGA i Hercules ?
>>>>> Gdybym chiał zrobić dobrze i tanio, to tak, chciałbym.
>>>> No, czy to by bylo tanio ... jakbys zrobil dobrze, to by z tego
>>>> wyszla SVGA i wymagala monitora SVGA :-)
>>> Na pewno taniej niż prowadzeniue ośmiu drutów w celu pokazania
>>> 256 poziomów jasności. Zdarzały sie i takie pomysły. A tu skoro
>>> monitor MDA potrafił pokazać więcej niż trzy poziomy jasności,
>>> to czemu z tego nie skorzystać tworząc lepszą kartę?
>
>> a) szybkie DAC byly widac kiepskie i drogie, skoro tak nie zrobiono
>> wczesniej,

>Kilkubitowy DAC, to parę oporników. Szybki jest. I niespecjalnie
>drogi.
>Więc nie to. Pepesza, która potrafi wystrzelić tyle bitów w krótkim
>czasie była droga.

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

>> b) czesc monitorow tego nie pokaze, i bedzie jeszcze gorzej niz
>> przy 2-bit sygnale.
>Dzisiaj to by była zaleta -- można ludziom sprzedać nowy monitor.
>Ale wtedy rozwój wyglądał tak, że dopasowywano się do istniejących
>rzeczy.

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

>Działało z większością dostępnych monitorów MDA/HGC -- więc
>był powód do uciechy. Te wczesne standardy (CGA, MDA) projektowano
>tak, by można było skorzystać z seryjnie produkowanych kineskopów
>i układów odchylania telewizorów.

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.

do góry

Pan J.F. napisał:

>>> a) szybkie DAC byly widac kiepskie i drogie, skoro tak nie zrobiono
>>> wczesniej,
>> Kilkubitowy DAC, to parę oporników. Szybki jest. I niespecjalnie
>> drogi. Więc nie to. Pepesza, która potrafi wystrzelić tyle bitów
>> w krótkim czasie była droga.
>
> Teoretycznie sie z Toba zgadzam, a jednak IBM w owych czasach robil
> inaczej. A VGA byly drogie (6 bitow to juz nie takie pare) ..

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.

>>> b) czesc monitorow tego nie pokaze, i bedzie jeszcze gorzej niz
>>> przy 2-bit sygnale.
>> Dzisiaj to by była zaleta -- można ludziom sprzedać nowy monitor.
>> Ale wtedy rozwój wyglądał tak, że dopasowywano się do istniejących
>> rzeczy.
>
> Dzis tez tak zle nie jest, trzeba byc duzym, aby przepchnac nowy
> "standard".

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.

>> Działało z większością dostępnych monitorów MDA/HGC -- więc
>> był powód do uciechy. Te wczesne standardy (CGA, MDA) projektowano
>> tak, by można było skorzystać z seryjnie produkowanych kineskopów
>> i układów odchylania telewizorów.
>
> Trudno aby zaczeli od stawiania laboratorium LCD.
> Zauwaz, ze czestotliwosci jednak nieco inne - i nie wahali sie ich
> zmieniac coraz bardziej.

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

--
Jarek

do góry

On 19/05/2016 12:48, J.F. wrote:
>> No wlasnie nie bardzo.
>> Z tego co czytalem to machanie portami GPIO w malinie to okolice
>> 1.2MHz ludzie osiągali...

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 :)

> Co 8 bitow odczytujesz rejestr, zapamietujesz jako caly bajt ... po czym
> caly bajt zapisujesz do drugiego rejestru, ktory wypuszcza po 8 bitow.
>
> I masz 8x wiecej czasu.

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

do góry

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

do góry

> 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.


jp

do góry

W dniu 2016-05-19 o 18:05, Mateusz Viste pisze:
> 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).

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

--
AWa.

do góry

Pan Andrzej W. napisał:

>> 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).
>
> Na na schemacie, który ktoś tu podrzucił widziałem 16,xxx MHz
> w MDA, oba zegary Ci się rozjadą.

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

do góry

On 20/05/2016 12:12, Andrzej W. wrote:
> 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.

Mateusz

do góry

W dniu czwartek, 19 maja 2016 18:05:32 UTC+2 użytkownik Mateusz Viste napisał:
> On 19/05/2016 12:48, J.F. wrote:
> >> No wlasnie nie bardzo.
> >> Z tego co czytalem to machanie portami GPIO w malinie to okolice
> >> 1.2MHz ludzie osiągali...
>
> 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 :)
>
Ale tam jest generator pwm.
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ę :)

do góry

W dniu czwartek, 19 maja 2016 23:43:54 UTC+2 użytkownik jacek pozniak napisał:
> > 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.
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 :)

do góry