🚀 go-pugleaf

Próbuję właśnie uruchomić własną konstrukcję - komputerek pod CP/M 
(docelowo także MP/M), zbudowany na relatywnie niszowym CPU od Ziloga, 
Z80182. W wielkim skrócie jest to Z180 z kilkoma dodatkowymi bajerami.
https://www.zilog.com/docs/z180/z80182.pdf

Na chwilę obecną udało mi się sprawić, że płytka wykonuje kod z flasha. 
Jestem w stanie pisać do wewnętrznych rejestrów (na oscyloskopie widać 
wpływ np. po ustawieniu wait-state'ów) i zmieniać stan pinów GPIO.

Utknąłem natomiast na próbach skorzystania z RAM-u, przez co nie mogę 
nawet skorzystać ze stosu.

Pamięć SRAM (AS6C4008) korzysta z wbudowanego w układ dekodera adresów, 
a więc linia /OE jest podłączona do wyjścia /RAMCS. Rejestry 
konfigurujące dekoder są ustawione poprawnie, bo jeśli próbuje pisać pod 
adres odpowiadający pamięci RAM, na linii RAMCS pojawia się stan niski.
Nie przechodzi natomiast test polegający na zapisaniu wartości (np. 
0x55) do komórki w ramie, ponownego odczytu i porównania wartości. Jeśli 
próbuję korzystać ze stosu (np. używając instrukcji CALL), program się 
wysypuje.

Próbowałem już następujących rzeczy:
1. Ustawiałem różne wartości wait-state'ów dla RAM-u.
2. Tymczasowo podmieniłem kwarc na wolniejszy, obniżając zegar systemowy 
z 12,5 MHz do 4 MHz.
3. Sprawdziłem na oscyloskopie stany linii w momencie zapisu do RAM-u. 
Na liniach adresowych i danych stabilne stany pojawiają się przed 
aktywacją /CS, a ich wartości odpowiadają temu, co chcę zapisać i gdzie. 
Sygnał /WR pojawia się po /CS i znika razem z nim.
4. Sprawdziłem na oscyloskopie stany linii w momencie odczytu. Linie /CS 
i /RD pojawiają się właściwie jednocześnie. Stany linii adresowych 
pasują do tego, co chcę odczytać. Sytuacja z liniami danych jest 
dziwniejsza - linie, które powinny być w stanie wysokim wyglądają 
normalnie. Natomiast linie niskie wyglądają w momencie aktywacji CS jak 
grupa równoległych przebiegów - coś jak linie w stanie wysokiej 
impedancji 
(https://www.speccy.pl/forum/index.php?action=dlattach;topic=7902.0;attach=28900;image)
5. Myślałem, że mam do czynienia z uszkodzeniem pamięci, więc 
spróbowałem innego egzemplarza. Niestety zachowuje się identycznie. 
Pamięci są z dobrego źródła (TME). Na wszelki wypadek zamówiłem więcej, 
jednak nie sądzę, żeby to coś mi dało.
6. Testowo spróbowałem użyć pinu MRD (sygnał generowany wewnętrznie jako 
/MRD = /RD AND /MREQ).

Na chwilę obecną kończą mi się pomysły - niby mógłbym jeszcze spróbować 
podmienić CPU na inny egzemplarz, ale nic nie wskazuje na jego 
uszkodzenie...

Ktoś ma jakiś pomysł co do możliwej przyczyny? Czego jeszcze mógłbym 
spróbować?