eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaProblem z dekoderem adresówProblem z dekoderem adresów
  • Data: 2025-04-16 10:14:23
    Temat: Problem z dekoderem adresów
    Od: Atlantis <m...@w...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    Jakiś czas temu zacząłem pracować nad projektem komputera na 8085,
    pierwotnie przyjmując następujące założenia co do organizacji pamięci.

    0x0000-0x7FFF - RAM1 (62256)
    0x8000-0xBFFF - RAM2 (62256 podzielony na dwa banki)
    0xC000-0xFFFF - EPROM

    Takie podejście całkiem fajnie sprawdzało się w przypadku BASIC-a, ale
    okazało się beznadziejne, gdy zabrałem się za uruchamiania CP/M -
    brakowało pamięci żeby uruchomić niektóre programy.

    Przygotowałem więc jeszcze jedną wersję płyty procesorowej, ze
    zmodyfikowanym dekoderem adresów (pierwotna wersja używała układów
    74HCT, tym razem użyłem GAL-a). Złożyłem to, zmodyfikowałem system,
    wszystkie zadziałało.

    Tym razem organizacja pamięci wygląda następująco:

    0x0000-0x7FFF - EPROM lub RAM1 w zależności od stanu linii ROM_SHADOW
    ustawianej na rejestrze 74273. Po resecie domyślnie startuje EPROM,
    potem można to zmienić.
    0x8000-0xFFFF - RAM2, dostępny cały czas.

    Przyszło mi jednak do głowy, żeby dwa wcześniej złożone wcześniej
    prototypy też zmodyfikować w ten sposób, aby pracowały z taką
    organizacją pamięci. Ujednolicenie tego z nową wersją przez wciśnięcie
    GAL-a wymagałoby zbyt dużych przeróbek, więc zastosowałem inne
    podejście. Usunąłem układ 74HCT139 i na jego miejsce wlutowałem nowy
    moduł dekodera adresów, zbudowany na elementach SMD (74HCT139 +
    pojedyncza bramka AND).

    Połączenia wyglądają następująco:
    Wejście A połówki 74HCT139 - sygnał SHADOW_ROM
    Wejście B połówki 74HCT139 - linia adresowa A15
    Wejście G połówki 74HCT139 - sygnał MEM_EN (z istniejącej logiki, która
    interpretuje sytuację na magistrali, stary dekoder tez z niego korzystał)
    Wyjście Y0 połówki 74HCT139 - CS_EPROM
    Wyjście Y2 połówki 74HCT139 - CSRAM1
    Wyjścia Y1 i Y3 połówki 74HCT139 - do wejść bramki AND, której wyjście
    stanowi sygnał CS_RAM2.

    Wejścia niewykorzystanej połówki 74HCT139 są połączone z masą.

    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.

    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.

    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?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: