Niestabilna praca komputera retro/DIY - rodziny ukła

Wróciłem ostatnio do jednego z moich starych projektów, komputerka retro na polskim procesorze MCY7880. Jego pierwotna wersja została zmontowana na płytkach uniwersalnych, z zastosowaniem dużej ilości kynaru.

formatting link
Bez większych problemów udało mi się na nim odpalić TinyBASIC-a, a potem dodać kontroler ekranu i klawiatury AT. Wszystko działało tak, jak powinno.

W międzyczasie zacząłem projektować bardziej finalną wersję, zmontowaną na dwóch (finalnie trzech) płytkach drukowanych (ręcznie trawionych, jednostronnych, z dużą liczbą kynarowych mostków po stronie elementów).

formatting link
Ta wersja jest już bardziej rozbudowana - dodałem chociażby kontroler DMA.

Po odpaleniu okazało się jednak, że występują pewne problemy. TinyBsic zgłasza się na porcie szeregowym. Jednak zazwyczaj komputer zawiesza się już po otrzymaniu pojedynczego znaku (i odesłaniu echa). Czasem jednak (bardzo rzadko) udawało mi się trafić na moment, kiedy komputer pracował na tyle długo, że udawało mi się wbić kawałek kodu w BASIC-u. Nigdy jednak nie pracował na tyle długo, żebym był w stanie wprowadzić choćby wypisywanie czegoś w pętli - komputer wieszał się zanim zdążyłem wykonać "RUN".

Najwyraźniej problem jest związany z aktywnością użytkownika, bo jeśli nie będę robił nic po resecie, to komputer sam z siebie się nie zawiesi. Będzie czekał na wysłanie pierwszego znaku i (zazwyczaj) zawiesi się właśnie dopiero po odesłaniu echa.

Początkowo sądziłem, że wina może leżeć po stronie zbyt cienkich kabli zasilających. Jednak po ich wyminie na znacznie grubsze problem wciąż występuje.

Komputerek składa się z dwóch płytek. Jedna zawiera procesor, bufory szyny adresowej, pamięci RAM oraz ROM, dekoder adresów, a także jeden port wyjściowy za pomoc którego można migać dwiema diodami. Jeśli odpalam tę pojedynczą płytkę z jakimś prostym programem do migania diodami - wszystko zdaje się działać stabilnie. Problemy najwyraźniej pojawiają się po podpięciu drugiej płytki, która zwiera peryferia (DMA, RTC, UART 8251, timer 8253, kontroler klawiatury

8242, kontroler przerwań 8259), przy próbie odpalenia TinyBasic'a.

Czy możliwe, że winę za taki stan rzeczy ponoszą układy z rodziny 74HCT, zastosowane w dekoderach adresów i innej "pomocniczej" logice? Wydawało mi się, że są one zgodne ze starą elektroniką z czasów TTL, ale może jednak NMOS-y od CEMI nie bardzo będą z nimi współpracowały? Bo chyba pamięci SRAM na 100ns nie będą zbyt wolne dla systemu na 8080...

Ktoś ma jakieś sugestie co do dalszego debugowania? Powinienem się czemuś przyjrzeć za pomoc analizatora stanów logicznych lub oscyloskopu?

Reply to
Atlantis
Loading thread data ...

[...]

weź oscyloskop i sprawdź jak wyglądają zbocza sygnałów. czy nie ma "dzwonienia", czy nie pojawiają sie oscylacje tam, gdzie powinien być stan stabilny. zakładam, że każdy układ ma odpowiedni kondensator blokujący.

co do pamięci i czasu dostępu, to sprawdź analizatorem zależności czasowe pomiędzy sygnałami CE, RD i WR a stanami na szynie danych. 100ns wydaje się dość dużo, da się jakieś wait stat'y dodać w konfiguracji CPU?

a.

Reply to
Arrmii

W dniu 2021-07-21 o 17:16, Atlantis pisze:

W pierwszej kolejności chciałbym pogratulować samozaparcia :)

Układy HCT są robione w technologii CMOS. Teoretycznie są kompatybilne z układami TTL, które  zarówno pod względem topografii jak i napięć poziomów logicznych. Jednakże posiadają część wad układów CMOS czyli większe pojemności wejściowe, które wymagają przeładowania i zwiększenie czasó propagacji przy sterowaniu z układów TTL, wrażliwość  na pozostawienie niepodłączonych wejść oraz podłączenie do wyjść typu OC. HCT tak jak podstawowa seria CMOS musi mieć wejścia wszystkich bramek podłączone czy to do +Vcc lub GND. Także tych nieużywanych. Pozostawione takie, niepodłączone wejścia mogą generować zakłócenia pozostałych bramek w skutek nieustalonych stanów przejściowych, kiedy to układ mocno obciąża zasilanie.

Widzę, że przy większości układów masz zblokowane zasilanie kondensatorami 100nF, ale nie wszystkie. W przypadku układów TTL jest to bardzo ważne.

Szkoda, że nie zamieściłeś schematów.

Sprzęgasz układy bezpośrednio? Używasz translatorów poziomów? Używasz jakieś układy w wersji OC np. drivery? Jakimi częstotliwościami taktujesz?

Reply to
Uzytkownik

Użytkownik "Atlantis" napisał w wiadomości grup dyskusyjnych:60f83a38$0$559$ snipped-for-privacy@news.neostrada.pl...

Czyli nalezy sie domyslac, ze schemat i program sa poprawne ?

A nie - to schemat niekoniecznie jest poprawny. Ale program sprawdzony...

Tak ogolnie:

-nie widze kondensatorow blokujacych, dodaj. troche elektrolitow na zasilaniu tez dodaj.

-mam zle doswiadczenia z wieloplytkowcami, jakies cuda potrafia latac po masach. no ale duza ilosc komputerow tak zrobiona,

-zwolnij zegar dwa razy - zobaczy sie, czy to jakas praca na krawedzi mozliwosci,

-mozna probowac chlodzic czy podgrzewac elementy.

Ale to mi wyglada na jakis inny problem - prawie dziala. "Zawieszenie" domyslam sie, ze diagnozujesz po tych migajacych diodach - to wcale nie musi byc prawdziwe zawieszenie.

Dobrze byloby sprawdzic analizatorem czy oscyloskopem co sie dzieje w czasie takiego zawieszenia.

A poza tym, to przeciez znasz pare powodow - luzna podstawka, podgieta nozka.

Zobacz co sie dzieje na magistrali. Czyta rozkazy czy nie, z jakich adresow.

J.

Reply to
J.F.

Zarówno jedno, jak i drugie jest dostępne na GitHubie - link wrzuciłem w pierwszej wiadomości w tym temacie. Od wczoraj przeprowadziłem kilka eksperymentów. Udało mi się stwierdzić, że z jakiegoś powodu usunięcie kontrolera klawiatury 8242 przywraca prawidłową pracę komputera. W kodzie kontroler nie jest ani inicjowany, ani używany (wszystkie wywołania procedur z nim związanych są zakomentowane). Układ ten co prawda steruje jeszcze bramkami dwóch timerów z 8253 (tym odpowiedzialnym za zliczanie "ticków" oraz generowanie dźwięku) ale te funkcje także nie są wykorzystywane. Nie uruchomiłem także jeszcze kontrolera przerwań 8259, który nie jest inicjowany, a globalne przerwania są wyłączone.

Kondensatory blokujące jak najbardziej są. Elektrolitów również trochę zastosowałem. Po prostu na schemacie nie są umieszczone przy układach, ale wydzielone na osobnym bloku (górna część schematów).

Reply to
Atlantis

Dziękuję. ;)

Opierasz się na nagraniu z YouTube'a? Spokojnie, kondensatory blokujące są przy wszystkich układach, przynajmniej mam nadzieję, że żadnego nie pominąłem. Po prostu nie widać wszystkich, ponieważ dla ułatwienia montażu (i oszczędzenia sobie wiercenia) w większości przypadków zastosowałem kondensatory SMD po drugiej stronie płytki. ;)

Są na GotHubie, do którego link wrzuciłem w pierwszej wiadomości.

Nie używam driverów OC. To znaczy w paru miejscach miałem linie OC (chyba przerwanie RTC miało wyjście tego typu), to dawałem tam rezystory podciągające. Częstotliwość taktowania dość standardowa dla systemów z

8080 - coś koło 1,8 MHz. Dokładnie nie pamiętam, sprawdzę.
Reply to
Atlantis

Zrobiłem jeszcze kilka testów. Okazuje się, że próba włączenia przerwań także blokuje komputer, przy czym dzieje się to w nieco inny sposób, niż w przypadku 8242.

1) Jeśli zostawię w podstawce 8242, to komputer (zazwyczaj) wyświetla test powitalny i czeka na polecenia. Zawiesza się (zwykle) po wprowadzeniu pierwszego znaku i odesłaniu echa. W rzadkich przypadkach działa na tyle długo, że mogę wprowadzić więcej. 2) Jeśli próbuję uruchomić przerwania (konfiguracja 8259 + instrukcja EI) komputer zawiesza się już po włączeniu zasilania i nie dochodzi nawet do napisu powitalnego.

Nie sądzę, aby obydwa przypadki były ze sobą związane, chociaż wykluczyć tego nie mogę. Podejrzewam, że problem z przerwaniami może wynikać z faktu, że pomyliłem się przenosząc projekt z prototypu. Jeszcze raz rzucę na to okiem.

Co powoduje problem z kontrolerem klawiatury - nie mam pojęcia. Teoretycznie dwie linie GPIO układu 8242 są wykorzystane do sterowania bramkami timera 8253 (konkretnie tymi odpowiedzialnymi za dźwięk oraz "systick"). Niemniej problem występuje nawet wtedy, gdy przerwania są wyłączne, a więc żaden timer nie powinien zablokować systemu.

Reply to
Atlantis

Problem z przerwaniami udało mi się rozwiązać. Okazało się, że był zupełnie programowy - przenosząc kod z prototypu o nieco innej architekturze (która przejawiała się nieco innym układem połączeń przerwań z poszczególnych urządzeń) pomyliłem się przy ustawianiu maski aktywnych przerwań. Dodatkowo debugowania nie ułatwił fakt, że razem z

8042 podczas testów usunąłem znajdujący się przy nim 7406 zapominając, że jeden z inwerterów użyłem na linii przerwania RTC.

Problemu z kontrolerem klawiatury nie udało mi się rozwiązać. Komputer nadal wiesza się, jeśli włożę 8242 w podstawkę.

Reply to
Atlantis

Dnia Sat, 24 Jul 2021 09:42:15 +0200, Atlantis napisał(a):

Jak to mowia - zrodlo problemu jest z reguly pol metra od monitora :-)

Szukaj dalej, pewnie jest przyczyna.

J.

Reply to
J.F.

Ale ile osob zrealizowalo i potwierdzilo, ze dziala ?

A tak w ogole - rzuc to hobby, zajmij sie ARM, to ma jakas przyszlosc :-)

Patrzylem na tym filmie z YT.

J.

Reply to
J.F.

Dnia Thu, 22 Jul 2021 12:04:49 +0200, Atlantis napisał(a):

A te znaki to wprowadzasz z klawiatury, czy portem szeregowym? A co sie w programie dzieje po odeslanu echa?

Co moze oznaczac, ze masz przerwania stale wyzwolone. Zobacz linie INT na procesorze, a pote poszczegolne IR na 8259.

Dosc prawdopodobne, ze to wszystko sa problemy z przerwaniami.

I cos mi chodzi po glowie, ze 8259 mial przerwania wyzwalane poziomem wysokim, wiec trzeba pull-down rezystor dac, albo edge trigerred ustawic.

Zakladajac, ze 8242 nie miesza na magistrali danych. Moglby przy zlym dekoderze adresow, czy przy szybkim zegarze.

No i tak patrze na schemat CPU ... sygnal AEN jest generowany przez IC3/Busen? Dochodzi m.in. do IC9 i generuje CS_2 z A7..5.

Na plycie IO CS_2 dochodzi do IC4B i generuje KBD_CS, ale do IC3 8242 dochodza sygnaly RD i WR, a nie IO_RD i IO_WR !!!

Jesli ten blad jest takze w rzeczywstosci, to az dziwne, ze choc troche komputer dziala ... musial program omijac zagrozone obszary pamieci.

J.

Reply to
J.F.

Zrobiłem kilka kolejnych testów. Na chwilę obecną zostawiłem tylko jedno aktywne przerwanie (od RTC). Przerwanie od timera wyłączyłem, bo wejście GATE tego timera powinno być sterowane przez 8242, z którym obecnie mam problemy. W kodzie zakomentowałem wywołanie funkcji inicjującej działanie 8242.

Na chwilę obecną samo włożenie 8242 po podstawki powoduje, że komputer przestaje działać (nie wyświetla się napis powitalny). Wyjęcie układu z podstawki przywraca zupełnie normalną pracę.

Sprawdziłem na egzemplarzu 8042 przetestowanym w innym, działającym układzie i z nim komputer zachowywał się identycznie.

Ponieważ identyczny problem mam w dwóch takich samych, równolegle budowanych komputerach podejrzewam, że wina musi leżeć gdzieś po stronie kodu albo schematu. Przy czym patrząc w jedno i drugie nie widzę niczego podejrzanego.

Reply to
Atlantis

Dzięki! To musi być to. Patrzyłem na ten schemat dziesiątki razy, a tak oczywistego błędu nie zauważyłem. No cóż... Będę musiał zrobić obejścia kynarem. ;)

Reply to
Atlantis

Na STM32 też zrobię czasem jakiś projekt, chociaż ciągle jeszcze moją ulubioną rodziną MCU są PIC32. ;)

Reply to
Atlantis

Albo wywalic 8242. Skoro i tak wyjscie jest na terminal, to po co jakas klawiatura :-)

J.

Reply to
J.F.

Widac w tej kompilacji stosowne fragmenty kodu trafily w zagrozone adresy pamieci :-)

J.

Reply to
J.F.

Bo to jest ciągle "work in progress". Docelowo ma do tego powstać jeszcze jedna płytka, na której znajdzie się kontroler ekranu (i być może kontroler stacji dyskietek). Prototyp złożony na płytce prototypowej już dostał kontroler ekranu, ale zrobiony na bardzo prostym w implementacji układzie TMS9918, który służył jako kontroler ekranu w komputerach MSX (a więc był już projektowany m.in. z myślą o grach). W finalnej wersji chciałbym jednak zastosować coś bardziej pasującego "klimatem" do ery komputerów na 8080. ;)

Docelowo chciałbym to przenieść na płytę w formacie mATX, ale nie wiem czy wystarczy mi czasu i ochoty. ;)

Reply to
Atlantis

Atlantisie, ale po co? Ja rozumiem, ze ktos chce Spectrum miec i przypomniec sobie gry z mlodosci. Albo wnukom pokazac - tak kiedys komputer wygladal.

Ja rozumiem, ze mozna wziac FPGA i zrobic trzy komputery z mlodosci w jednym. Fajny projekt ... aby wnukom pokazac.

Ale robic przestarzaly komputer bez oprogramowania? Po co? CP/M odpalic? jest emulator.

J.

Reply to
J.F.

Taka moda. Pół jutjuba projektuje teraz retro komputery... :-) Z najciekawszych jakie ostatnio widziałem jest Cerberus 2080 z 6502 i Z80, dual port RAM i CPLD do generowania video i innych funkcji

formatting link

Reply to
Cezar

Bo teraz można to robić relatywnie łatwo i tanio. Oczywiście o ile ktoś nie przesadzi tak jak ja i nie zacznie składać komputera na 8080. ;) Na początku lat dziewięćdziesiątych niejeden elektronik amator chciałby sobie złożyć CA-80, ale problemem było często samo zdobycie części. Dzisiaj te elementy można dostać za bezcen na Allegro - kupienie Z80, pamięci SRAM, EPROM-ów czy garści układów logicznych nie jest problemem. Dwadzieścia-trzydzieści lat temu układy GAL właściwie nie były dostępne do hobbystów. Teraz można za rozsądną cenę kupić CPLD i FPGA. Ne wspominając o narzędziach w stylu programatorów, symulatorów EPROM czy analizatorów stanów logicznych. No i samo rozwijanie kodu stało się znacznie prostsze w momencie, gdy ma się GitHuba, współczesny komputer i współczesne kompilatory. Nowe gry i dema na Spectrum powstają cały czas, ale przecież nikt ich nie pisze n gumowej klawiaturze. ;)

Jest tego całe mnóstwo. Kolejny klon Spectrum powstaje pewnie co parę miesięcy. ;) W tej chwili chyba najciekawszym projektem będzie Commander X16 - projekt inspirowany C64, ale mocno uwspółcześniony, zbudowany w formie płyty ATX.

Zauważyłem, że powstaje też trochę projektów na 68k - z obsługą pamięci SIMM, zdolnych do odpaleni Linuxa.

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.