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