8085 i karta CF

[Atlantis]

Wróciłem ostatnio to własnych projektów retro i próbuję uruchomić kolejny komputerek pracujący pod kontrolą CP/M. Projekt jest do pewnego momentu oparty na moim wcześniejszym projekcie na 8080, gdzie również miałem problemy z kartą CF (opisywany tutaj). Tym razem jednak zastosowałem procesor 8085.
Generalnie na chwilę obecną działa wszystko za wyjątkiem właśnie wspomnianej karty CF. Jestem w stanie odpalić TinyBasic i wykonywać w nim programy. Działają peryferia, a to pozwala mi sądzić, że dekodowanie adresów również pracuje poprawnie. Niestety nie jestem w stanie odczytać danych z karty. Jakaś komunikacja pomiędzy nią i systemem występuje, bo po uruchomieniu komputera, podczas inicjacji karty na chwilę zapala się dioda aktywności. Niestety, ani nazwa karty ani MBR nie zostają odczytane poprawnie. Kod sterownika karty jest sprawdzony, bo pochodzi z wcześniejszego komputera na 8080.

Połączenia wyglądają następująco:
Linie D0..D7 są buforowane za pomocą 74HCT245. Kierunek bufora określa linia RD (nieopóźniona), a jego aktywację przeprowadza sygnał CF_CS z dekodera adresów I/O. Dekoder jest bramkowany linią IO_M, więc nie będzie dochodziło do aktywacji bufora podczas odczytów z pamięci. Generalnie układ połączeń bufora pochodzi z komputera na 8080, gdzie nie tylko działał bez problemu, ale rozwiązał problemy z kartą. Próbowałem podłączyć kartę z pominięciem bufora, ale problem nie zniknął.

Linie RD oraz WR dla karty są opóźnione o jeden cykl zegara (praktyka zalecana przy interfejsowaniu kart CF ze starymi procesorami). Na oscyloskopie faktycznie widać, że linie przechodzą w stan niski nieco później od linii systemowych, ale wracaja do wysokiego w tym samym momencie. Czyli działają tak, jak powinny.
Opóźnienie jest zrealizowane za pomocą układu GAL16V8A, za pomocą następujących równań:

Kod: [Zaznacz]

DCFRDFF.R = RD
DELCFRD = DCFRDFF # RD
DCFWRFF.R = WR
DELCFWR = DCFWRFF # WR

Żeby nie było niejasności - próbowałem też używać karty ze zwykłymi sygnałami RD/WR, bez opóźnień. Nic to nie zmieniło.

Sygnał CS karty pochodzi z dekodera adresów - to ten sam sygnał, który odblokowuje bufor.

Mam dwa egzemplarze tego komputerka. Problem występuje na każdym z nich. Próbowałem też podmieniać procesor na inne egzemplarze, w tym w wersji CMOS. Nic nie pomaga.
Ktoś ma jakiś pomysł gdzie mógłbym szukać przyczyny takiego stanu rzeczy?

[Atlantis]

Ok. Wygląda na to, że udało mi się znaleźć prawdopodobną przyczynę. Przyjrzałem się bliżej sygnałowi CS, aktywującemu kartę CF. Wygląda na to, że są na nim obecne zakłócenia w postaci krótkich szpilek przeciwnego stanu - jeśli CS jest niski, te szpilki przyjmują stan wysoki, jeśli jest wysoki, szpilki są w kierunku stanu niskiego. Prześledziłem inne sygnały CS z dekodera adresów IO (74HCT138) i widzę, że na kilku innych liniach (ale nie wszystkich) taki stan rzeczy także występuje. Szukając dalej doszedłem do wniosku, że źródłem tych szpilek są niższe linie adresowe (A0..A7), zatrzaskiwane w rejestrze (74HCT573). Okazuje się, że obecność szpilek jest faktycznie skorelowana czasowo z narastającym zboczem sygnału ALE, przy czym nie są one obecne zawsze - czasami zamiast pełnej szpilki widać w tym miejscu tylko niewielkie zakłócenia w postaci chwilowego szumu na linii. Próbowałem wstawić niewielki filtr RC (1k, 100pF) na linię ALE, jednak w żaden sposób to nie pomogło - zbocza tego sygnału co prawda stały się mniej strome, jednak szpilki na liniach adresowych nie zniknęły.
Wyższe linie adresowe (A8..A15), które nie są multipleksowane z magistralą danych są wolne od jakichkolwiek zakłóceń.
Ktoś ma pomysł w jaki sposób wyeliminować ten problem?

[Zegar]

Specjalistą od CF jest kolega @tapy, więc zapytaj go. Pomagał mi kiedyś uruchomić jeden komputer z CF i przy okazji przeczytałem trochę jego materiałów. Dużo zależy od konkretnego egzemplarza karty.

[tapy]

Ktoś ma pomysł w jaki sposób wyeliminować ten problem?

Po prostu użyj 74HCT374 bez negacji sygnału zatrzaskiwania. Prawdopodobnie w czasach kiedy panowała technologia LS to zatrzaski sterowane poziomem były bardziej odporne na zakłócenia, dlatego było zalecane użycie 74x373. Rodzina HCT jest na tyle szybka, że zatrzask sterowany narastającym zboczem działa dobrze, podobny zabieg stosuję w Z280 i nie obserwuję takich objawów.

[Atlantis]

Po prostu użyj 74HCT374 bez negacji sygnału zatrzaskiwania. Prawdopodobnie w czasach kiedy panowała technologia LS to zatrzaski sterowane poziomem były bardziej odporne na zakłócenia, dlatego było zalecane użycie 74x373. Rodzina HCT jest na tyle szybka, że zatrzask sterowany narastającym zboczem działa dobrze, podobny zabieg stosuję w Z280 i nie obserwuję takich objawów.

Hmm... Też o tym pomyślałem, ale mam pewne wątpliwości. Czy przypadkiem nie jest tak, że:

• 74573 posiada pin LE. Gdy ten znajduje się w stanie wysokim, stan wejść jest przekazywany na wyjścia w czasie rzeczywistym. Stany te są zatrzaskiwane dopiero na zboczu opadającym LE.
• 74574 posiada pin CK. Stan wejść jest zatrzaskiwany na wyjściach jest zatrzaskiwany od razu na zboczu narastającym CK.

Obecnie mam 74HCT573.
Na oscyloskopie widzę, że szpilki na liniach A0..A7 korelują ze zboczami narastającymi ALE. Wychodzi więc na to, że linie AD0...AD7 przez chwilę nie zdążą się jeszcze ustabilizować, gdy linia ALE już idzie do góry, przez do przez moment na linie A0..A7 trafia stara zawartość linii D0..D7 lub stany nieustalone, co objawia się w postaci szpilki. Po chwili sytuacja się stabilizuje, szpilka znika, a gdy ALE przechodzi w stan niski, właściwe adresy zostają zatrzaśnięte.
Obawiam się, że bezpośrednia podmiana układu na 74HCT574 może pogorszyć sytuację - dalej będę miał niepoprawny stan na liniach AD0..AD7 w momencie narastającego zbocza ALE. Tym razem jednak nie zostanie on na moment przekazany na wyjścia - zostanie on na nich od razu zatrzaśnięty. Tak więc zamiast krótkich szpilek na A0..A7, będę miał na nich w ogóle przekłamane stany. A to już może skutecznie sabotować działanie całego systemu. Wydaje mi się, że aby podmiana miała sens, konieczne byłoby wykonanie jeszcze jednego kroku - wprowadzenie lekkiego opóźnienia na linii ALE, aby dać czas na ustalenie się właściwych stanów na wejściach, przed ich zatrzaśnięciem.

Czy moje rozumowanie jest poprawne?

Ewentualnie mógłbym jeszcze też spróbować nieco opóźnić aktywację dekodera adresów IO (74HCT138), który obecnie jest aktywowany wysokim stanem linii IO_M. Gdyby wstawić tam jakąś linię opóźniającą, szpilki przynajmniej nie propagowałyby na linie CS. Jednak to półśrodek, gdyż zakłócenia cały czas byłyby obecne na dolnej połowie magistrali adresów.

Po głowie chodzi mi też alternatywna hipoteza. Czy przypadkiem podobnego zachowania nie mogą powodować problemy z prowadzeniem/filtrowaniem zasilania? W sensie może to spadek napięcia w momencie zmiany stanu wszystkich linii jednocześnie powoduje chwilowe "szarpnięcie"?

[tapy]

Tak, jakość zasilania ma tu kluczowe znaczenie. Przełączanie TTL nawet w technologii CMOS to znaczne jego szarpnięcie.

Spojrzałem do noty katalogowej 80C85 i z niej wynika że wprowadzenie opóźnienia sygnału ALE przy zastosowaniu zatrzasków sterowanych zboczem może skończyć się katastrofą. Od strony CPU stan linii AD0-AD7 jako dolna część adresu musi być stabilna do zakończenia aktywności sygnału ALE. Niepokojąca jest informacja: "przez moment na linie A0..A7 trafia stara zawartość linii D0..D7 lub stany nieustalone", bo to może oznaczać że trop problemu z zasilaniem jest wielce prawdopodobny. Stany nieustalone linii AD0-AD7 chwilę po zakończeniu cyklu ALE (które muszą się pojawiać w trakcie przełączenia w CPU adres->dane) nie mają wpływu na zachowanie podłączonych urządzeń na szynie (sygnały RD,WR są dopiero w cyklu T2).

Dopisek: Rzeczywiście w przypadku 8085 to jednak zostawiłbym 74x573, bo to będzie lepsze rozwiązanie. Nigdy się nie zagłębiałem głębiej w ten temat i wychodzi na to że zastosowałeś bardziej optymalne rozwiązanie. Jeśli jest to procesor NMOS to pull-up na szynie AD0-AD7 może rozwiązać problem.

[Atlantis]

Od strony CPU stan linii AD0-AD7 jako dolna część adresu musi być stabilna do zakończenia aktywności sygnału ALE. Niepokojąca jest informacja: "przez moment na linie A0..A7 trafia stara zawartość linii D0..D7 lub stany nieustalone", bo to może oznaczać że trop problemu z zasilaniem jest wielce prawdopodobny.

Zasilanie to jedna z możliwości. Jednak wydaje mi się, że czas propagacji sygnałów też może mieć znaczenie. Linia ALE stanowi krótki kawałek ścieżki pomiędzy CPU i rejestrem, który znajduje się tuż obok. Linie D0..D7 natomiast rozciągają się na dwóch jednostronnych płytkach (a więc prowadzenie ścieżek wymaga stosowania mostków z kynaru), które są połączone taśmą. Tak więc pojemności montażowe będą większe.
Z punktu widzenia CPU może to wyglądać tak, że linia ALE zostaje podniesiona dopiero wtedy, gdy na AD0...AD7 trafił już młodszy bajt adresu. W rzeczywistości jednak czasy propagacji będą inne i ALE wyprzedzi ustabilizowanie się tych sygnałów.

Stany nieustalone linii AD0-AD7 chwilę po zakończeniu cyklu ALE (które muszą się pojawiać w trakcie przełączenia w CPU adres->dane) nie mają wpływu na zachowanie podłączonych urządzeń na szynie (sygnały RD,WR są dopiero w cyklu T2).

A stany nieustalone na początku sygnału ALE, które powodują powstawania opisanych szpilek?
Nie jestem nawet pewien czy faktycznie te szpilki na A0..A7 są powodem moich problemów z kartą CF, ale zwyczajnie nie widzę żadnego innego problemu. Karta CF otrzymuje opóźnione sygnały RD i WR opóźnione o jeden cykl zegara (za pomocą dodatkowej logiki zaimplementowanej w GAL). Jednak okolica karty CF jest wyjątkowa pod jednym względem - posiada bufor 74245, którego kierunek jest ustawiany linią RD (systemową, nieopóźnioną) a aktywacja następuje za pomocą linii CS karty CF. Tak więc teoretycznie chyba istnieje możliwość, że szpilka namiesza coś w komunikacji.
Z drugiej strony zrobiłem eksperyment z zupełnym usunięciem bufora i karta CF nadal nie chciała działać prawidłowo.

Dopisek: Rzeczywiście w przypadku 8085 to jednak zostawiłbym 74x573, bo to będzie lepsze rozwiązanie. Nigdy się nie zagłębiałem głębiej w ten temat i wychodzi na to że zastosowałeś bardziej optymalne rozwiązanie. Jeśli jest to procesor NMOS to pull-up na szynie AD0-AD7 może rozwiązać problem.

Tak, procesor jest w wersji NMOS. Niemniej robiłem też eksperment z 80C85 i problem z kartą nie zniknął. Nie wiem czy szpilki były obecne na niższych liniach magistrali adresowej, bo wtedy tego jeszcze nie sprawdzałem.
Może faktycznie spróbuję dodać pull-upy na liniach AD0..AD7. Nie przeszkodzi to w późniejszym dodaniu DMA (8257) do komputera?

[tapy]

Nie, pull-up nie szkodzą. Ba! W przypadku istnienia i korzystania z odrębnego układu DMA w systemie są one wymagane nawet dla linii sterujących (w trakcie zwalniania magistrali i sygnałów sterujących WR,RD,IOM,... przez CPU występują stany nieustalone, nim kontrolę nad nimi przejmie układ DMA, co może prowadzić do nadpisania informacji w pamięci lub układów IO). Ta uwaga odnosi się do dowolnej technologii wykonania CPU oraz jego architektury (CPU z wbudowanym DMA nie cierpią na tą przypadłość).

Stany nieustalone (szpilki) w cyklach gdy nie następuje odczyt/zapis/przyjęcie przerwania są naturalną cechą praktycznie każdego mikroprocesora. To co dzieje się na magistrali przed sygnałem ALE nie ma znaczenia, w omawianym przypadku zapewne te zakłócenia nie generują sygnału CS dla karty CF, więc to nie one są problemem z odczytem karty. Opcjonalnym rozwiązaniem zmniejszenia tych pasożytniczych sygnałów jest zastosowanie niewielkich rezystorów (~10R) na każdą linię (w przypadku HD63C09 jest to nawet zalecenie producenta CPU, co prawda trochę z innego powodu, ale efekt będzie taki sam).

[Atlantis]

Nie, pull-up nie szkodzą. Ba! W przypadku istnienia i korzystania z odrębnego układu DMA w systemie są one wymagane nawet dla linii sterujących (w trakcie zwalniania magistrali i sygnałów sterujących WR,RD,IOM,... przez CPU występują stany nieustalone, nim kontrolę nad nimi przejmie układ DMA, co może prowadzić do nadpisania informacji w pamięci lub układów IO). Ta uwaga odnosi się do dowolnej technologii wykonania CPU oraz jego architektury (CPU z wbudowanym DMA nie cierpią na tą przypadłość).

Ok, w takim razie dla świętego spokoju dodam miejsce na pull-upy w kolejnej wersji płytki.
Przed chwilą podciągnąłem linie AD0..AD7 do VCC za pomocą drabinki rezystorowej 4,7k. Nic się nie zmieniło. Karta CF nadal nie działa poprawnie, szpilki na liniach A0..A7 oraz CS są widoczne. Wrzucam oscylogramy.

Stany nieustalone (szpilki) w cyklach gdy nie następuje odczyt/zapis/przyjęcie przerwania są naturalną cechą praktycznie każdego mikroprocesora. To co dzieje się na magistrali przed sygnałem ALE nie ma znaczenia

Tylko tutaj szpilki są widoczne w na zboczu narastającym sygnału ALE i w początkowej fazie jego trwania. Czy również mogę założyć, że nie maja one znaczenia, skoro nie pokrywają się z przejściami RD/WR w stan niski?

w omawianym przypadku zapewne te zakłócenia nie generują sygnału CS dla karty CF, więc to nie one są problemem z odczytem karty.

Rozumiem, że karta CF zignoruje chwilowe przejście linii CS w stan niski, jeśli jednocześnie linie RD i WR pozostaną w stanie wysokim? W żaden sposób nie wpłynie to na jej wewnętrzną maszynę stanów i nie zakłóci aktualnie przeprowadzanej operacji? W sumie bufor 74HCT245 na liniach D0..D7 karty także nie powinien mieć z tym problemu. Jego kierunkiem steruje linia RD. W momencie wystąpienia szpilki będzie ona w stanie wysokim, więc w najgorszym razie chwilowe otwarcie bufora (sygnałem CF_CS) wystawi w kierunku karty aktualną wartość na magistrali. Jednak bez (opóźnionego zresztą) sygnału WR dla karty, ta nie powinna niczego z tym faktem zrobić.

Ok, czyli wygląda na to, że szpilki faktycznie były fałszywym tropem. Tylko w takim razie co może powodować takie zachowanie karty? Gdzie szukać przyczyny. Jak mówiłem - mam bufor na liniach danych oraz opóźnione sygnały RD/WR - lekarstwa na najczęstsze problemy z kartami CF w systemach retro. Część software'owa została przeniesiona z przetestowanego systemu na 8080, gdzie karta działa poprawnie (tam też miałem problemy, ale pomógł właśnie bufor). Komunikacja z kartą w jakimś stopniu działa (bo przy inicjacji na chwilę zapala się dioda), po prostu przy próbie odczytu danych dostaję śmieci.

Masz jakiś pomysł co może być nie tak i jak to dalej debugować? Bo mi już kończą się pomysły. Uznałbym, że może to jakiś błąd w montażu, ale po pierwsze nie widzę niczego podejrzanego, a poza tym złożyłem dwa egzemplarze i obydwa zachowują się tak samo.

EDIT:
W ramach eksperymentu dodałem jeszcze małe (22uF) kondensatory elektrolityczne przy pinach VCC karty CF, jej bufora oraz rejestru 74HCT573. Dodatkowo zasilanie w te miejsca podprowadziłem osobnymi przewodami.
Niestety, nic się nie zmieniło. W TinyBasicu jestem w stanie pisać do i odczytywać wartości z rejestrów karty, jednak z jakiegoś powodu próba zainicjowania systemu CP/M wywala się już na etapie odczytania informacji o karcie oraz sektora MBR.

[damik]

Testowałeś to tylko na jednej karcie CF czy na różnych rodzajach innych modeli kart?
Z doświadczenia wiem że niektóre karty CF są bardziej oporne niż inne i to z różnych powodów.

[Waldek]

Na innym forum dotyczącym mikrokontrolerów również były problemy z kartą SD dotyczące operacji odczytu i zapisu.
Rozwiązanie było proste, dodatkowe przesianie 3V3 do czytnika kart.
Może i w tym przypadku to pomoże 

[Atlantis]

Testowałeś to tylko na jednej karcie CF czy na różnych rodzajach innych modeli kart?
Z doświadczenia wiem że niektóre karty CF są bardziej oporne niż inne i to z różnych powodów.

Przetestowałem na wszystkich kartach, które posiadam. Wszystkie z nich działały poprawnie (przynajmniej przy pobieżnych testach) na starszym systemie z 8080.
To znaczy na 8080 początkowo też miałem problemy z kapryśnością niektórych kart, ale tam rozwiązało je dodanie bufora na liniach danych. I nawet wtedy te problemy nie były aż tak oczywiste - komunikacja z kartą działała, po prostu raz na jakiś czas dochodziło do przekłamania w transmisji jednego bajtu czy dwóch.

Na innym forum dotyczącym mikrokontrolerów również były problemy z kartą SD dotyczące operacji odczytu i zapisu.
Rozwiązanie było proste, dodatkowe przesianie 3V3 do czytnika kart.
Może i w tym przypadku to pomoże 

U mnie to jest karta CF, tak więc jest jest zasilana z 5V. Przy jej pinach VCC już teraz znajduje się kondensator 100 nF, a wczoraj w ramach eksperymentu dodałem jeszcze elektrolit 22 uF i podciągnąłem zasilanie osobnym przewodem z punktu bliżej zasilacza. Może z ciekawości dodam jeszcze mały rezystor, ale szczerze mówiąc wątpię żeby wina leżała po stronie zasilania.

Tak szczerze mówiąc to te szpilki na liniach sdresowych i sygnale CS nie dają mi spokoju. Niby nie korelują one z sygnałami RD i WR, ale to jak dotąd jedyna anomalia, którą udało mi się namierzyć.

[Waldek]

Chwileczkę!
Używasz karty CF z gniazdem czy tego chińskiego adaptera CF na IDE?
W adapterze brakowało gdzieś połączenia z Vcc.

[Waldek]

Nie!
Teraz napisałem bzdury.
Problem z brakującą linią na module CF do IDE dotyczył interfejsu DivIDE, sorry.

[Atlantis]

Używasz karty CF z gniazdem czy tego chińskiego adaptera CF na IDE?

Używam gniazdka na kartę CF na płytce własnego projektu. Gniazdko ze sprawdzonego źródła (DigiKey) i przetestowane już w kilku projektach. Schemat i znaczna część układu ścieżek zresztą też.
Jeśli chodzi o szpilki na liniach A0..A7 oraz CS, to udało mi się ich pozbyć. Rozwiązanie okazało się być bardzo proste - wystarczyło zastosować 74HCT574 (zamiast 573) i zatrzaskiwać dolny bajt magistrali adresowej za pomocą zanegowanego sygnału ALE. Teraz adres jest aktualizowany już po ustabilizowaniu sygnałów na liniach AD0..AD7. Pojawia się w związku z tym pewne opóźnienie, ale i tak adres (i co za tym idzie sygnał CS) jest dostępny na długo przed ustawieniem linii RD/WR.

Komputer w takim układzie działa prawidłowo, niestety problem z kartą CF nadal występuje. Przynajmniej tyle, że można wykluczyć te nieszczęsne szpilki jako przyczynę...