Jakiś czas temu złożyłem amatorski komputerek ośmiobitowy na procesorze
8080 (a właściie polskim MCY7880) i zabrałem się za uruchamianie na nim
CP/M. Całość była złożona na płytce prototypowej, więc teraz zabrałem
się za budowę bardziej finalnej wersji, przy okazji przenosząc się na
8085. Udało mi się uruchomić większość peryferiów i przenieść kod z
wersji prototypowej. Tak naprawdę wymagane były tylko niewielkie zmiany
- np. niektóre peryferia znajdują się teraz pod innymi adresami.

W przypadku karty CF trafiłem jednak na ścianę. Z jakiegoś powodu nie
jestem w stanie odczytać ani informacji o karcie (przychodzą bzdury, a
powinna się wyświetlać jej nazwa) ani sektora rozruchowego (kod nie
znajduje poprawnych wartości w MBR). Najwyraźniej jednak komunikacja
pomiędzy kartą i systemem działa, bo:
1. Jestem w stanie zainicjować kartę, a w trakcie operacji zmienia się
zawartość odczytywanego rejestru STATUS.
2. Przy próbie odczytu danych z karty zapala się na chwilę dioda na
linii DASP.

Rzucił mi się w oczy jeszcze jeden dziwny szczegół. Dobrałem kwarc tak
samo, aby zegar systemowy był dokładnie taki sam w wersji na 8080 i 8085
(2,048 MHz). Z jakiegoś powodu pojawiło się inne zachowanie karty, jeśli
chodzi o timeout podczas jej inicjacji. Timeout to dwie pętle na
rejestrach B i C. W wersji na 8080 rejestr C miał początkową wartość 32,
a B był przy każdym przebiegu inicjowany wartością 255.
W przypadku konstrukcji na 8085 jednak to nie wystarczało i musiałem
podbić rejestr C do 64, żeby inicjacja miała szanse przejść.

Patrzę na schemat i nie mogę znaleźć żadnej różnicy w połączeniach. Kod
jak mówiłem został przeniesiony ze starego projektu, zmienił się tylko
adres karty.

Ktoś ma pomysł gdzie szukać przyczyny?

do góry

On Fri, 3 Jan 2025 23:28:08 +0100, Atlantis wrote:

> Jakiś czas temu złożyłem amatorski komputerek ośmiobitowy na procesorze
> 8080 (a właściie polskim MCY7880) i zabrałem się za uruchamianie na nim
> CP/M. Całość była złożona na płytce prototypowej, więc teraz zabrałem
> się za budowę bardziej finalnej wersji, przy okazji przenosząc się na
> 8085. Udało mi się uruchomić większość peryferiów i przenieść kod z
> wersji prototypowej. Tak naprawdę wymagane były tylko niewielkie zmiany
> - np. niektóre peryferia znajdują się teraz pod innymi adresami.
>
> W przypadku karty CF trafiłem jednak na ścianę. Z jakiegoś powodu nie
> jestem w stanie odczytać ani informacji o karcie (przychodzą bzdury, a
> powinna się wyświetlać jej nazwa) ani sektora rozruchowego (kod nie
> znajduje poprawnych wartości w MBR). Najwyraźniej jednak komunikacja
> pomiędzy kartą i systemem działa, bo:
> 1. Jestem w stanie zainicjować kartę, a w trakcie operacji zmienia się
> zawartość odczytywanego rejestru STATUS.
> 2. Przy próbie odczytu danych z karty zapala się na chwilę dioda na
> linii DASP.
>
> Rzucił mi się w oczy jeszcze jeden dziwny szczegół. Dobrałem kwarc tak
> samo, aby zegar systemowy był dokładnie taki sam w wersji na 8080 i 8085
> (2,048 MHz). Z jakiegoś powodu pojawiło się inne zachowanie karty, jeśli
> chodzi o timeout podczas jej inicjacji. Timeout to dwie pętle na
> rejestrach B i C. W wersji na 8080 rejestr C miał początkową wartość 32,
> a B był przy każdym przebiegu inicjowany wartością 255.
> W przypadku konstrukcji na 8085 jednak to nie wystarczało i musiałem
> podbić rejestr C do 64, żeby inicjacja miała szanse przejść.

Roznic w czasach instrukcji chyba nie ma ..

>
> Patrzę na schemat i nie mogę znaleźć żadnej różnicy w połączeniach. Kod
> jak mówiłem został przeniesiony ze starego projektu, zmienił się tylko
> adres karty.
>
> Ktoś ma pomysł gdzie szukać przyczyny?

a) kwarc Ci sie wzbudził na overtonie i masz 6MHz?
choc pasowałoby raczej 4MHz.

b) jesli mnie skleroza nie myli system 8080 wymagał kwarca znacznie
szybszego, który był dzielony w innej kosci. Rozumiem, że dobrałej
odpowiednio?

c) a nie zapomniałej zmienic adresu w jakiejs instrukcji?

d) Use Z80, Luke :-)

e) Use ARM, Luke :-)

J.

do góry

On 4.01.2025 01:01, J.F wrote:

> Roznic w czasach instrukcji chyba nie ma ..

Nie, z tego co kojarzę to 8080 i 8085 są ze sobą kompatybilne
programowo. Są pewne różnice sprzętowe, które musiałem uwzględnić.
Przykładowo system z 8080 posiada osobne linie IO_RD, IO_WR, MEM_RD i
MEM_WR, generowane przez kontroler magistrali 8228. 8085 posiada tylko
linie WR i RD, których funkcja jest zależna od stanu pinu IOM. Musiałem
więc wygenerować sobie osobne linie dla IO oraz pamięci, za pomocą
GAL-a. Ale raczej to nie tutaj leży przyczyna, bo wszystkie inne
testowane peryferia działają poprawnie.


> a) kwarc Ci sie wzbudził na overtonie i masz 6MHz?
> choc pasowałoby raczej 4MHz.

Sprawdzone oscyloskopem. Na linii CLK mam poprawną częstotliwość 2,048 MHz.


> b) jesli mnie skleroza nie myli system 8080 wymagał kwarca znacznie
> szybszego, który był dzielony w innej kosci. Rozumiem, że dobrałej
> odpowiednio?

Tak, wziąłem to pod uwagę. W przypadku 8080 częstotliwość kwarcu była
dzielona dziewięć razy, więc do uzyskania 2,048 MHz potrzebny był kwarc
18,432 MHz. W przypadku 8085 dzielona jest tylko dwa razy, wiec dałem
kwarc 4,096 MHz.


> c) a nie zapomniałej zmienic adresu w jakiejs instrukcji?

Nie wydaje mi się. W projekcie mam wydzielony osobny plik
definitions.asm, w którym znajdują się rozmaite parametry, które mogą
się różnić pomiędzy poszczególnymi wersjami. W przypadku karty CF różni
się tylko CFBASE - adresy poszczególnych rejestrów są generowane przez
dodanie kolejnych liczb do tej bazy. A ten adres się zgadza. W dodatku
gdyby się nie zgadzał, karta w ogóle nie byłaby wykrywana i nie
reagowałaby na próbę inicjacji.

Dodatkowo:
1. Przeszukałem diffem kod źródłowy z obydwu wersji. Nie widzę żadnych
różnic w okolicach związanych z kartą CF.
2. Złożyłem dwa egzemplarze płytki. Różnią się niewielkimi detalami, ale
część z kartą CF jest taka sama. Problem jest powtarzalny na obydwu
płytkach.
3. Zapomniałem dodać, że linie D0..D7 są podłączone do karty CF za
pośrednictwem układu 74HCT245 (pin DIR do IO_RD, pin G do sygnału CS
karty). To jest właśnie efekt eksperymentów na wersji prototypowej,
gdzie nie byłem w stanie uzyskać stabilnych transmisji - czasem jakiś
bajt został zgubiony lub przekłamany. Po dodaniu bufora wszystko zaczęło
działać stabilnie i poprawnie, wiec uwzględniłem go także w wersji na 8085.

Hmm... Teraz właśnie dotarło do mnie, że w sumie pomiędzy wersjami jest
istotna różnica - linie D0..D7 w 8085 są multipleksowane z młodszym
bajtem magistrali adresowej. Może sterując buforem powinienem uwzględnić
jeszcze sygnał ALE, żeby był zamknięty w momencie, gdy na liniach danych
są linie adresowe?


> d) Use Z80, Luke :-)

Jest też taki plan, jednak 8085 wydawał się prostszym krokiem z poziomu
już istniejącego projektu na 8080.


> e) Use ARM, Luke :-)

E tam, ARM nie pasuje do retro. :)

do góry

W dniu 4.01.2025 o 09:06, Atlantis pisze:
> Hmm... Teraz właśnie dotarło do mnie, że w sumie pomiędzy wersjami jest
> istotna różnica - linie D0..D7 w 8085 są multipleksowane z młodszym
> bajtem magistrali adresowej. Może sterując buforem powinienem uwzględnić
> jeszcze sygnał ALE, żeby był zamknięty w momencie, gdy na liniach danych
>  są linie adresowe?
Wg mnie to będzie jedyna przyczyna, dane musisz zatrzaskiwać tym ALE.

--
Janusz

do góry

On 4.01.2025 11:43, Janusz wrote:

> Wg mnie to będzie jedyna przyczyna, dane musisz zatrzaskiwać tym ALE.

Samo ALE to chyba za mało. W tej chwili polegam tylko na sygnale IO_RD
do ustawiania kierunku transferu - jeśli linia jest w stanie niskim, to
mamy odczyt z karty, jeśli jest wysoka, to zapis do niej.
Gdybym w takim wypadku użył ALE do sterowania pinem G, to za każdym
razem gdy tylko na liniach D0..D7 pojawiałyby się dane, bufor otwierałby
się w którąś stronę. Pół biedy, gdyby linia IO_RD znajdowała się wtedy w
stanie wysokim - karta by po prostu zignorowała to co pojawi się na
magistrali, nie widząc aktywnych sygnałów CS i RD. Jednak gdyby kierunek
bufora był ustawiony w przeciwną stronę, to wtedy pojawi się następująca
sytuacja:
1. ALE otworzy bufor.
2. IO_RD ustawi kierunek od karty do magistrali systemowej.
3. Karta nie widząc sygnału CS, będzie trzymała swoje wyjścia danych w
stanie wysokiej impedancji. Przez bufor na magistralę trafią więc stany
nieustalone.

Trochę poeksperymentowałem, dodając trochę logiki do GAL-a. Na chwilę
obecną wygląda to tak:

/MEMRD = /IOM * /RD
/MEMWR = /IOM * /WR
/IORD = IOM * /RD
/IOWR = IOM * /WR
/LOCPTCS = /LOCIOCS * /A4 * IOM * /WR
/LOCCFCS = /LOCIOCS * A4 * IOM * /ALE

Rzeczy, których mogę być pewien:
- Poprawnie działa generowanie sygnałów MEMRD i MEMWR, bo pamięci
działają poprawnie i kod z EPROM-u się wykonuje.
- Poprawnie działa generowanie sygnałów IORD i IOWR, bo peryferia (poza
kartą) działają poprawnie. Mogę odczytywać i zapisywać z/do nich dane.
- Poprawnie działa przynajmniej kawałek dekodera adresów, bo linia
LOCPTCS (sterująca portem 74273) działa poprawnie.

Tylko z kartą są problemy. Bufor wydaje się być najbardziej oczywistym
kandydatem, bo to główna różnica w stosunku do innych peryferiów.
Zastanawiam się teraz czy przypadkiem nie mam jakiegoś problemu z
timingami i któryś sygnał nie pojawia się za wcześnie lub za późno.
Przykładowo w chwili obecnej sygnał CS steruje zarówno kartą, jak i
otwarciem bufora (linia G). Może powinienem to jakoś rozdzielić?

Nie wiem czy w akcie desperacji nie wywalę w ogóle tymczasowo bufora i
nie połączę linii danych bezpośrednio. Widziałbym przynajmniej czy coś
się zmieniło i czy jest poprawa. W prototypie na 8080 karta działała bez
bufora w miarę ok, ale od czasu do czasu pojawiały się przekłamania w
transmisjach.

do góry

Ok, w ramach eksperymentu usunąłem bufor i podłaczyłem kartę
bezpośrednio do magistrali systemowej. Problem nadal występuje. Teraz
już w ogóle nie mam pojęcia co może być nie tak. W wersji z 8080 bez
bufora odczyt był niestabilny, ale przynajmniej był...

do góry

Czytam jeszcze informacje w Intenrecie, na temat podłączania karty CF do
starych systemów mikroprocesorowych i z tego co widzę, pojawia się też
temat opóźniania linii RD. Niektórzy proponują dodanie niewielkiego
filtra RC, inni stosują dodatkową logikę (np. do synchronizacji RD z
kolejnym impulsem na linii CLK).
Skoro nie w buforze, to może tutaj leży przyczyna. Możliwe, że w
przypadku prototypu sprawę załatwiały pojemności i indukcyjności
montażowe - karta CF znajdowała się na osobnym module, a montaż był
wykonany na płytkach uniwersalnych, za pomocą kynaru. W nowej wersji
slot CF znajduje się tuż przy procesorze, a płytka jest wytrawiona.

do góry

On Sun, 5 Jan 2025 18:52:00 +0100, Atlantis <m...@w...com>
wrote:
> starych systemów mikroprocesorowych i z tego co widzę, pojawia się
> też
> temat opóźniania linii RD.

Nie bez powodu np. w niektórych peryferiach jest slope config czy
np. w spi konfiguracja momentu próbkowania linii SDI
(middle/beginning/end).

--
Marek

do góry

On 6.01.2025 07:32, Marek wrote:

> Nie bez powodu np.  w niektórych peryferiach jest slope config czy np. w
> spi konfiguracja momentu próbkowania linii SDI (middle/beginning/end).

Najwyraźniej to jeszcze ciągle nie to. Dodałem opóźnienie na linii RD
karty, korzystając z niewykorzystanego pinu układu GAL. Linijka
realizującego to kodu wygląda następująco:

DELCFRD.R = IORD

W wyniku tego stan linii IORD jest zatrzaskiwany na wyjściu DELCDRD za
pomocą zegara systemowego.

Sprawdziłem na oscyloskopie - linia DELCFRD faktycznie przechodzi w stan
niski jeden cykl zegarowy później, ale przejście do stanu wysokiego
następuje dwa cykle po linii IORD.
Co ciekawe rozwiązanie to nie chciało zadziałać na ATF16VB - linia
DELCFRD była cały czas w stanie wysokim. Za to na starym GAL16VA nie ma
tego problemu.

Niestety, nic się nie zmieniło w zachowaniu karty. Dioda nadal błyska,
wskazując na próbę odczytu, nie są jednak odczytywane sensowne dane.

Połączenia w tej chwili wyglądają następująco:
1. Magistrala danych podłączona przez dwukierunkowy bufor 74HCT245
2. Kierunkiem bufora steruje linia IORD (ogólnosystemowa, nieopóźniona)
3. Sygnałem G bufora steruje linia CS karty CF
4. Sygnałem RD karty CF steruje opóźniony sygnał DELCFRD, generowany w
GAL-u według powyższego opisu
5. Sygrałem WR karty CF steruje sygnał IOWR (równiez ogólnosystemowy,
nieopóźniony)

Na chwilę obecną kończą mi się już pomysły...

do góry

Ok, już po napisaniu poprzedniej wiadomości udało mi się rozwiązać
problem z wydłużaniem opóźnionego sygnału RD dla karty. Wystarczyło
dodać XOR wyjścia flip-flopa z jego wejściem. Niestety kosztowało mnie
to jedną linię GAL16V8A. W lepszym układzie dałoby się to ogarnąć za
pomocą wejścia asynchronous set, ale niestety ten konkretny GAL takiego
nie posiada.

Problem nadal występuje. Niemniej w artykułach z sieci widzę, że ludzie
dodają opóźnienie także opóźnienie na linii WR. Tego też spróbuję. Nawet
jeśli nie zadziała, to pewnie i tak zostawię te opóźnienia w projekcie,
dla zapewniania lepszej kompatybilności z kartami (gdy już uda mi się
rozwiązać główny problem).

Przy okazji widzę, że mogę trochę zoptymalizować projekt odziedziczony
po wersji z 8080. W tej chwili nie ma chociażby sensu generowanie
osobnych linii IORD/IOWR, skoro dekoder adresów IO jest bramkowany
sygnałem IOM. Sygnały MEMWR/MEMWR zostawię, bo przerobienie dekodera
adresów dla pamięci byłoby trochę bardziej kłopotliwe.

do góry