Do pewnego prostego projektu potrzebuję biblioteki, która pozwoli mi na
wysyłanie tekstu na ekran telewizora, przez najzwyklejsze wyjście
kompozytowe. Nie ma wielkich wymagań co do jakości obrazu. Wystarczy
biały tekst na czarnym tle, bez odcieni szarości, rozdzielczość na
poziomie C64. Byle tylko jitter nie rzucał się w oczy.

Kod samej aplikacji nie będzie zbyt rozbudowany, tak naprawdę chodzi o
wykonywanie paru prostych operacji i wyrzucenie wyniku na ekran TV. Nie
będzie konieczne wykorzystywanie peryferiów, może poza jednym
przerwaniem zewnętrznym.

Pobieżnie przeszukałem Internet i widzę, że paru ludzi już tego
próbowało, uzyskując całkiem imponujące efekty na mocnych procesorach w
stylu STM32 albo PIC32. Mi jednak zależy na minimalistycznej wersji,
zastanawiam się więc jaki MCU będzie absolutnym minimum.

Znalazłem parę projektów napisanych na AVR albo ośmiobitowe PIC, ale:
1) Zostały napisane jeszcze na mocno przestarzałą wersję avr-gcc i nie
kompilują się, wywalając cała masę błędów i ostrzeżeń. Dostosowanie kodu
do obecnych standardów wymagałoby trochę zachodu.
2) Zostały one napisane na jeden ze starych kompilatorów dla PIC i nie
kompilują się pod XC8. Czyli ten sam problem, co powyżej.
3) Kod został napisany w asemblerze PIC, tak więc dostosowanie tego do
własnych potrzeb nie będzie łatwe.

Ktoś zna jakieś gotowe rozwiązanie, nie licząc Arduino? ;)
Potrzebuję tylko zestawu najbardziej podstawowych funkcji do pracy w
trybie tekstowym: init(), clearscreen(), gotoxy() oraz putc().

do góry

W dniu 2018-09-21 o 10:00, Atlantis pisze:
> Mi jednak zależy na minimalistycznej wersji,
> zastanawiam się więc jaki MCU będzie absolutnym minimum.
>

Chodzi mi po głowie, że w 1988r brat napisał rs232 na 8748 poświęcając
8,5 rozkazu na 1 bit, aby uzyskać prędkość 57600. Z tego mi wychodzi, że
rozkaz zajmował 2us czego już zupełnie nie kojarzę.
Te 0,5 rozkazu było specjalnie wstawiane (jeden bit 8 rozkazów, kolejny
9 rozkazów) aby uzyskać typową prędkość. Bez tej zabawy może bit
mieściłby się w 6 rozkazach (nigdy nie pisałem w assemblerze - nie wiem).

Częstotliwość odchylania poziomego w klasycznym TV jest rzędu 30kHz
Czyli okres rzędu 33us. Załóżmy, że z tego 30us obszar widoczny, a 3us
na powrót.
Nie wiem jaka była rozdzielczość C64 - strzelam 300 (aby się łatwo
liczyło) pxl na szerokość ekranu. Czyli 30/300 = 100ns na pixel.
Z tego wychodzi że trzeba wystawiać kolejne bity z prędkością 10MHz.
Jeśli wystawienie bitu wymaga 6 rozkazów to procek wykonujący 1 rozkaz
na takt zegara musi chodzić z zgarem 60MHz.

Tak mi wychodzi przy założeniu realizacji zagadnienia całkiem
softwareowo. Obecne procki mają różne peryferia dające się zapewne jakoś
wykorzystać. Wystarczyło by coś co wysyła bajt szeregowo (z zegarem
10MHz) i program już nie musi zajmować się każdym bitem a dopiero
bajtem. A jak miałby coś co pozwoli wypluć serię bajtów z pamięci to
pozostaje zajmowanie się dopiero całą linijką - już nuda.

P.G.

do góry

W dniu 2018-09-21 o 10:00, Atlantis pisze:
> Do pewnego prostego projektu potrzebuję biblioteki, która pozwoli mi na
> wysyłanie tekstu na ekran telewizora, przez najzwyklejsze wyjście
> kompozytowe. Nie ma wielkich wymagań co do jakości obrazu.

atxmega Ci to zrobi, w ksiązce
https://helion.pl/ksiazki/avr-uklady-peryferyjne-tom
asz-francuz,avrukp.htm
jest w rozdziale 33 generowanie obrazu video, kod jest na stronie do
ściągnięcia.

--
Pozdr
Janusz

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:po2d50$1s6$1$P...@n...chmurka.ne
t...
W dniu 2018-09-21 o 10:00, Atlantis pisze:
>> Mi jednak zależy na minimalistycznej wersji,
>> zastanawiam się więc jaki MCU będzie absolutnym minimum.

>Chodzi mi po głowie, że w 1988r brat napisał rs232 na 8748
>poświęcając 8,5 rozkazu na 1 bit, aby uzyskać prędkość 57600. Z tego
>mi wychodzi, że rozkaz zajmował 2us czego już zupełnie nie kojarzę.

Jesli 8051 zajmowal 1us, to czemu by wczesniej nie mial trwac 2us.

>Częstotliwość odchylania poziomego w klasycznym TV jest rzędu 30kHz

15625

>Czyli okres rzędu 33us. Załóżmy, że z tego 30us obszar widoczny, a
>3us na powrót.

okres 64us, na linie ok 50us

>Nie wiem jaka była rozdzielczość C64 - strzelam 300 (aby się łatwo
>liczyło) pxl na szerokość ekranu. Czyli 30/300 = 100ns na pixel.
>Z tego wychodzi że trzeba wystawiać kolejne bity z prędkością 10MHz.
>Jeśli wystawienie bitu wymaga 6 rozkazów to procek wykonujący 1
>rozkaz na takt zegara musi chodzić z zgarem 60MHz.

Piotrze, ale teraz mamy szybkie procki

http://belogic.com/uzebox/index.asp
https://people.ece.cornell.edu/land/courses/ece4760/
FinalProjects/f2014/jn286_cy255/jn286_cy255/index.ht
ml

Nie ma to moze az 300 pikseli w poziomie, ale efekty i tak sa
imponujace.

>Tak mi wychodzi przy założeniu realizacji zagadnienia całkiem
>softwareowo. Obecne procki mają różne peryferia dające się zapewne
>jakoś wykorzystać. Wystarczyło by coś co wysyła bajt szeregowo (z
>zegarem 10MHz) i program już nie musi zajmować się każdym bitem a
>dopiero bajtem.

Typowy rejestr szeregowy ... tylko zegar trzeba dobrac, no i jakies
DMA by sie przydalo, albo FIFO ...

No i ciagle mozna jeszcze odtworzyc ZX81 :-)

J.

do góry

Hello Piotr,

Friday, September 21, 2018, 11:20:37 AM, you wrote:

> W dniu 2018-09-21 o 10:00, Atlantis pisze:
>> Mi jednak zależy na minimalistycznej wersji,
>> zastanawiam się więc jaki MCU będzie absolutnym minimum.
>>

> Chodzi mi po głowie, że w 1988r brat napisał rs232 na 8748 poświęcając
> 8,5 rozkazu na 1 bit, aby uzyskać prędkość 57600. Z tego mi wychodzi, że
> rozkaz zajmował 2us czego już zupełnie nie kojarzę.
> Te 0,5 rozkazu było specjalnie wstawiane (jeden bit 8 rozkazów, kolejny
> 9 rozkazów) aby uzyskać typową prędkość. Bez tej zabawy może bit
> mieściłby się w 6 rozkazach (nigdy nie pisałem w assemblerze - nie wiem).

> Częstotliwość odchylania poziomego w klasycznym TV jest rzędu 30kHz

15625 Hz

> Czyli okres rzędu 33us.

64 us

> Załóżmy, że z tego 30us obszar widoczny,

56 us

> a 3us na powrót.

8 us

> Nie wiem jaka była rozdzielczość C64 - strzelam 300 (aby się łatwo
> liczyło) pxl na szerokość ekranu. Czyli 30/300 = 100ns na pixel.
> Z tego wychodzi że trzeba wystawiać kolejne bity z prędkością 10MHz.

Podziel przez 2.

> Jeśli wystawienie bitu wymaga 6 rozkazów to procek wykonujący 1 rozkaz
> na takt zegara musi chodzić z zgarem 60MHz.

Wystawia się bajt a bity załatwia rejestr przesuwny...

> Tak mi wychodzi przy założeniu realizacji zagadnienia całkiem
> softwareowo. Obecne procki mają różne peryferia dające się zapewne jakoś
> wykorzystać. Wystarczyło by coś co wysyła bajt szeregowo (z zegarem
> 10MHz) i program już nie musi zajmować się każdym bitem a dopiero
> bajtem. A jak miałby coś co pozwoli wypluć serię bajtów z pamięci to
> pozostaje zajmowanie się dopiero całą linijką - już nuda.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

W dniu 2018-09-21 o 12:24, RoMan Mandziejewicz pisze:
>
>> Częstotliwość odchylania poziomego w klasycznym TV jest rzędu 30kHz
>
> 15625 Hz

Nie pamiętałem. Wpisałem w Google i pierwsze trafienie podało mi zakres
(zapewne jakiegoś monitora) od 30kHz w górę. A że było zgodne z tym co
po głowie chodziło to nie sprawdzałem dokładniej

Faktycznie. Kiedyś 15625 było znaną mi liczbą.

>
>> Czyli okres rzędu 33us.
>
> 64 us
>
>> Załóżmy, że z tego 30us obszar widoczny,
>
> 56 us
>
>> a 3us na powrót.
>
> 8 us
>
>> Nie wiem jaka była rozdzielczość C64 - strzelam 300 (aby się łatwo
>> liczyło) pxl na szerokość ekranu. Czyli 30/300 = 100ns na pixel.
>> Z tego wychodzi że trzeba wystawiać kolejne bity z prędkością 10MHz.
>
> Podziel przez 2.

OK. Ale w takim przypadku zwiększyłbym też liczbę pixli na ekran do 600
(bo 300 wydaje mi się zaniżone) i znów wyjdzie 10MHz.

>> Jeśli wystawienie bitu wymaga 6 rozkazów to procek wykonujący 1 rozkaz
>> na takt zegara musi chodzić z zgarem 60MHz.
>
> Wystawia się bajt a bity załatwia rejestr przesuwny...
>

O tym piszę dalej. W 8748 chyba tego nie mieliśmy bo zapewne jakoś byśmy
wykorzystali. Tyle, że dla RS232 trzeba by mieć bufor 10 bitów.

>> Tak mi wychodzi przy założeniu realizacji zagadnienia całkiem
>> softwareowo. Obecne procki mają różne peryferia dające się zapewne jakoś
>> wykorzystać. Wystarczyło by coś co wysyła bajt szeregowo (z zegarem
>> 10MHz) i program już nie musi zajmować się każdym bitem a dopiero
>> bajtem. A jak miałby coś co pozwoli wypluć serię bajtów z pamięci to
>> pozostaje zajmowanie się dopiero całą linijką - już nuda.

P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:po2hl9$3mu$1$P...@n...chmurka.ne
t...
W dniu 2018-09-21 o 12:24, RoMan Mandziejewicz pisze:
>> Częstotliwość odchylania poziomego w klasycznym TV jest rzędu 30kHz
>> 15625 Hz

>Nie pamiętałem. Wpisałem w Google i pierwsze trafienie podało mi
>zakres (zapewne jakiegoś monitora) od 30kHz w górę. A że było zgodne
>z tym co po głowie chodziło to nie sprawdzałem dokładniej

Bo sie kiedys monitory komputerowe urwaly od TV.
Najpierw byla EGA, potem VGA i SVGA mialy 31-35 kHz, potem to juz
stracilem rachube :-)

>>> Nie wiem jaka była rozdzielczość C64 - strzelam 300 (aby się łatwo
>>> liczyło) pxl na szerokość ekranu. Czyli 30/300 = 100ns na pixel.
>>> Z tego wychodzi że trzeba wystawiać kolejne bity z prędkością
>>> 10MHz.
>
>> Podziel przez 2.

>OK. Ale w takim przypadku zwiększyłbym też liczbę pixli na ekran do
>600 (bo 300 wydaje mi się zaniżone) i znów wyjdzie 10MHz.

Spectrum mialo 256. Fakt, ze duze marginesy.

Atari 8 bit ... hm, czy nie ~7MHz zegara pikslowego, bo sie nakladalo
na podnosna koloru ...

Zalezy jaki tekst chcemy - ma byc duzo literek, czy duze literki :-)

J.

do góry

W dniu 2018-09-21 o 12:23, J.F. pisze:
>> Chodzi mi po głowie, że w 1988r brat napisał rs232 na 8748 poświęcając
>> 8,5 rozkazu na 1 bit, aby uzyskać prędkość 57600. Z tego mi wychodzi,
>> że rozkaz zajmował 2us czego już zupełnie nie kojarzę.
>
> Jesli 8051 zajmowal 1us, to czemu by wczesniej nie mial trwac 2us.

Ja nie neguję, że mógł. Tylko napisałem, że nie kojarzę. Jakby ktoś mnie
zapytał ile trwał rozkaz w 8748 to bym chyba sądził, że 1us. Ale może
dawaliśmy wolniejszy od max kwarc. Nie pamiętam, a szukać mi się nie chce.

> Piotrze, ale teraz mamy szybkie procki

Pytanie było:
"Mi jednak zależy na minimalistycznej wersji,
zastanawiam się więc jaki MCU będzie absolutnym minimum."
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:po2iip$449$1$P...@n...chmurka.ne
t...
W dniu 2018-09-21 o 12:23, J.F. pisze:
>> Piotrze, ale teraz mamy szybkie procki

>Pytanie było:
>"Mi jednak zależy na minimalistycznej wersji,
>zastanawiam się więc jaki MCU będzie absolutnym minimum."

Ale ja tez nie proponuje jakis GHz, skoro wystarcza 20MHz.
Przyklady miales.

Czasy 8051 sie skonczyly :-)
Choc i na nim z wykorzystaniem rejestru szeregowego chyba by sie dalo
:-)




J.

do góry

Nie jest to trywialne, nawet jeśli chcesz tylko czarno biały tekst.
Wszelkie rozwiązania na słabych CPU wymagają wsparcia sprzętowego albo
stosowania różnych trików, które nie ułatwiają programowania głównego wątku
programu.

jp


Atlantis wrote:

> Do pewnego prostego projektu potrzebuję biblioteki, która pozwoli mi na
> wysyłanie tekstu na ekran telewizora, przez najzwyklejsze wyjście
> kompozytowe. Nie ma wielkich wymagań co do jakości obrazu. Wystarczy
> biały tekst na czarnym tle, bez odcieni szarości, rozdzielczość na
> poziomie C64. Byle tylko jitter nie rzucał się w oczy.
>
> Kod samej aplikacji nie będzie zbyt rozbudowany, tak naprawdę chodzi o
> wykonywanie paru prostych operacji i wyrzucenie wyniku na ekran TV. Nie
> będzie konieczne wykorzystywanie peryferiów, może poza jednym
> przerwaniem zewnętrznym.
>
> Pobieżnie przeszukałem Internet i widzę, że paru ludzi już tego
> próbowało, uzyskując całkiem imponujące efekty na mocnych procesorach w
> stylu STM32 albo PIC32. Mi jednak zależy na minimalistycznej wersji,
> zastanawiam się więc jaki MCU będzie absolutnym minimum.
>
> Znalazłem parę projektów napisanych na AVR albo ośmiobitowe PIC, ale:
> 1) Zostały napisane jeszcze na mocno przestarzałą wersję avr-gcc i nie
> kompilują się, wywalając cała masę błędów i ostrzeżeń. Dostosowanie kodu
> do obecnych standardów wymagałoby trochę zachodu.
> 2) Zostały one napisane na jeden ze starych kompilatorów dla PIC i nie
> kompilują się pod XC8. Czyli ten sam problem, co powyżej.
> 3) Kod został napisany w asemblerze PIC, tak więc dostosowanie tego do
> własnych potrzeb nie będzie łatwe.
>
> Ktoś zna jakieś gotowe rozwiązanie, nie licząc Arduino? ;)
> Potrzebuję tylko zestawu najbardziej podstawowych funkcji do pracy w
> trybie tekstowym: init(), clearscreen(), gotoxy() oraz putc().

--
jp

www.flowservice.pl
www.flowsystem.pl

do góry