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.

https://hackaday.io/project/161333-polon-7880

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).

https://www.youtube.com/watch?v=CoANjd3YkHU
https://github.com/marekw1986/POLON7880

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?

do góry

On Wednesday, July 21, 2021 at 5:16:12 PM UTC+2, Atlantis wrote:
> Wróciłem ostatnio do jednego z moich starych projektów, komputerka retro
> na polskim procesorze MCY7880.
>
[...]
> Ktoś ma jakieś sugestie co do dalszego debugowania? Powinienem się
> czemuś przyjrzeć za pomoc analizatora stanów logicznych lub oscyloskopu?

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.

do góry

W dniu 2021-07-21 o 17:16, Atlantis pisze:
> 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?

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?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:60f83a38$0$559$6...@n...neostrada.
pl...
>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.

>https://hackaday.io/project/161333-polon-7880

>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.

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

>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).

>https://www.youtube.com/watch?v=CoANjd3YkHU
>https://github.com/marekw1986/POLON7880

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

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

>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.

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.

>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?

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

J.

do góry

On 22.07.2021 00:04, J.F. wrote:

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

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.



> Tak ogolnie:
> -nie widze kondensatorow blokujacych, dodaj. troche elektrolitow na
> zasilaniu tez dodaj.

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).

do góry

On 21.07.2021 23:49, Uzytkownik wrote:

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

Dziękuję. ;)


> 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.

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. ;)


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

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


> 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?

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ę.

do góry

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.

do góry

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ę.

do góry

Dnia Sat, 24 Jul 2021 09:42:15 +0200, Atlantis napisał(a):
> 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.

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

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

Szukaj dalej, pewnie jest przyczyna.

J.

do góry

Dnia Thu, 22 Jul 2021 10:09:31 +0200, Atlantis napisał(a):
> On 22.07.2021 00:04, J.F. wrote:
>> Czyli nalezy sie domyslac, ze schemat i program sa poprawne ?
>
> Zarówno jedno, jak i drugie jest dostępne na GitHubie - link wrzuciłem w
> pierwszej wiadomości w tym temacie.

Ale ile osob zrealizowalo i potwierdzilo, ze dziala ?

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

>> Tak ogolnie:
>> -nie widze kondensatorow blokujacych, dodaj. troche elektrolitow na
>> zasilaniu tez dodaj.
>
> 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).

Patrzylem na tym filmie z YT.

J.

do góry