Komputer 8-bitowy

[jethrotull]

Dzięki, ja nie narzekałem że muszę zrobić kartę PAL, tylko się cieszyłem tą perspektywą. Pewnie po prostu zrobię obie: VGA i PAL.
W przypadku karty PAL mam zresztą gotowy projekt: https://www.waveguide.se/?article=bitma ... -interface, trzeba tylko dodać generator znaków.

A skoro już mowa o generatorze znaków to niestety wygląda na to że wypluwanie znaków bezpośrednio z ROMu generatora po jednym bicie się nie uda - moje pamięci są zdecydowanie za wolne na to. Zamiast tego chyba posłużę się tradycyjnym układem '165, do którego będę ładował znaki po osiem bitów na raz.

[jethrotull]

Pewnia rzecz mi nie dawała spokoju: otóż kiedy walczyłem ze szpilami zbudowałem układ testowy żeby zreprodukować problem przy minimalnej liczbie komponentów. Układ składał się tylko z licznika '590, ROMu 28F010 i zegara. Licznik adresował pierwsze 8 linii adresowych ROMu, a z jednej z linii danych brałem sygnał wyjściowy. Już przy takim prostym układzie obserwowałem znienawidzone szpile.

Z drugiej strony jednak, Ben Eater w swojej konstrukcji https://www.youtube.com/watch?v=uqY3FMuMuRo użył zasadniczo identycznego pomysłu. OK, sygnały synchronizacji generowane są za pomocą bramek a nie ROMu zastępującego logikę kombinacyjną, ale już składowe kolorów są wytwarzane identycznie jak w moim układzie testowym. I u niego żadnych szpil nie ma. Wiem jak jakie rzeczy wyglądają na ekranie, bo próbowałem podawać składową koloru bez przepuszczania jej przez zatrzask, i otrzymałem na ekranie pełno śmieci, sygnał był bardzo zanieczysczony szpilami.

Czemu więc ja mam szpile a Ben nie?

Przyszło mi do głowy, że 28F010 to nie jest typowy EEPROM, tylko pamięć Flash. Testowałem na kilku egzemplarzach, i wszystkie działały tak samo jeśli chodzi o szpile (oraz pod każdym innym względem). Ben natomiast używa tradycyjnego EEPROMu 28C256. Chwyciłem więc jedną taką kostkę, zaprogramowałem i wsadziłem w mój układ testowy. I co? Brak szpil! A mój 28C256 jest ponaddwukrotnie wolniejszy niż 28F010.

Nie potrafię tego wyjaśnić, ale jeśli ktoś potrafi to będę nad wyraz wdzięczny.

[tszczesn]

Najwyraźniej Ben miał szczęście. To co się dzieje na wyjściach pamięci przed upływem gwarantowanego czasu dostępu jest nieokreślone, Zależy od konstrukcji tego konkretnego chipu, może być cokolwiek. W takiej sytuacji trzeba na wyjściu dawać zatrzask, albo korzystać z wejścia OE pamięci i podciągnąć wyjścia opornikami do stabilnego 0 lub 1 (gorsze rozwiązanie).

[jethrotull]

tego drugiego próbowałem bez skutku. teraz ja już też mam szczęście

[jethrotull]

Obecny stan generatora sygnału VGA (działającego):

VgaGen.png

Wsad ROMu:
https://github.com/vampirehunt2/aniol64 ... /VGAGG.BIN

[jethrotull]

Próbuję rozszerzyć prototyp karty graficznej tak, aby obsługiwał pamięć obrazu i pełną docelową rozdzielczość, czyli 320x240 pikseli.
Tymczasowo 28c256 z wypaloną bitmapą udaje pamięć obrazu. Dane z tej pamięci są ładowane do rejestru '165 i wysuwane z niego po jednym bicie/pikselu prosto na wyjście.

Schemat:

VgaGen.png

Zauważmy, że schemat nie zawiera jeszcze generatora znaków, obraz jest bitmapą.
Prawa strona schematu zawiera układ dekodujący adres pamięci obrazu, ta część nie jest zaimplementowana w prototypie.

Efekt działania:

IMG_20220129_125632939.jpg

Jak widać na zdjęciu, prototyp w zasadzie działa i obraz jest czytelny, zawiera jednak artefakty:
- szumy, widoczne szczególnie w pobliżu prawego dolnedo rogu ekranu wynikają z faktu że pin GREEN monitora jest sterowany bezpośrednio z wyjścia rejestru przesuwnego, a więc sygnałem 0-5V zamiast 0-0.7V. Dodanie odpowiedniego dzielnika napięcia na wyjściu rejestru zapewne rozwiąże ten problem, a w każdym razie zmniejszy szumy siedmiokrotnie, co powinno sprawić że będą praktycznie niewidoczne

- niektóre linie poszczególnych znaków są przesunięte o jeden piksel w prawo (nieszczęśliwie wybrana, pokraczna czcionka nie ułatwia zauważenia tego artefaktu). Jak mniemam, jest to spowodowane prymitywnym sposobem ładowania rejestru sygnałem z rudymentarnego monoflopa. Niestety, najwęższy impuls jaki mogę uzyskać z tego monoflopa ma ok 100ns, czyli jest szerszy niż czas trwania jednego piksela. Dodatkowo, rejestr jest ładowany kiedy trzy najmłodsze bity licznika pikseli mają wartość 000, czyli nie można zapewnić że dane na wyjściu pamięci obrazu są już poprawnie ustalone. Rozwiązanie: zastosować sprytniejszy generator impulsu pozwalający uzyskać 20ns szerokość impulsu i ładować rejestr po upłynięciu czasu odpowiadającego dwóm lub trzem pikselom od ustalenia adresu podawanego na wejście pamięci obrazu.

- górna linia obrazu zawiera jakieś śmieci, jeszcze nie wiem dlaczego. Może uda się wyregulować monitor tak, żeby ta linia nie była widoczna.

[jethrotull]

Jak się nazywa "tactile dome" po polsku?

https://www.mouser.pl/new/keystone/keys ... -switches/

[Tomasz Gumny]

To "membrana" albo styk do klawiatury membranowej: https://www.satori.pl/klawiatury-membranowe/

[jethrotull]

Opisanego wyżej problemu z migotaniem niektórych linii obrazu VGA nie dało się w żaden inteligentny sposób usunąć: ani stosując bardziej ambitnego monoflopa ani przepuszczając sygnały synchronizacji przez rejestr (co już przecież wcześniej działało kiedy generacja VGA działała na układzie 28F010!). W końcu więc sięgnąłem po sposób głupi: wymieniłem pamięć 27C512 na inny egzemplarz tego samego typu i problem zniknął. Pewnie ten pierwszy był uszkodzony, albo, co bardziej prawdopodobne, kiepsko stykał na płytce prototypowej.

[jethrotull]

Zbliżam się (mam nadzieję) do końca budowy prototypu karty graficznej, w związku z tym musiałem się zastanowić gdzie w mapie pamięci umieścić pamięć obrazu. Zdecydowałem że będą to ostatnie 2KB stałego (nie obejmującego przełączania banków) obszaru ROM, innymi słowy adresy między 14K a 16K. Zmniejszy to wielkość mojego ROMu o 2 kilobajty, co jest akceptowalne, bo nadal będę miał 126KB do dyspozycji, biorąc pod uwagę przełączanie banków.

Aby umieścić pamięć obrazu w przestrzeni adresowej procesora muszę wygenerować sygnał VRAMSEL, który będzie uaktywniał pamięć obrazu, a także komplementrny sygnał VRAMSEL', który będzie pozwałał na przysłonięćie znajdującej się w tym obszarze pamięci ROM. W tym zakresie pamięci linie adresowe A15..A11 mają wartości 00111. Potrzebuję więc zdekodować pięć linii adresowych aby wygenerować potrzebne sygnały.

Po lewej wersja naiwna dekodowania, która wymaga jednak dwóch czipów: '04 i '08. Po prawej wynik moich rozmyślań nad możliwością zrealizowania tej funkcji na jednym czipie (owszem, mógłbym użyć komparatora adresów '679, ale on jest w dużej obudowie DIP20, i, z tego co widziałem, trudno dostępny).

VramAddressDecode.png

[tszczesn]

Twój układ na bramkach ma aż pięć poziomów, do tego różne drogi mają różne czasy propagacji, co może generować ekstra szpilki dające niechciane efekty. Zastosuj albo klasyczny układ sumy iloczynów (sa nawet gotowe układy z odpowiednimi bramkami do tego celu 745x, np. UCY74H53 z CEMI, wraz z ekspanderem 7460). Pomysł z multiplekserem tez lepszy.

[jethrotull]

Owszem, ale procesor jest tak wolny w porównaniu z czasem propagacji przez nawet pięć szeregowo połączonych bramek, że nie powinno to mieć znaczenia. Całkowity czas propagacji wyniesie jakieś 5 * 7ns = 35ns, dla porównania czas dostępu do pamięci ROM wynosi 120ns.
Nawet przy maksymalnej prędkości zegara 4MHz czas między ustaleniem adresu a odczytem z pamięci (dwa takty pocesora) wynosi 500ns.

Nota bene, multiplekser '151 też ma 5 poziomów bramek wewnątrz: https://www.digchip.com/datasheets/part ... 1N-pdf.php

Moja motywacja dla zastosowania multipleksera to było ograniczenie liczby indiwidualnych części w układzie i redukcja plątaniny kabli.

[tszczesn]

Fakt. Ale różne czasy propagacji na różnych drogach sygnału zawsze pozostają w mocy, niezależnie od szybkości bramek masz szanse na fałszywe szpilki na wyjściu.

[Tomasz Gumny]

Tymczasowo 28c256 z wypaloną bitmapą udaje pamięć obrazu.

Skoro pamięć ekranu jest cały czas odczytywana, to jak i kiedy procesor będzie ją zapisywać?

[jethrotull]

Świetne pytanie!

Mam pamięć dwuportową, 2KB RAMu w potężnej obudowie DIP48 (aż mnie pan w sklepie elektronicznym pytał po co mi taki potwór). Ma zdwojone wszystkie linie oprócz zasilających, więc można ją jednocześnie odczytywać i zapisywać, w sposób całkowicie asynchroniczny. Tym samym całkowicie unikam wszelkich kłopotów z synchronizacją dostępu do pamięcu między CPU a kartą graficzną, oraz spowolnienia pracy procesora z tym związanego.

Wadą tego rozwiązania jest że całe dwa kilobajty są potrzebne do wyświetlenia jednego ekranu. Część pamięci jest marnowana gdyż znaki tam przechowywane przypadają na obszar blankowania (nie wiem jak to ładnie po Polsku powiedzieć - wygaszania?) poszczególnych linii. Co gorsza, ponieważ liczba znaków w linii, nawet po wzięciu pod uwagę okresu blankowania, nie jest całkowitą potęgą dwójki, wszystkie adresy pamięci między końcem linii a najbliższą całkowitą potęgą dwójki są również marnowane. Żeby być bardziej precyzyjnym, 40 znaków przypada na obszar widoczny, dalsze 10 na obszar blankowania linii, a kolejne 14 jest po prostu omijane - licznik X jest resetowany i te adresy nigdy nie są generowane. W sumie więc na każdą linię przypadają 64 bajty pamięci. Linii jest 30, co oznacza prawie 2KB zajętej pamięci, i nic nie zostaje np. na podwójne buforowanie albo sprzętowe przewijanie (hardware scrolling). Wykluczone są również tryby bitmapowe.

Można by ominąć ten problem stosują osobny licznik X dla generowania sygnałów synchornizacji, i, równoleglem osobny licznik X do generowania adresów pamięci obrazu. Nawet jednak w takim przypadku musiałbym ograniczyć liczbę linii ekranu z 30 do 25 żeby zmieścić w RAMie obrazu dwa osobne ekrany i np. móc zrealizować podwójne buforowanie. Na razie więc tego nie planuję.