Przeszukaj forum

Opis ten dotyczy zegara, który został przeze mnie zbudowany trzydzieści lat temu w 1995 roku. Natomiast projekt tego zegara pochodzi ze starszego o jedenaście lat „Radioelektronika” nr 3/84. Zegar ten wskazuje czas za pomocą kolorowych diod LED, które również imitują ruch wahadła. Zegar zawiera też dwa głośniki. Jeden z nich wykorzystany jest w budziku, a drugi z nich symuluje tykanie zegara mechanicznego. Zegar ustawia się za pomocą dwóch przełączników dźwigniowych. Kolejne dwa przełączniki służą do wyłączenia budzika i tykania zegara. W chwili budowy tego zegara była to już podstarzała konstrukcja pod względem technicznym. Kiedy już wykonałem elektronikę tego zegara pojawił się problem jego obudowy. Zrobiłem ją z drewna stylizując na obudowę zabytkowego zegara. Później dodałem niej dodałem „ozdoby” w postaci orzełków, efektu świetlnego LED włączającego się wraz z budzikiem i powstał taki swoisty kicz. Dziś zupełnie inaczej wykonał bym tą obudowę. Opis i schemat Zegar ten bo był prawdziwy „hard core”. Zbudowany jest on od podstaw na cyfrowych układach scalonych TTL i jednym CMOS. Ich liczba jest spora bo 30 szt. Natomiast w oryginalnej konstrukcji było 34 szt. układów TTL. Zegar nieco odchudziłem o układy scalone w odniesieniu do pierwotnej jego koncepcji. Głównie w generatorze 50Hz, który zbudowałem w oparciu o układ CMOS 4060 i TTL 7474. Poniżej mamy oryginalny schemat tego generatora, schemat dzielników częstotliwości oraz układu dekodera wyświetlaczy. W schemacie dzielników częstotliwości za wiele nie dało się uprościć. Natomiast w schemacie dekodera wyświetlaczy można było (co mi wówczas umknęło) wyeliminować trzy układy TTL 74154 zmieniając sterowanie tymi diodami na multipleksowe. Dekodery te są aktywowane sygnałami K1-K4 (kwadranse). Tymczasem sygnały te po inwersji i wzmocnieniu (tranzystor) poziomu logicznego można było wykorzystać do aktywowania jednej z czterech sekcji diod LED od strony anod. Natomiast od strony katod wszystkie cztery sekcje diod LED dołącza się do jednego demultipleksera 74154, eliminując pozostałe trzy demultipleksery 74154. W danym momencie świeci jedna dioda minutowa i godzinowa, więc wystarczy jeden rezystor ograniczający prąd dla każdej z tych diod. Zegar wyposażony jest dodatkowo w elektroniczne wahadło imitujące zapalaniem diod LED ruch prawdziwego wahadła. Drugim układem jest efekt dźwiękowy „tik – tak”. Głośnik jest wpięty w obwód kolektora tranzystora przez potencjometr umożliwiający „regulację głośności”. Nie ma diody zabezpieczającej tranzystor, który mimo to nie uległ uszkodzeniu. Być może dzięki temu potencjometrowi, który ograniczał wartość prądu przepięcia powstającego na cewce głośniczka. Również „mała” cewka głośniczka może nie generuje tak dużych przepięć jak cewka przekaźnika. Zegar wyposażony jest również skompilowany w budowie i obsłudze budzik. Dwa dekodery 74154 i dwa multipleksery 75150, które kod BCD dekodują na kod dziesiętny, po to aby porównać go z kodem BCD ustawionym na wejściach adresowych multiplekserów 75150. Osobno ustawia się godziny i minuty w kodzie BCD oraz kwadranse. Po zdekodowaniu czasu budzenia włączany jest generator. Tutaj początkowo przewidziałem multiwibrator monostabilny 74121, który miał włączyć generator sygnału budzenia na określony czas. Dźwięk oryginalnego generatora nie należał raczej do przyjemnych. Stąd pomysł, aby użyć układu odgrywającego 16 melodii UM3482M. Na płytce pojawiła się uproszczona wersja tej pozytywki. Jednak z jakiegoś powodu później zamontowałem tą pozytywkę na osobnej płytce. Być może ta uproszczona pozytywka nie działa poprawnie, a nie chciałem drugi raz wykonywać dużej płytki drukowanej i tak już zostało. Pozytywka włączana jest przez przekaźnik kontaktronowy. Jest on zbędny, ale myślałem przyszłościowo i jego drugi styk można wykorzystać do włączenia innego urządzenia. Później wykorzystałem go do włączania efektu świetlnego. Układ budzika można uprościć eliminując multipleksery i ich kłopotliwe ustawianie w kodzie BCD. Można je zastąpić przełącznikami SW DIP, lub zworkami goldpin wybierając, godzinę, minutę i kwadrans włączenia alarmu. Oryginalnie programator budzika wykonany jest na przełącznikach SW DIP umieszczony w plastikowej obudowie z tyłu, na zewnątrz obudowy zegara. Zasilacz na pięciu tranzystorach został zastąpiony układem LM7805. Do budowy zegara wykorzystywałem układy scalone TTL w wersji „LS” lub „L”. Wersja „LS” to wersja szybka o zmniejszonym poborze mocy. Wersja „L” to wersja o zmniejszonym poborze mocy. Trzeba bowiem wiedzieć, że układy cyfrowe TTL w w standardowej wersji są mocno prądożerne i jeden demultiplekser 74154 to może pobierać nawet około 60 mA prądu! Ostatecznie udało mi się zjeść z poborem prądu do około 0,8A. Z tego też powodu zegar nie ma podtrzymania bateryjnego. Głównym prądożercą są właśnie układy cyfrowe TTL. Choć w dzisiejszych czasach nie było by problemu z odpowiednim akumulatorem o małych wymiarach. Szczególnie w tak dużej obudowie. Stabilizator LM7805 mocno się nagrzewał i zastosowałem drugi stabilizator LM7812, który dostarcza napięcie do „efektu świetlnego” włączanego z budzikiem oraz wstępnie obniża napięcie dla układu LM7805. Transformator do zasilacza został przeze mnie przezwojony z transformatora z odzysku. Wykonanie zegara Zegary wykonałem trzydzieści lat temu w czasach kiedy wiedzę czerpało się z książek i czasopism, a komputery dopiero trafiały pod strzechy. Nie wypominając o programach EDA i internecie. Płytki drukowane których rysunki się zachowały powstały ręcznie na papierze do drukarki (płytka wyświetlacza) z użyciem szkolnych przyborów rysunkowych, linijki, cyrkla i kątomierza. Płytki malowane ręcznie i ręcznie wiercone. Projektując płytki miałem dylemat jak je zaprojektować. Czy diody LED umieścić poza płytką i łączyć przewodami, czy umieścić ja na płytce. Wybrałem to drugie rozwiązanie. Kolejny problem to długości ścieżek adresowych demultiplekserów 74154 na płytce wyświetlacza, które wynoszą około 60 cm! Układy TTL są podatne na zakłócenia i nie lubią tak długi połączeń. Później doszły kolejne długie połączenia między płytkami za pomocą przewodów. Aż dziw bierze, że zegar działa bez większych problemów. Płytki zegara. Kolejno od lewej, płytka wyświetlacza, płytka liczników i budzika i ostatnia mała płytka jako "poprawka" w odniesieniu do błędu w oryginalnym schemacie. Płytki efektu świetlnego - serduszka. Pierwsza od lewej płytka główna. Następna płytka to płytka wyświetlacza. Wnętrze zegara. Pierwsze zdjęcie od lewej, ogólny widok wnętrza zegara. Drugie zdjęcie zbliżenie na płytkę liczników. Trzecie zdjęcie Przełączniki SW DIP do ustawiania budzika. Pierwsze zdjęcie z lewej zbliżenie na płytkę wyświetlacza. W lewym górnym rogu wyświetlacza widoczna jest płytka pozytywki. W prawym górnym rogu płytki wyświetlacza widoczna jest płytka główna efektu świetlnego. Drugie zdjęcie zbliżenie na płytkę główną efektu świetlnego i dodatkowy zasilacz 12V z nietypowym radiatorem. Po wykonaniu płytek i wlutowaniu elementów połączyłem je na stole przewodami i nastąpiła próba. Zegar ruszył od razu, lecz obserwując jego wskazania błędnie były wskazywane godziny. Okazało się, że na oryginalnym schemacie jest błąd licznika godzin, którego to błędu nie zauważyłem. Mianowicie użyto licznika 7492 -układ U11, który pracuje w kodzie 6421 zamiast 8421. Stąd mała płytka przyklejona na płytce wyświetlacza (niebieska ramka na rysunku płytki wyświetlacza) z układami 7493 i 7400 (potrzebny był inwerter) korygujące ten błąd. Kilka tygodni później wykonałem obudowę zegara ze zdjęcia i umieściłem w niej zegar. Trymerem musiałem skorygować taktowanie generatora, aby zegar nie miał dużych odchyłek wskazań czasu. Również moje obawy dotyczące długich ścieżek na płytkach i długich połączeń kablowych okazały się na wyrost. Zegar pracował poprawnie pomimo braku kondensatorów odsprzedając zasilanie poszczególnych układów TTL. Choć jak pamiętam sporadycznie zdarzało się, że od zakłóceń z sieci energetycznej zegar się samoczynnie przestawiał. Poniżej film z działania tego zegara. Słabej jakości, na szybko nagrany kiepskim telefonem komórkowym Niestety zegara tego już nie mam i innych filmów i zdjęć nie mam jak zrobić. Kilka lat później powstały jaszcze dwa inne podobne pod względem obudowy zegary, które możemy zobaczyć poniżej. Dziś zupełnie inaczej bym wykonał ten zegar. Uprościł o kilka kolejnych układów TTL i zmieścił na jednej płytce drukowanej formatu kartki A4 lub nieco mniejszej. Zamontował bym go w obudowie w formie zbliżonej do ramki obrazu. Być może za płytą czołową z pleksi, aby było widać jego wnętrze na fabrycznie wykonanej płytce drukowanej, aby odpowiednio wyeksponować jego wnętrze. Projekt ten w dzisiejszych czasach nie jest wart naśladowania. Chyba, że w celach edukacyjnych. Również niektóre układy scalone TTL mogą być trudno dostępne, a ich cena niewspółmierna do ich funkcji i możliwości. Załączniki: 1. Wydruki PDF z Protel99SE.zip – wydruki PDF z wirtualnej drukarki z Protela 99 SE ze schematami i rysunkami płytek. Zostały one przerysowane około dziewięć lat później do Protela 99 SE. Nie były one sprawdzane praktycznie, a płytki zostały przerysowane bez synchronizacji ze schematem. Nie wykluczam więc ewentualnych błędów. Zegar RE_3-84.pdf.zip 2. Zegar RE_3-84.pdf.zip – skany oryginalnego projektu tego zegara z „Radioelektronika” 3/84 zapisane w pliku PDF liczącym cztery strony. Zegar RE_3-84.pdf.zip Wydruki PDF z Protel99SE.zip

Słowem wstępu, trzeba przyznać że tytuł artykułu sam w sobie jest dość kontrowersyjny. Dlaczego autorowi przyszło na myśl chwalić się najgorszą kartą graficzną na świecie, i to jeszcze drugą? Już spieszę z odpowiedzią: jest to moduł większego projektu, który jest dla mnie - autora - swego rodzaju wyzwaniem, dla czytelników - ciekawostką. A sprawa rozchodzi się o komputer ośmiobitowy. Jak zatem mogłaby wyglądać najgorsza karta graficzna? GeForce GT 210? Nie, pewnie jakiś radeon. Może zintegrowana grafika? W dobie XXI wieku już mało kto pamięta karty jeszcze starsze - stosowano niegdyś karty na szynach ISA, jak Trident TVGA-9000i (którego akurat posiadam). Karty te generowały obraz w rozdzielczości 640x480px, a przynajmniej przy trybie tekstowym. Przy trybie tekstowym, czyli karta generowała tylko i wyłącznie znaki, czasem tylko jednego koloru - lecz miała wtedy "fizycznie" największą rozdzielczość. Tryb graficzny umożliwiał kontrolę obrazu co do piksela i zmieniać nawet jego kolor, lecz wymagało to większej ilości zużycia RAMu - stąd tryby graficzne często były niższej rozdzielczości. Nie są to jednak karty najgorsze. Zainspirowany filmem Bena Eatera o jego "najgorszej karcie graficznej", postanowiłem samodzielnie zrobić takową kartę. Przyda się ona do zbudowania komputera ośmiobitowego, który już wcześniej zacząłem realizować, a że jeszcze przyszły mi płytki do rozlutu i były wakacje, był to całkiem dobry pomysł. Jak zatem prezentuje się karta? Źle. Na pewno teraz nasuwa się mnóstwo pytań czytelnikowi - więc już spieszę z opisem całości. Proces tworzenia karty zacząłem od postawienia założeń - na pewno nie chcę używać układów mocniejszych od Z80 (dla przykładu atmega 328p jest 16x mocniejsza od Z80), ponieważ nie ma to sensu - przerost formy nad treścią. Nie potrzebuję także trybu graficznego, chcę tylko terminal - więc tryb tekstowy mi wystarczy. Obraz chcę wyświetlać na monitorze kineskopowym (docelowo), więc chcę generować sygnał VGA. Kolor by się przydał, lecz priorytetem jest samo wyświetlanie znaków. Tak więc wiedziałem co chcę zrobić, musiałem się zastanowić jak. Najsampierw - zobaczyłem jaki sygnał należy generować. Tak więc, sygnał VGA to głównie 5 sygnałów - cyfrowa linia synchronizacji poziomej i pionowej, oraz 3 analogowe dla kolorów: czerwony, zielony i niebieski. Sygnał ten był opracowywany dla monitorów CRT, który obraz był generowany przez działko elektronowe, i sygnały cyfrowe tym działkiem sterują. Działko to pluje linię (display), po czym potrzebuje jeszcze chwili czasu (front porch), po czym - można powiedzieć - "synchronizuje się" z sygnałem (sync pulse), i wraca na początek linii (back porch). Całkiem podobnie jest dla linii synchronizacji pionowej. Kolory, jak już wcześniej wspomniałem, są sygnałem analogowym. Oznacza to, że im większe napięcie damy na ten sygnał, tym kolor będzie mocniejszy, a przy użyciu 3 sygnałów R, G i B - można te kolory łączyć. Jeżeli obraz nie jest wyświetlany, linie te powinny być podciągnięte do masy układu. I to w skrócie byłoby tyle - jeszcze rzut oka na czasy poszczególnych etapów sygnałów: Jak widać, aby uzyskać obraz 800x600 pikseli trzeba całość taktować aż czterdziestoma megahercami. Bramki logiczne, a i też niektóre mikrokontrolery nawet nie obsługują takich dużych częstotliwości - więc zdecydowałem się obniżyć ten zegar do 20MHz, co pozwoli uzyskać obraz 400x300 pikseli. Czasy zostają te same - lecz liczba pikseli się zmieni, co będzie bardzo ważną informacją w dalszej części artykułu. Wracając do układu Bena Eatera: on te czasy generował przy użyciu trzech liczników 4bit, potem porównywał konkretną liczbę z tych liczników, aby następnie sterować przerzutnikiem R/S dla linii synchronizacji. Ja uznałem "ale czemu tak komplikować sobie życie", zastosowałem jeden licznik binarny 12bit, a liczby porównywałem tylko logicznymi "jedynkami". Tak zatem wyglądają pierwsze dwa arkusze schematów: Pierwszy arkusz pokazuje kwestię zasilania, oraz złącz (karta będzie karmiona pięcioma woltami z zasilacza). Na złączu 40pin zaś znajdziemy ośmiobitową szynę danych, szesnastobitową szynę adresów, sygnały do wybierania jednego z 8 urządzeń, oraz piny WR i RD, odpowiadajace za operację zapisu i odczytu na wybranym urządzeniu. Złącze to łatwo można zdobyć z starych nagrywarek na szynie IDE, tasiemkę też - którą akurat kupiłem i skróciłem. Następny arkusz pokazuje licznik poziomy. Sam zegar na początku zrealizowałem przez układ 74HC14, z kwarcem 20MHz. Działał tylko po przyłożeniu palca (lub parówki) do styków kwarcu. Zamiast tego, generator sygnału 20MHz napędza licznik, który zlicza kolejno liczby w postaci binarnej. Liczby te sprawdzają bramki NAND, które interesują konkretnie 4 liczby: 400, 420, 484 i 528. Liczby te wziąłem z powyższej tabelki - a konkretnie po pierwszych 400 pikselach ustawiamy przerzutnik RS, dla wew. sygnału do wyświetlania pikseli. Sygnał HBLANK jest aktywny wtedy, kiedy nie powinny być wyświetlane żadne piksele. Następnie przy 420 pikselach ustawiamy kolejny przerzutnik, tym razem dla sygnału synchronizacji linii. Po 64 pikselach licznik ten jest resetowany, a przy 528 pikselu resetowany jest przerzutnik do wyświetlania pikseli, oraz resetowany sam licznik - następuje nowa linia, co jest też sygnałem taktującym dla zegara pionowego (sygnał jest przepuszczany przez bramkę NOT, ponieważ linia resetu i zegara jest aktywna w stanie wysokim). Tutaj też dość ważna informacja: na liczbę binarną składają się zarówno zera, jak i jedynki. Dlaczego zatem porównuję same jedynki? Każdy inny sygnał (który powinien być zerem) musiałbym podpiąć do bramki przez NOT, co by skutecznie powieliło ilość użytych układów. Porównywanie samych jedynek umożliwiło ominięcie tego, lecz "wybrana" liczba będzie występowała kilka razy. Nie ma to znaczenia i tak, ponieważ przerzutnik i tak został już ustawiony/zresetowany, a licznik jest potem resetowany. Tutaj jednak popełniłem kilka błędów. Do samej noty licznika (a nie samego pinoutu) zajrzałem duuużo później, gdzie przeczytałem, że liczniki te obsługują do 12MHz i to przy zasilaniu 15V (!) - tłumaczyło to wiele anomalii, lecz co ciekawe - zastosowanie liczników tych samych, lecz w wersji SMD zniwelowało wszelkie te anomalie. A że nie miałem pod ręką przejściówek z SO16 na DIP16, zrobiłem te śmieszne pajączki które widać na zdjęciu. Ważne że działa. Jest też jeszcze jeden błąd, który i ja popełniłem, i pan Eater popełnił: w informatyce zawsze się liczy od zera. Myślę że po wytłumaczeniu poprzedniego licznika, tutaj nie będzie niespodzianek. Jednak z racji tego, że na sygnał taktujący dostajemy 37.(87)kHz (zgodnie z tabelką), szukamy także pikseli podanych w tabelce: 600, 601, 605, 628. Technicznie rzecz biorąc pozwalałoby to na wyświetlanie obrazu 400x600px, lecz! Taka rozdzielczość byłaby troszkę niestandardowa, a litery byłyby mocno spłaszczone - przez co nieczytelne. Tak zaprojektowany i złożony układ prezentował się następująco: Generował on tylko i wyłącznie kolorowy ekran, lecz to już było coś. Problem zaczął w kwestii RAMu i ROMu. Zaczynając od RAMu, uznałem, że najlepiej będzie dodać licznik ósemkowy, który w połączeniu z bramkami AND, będzie po kolei sprawdzał każdy bit występujący na szynie danych pamięci ROM. W praktyce efekty okazały się co najmniej marne: Powinien się tutaj wyświetlać jeden znak, wykrzyknik, a dostałem... to. Potem spróbowałem czegoś podobnego lecz zamiast licznika ósemkowego - demultiplekser 74LS138. Bezskutecznie. Postanowiłem więc "wbudować" ten element karty do samej pamięci, marnując ją przy tym ogromnie: ponieważ obraz jest pobierany bezpośrednio z ROMu, wykorzystując przy tym jeden bit. A jest to pamięć ośmiobitowa. Tak więc zastosowany układ M27C1001, który jest pamięcią UV EPROM o pojemności 1Mbit, okazał się pomieścić "tylko" 4 tablice znaków po 255 znaków. A wygląda to tak: Linie adresu A0-A7 to wybór znaku, A8-A11 wybór linii, A12-A14 wybór kolumny, A15 - discord light theme, A16 - CP438, o którym mowa za chwilę. Pamięć samą w sobie zaprogramowałem wcześniej zrobionym i przerobionym programatorem, i mogę jeszcze powiedzieć, że mimo wersji o czasie odczytu do 100ns, wszystko działa sprawnie (a powinien być niższy od 50ns). Nawiązując jeszcze do samego wykonania płytki: przy projektowaniu schematu, nie wiedziałem do końca czy on zadziała. Dlatego nie trawiłem żadnych płytek, lecz całość wykonałem na płytkach prototypowych. Zasilanie doprowadzam górą, kynarami; sygnały zaś doprowadzam drutem 0.12mm z silniczka, który już się prawie skończył... Wracając: akurat się tak złożyło, że znak będzie duży na 8x16 (2³ x 2⁴) pikseli, co przy ekranie 400x300 pozwoli na wyświetlanie 50x18 znaków, nawet nieźle jak na gołe bramki logiczne. Po podpięciu pamięci RAM obraz wyglądał tak: Są to losowe znaki, co wynika z tego że pamięć RAM przy włączeniu zawiera losowe dane. A, nie powiedziałem jeszcze o samej tablicy znaków. Mocno inspirując się klasyczną, dosową czcionką, tak wygląda cała tablica znaków: Wykorzystując dodatkowy bit adresu pamięci EPROM, pozwoliłem sobie na zapis nowej tablicy znaków: CP438, gdzie standardowe znaki alfabetu są zastąpione przez Standardowy Alfabet Galaktyczny. Następnie w Processingu zrobiłem prosty program konwertujący piksele obrazu w tablicę zmiennych typu byte, jak docelowo miały być zapisywane znaki, a następnie tablicę tę skopiowałem do programatora. Niestety, nie opracowałem jeszcze zapisu z komputera, lecz na pewno będę musiał prędzej czy później zrobić - na chwilę obecną, programy muszą być mniejsze od pamięci samej atmegi. Więc skoro pamięć RAM i ROM już działała, to czego do szczęścia jeszcze trzeba? Ano, potrzebujemy coś zapisać do tej karty! I tutaj zaczęły się prawdziwe schody. Problem polega w tym, że pamięć RAM jest ciągle odczytywana przez timery. Przerwanie ich będzie skutkowało też przerwaniem wyświetlania obrazu. No i niestety, ale tak jest, ponieważ nie mam pomysłu jak inaczej wymyślić zapis. Tak więc, do odcinania timerów od RAMu służą tutaj bufory trójstanowe - 74HC245 i 244 (takie miałem pod ręką). Ale, zwykłe linie adresów i danych też trzeba było odciąć - więc musiałem zastosować tutaj 8 układów po 16 nóżek, więc lutownicą się namachałem. Na moje szczęście, powyższy schemat zadziałał za pierwszym razem. Jednak przez rozbieg, pomiędzy pamięć ROM i RAM dałem także bufor - jeżeli wstawiłbym tam zatrzask, to w najszczęśliwszym wypadku (zapis krótszy niż 0.4us) nie byłoby nic widać. Jednak zatrzask skutecznie by pozwolil zredukować liczbę anomalii, ale mimo wszystko tragedii nie ma przy zastosowaniu "zwykłego" bufora. Jak widać, proces zapisu jest aktywowany tylko, kiedy i linia zapisu i linia wyboru urządzenia są w stanie niskim - jest to realizowane bramką OR. Tak więc bufory są, wszystko jest, ale... kartę trzeba było jakoś sprawdzić. Jako, że płytkę z samym Z80 będę lutował później, na razie zapis przeprowadza Arduino MEGA (jeszcze raz: ono służy TYLKO do testowania karty, nie do generowania obrazu!), i karta działa zadziwiająco dobrze: Obraz jest monochromatyczny; zastosowanie palety kolorów byłoby ciekawym wyzwaniem. Kolor wybiera się przełącznikiem DIP przy złączu VGA. Ciekawa rzecz też była kiedy na początku źle zapisałem pamięć, na odwrót... Niestety, występuje także kilka anomalii. Lewy brzeg ekranu jest okupowany przez zgliczowane piksele, przez które najlepiej cały obraz jest przesunąć o znak w prawo. Pamięć ROM także wypaliłem w niezbyt komfortowych dla niej warunkach, więc piksele nie są do końca dobrze wypalone. Ciekawą anomalią są też te paski z tyłu, które występują tak trochę sinusoidalnie? Są stałe, rezystory pulldown i pullup nic nie dają... ale jeżeli sygnał koloru prześle przez płytkę stykową, linie magicznie znikają! Kiedy dostanę porządny oscyloskop (obecnie mam przystawkę hanteka, która mierzy tylko w kHz), głębiej to zbadam. Wiem też, że karta jest mocno wrażliwa na zakłócenia, np. z kabla USB czy oscyloskopu. Cały kod i obliczenia (dokumentację) udostępnię dopiero kiedy je sobie uporządkuję, bo kod arduino jest bardzo nieoptymalny, a obliczenia rozsiane po notesie... jak to pozbieram, wyślę na GitHuba, a całość opiszę po angielsku. EDIT: link do githuba Tak czy siak; karta jest gotowa, i może pracować razem z Z80, lub jako osobny moduł dla takiego Arduino (jak wiemy z poprzedniej konstrukcji, atmega nie do końca sobie radzi z VGA...) Wniosek: zostawić stare układy TTL, kupić płytkę z FPGA i się uczyć z forbotowego kursu. discord light theme