Mikrokomputer COBRA 1

PAMPKIN wrote:

Też tak sądzę, ale skoro powstało około 100 szt. PCB, to szukamy jeszcze pozostałych 60, minus te które są tutaj.

Doliczając moją Cobre, uruchomiona na oryginalnej płytce PCB, brakuje już tylko 59.
Pozdrawiam

Witam !

W obudowie Cobry 1 nie planowałem umieszczenia gniazda z jej wewnętrznymi sygnałami, zadowalając się jedynie jej uruchomieniem.
Po pewnym czasie doszedłem do wniosku, że poprzez to gniazdo będzie można dokonać wielu rozszerzeń.
Wzorując się na gnieździe z ZX Spectrum planuję umieszczenie takowego w swojej Cobrze.
Gniazdo przerobiłem z pozyskanego gniazda ze starej płyty PC.
Jak to zrobiłem przedstawia umieszczone poniżej zdjęcie.

Opisane na gnieździe sygnały są umieszczone pod moje potrzeby, do testowania "czegoś tam".

Pozdrawiam.

PS
W opisie gniazda winno być "widok z tyłu komputera".

zdzis_ek wrote:

Witam !

W obudowie Cobry 1 nie planowałem umieszczenia gniazda z jej wewnętrznymi sygnałami, zadowalając się jedynie jej uruchomieniem.
Po pewnym czasie doszedłem do wniosku, że poprzez to gniazdo będzie można dokonać wielu rozszerzeń.
Wzorując się na gnieździe z ZX Spectrum planuję umieszczenie takowego w swojej Cobrze.
Gniazdo przerobiłem z pozyskanego gniazda ze starej płyty PC.
Jak to zrobiłem przedstawia umieszczone poniżej zdjęcie.

Opisane na gnieździe sygnały są umieszczone pod moje potrzeby, do testowania "czegoś tam".

Pozdrawiam.

PS
W opisie gniazda winno być "widok z tyłu komputera".

Fajny sposób na pozyskiwanie gniazd z płyt głównych. Próbowałem kiedyś wylutować takie gniazdo, ale nigdy mi to nie wyszło w normalny sposób.

Byłby ktoś zainteresowany budową kalkulatora na scalakach TTL/CMOS? Zawsze chciałem zrobić jakiś prosty system procesorowy, który miałby potem służyć do celów edukacyjnych, prezentacyjnych i zabawowych

Takie coś już zrobili inni:
https://www.youtube.com/watch?v=70AaNg9llmg
http://www.bigmessowires.com/nibbler/
http://www.bigmessowires.com/bmow1/

Cel byłby taki, żeby zrobić coś jak najbardziej na kształt normalnego kalkulatora, byle tylko z prostych scalaków. W chwili obecnej mam sterownik wyświetlacza multipleksowanego, który pobiera z pamięci RAM (74670 dual port 4x4bit sram yeah!) poszczególne cyfry i wyrzuca je na wyświetlacze 7seg, zapalając przy okazji kropkę lub minus w razie konieczności. Kolejnym krokiem będzie klawiatura, a potem właściwy procesor.

Tak to obecnie wygląda i nawet działa

-> leonow32, temat jest o Cobrze więc nie ma co robić smietnika o CPU na TTL-ach (zobacz EDUC-8 oraz DIGI-CAL z Practical Electronics)

Czy ktoś się pochwali Cobrą uruchomiona na replice PCB? Na mojej RAM działa poprawnie tylko z obsadzonym jednym bankiem a 16KB to za mało na CP/M

sq6fmy wrote:

Czy ktoś się pochwali Cobrą uruchomiona na replice PCB? Na mojej RAM działa poprawnie tylko z obsadzonym jednym bankiem a 16KB to za mało na CP/M

Rozumiem, że próbujesz uruchomić CP/M na Cobrze. Załączam najnowszą wersję emulatora, w porównaniu z poprzednią udostępnioną były głównie poprawy błędów i uzupełnienie o dokumentację.

Jeżeli do CP/M nie jest wymagane niestandardowe wyposażenie Cobry, to czy możesz sprawdzić, czy na tym emulatorze da się uruchomić CP/M? Pewnie w samym CP/M trzeba przynajmniej przerobić procedury obsługi klawiszy i ekranu. Nie wiem, co z plikami, bo na pierwszy rzut oka CP/M jest podobny do DOS wyświetlając katalog bieżący, a w Cobrze nie ma nic związanego z plikami dyskowymi, więc wydaje mi się, że CP/M nijak nie pasuje do Cobry, ale próbować uruchomić można.

Co do systemu CP/M na komputerze COBRA można by wykorzystać trik znany z ZX Spectrum. Tam system CP/M uruchamiał się w pełni w stacji dyskowej FDD3000, gdzie do dyspozycji miał osobny procesor Z80A oraz pełne 64KB RAM. Sam Spectrum był tylko terminalem, który łączył się przez interface stacji.

Myślę, że odpowiednio napisany program terminala na komputerze COBRA razem z prostym interface (Oryginalny interfejs od strony komunikacji jest banalnie prosty), dogadałby się z tą stacją i CP/M wraz ze swoją biblioteką oprogramowania stałby wtedy otworem.

Napisanie bios dla CP/M i uruchomienie go na Cobrze (z compact flashem jako pamięć masowa) to najmniejszy problem - zrobi się . A emulator Cobry to mam swój (->andrzejlisek, chyba nawet mnie o zródła prosiłeś kiedyś). Swoim postem bardziej chciałem wywołać osoby, które zrobiły Cobrę na płytce narysowanej przez kolegę parę postów wyżej. Zastanawiam się czy tam gdzieś jeszcze nie siedzi jakiś psikus na płytce?! Używam 4164 zamiast 4116 (odłączone napięcia -5V/+12V i linia A7 na masie) i włożenie kości do wiecej niż jednego banku powoduje błędne odczyty w części komórek RAM (acz wygląda, że losowo). Nie pamiętam do jakich wniosków doszedłem ale nie podobały mi się oscylogramy na na liniach nRAS i nCAS. W ogóle to nieciekawie wyglądały linie zasilania mimo dodania dodatkowych kondensatorów odsprzęgających.

Czy te twoje 4164 są z 7 bitowym odświeżaniem?

Nie wiem, różne testowałem bo miałem podejrzenia, że czas dostępu coś zmienia w zachowaniu. Ale to chyba nie jest ważny parametr bo mają linie A7 na masie wiec i tak tylko siedem linii adresu jest wykorzystywane - nie chce modyfikować płytki aby 8 sztuk pamięci obsługiwało trzy banki.

1. Kolega zdzis_ek jest najbliższy tego o co mi chodziło. Poniżej mój wzór:



2. Wychodzi na to, że przegapiłem produkcję repliki, czy któryś z kolegów może udostępnić jakąś fotkę. Może sq6fmy

Witam wszystkich fanów komputera Cobra
Jestem szczęśliwym - jak już pisałem wcześniej - posiadaczem wersji COBRA1. Mam złożony komputer i działający. Ten komputer jest dla mnie sentymentalną podróżą do czasów gdy brakowało w Polsce wszystkiego a tacy ludzie jak ja zbieraliśmy doświadczenie w programowaniu czy też budowie domowych komputerów. COBRA pozwoliła dołączyć do grona ludzi zajmującymi się komputerami bo moja przygoda i pasja rozpoczęła się właśnie wtedy i potem praca jako informatyk. Teraz wiek słuszny i niestety zostałem odstawiony na boczny tor.
Koledzy, posiadam już bardzo zniszczoną wersję kasety z nagraniem sytemu do COBRY, czy ktoś z Was posiada plik dźwiękowy? A może wersję systemu do pamięci ROM?

bieganj wrote:

Witam wszystkich fanów komputera Cobra
Jestem szczęśliwym - jak już pisałem wcześniej - posiadaczem wersji COBRA1. Mam złożony komputer i działający. Ten komputer jest dla mnie sentymentalną podróżą do czasów gdy brakowało w Polsce wszystkiego a tacy ludzie jak ja zbieraliśmy doświadczenie w programowaniu czy też budowie domowych komputerów. COBRA pozwoliła dołączyć do grona ludzi zajmującymi się komputerami bo moja przygoda i pasja rozpoczęła się właśnie wtedy i potem praca jako informatyk. Teraz wiek słuszny i niestety zostałem odstawiony na boczny tor.
Koledzy, posiadam już bardzo zniszczoną wersję kasety z nagraniem sytemu do COBRY, czy ktoś z Was posiada plik dźwiękowy? A może wersję systemu do pamięci ROM?

Jeśli pisząc system COBRY masz na myśli BASIC to znajdziesz go m.in. tutaj

kolega PAMPKIN napisał:

Quote:

1. Kolega zdzis_ek jest najbliższy tego o co mi chodziło.

Nie bardzo wiem o jaką replikę chodzi, ale ja gniazdo wykonałem z gniazda PC - zdjęcie poniżej.

Quote:

="sq6fmy
Czy ktoś się pochwali Cobrą uruchomiona na replice PCB? Na mojej RAM działa poprawnie tylko z obsadzonym jednym bankiem a 16KB to za mało na CP/M

Do końca tygodnia postaram się jeszcze raz prześledzić zgodność ścieżek na płycie ze schematem. Może uda się znaleźć błąd na płycie.

Swoją drogą, czy posiadacze sprawnej cobry na oryginalnej płycie mogą potwierdzić, że poprawnie obsługuje ona pełne 48k? Może błąd jest w projekcie?

Zdjęcie płyty:

Schematowi bym nie ufał tak do końca ale jak go przeglądałem to nie rzuciło mi się nic złego w oczy. A może porównaj layout repliki z skanami czystej oryginalnej płyty, która była ostatnio na allegro (był wrzucony w tym temacie). Nie twierdze, że layout repliki jest zły, zakładam także, że sam coś sknociłem. Zauważyłem, że bufory danych dosyć mocno się grzeją - wyglądało jakby na magistrali danych w pewnych momentach były aktywne dwa wyjścia równocześnie?! Seria 74S brała dużo prądu i się grzałą ale i tak mi to podejrzanie wyglądało.

@zipzap

Oryginalna Cobra poprawnie obsługuje 48k.

@sq6fmy

Bufory dość mocno się grzeją również i w oryginale.

Dodano po 2 [godziny] 24 [minuty]:

@zipzap

Na szybkiego spojrzałem na czysty oryginał płyty oraz jej replikę, gdyż jestem w posiadaniu ich obu.
Na replice brak jest połączenia nóżek kondensatorów blokujących Cb do linii -5V.

Sprawdziłem zgodność płytki ze schematem właściwie całej części procesorowej. Poza wspomnianymi wcześniej błędami wszystko w kwestii sygnałów się zgadza.
Może więc błędy z większą ilością ramu wynikają z innych powodów, np.:

1. wspomniany brak połączenia kondensatorów filtrujących (znowu brak 1 mm ścieżki przy każdym kondensatorze) - może zasilanie jest za bardzo zaśmiecone. Dodatkowo, kondensatory Cb nad układami 38-45 powinny filtrować -5v, a nie 12V. Trzeba przeciąć ścieżkę od strony 12V i dodać mikropołączenie do -5V.
2. Dołożenie dodatkowych pamięci powoduje zbyt duży pobór prądu i zasilacz nie wyrabia na jednym lub kilku napięciach
3. Uszkodzenie układów pamięci
4. Uszkodzenie innych układów

Dzięki za weryfikacje.

Braki przy napięciach -5V/+12V wychwyciłem przy montażu ale u mnie i tak te napięcia nie występują (4164 są jednonapięciowe).

I pamięci i reszta układów była testowana (poza układami 74S ale były podmieniane oryginalne 82xx). Pamięci z kolei mam dużo różnych wykonań i wszystkie były testowane i to po pół godziny (pojedyńcze uszkodzone się trafiały ale głównie w wykonaniu Tesli).

Ale punkt drugi daje do myślenia. Nie zaobserwowałem dużych spadków na liniach zasilania (oscyloskopem w różnych miejscach układu) ale zrobię na testy liniowy zasilacz 5V/3A i wtedy sprawdzę. Kto wie

coberr wrote:

Co do materiałow n/t COBRY - nadal poszukuję wszelkich materiałow - głównie skanów artykułu z opisem komend (ew. procedur) programu MONITOR. Był to numer chyba 5 lub 6 1985. Ew, ktorys z 1986r.
Czy powstał na niego jakis Assembler/ Disassembler?

Dissasembler w mojej głowie

Przez 30 lat pamiętam C9.

Fajny dla mnie wątek na zasadzie sentymentalnej.
Zdisasemblowałem ówcześnie (student wyższych lat) zamieszczony w czasopiśmie hex monitora. Nie tylko projekt sprzętowy miał liczne błędy, software też. Np instrukcja do monitora mówiła o czymś innym (znaczne różnice w menu) niż software rzeczywiście zawierał, mowa o tym samym numerze czasopisma więc nie rozbieżność czasowa.

EDIT: przeczytałem ten wątek ... czy błędy były świadomie wprowadzone/pozostawione? Wtedy byłem za młody, dziś mogę przypuszczać, to był okres schyłku "komiunizma", projekt powstał w OBR, to były takie cieplarnie (nie jedyne) gdzie specjalista chodził na ok. 8 godzin aby trzaskać fuchy "dla prywaciarzy". Może biznes miał polegać na wydaniu poprawionego kitu prywatnie, co się rozeszło po kościach? Wzmianki w czasopiśmie zapowiadały produkcję płyty głównej, ale nikt jej nie widział.

PAMPKIN wrote:

Jeśli pisząc system COBRY masz na myśli BASIC to znajdziesz go m.in. tutaj

Postanowiłem wypróbować wszystkie gry w Basicu umieszczone pod powyższym linkiem.

Wszystkie gry działają oprócz gry "Nalot". Na początku myślałem, że jest jakiś błąd w samym emulatorze, który objawia się problemem z wczytaniem dłuższego pliku WAV, jednak okazało się, że te dwa pliki są nietypowe, mają nieco dłuższy nagłówek. W programie dźwiękowym wczytałem i zapisałem te pliki. Teraz mają typowy nagłówek o długości 44 bajtów, jak każdy typowy plik WAV PCM.

Ponieważ są nagrane z częstotliwością 48000Hz, przed wczytaniem tego pliku należy ustawić następujące parametry magnetofonu:
Czas trwania próbki nagrania: 68
Czas impulsu długiego: 18
Pozostałe parametry można pozostawić bez zmian.

Po tej zmianie pliki wczytują się poprawnie jako programy Basic. Pozostałe gry wczytują się poprawnie przy domyślnych ustawieniach magnetofonu.

Załączam poprawione pliki WAV gry "Nalot".

Witam !

Zrobiłem wstępny projekt płytki PCB części procesorowej Cobry 1 na układach SMD.
Chcę umieścić jako RAM dwie pamięci 4-bitowe typu 4464 lub 41464 w obudowie PLCC18.
Tego typu pamięci były montowane np. w C64.
Nie bardzo wiem co podać na końcówkę -OE/ tych pamięci.
W C64 końcówka ta jest połączona do masy.
W projekcie płytki PCB pozostawiłem możliwość zrobienia mostka do masy lub podania odpowiedniego sygnału.
Może ktoś z Was wie co z tym fantem zrobić?
Przedstawiam projekt tej płytki.

Część wizyjną PCB Cobry 1 zaprojektowałem i wykonałem trochę wcześniej.
Po wydrukowaniu, metodą żelazkową dokonałem termotransferu swojego dzieła na laminat PCB.
Po wytrawieniu uzyskałem coś takiego.


Teraz czeka mnie cynowanie płytki, wiercenie i montaż.
Dokonałem zmian w schemacie Cobry 1 pod potrzeby tego nowego projektu, oraz zrobiłem opis montażu elementów elektronicznych na tym PCB.


Pozdrawiam

Tak na szybko patrzac w DS... OE - output enable... niby jest na timingach, ale patrzac na to jak jest podpiete idzie na bramke ktora sterowana jest tez WE... Jest to wyjscie zanegowane wiec wyglada po tej bramce ze podpiecie do GND bedzie OK...

Niestety po aktualizacji Arch Linux-a AR wywala mi sie po okolo 3 sekundach od otwarcia PDF-a... wiec nie moge dokladnie przeczytac

Natomiast co do pamieci to mozna by pomyslec tez o pamieciach z modulow SIMM od PC, sa latwo dostepne. Gdzies mi chodzi po glowie ze ktos takie tez podpinal do C64 i to dzialalo, trzeba by zerknac na DS, timingi i zobaczyc - moze i tutaj byla by szansa...

Linia OE służy do włączania wyjściowych wzmacniaczy odczytu. Te pamięci nie mają oddzielnych linii danych do odczytu i zapisu tak jak pamięci jednobitowe, zatem sygnał OE jest potrzebny by podczas zapisu dane odczytane nie kolidowały z sygnałami na wejściach danych.
Stan niski powinien się pojawiać podczas odczytu pamięci. Sterowanie tym sygnałem ma bardzo duże znaczenie w trybie Read-Modify-Write, ponieważ wtedy mamy jednorazowo zaadresowaną przez RAS i CAS matrycę pamięci, i manipulujemy danymi na liniach danych. Pamięć musi wtedy wiedzieć, kiedy wyłączyć dane przeznaczone do odczytu by umożliwić późniejszy zapis.

Problem się pojawi gdy przyjdzie do odświeżania tych pamięci, ponieważ wymagają wtedy 8 bitów adresowych, a Z80 używa 7 przy cyklu RFSH. Coś mi się wydaje, że trzeba będzie przekonstruować układ sterowania RAS, CAS i multiplekserów adresowych by skorzystać z dobrodziejstw trybu CAS-before-RAS. W trybie tym pamięć wykorzystuje swój własny licznik odświeżania.

Dodano po 17 [minuty]:

tplewa wrote:

Natomiast co do pamieci to mozna by pomyslec tez o pamieciach z modulow SIMM od PC, sa latwo dostepne. Gdzies mi chodzi po glowie ze ktos takie tez podpinal do C64 i to dzialalo, trzeba by zerknac na DS, timingi i zobaczyc - moze i tutaj byla by szansa...

Już parę stron wcześniej proponowałem wykorzystanie modułów SIMM 256KB. Możnaby wtedy skorzystać z tych dodatkowych KB przełączając banki. Ale przy takich skromnych możliwościach zarówno muzycznych jak i graficznych (a te wymagają sporo danych) nie wydaje się to potrzebne. Chyba, że opracujemy lepszy sterownik graficzny (np. 320x256 16 kolorów) i poprawimy interpreter BASIC-a by z niego mógł skorzystać.

W sumie co do pamieci SIMM to musialem przeoczyc, bardziej chodzilo mi o to ze te pamieci sa tanie i niemal wszedzie dostepne (a u niektorych osob moga sie paletac gdzies w domu ze starego komputera).

Natomiast co do OE to moge sie mylic, zobacze w domu bo w pracy mi sie system juz tak rozpierniczyl po aktualizacji ze nie moge otworzyc PDF-a jakiegokolwiek...

Ale zdawalo mi sie ze przy zwarciu do masy przelaczac bedzie sygnal WE (read/write)... jednak schemat blokowy pamieci widzialem przez niecala sekunde zanim sie wypierniczylo wiec tutaj moge sie mylic...

Znalazłem w sieci schemat Z80 CPU z wykorzystaniem pamięci 4464.
Może chodzić tylko o CAS.

Witam
Tu jest opis i zdjęcia z podłączenia takiej pamięci do C64:

Link

"Sterownik graficzny (np. 320x256 16 kolorów)" - czy mógłbyś coś przybliżyć jak miałoby to być zrealizowane?

Zdzis_ek - podziwiam Twoj zapał i Twoje projekty

Jednak zamiast porywac sie na nowy projekt - mysle ze mim wszystko dobrze by było - zebys jednak odpalił w pierwszej kolejnosci cobrę, ktora zrobiłes z przelotkami nitowanymi.

Jesli ruszysz te mendę na pamieciach 4164 - będziesz miał solidną bazę do eksperymentowania z pamieciami 41464.

co do róznic - z tego co widzę - nie ma jakichś wielkich róznic - jesli chodzi o sterowanie w trybie podstawowym tych pamieci.

41464 w trybie READ sterujesz praktycznie tak jak 4164 - z uwzględnieniem sygnalu OE'. A ten bez problemu uzyskasz odpowiednio bramkując linie MREQ' RD' - w sumie cobra juz ten sygnał ma. (MEMR')

W trybie zapisu - sygnał OE' nie ma znaczenia - tym bardziej - ze i tak jest w stanie wysokim (wymuszonym przez procesor (MEMR')

niestety problemem będzie sam cykl odświeżania - który w tych pamięciach jest 8-mio a nie 7-mio bitowy. Mozna to ominąć - jednak wymaga to kilku przeróbek przy multiplekserach ( dodania układu generującego ten nieszczęsny ósmy bit)
taki "rasowy" układ powinien oczywiscie współpracować z sygnałem RFSH procesora.

Z mojej strony - jesli chodzi o cobre - wyrzeźbiłem jedynie w marcu bieżącego roku dodatkową płytkę - przekształcającą cobre w swego rodzaju "tester systemów mikroprocesorowych". Szumnie brzmi ale w rzeczywistosci nie ma tam nic wielkiego - raptem 2x8255, 8KB EEPROM (jako pamiec programu) , kilka 8-krotnych buforów trójstanowych, kilka dodatkowych bramek oraz udalo sie wcisnąć układ dźwiękowy.
Układ AY juz zadziałał - resztę musiałem odłożyc na poźniej. Moze za kilka miesiecy do tego ustrojstwa ponownie zasiądę.
Pozostalo napisac oprogramowanie pod konkretny system. (docelowo powstalo to w celu uruchomienia płyty Mr Do! run run - stara gra arcade).

DSC009..JPG Download (491.35 kB)


moze opisze gdzies kiedyś to ustrojstwo w jakimś DIY...

zdzis_ek wrote:

Znalazłem w sieci schemat Z80 CPU z wykorzystaniem pamięci 4464.

obawiam sie, że to własnie ta specjalizowana matryca wytwarza sygnał odświeżania dla twojej pamieci.

jackfinch wrote:

"Sterownik graficzny (np. 320x256 16 kolorów)" - czy mógłbyś coś przybliżyć jak miałoby to być zrealizowane?

Jeśli chodzi o komputer COBRA to musiałby to być jakiś autonomiczny sterownik tak jak jest teraz. Jego pamięć musiałby by być mapowana w przestrzeni również tak jak jest teraz.
Pierwsza to pamięć "tekstowa", tak by sterownik był kompatybilny z obecnym. Po rekonfiguracji sterownika (przez porty do jego rejestrów) sterownik mógłby się przełączyć w tryb graficzny. I tu mamy dwie opcje. Pamięć grafiki jest widoczna jako okno o rozmiarze pamięci "tekstowej" lub mapowana w całości gdzieś w pozostałej części pamięci RAM.

Najgorsze jest to, że przyjmując rozdzielczość 320x200 16kolorów gdzie każdy piksel mógłby mieć swój własny kolor potrzeba 32kB Video RAM (4 bitplany po 8KB). Jak dobrze liczę. Więc zamapowanie tej pamięci w całości w dostępną przestrzeń adresową jest raczej awykonalne.

Jest trochę gotowych układów:
https://en.wikipedia.org/wiki/Video_display_controller

Patrząc bardziej realistycznie, Cobra generuje obraz 32x24 znaki, czyli w rozdzielczości 256x192 z narzuconymi znakami.

Gdyby chcieć obsłużyć rozdzielczość 256x192 w kilku wariantach kolorystycznych, to potrzebna byłaby następująca pamięć:
2 kolory - 6144
4 kolory (np. 4 odcienie szarości) - 12288
16 kolorów - 24576
O ile 2 kolory dało by się wepchnąć, to więcej kolorów już nie bardzo.

Można zastosować rozwiązanie takie, jak w ZX Spectrum, czyli 16 kolorów, ale w blokach 8x8 pikseli, tak więc 6144 pikseli + 768 bloków po 1 bajcie na 2 bloki daje razem 6528 bajtów.

Rozdzielczość 256x192 byłaby dostępna, gdyby pominąć generator znaków.

Chcąc zachować kompatybilność wsteczną, do dyspozycji grafiki pozostaje pamięć od F800 wzwyż, czyli tylko 2048 bajtów. Pamięć mapowana w tej przestrzeni musiałaby być przełączana poprzez stronicowanie i tak, jak będą 4 strony, to ma się do dyspozycji 8192 bajtów pamięci graficznej. Wtedy w trzech stronach byłyby piksele ekranu, bo akurat 3*2048 daje 6144, a w czwartej stronie byłyby kolory bloków. W przypadku 16 kolorów, dla bloków 8x8 pikseli byłoby 384 bajtów, ale dla bloków 4x4 piksele byłoby 1536, co nadal mieści się w jednej stronie 2048 bajtów.

Możnaby ten problem ugryźć zupełnie inaczej. Można za pomocą AVR czy czegoś innego zbudować "kartę graficzną" z łączem szeregowym i własną pamięcią. Wtedy byłby określony zestaw rozkazów interpretowany przez AVRa, a sam AVR zajmowałby się resztą. Jakiś czas temu zbudowałem taki sterownik do LCD monochromatycznego 192x64 piksele, zastosowałem taką listę rozkazów:



Kiedyś chciałem opisać konstrukcję w DIY, ale było jedno niedociągnięcie, jednak z różnych powodów to się odwlekało i nieco zapomniałem o tym. Tylko nagrałem filmiki z pierwszych prób działania w połączeniu z DSM-51, jednak można podłączyć do dowolnego urządzenia z UART pracującym w poziomach RS232 lub TTL.
https://www.youtube.com/watch?v=5dL43_pmpAU
https://www.youtube.com/watch?v=YNZVdzwIfl4

Dodano po 23 [minuty]:

Wydaje się, że stosunkowo łatwo można dorobić tryby graficzne 1-bitowe o rozdzielczości 6144 pikseli.

Już fabrycznie da się uzyskać grafikę o rozdzielczości 64x72 piksele korzystając z dedykowanych znaków. Można ten pomysł nieco rozwinąć, wtedy jedyną rzecz, jaką trzeba dorobić, to możliwość programowego podmieniania pamięci znaków poprzez wybór jednej z nich.

Wiedząc, że jest 256 znaków, jeden znak można podzielić na 8 elementów, które odpowiadają 8 bitom. Dzieląc znak na następujące sposoby można uzyskać następujące rozdzielczości:

Jak łatwo zauważyć, każda z tych rozdzielczości to 6144 pikseli, a znak dzieli się na 8 elementów.

Gdyby generator znakowy rozbudować tak, że znak byłby opisywany dwoma bajtami, a więc mając do dyspozycji 65536 znaków, to sam znak można podzielić na 16 elementów uzyskując następujące rozdzielczości:

Teraz rozdzielczość ma 12288 pikseli, a do obsługi jest potrzebna pamięć 1536 bajtów.
Do generowania byłaby w tym przypadku odpowiednio przygotowana pamięć EEPROM o pojemności 64kB do obsługi jednego trybu, gdzie na podstawie pamięci roboczej byłby wybierany znak na podstawie dwóch kolejnych bajtów.

W każdym przypadku, samo rysowanie, czyli dobór znaków na podstawie spodziewanego rysunku, musiałoby się odbywać programowo.