W dniu 16.04.2025 o 10:14, Atlantis pisze:
[cut]

> Konieczne było też wprowadzenie paru innych modyfikacji (m.in. wywalenie
> istniejącego układu do tymczasowego ustawiania linii A14 i A15 po
> resecie (żeby kod wykonywał się z EPROM-u w górnej części przestrzeni
> adresowej) oraz doprowadzenie A14 do RAM2.
>
Czyżby problem z odpowiednim zwalnianiem linii A14?
Nie widzę co prawda schematu, ale ewidentnie sprawa programowa.

Adresy powinny być chyba kodowane i dekodowane bajtowo w jednym układzie
(dla danego bajtu). Podobne numery robił mi kiedyś zamierzchły 80C552 na
przełączaniu banków pamięci zewnętrznej.

> Generalnie przyglądałem się schematowi dziesiątki razy i nie widzę
> powodu, dla którego miałoby to nie działać. Połączenia odpowiadają
> logice, którą zaimplementowałem w GAL-u we wspomnianej wersji, która
> działa. Sprawdziłem też połączenia multimetrem aby upewnić się, że
> wszystkie sygnały dochodzą tam, gdzie trzeba.
>

Oscyloskop Twoim przyjacielem. A jeszcze lepiej analizator stanów (bajtowy).

> Co dzieje się w rzeczywistości? Po resecie kod zaczyna wykonywać kod z
> EPROM-u, posiada też dostęp do RAM2 (bo tam trzyma stos i niektóre
> zmienne). Uruchamia się bootloader, który ładuje CP/M z karty pamięci do
> pewnego obszaru w RAM2. Operacja kończy się powodzeniem i wykonany
> zostaje skok do tej lokalizacji. Tutaj też jeszcze kod działa, bo
> kolejne instrukcje są wykonywane. Aż do momentu, kiedy próbuję
> przestawić stan linii ROM_SHADOW, aby mieć dostęp do RAM1. Wtedy
> wszystko się zawiesza. Jak wspominałem, w przypadku rozwiązania z GAL-em
> wszystko działało, więc problem nie leży po stronie kodu.
>
> Ktoś ma pomysł co może być przyczyną takiego zachowania? Sytuacja
> objawia się tak samo w przypadku obydwu zmodyfikowanych egzemplarzy.
> Jakiś problem z timingami zastosowanych elementów SMD?

Też może być...