Ok, przeanalizowałem jeszcze raz sytuację za pomocą oscyloskopu i wydaje
mi się, że znalazłem potencjalną przyczynę.

Na linii CS karty CF widać krótkie szpilki. Gdy linia jest w stanie
wysokim, przechodzi na krótki moment do stanu niskiego, gdy natomiast
znajduje się w stanie niskim, przechodzi na moment do wysokiego.
Sprawdziłem inne sygnały z dekodera IO (74HTC138) i podobną sytuację
widać także na niektórych (obecnie niewykorzystywanych liniach CS).

Wygląda na to, że źródłem tych zakłóceń jest linia adresowa A5, ale
podobne szpilki widzę także na innych liniach z mniej znaczącego bajtu
linii adresowych (a więc multipleksowanego z magistralą danych). Więcej
znaczące linie adresowe wyglądają zupełnie czysto. Momenty wystąpienia
tych zakłóceń korelują narastającym zboczem sygnału ALE. Czasami widać
to jako wyraźną szpilkę wyraźnej zmiany stanu, ale często też w tych
punktach widać jedynie drobne wahania sygnału.

Wygląda na to, że szpilki są za krótkie, żeby zakłócić działanie retro
peryferiów (jak 8251 albo 8253) ale już karta CF rejestruje je jako
normalny sygnał aktywacji i stąd zaburzona komunikacja. Przynajmniej
taka hipoteza wydaje się być sensowna.

Problem jest powtarzalny - występuje na dwóch egzemplarzach urządzenia.

Ktoś spotkał się z czymś takim? Zastanawiam się jak temu przeciwdziałać.
Opóźnić aktywację rejestru 74HCT573 (trzymającego dolny bajt adresu) za
pomocą jakiegoś filtra RC na linii ALE? A może winny jest rejestr z
rodziny HCT, który działa za szybko?

do góry

On 15.01.2025 18:03, Atlantis wrote:

> Wygląda na to, że źródłem tych zakłóceń jest linia adresowa A5,

Ale to jakaś wyjątkowo dziwnie jest poprowadzona? Zbocza ma szczególnie
ostre? Dlaczego tylko ona? Nie szarpie zasilaniem? Sygnały, które
zakłóca typu OC są ze słabymi pull-upami? ...choć jeśli to się dzieje w
obydwie strony to bardziej to na hazard wygląda.

--
Mirek

do góry

On 15.01.2025 18:56, Mirek wrote:

> Ale to jakaś wyjątkowo dziwnie jest poprowadzona? Zbocza ma szczególnie
> ostre? Dlaczego tylko ona?

Nie wyraziłem się dostatecznie jasno. Problem nie dotyczy tylko linii
A5, a całego niższego bajtu magistrali adresowej (który w 8085 jest
multipleskowany z magistralą danych). Po prostu po linii A5 te szpilki
przez 74HCT138 propagują na linię CS karty.
Wygląda na to, że miejsca występowania szpilek korelują z narastającym
zboczem sygnału ALE, który zatrzaskuje młodszy bajt adresu w układzie
74HCT573. Przy czym nie jest tak, że każdy impuls na ALE = jedna
szpilka. Czasem w tych miejsach widoczny jest jedynie lekki szum na
liniach adresowych, a czasami w ogóle nie widać szpilek.

W ramach eksperymentu próbowałem dodać filtr RC (330om, 100pF) na linii
ALE. Jednak o ile zbocza sygnału się wygładziły, to problem ze szpilkami
na liniach adresowych nie zniknął.

do góry

On 15.01.2025 20:34, Atlantis wrote:

> Nie wyraziłem się dostatecznie jasno. Problem nie dotyczy tylko linii
> A5, a całego niższego bajtu magistrali adresowej (który w 8085 jest
> multipleskowany z magistralą danych).

A ten 573 odfiltrowany dobrze?
Czyli on jest źródłem szpilek?.
ALE jest tylko do niego?
No dobra, a jak 8085 wystawi ALE, to linie do 573 zmieniają natychmiast
stan? - chodzi mi o to czy ta zmiana jest jakoś skorelowana ze szpilkami.


> Po prostu po linii A5 te szpilki
> przez 74HCT138 propagują na linię CS karty.[...]

> ramach eksperymentu próbowałem dodać filtr RC (330om, 100pF) na linii
> ALE. Jednak o ile zbocza sygnału się wygładziły, to problem ze szpilkami
> na liniach adresowych nie zniknął.

To ja bym próbował kondensatory dawać na A5, na CS...

A jak wyglądają czasy tych szpilek w porównaniu do taktu procesora?


--
Mirek

do góry

On 15.01.2025 21:05, Mirek wrote:

> A ten 573 odfiltrowany dobrze?

Masz na myśli zasilanie? Standardowo (jak każdy układ scalony w
projekcie) ma kondensator 100 nF do masy przy pinie VCC. Jednak jak
przyjrzałem się projektowi płytki, to może faktycznie moża by w tej
okolicy dać jakiś mały elektrolit i poprowadzić zasilanie jakaś krótszą
drogą z okolicy miejsca podpięcia zasilacza. To samo z masą...


> Czyli on jest źródłem szpilek?.

Na to wygląda. Na wyjściach 74HCT573 pojawiają się po raz pierwszy i
stamtąd propagują na dekoder adresów IO.


> ALE jest tylko do niego?

Tak.


> No dobra, a jak 8085 wystawi ALE, to linie do 573 zmieniają natychmiast
> stan? - chodzi mi o to czy ta zmiana jest jakoś skorelowana ze szpilkami.

Jeśli dobrze rozumiem działanie 74573, to w stanie wysokim na wejściu LE
będzie on po prostu powtarzał stany wejść na wyjściach. Zatrzaśnięcie
następuje dopiero wraz ze zboczem opadającym na LE. Czyli mamy do
czynienia z następującą sytuacją:
- Procesor ustawia stan wysoki na ALE.
- Na liniach AD0..AD7 nie zdążyły się jeszcze ustalić właściwe poziomu
odpowiadające dolnemu bajtowi adresu. Przez chwil mamy tam stare dane z
D0..D7 albo stany nieustalone. Mogą to tłumaczyć np. pojemności
montażowe - magistrala rozciąga się na dwie płytki, podczas gdy sygnał
ALE to krótka ścieżka pomiędzy dwoma sąsiadujacymi scalakami.
- Przez moment ten niepoprawny, niestabilny stan jest widoczny na
wyjściach 74573 (bo w stanie wysokim LE jest on przezroczysty), co
objawia się w postaci szpilki.
- Po chwili sytuacja się stabilizuje, na wyjścia przekazywane są już
właściwe sygnały, a na zboczu opadającym ALE następuje ich zatrzaśnięcie.
- To też tłumaczyć dlaczego szpilki nie są widoczne przy każdym impulsie
na ALE. Raz na jakiś czas po prostu zdarza się, że poprzedni stan jest
zgodny z tym, co finalnie ma się znaleźć na danej linii Ax.


> To ja bym próbował kondensatory dawać na A5, na CS...

Tak, ale to będzie tylko walka z objawem, a nie przyczyną.
Przy założeniu, że powyższa diagnoza jest prawidłowa, powinienem opóźnić
moment, w którym 74HCT573 widzi stan wysoki na ALE, żeby linie AD0..AD7
miały czas się ustabilizować. Temu miał służyć filtr na tej linii, ale
może zwyczajnie dałem za małe opóźnienie? Albo zamiast filtra RC
powinienem dać jakąś linię opóźniającą na bramkach/inwertorach?


> A jak wyglądają czasy tych szpilek w porównaniu do taktu procesora?

Są znacząco krótsze od czasów trwania normalnych sygnałów w tym
systemie. Wydaje mi się, że właśnie dlatego nie wpływają na działanie
innych komponentów, poza kartą CF. Stare peryferia w stylu 8251 albo
8253 zwyczajnie ignorują tak krótkie anomalie na liniach CF, podczas gdy
(relatywnie) współczesna karta CF jest już na tyle szybka, że
interpretuje je jako normalny sygnał aktywacji, co miesza w komunikacji
z nią.

do góry

On Thu, 16 Jan 2025 09:38:03 +0100, Atlantis wrote:
> On 15.01.2025 21:05, Mirek wrote:
>> A ten 573 odfiltrowany dobrze?
>
> Masz na myśli zasilanie? Standardowo (jak każdy układ scalony w
> projekcie) ma kondensator 100 nF do masy przy pinie VCC. Jednak jak
> przyjrzałem się projektowi płytki, to może faktycznie moża by w tej
> okolicy dać jakiś mały elektrolit i poprowadzić zasilanie jakaś krótszą
> drogą z okolicy miejsca podpięcia zasilacza. To samo z masą...
>
>
>> Czyli on jest źródłem szpilek?.
>
> Na to wygląda. Na wyjściach 74HCT573 pojawiają się po raz pierwszy i
> stamtąd propagują na dekoder adresów IO.

Po zatrzaśnieciu adresu szpilek nie powinno być.
Przed, przy wysokim ALE - mogą, bo rejestr jest transparentny.

Datasheet nawet sugeruje, że wtedy jeszcze linie AD0-7 mogą się
zmieniac.

Ale ... wtedy sygnały /RD i /WR nie są jeszcze aktywne.


>> No dobra, a jak 8085 wystawi ALE, to linie do 573 zmieniają natychmiast
>> stan? - chodzi mi o to czy ta zmiana jest jakoś skorelowana ze szpilkami.
>
> Jeśli dobrze rozumiem działanie 74573, to w stanie wysokim na wejściu LE
> będzie on po prostu powtarzał stany wejść na wyjściach. Zatrzaśnięcie
> następuje dopiero wraz ze zboczem opadającym na LE. Czyli mamy do

Tak.

> czynienia z następującą sytuacją:
> - Procesor ustawia stan wysoki na ALE.
> - Na liniach AD0..AD7 nie zdążyły się jeszcze ustalić właściwe poziomu
> odpowiadające dolnemu bajtowi adresu. Przez chwil mamy tam stare dane z
> D0..D7 albo stany nieustalone. Mogą to tłumaczyć np. pojemności
> montażowe - magistrala rozciąga się na dwie płytki, podczas gdy sygnał
> ALE to krótka ścieżka pomiędzy dwoma sąsiadujacymi scalakami.
> - Przez moment ten niepoprawny, niestabilny stan jest widoczny na
> wyjściach 74573 (bo w stanie wysokim LE jest on przezroczysty), co
> objawia się w postaci szpilki.

Jakos tak,

> - Po chwili sytuacja się stabilizuje, na wyjścia przekazywane są już
> właściwe sygnały, a na zboczu opadającym ALE następuje ich zatrzaśnięcie.

Tak.

> - To też tłumaczyć dlaczego szpilki nie są widoczne przy każdym impulsie
> na ALE. Raz na jakiś czas po prostu zdarza się, że poprzedni stan jest
> zgodny z tym, co finalnie ma się znaleźć na danej linii Ax.

Wiekszość peryferiow z tamtej rodziny, jest na takie zmiany na linii
CS odporna - musi być jeszcze dodatkowo sygnał RD lub WR.

Karty CF ... chyba tak samo.

Tryb 8-bit ustawiłes, karty nie resetujesz, zasilania jej nie
wyłączasz?

To jeszcze niby jakies czasy propagacji mogą być, że ten 573 i 138
jakies powolne, i zmiany docierają, gdy już sygnaly RD/WR są aktywne.

Ale wątpie, nie przy tym zegarze ...

>> To ja bym próbował kondensatory dawać na A5, na CS...
>
> Tak, ale to będzie tylko walka z objawem, a nie przyczyną.
> Przy założeniu, że powyższa diagnoza jest prawidłowa, powinienem opóźnić
> moment, w którym 74HCT573 widzi stan wysoki na ALE, żeby linie AD0..AD7
> miały czas się ustabilizować.

Ogolnie to chyba o nic.
Sam procesor zapewnia odpowiedni czas.
Szpile mogą się pojawić, ale powinny być niegroźne.

J.

do góry

On 16.01.2025 09:38, Atlantis wrote:

> Przy założeniu, że powyższa diagnoza jest prawidłowa, powinienem opóźnić
> moment, w którym 74HCT573 widzi stan wysoki na ALE, żeby linie AD0..AD7
> miały czas się ustabilizować. Temu miał służyć filtr na tej linii, ale
> może zwyczajnie dałem za małe opóźnienie? Albo zamiast filtra RC
> powinienem dać jakąś linię opóźniającą na bramkach/inwertorach?


Może wystarczy tą ścieżkę ALE wydłużyć?
Z drugiej strony - źle masz zrobione to generowanie CS - może powinno
być dodatkowo uzależnione od ALE w stanie niskim?
Ja źle zrozumiałem twoje "propaguje się" - skojarzyłem jako przesłuch
między ścieżkami albo zakłócenie na zasilaniu itp. a wygląda na to, że
to jest prawidłowe działanie 138 - dostaje szpilkę, to dekoduje szpilkę.


--
Mirek

do góry

Atlantis <m...@w...com> wrote:
> On 15.01.2025 21:05, Mirek wrote:
>
>> A ten 573 odfiltrowany dobrze?
>
> Masz na myśli zasilanie? Standardowo (jak każdy układ scalony w
> projekcie) ma kondensator 100 nF do masy przy pinie VCC. Jednak jak
> przyjrzałem się projektowi płytki, to może faktycznie moża by w tej
> okolicy dać jakiś mały elektrolit i poprowadzić zasilanie jakaś krótszą
> drogą z okolicy miejsca podpięcia zasilacza. To samo z masą...
>
>
>> Czyli on jest źródłem szpilek?.
>
> Na to wygląda. Na wyjściach 74HCT573 pojawiają się po raz pierwszy i
> stamtąd propagują na dekoder adresów IO.
>
>
>> ALE jest tylko do niego?
>
> Tak.
>
>
>> No dobra, a jak 8085 wystawi ALE, to linie do 573 zmieniają natychmiast
>> stan? - chodzi mi o to czy ta zmiana jest jakoś skorelowana ze szpilkami.
>
> Jeśli dobrze rozumiem działanie 74573, to w stanie wysokim na wejściu LE
> będzie on po prostu powtarzał stany wejść na wyjściach. Zatrzaśnięcie
> następuje dopiero wraz ze zboczem opadającym na LE. Czyli mamy do
> czynienia z następującą sytuacją:
> - Procesor ustawia stan wysoki na ALE.
> - Na liniach AD0..AD7 nie zdążyły się jeszcze ustalić właściwe poziomu
> odpowiadające dolnemu bajtowi adresu. Przez chwil mamy tam stare dane z
> D0..D7 albo stany nieustalone. Mogą to tłumaczyć np. pojemności
> montażowe - magistrala rozciąga się na dwie płytki, podczas gdy sygnał
> ALE to krótka ścieżka pomiędzy dwoma sąsiadujacymi scalakami.
> - Przez moment ten niepoprawny, niestabilny stan jest widoczny na
> wyjściach 74573 (bo w stanie wysokim LE jest on przezroczysty), co
> objawia się w postaci szpilki.
> - Po chwili sytuacja się stabilizuje, na wyjścia przekazywane są już
> właściwe sygnały, a na zboczu opadającym ALE następuje ich zatrzaśnięcie.
> - To też tłumaczyć dlaczego szpilki nie są widoczne przy każdym impulsie
> na ALE. Raz na jakiś czas po prostu zdarza się, że poprzedni stan jest
> zgodny z tym, co finalnie ma się znaleźć na danej linii Ax.
>
>
>> To ja bym próbował kondensatory dawać na A5, na CS...
>
> Tak, ale to będzie tylko walka z objawem, a nie przyczyną.
> Przy założeniu, że powyższa diagnoza jest prawidłowa, powinienem opóźnić
> moment, w którym 74HCT573 widzi stan wysoki na ALE, żeby linie AD0..AD7
> miały czas się ustabilizować. Temu miał służyć filtr na tej linii, ale
> może zwyczajnie dałem za małe opóźnienie? Albo zamiast filtra RC
> powinienem dać jakąś linię opóźniającą na bramkach/inwertorach?

Gdyby to był problem to 574 powinien go rozwiązać.

>> A jak wyglądają czasy tych szpilek w porównaniu do taktu procesora?
>
> Są znacząco krótsze od czasów trwania normalnych sygnałów w tym
> systemie. Wydaje mi się, że właśnie dlatego nie wpływają na działanie
> innych komponentów, poza kartą CF. Stare peryferia w stylu 8251 albo
> 8253 zwyczajnie ignorują tak krótkie anomalie na liniach CF, podczas gdy
> (relatywnie) współczesna karta CF jest już na tyle szybka, że
> interpretuje je jako normalny sygnał aktywacji, co miesza w komunikacji
> z nią.

Karta powinna ignorować co jest na szynie dopuki nie jest wybrana.
Może wymagać żeby sygnał był stabilny jakiś czas przed wybraniem.
Ja by raczej patrzył na logikę zmieniającą sygnały sterujące do
karty, jeśli tam masz szpilki czy za małe opóźnienie to może być
problem.

--
Waldek Hebisch

do góry

On 16.01.2025 16:49, J.F wrote:

> Po zatrzaśnieciu adresu szpilek nie powinno być.
> Przed, przy wysokim ALE - mogą, bo rejestr jest transparentny.
> Datasheet nawet sugeruje, że wtedy jeszcze linie AD0-7 mogą się
> zmieniac.

Szpilki właśnie najwyraźniej wynikały z transparentności 573. W ramach
eksperymentu zmieniłem podejście i zastosowałem 574 zatrzaskiwany
zanegowanym sygnałem ALE. Teraz rejestr jest uzupełniany dopiero na
zboczu opadającym ALE, już po ustabilizowaniu się adresu.
Szpilki zniknęły, ale i tak mam fałszywą aktywność na liniach CS
wychodzących z dekodera IO. Nie wziąłem pod uwagę tego, że samo
połączenie linii IO_M z wejściem G1 74HCT138 nie wystarczy aby
skutecznie zablokować dekoder. Linia IO_M przechodzi w stan wysoki już
na samum początku cyklu, zanim adresy się zaktualizują, więc przez
chwilę siedzi tam jeszcze stara wartość. Mógłbym to rozwiązać stosując
dodatkowy układ 7474, ale chyba sobie daruję, bo bo te fałszywe stany
niskie i tak pojawiają się przed sygnałami RD/WR. Chociaż może pomyślę o
tym przy projektowaniu kolejnej wersji płytki. ;)


> Ale ... wtedy sygnały /RD i /WR nie są jeszcze aktywne.

No właśnie... Początkowo myślałem, że te szpilki na linii CS karty CF
mogą mieć jakiś związek z moimi problemami z kartą CF. Ale im więcej o
tym myślę... Przecież w poprzednim komputerku z 8080 karta działała bez
problemu, a tam dekoder IO w ogóle nie był w żaden sposób blokowany
(choćby dlatego, że 8080 nie ma linii IO_M i trzeba by ją generować z
innych sygnałów). Dekoder działał cały czas, reagując na wszystko, co
akurat pojawiło się na dolnym bajcie magistrali adresowej. Dopiero
aktywność na jednej z linii IORD, IOWR, MEMRD, MEMWR powodowała
aktywację konkretnego urządzenia.


> Karty CF ... chyba tak samo.

Właśnie... Sam fakt, że byłem w stanie używac karty CF w systemie z 8080
tego dowodzi.


> Tryb 8-bit ustawiłes, karty nie resetujesz, zasilania jej nie
> wyłączasz?

Kod jest dokładnie taki sam jak w systemie z 8080 (gdzie karta działała
bez problemu). Jedyna zmiana polegała na podmianie adresów rejestrów
karty (które w nowym komputerze znalazły się w innych miejscach) oraz
podniesieniu timeoutów przy odczytach (to już później, w ramach
eksperymentów). Poza tym sterownik jest identyczny.
Linię reset też sprawdziłem. Od razu przyszło mi do głowy, czy
przypadkiem nie pomyliłem się i nie podpiąłem jej do linii reset o
odwróconej logice, ale nie. Zresztą wtedy karta w ogóle byłaby trzymana
w stanie wiecznego resetu, a ona reaguje na próby komunikacji (dioda
miga przy próbie inicjacji i odczytu, jestem w stanie odczytywać rejestr
STATUS). Po prostu gdy próbuję odczytać strukturę info i MBR, przychodzą
bzdury.


> To jeszcze niby jakies czasy propagacji mogą być, że ten 573 i 138
> jakies powolne, i zmiany docierają, gdy już sygnaly RD/WR są aktywne.

Oscylogramy tego nie potwierdzają. Dodatkowo jeszcze dodałem w GAL-u
logikę opóźniającą aktywację linii RD i WR dla karty CF o jeden cykl
zegara. Niektóre źródła zalecają takie rozwiązanie dla większej
kompatybilności - niektóre karty są ponoć na to wyczulone.


> Ogolnie to chyba o nic.
> Sam procesor zapewnia odpowiedni czas.
> Szpile mogą się pojawić, ale powinny być niegroźne.

Właśnie też zaczyna mi się wydawać, że przyczyna pewnie leży gdzie
indziej...

do góry

W dniu 17 sty 2025 o 11:30, Waldek Hebisch pisze:

> Karta powinna ignorować co jest na szynie dopuki nie jest wybrana.

Sie znaczy pUka do dnia wyborów?...

--
`_._ _,-'""`-._ .`'.-. ._. .-.
(,-.`._,'( |\`-/| '.'O`-,` .,; o.' eneuel@@gmail.com '.O_'
`-.-' \ )-`( , o o) `-:`-'.'.`\.'.' '~'~'~'~'~'~'~'~' o.`.,t
-bf- `- \`_`"'-.o'\:/.d`|'.p \; https://www.eneuel.ct8.pl \|/..s

do góry