I8085 - emulator procesora
: wtorek 03 paź 2023, 00:18
Emulator procesora i8085
Nadeszła w końcu ta chwila, by zająć się stworzeniem softu dla generatora opartego na procku i8085. Ot wala mi się kilka takich w szufladzie, więc uznałem, że to dobry pomysł, by zatrudnić ich do jakiegoś działania. Sprzęciora już nawet zrobiłem, więc pora na kolejny krok do celu. Jakiś czas tam napisałem sobie program, który kompiluje program w asm i generuje kod binarny w formacie hex. Być może i są jakieś niekomercyjne narzędzia pozwalające na tworzenie softu dla tych procków. Prawdę mówiąc to specjalnie nie szukałem. Zacząłem nawet tworzyć kawałek softu, jednak zaczęło mi się trochę kaszanić w programie. Bo to człowiek już dawno nie pisał w asemblerze, a tu w dodatku jeszcze takim trochę dziwnym, gdyż będąc przyzwyczajony do składni zilogowej, która jest jasna i klarowna, to należy wrócić do składni inteloskiej. Ta już nie jest tak elegancka, ale nie ma co narzekać i wytykać intelowi jakieś uwagi. Chłopcy zrobili to jak zrobili i tyle.
Rozwiązaniem tego problemu jest posiadanie emulatora działania procka: czy to sprzętowego czy programowego. W kwestii emulatorów sprzętowych, to … są absolutnie poza zasięgiem. Ten procek był na topie jakieś 50 lat tamu i dzisiaj, nawet jeżeli takowe istnieją to będą kosztowały majątek. Pozostaje rozwiązanie w wariancie emulatora programowego. Generalnie nie jest to jakiś wielki problem, ot program jak program, jest to napisania. Pozostaje kwestia dostępu do właściwej wiedzy. Tu staje się przydatna moja stara książka, która wniosła wiele w rozumienie techniki mikroprocesorowej: praca zbiorowa, „Modułowe systemy mikrokomputerowe”.
W owej książce jest podana lista instrukcji procka i8080 i rozszerzenia dla procka i8085 (oczywista, że najwięcej miejsca jest poświęcone Z80). Ogólnie wiadomo, że Z80 jest kompatybilny pod względem kodów binarnych z prockami intela dysponując jednak znacząco większą liczbą instrukcji. Ano zostało to zrobione poprzez wykorzystanie „dziur” w kodach intelowych (tych od i8080). Procek i8085 również wykorzystał wolne miejsca, gdyż doszły dwie instrukcje (RIM i SIM). No więc będąc wyposażony w szczegółową wiedzę, postanowiłem stworzyć program emulatora.
Jednak coś mnie tknęło i postanowiłem podane informacje zweryfikować. Dotarłem do oryginalnej dokumentacji tego procka:
gdzie jasno jest postawiona sprawa, że praca zbiorowa jest polskim nadużyciem i mija się trochę z prawdą. Poza tym jest więcej istotnych szczegółów, których znajomość jest niezbędna do stworzenia poprawnie działającego programu.
No i oczywista, jest lista instrukcji wraz z ich kodami. No i nawet bez okularów widać, że procek nie realizuje instrukcji opisanych w polskiej książce.
Powstał mały dylemat: kto mówi prawdę? Tu nie wahałem się zbytnio i zaufałem oryginalnym publikacjom. Przykładowo kod CB hex będący dla ziloga prefiksem rozszerzenia do operacji bitowych, czy ED hex jako rozszerzenie do wielu ciekawych i przydatnych instrukcji czy DD hex i FD hex jako prefiksy do instrukcji operujących na rejestrach indeksowych, których w prockach intelowych nie ma. Te kody (i kilka innych) to są dziury dla procka i8085. Swoją drogą ciekawe co zrobi procek i8085, jak go się przymusi do wykonania tych instrukcji. To może być ciekawy temat badawczy, bo jak coś takiego zbadać? Procek może to olać, zawisnąć a może zrobić coś innego i tajemniczego. No może to kiedyś sprawdzę.
No więc stworzyłem sobie program do śledzenia wykonania programu dla procka i8085. Napisałem go sobie w pascalu (lazarus).
Moim celem jest stworzenie narzędzia pozwalającego na diagnostykę w szerokim zakresie. Wymaga to określenia dla programu wielu informacji, gdyż program wyłapuje przykładowo zapis do pamięci EPROM, odczyt/zapis z pamięci nieistniejącej (gdyż nie ma obowiązku, by do procka była przypięta pamięć wypełniająca całą przestrzeń adresową). Podobnie są monitorowane użycia portów we/wy. Należy wcześniej określić jakie adresy portów są używane i symulacja wykonania programu dla procka i8085 się zatrzyma, jeżeli nie zostaną wyspecyfikowane „legalne” adresy portów. By nie wklepywać tego za każdym razem, jest plik opisujący projekt (symulacji). Oczywiście, wszystkie szczegóły można w dowolnej chwili zmodyfikować.
Przykładowy projekt: w okienku projektu wyświetlone są wszystkie szczegóły dotyczące środowiska, w którym jest uruchamiany program.
System prockowy składa się z pamięci EPROM (lub innej nieulotnej) lokowanej w przestrzeni od 0000 hex do 7FFF hex oraz pamięć RAM lokowana od 8000 hex do FFFF hex. W sumie obie pamięci wypełniają całą przestrzeń. Dodatkowo występują porty wejścia, porty wyjścia (jak przykładowo i8212) czy porty wyjścia/wejścia (jak przykładowo i8255). Dla jednych dostępne są jedynie instrukcje IN, dla innych jedynie OUT lub dla tych trzecich zarówno IN jak i OUT. Również program emulatora wspiera obsługę przerwań. Może to być kontroler zbudowany na bazie i8214, który generuje instrukcje RST 1 … RST 7 lub przerwania połówkowe, które są zintegrowane w samym procku. No i oczywiście przerwanie niemaskowalne TRAP. Te przerwania (niemaskowalne oraz połówkowe) mogą być nieużywane w systemie (ze stałym sygnałem wymuszonym przez odpowiednie przyłączenie wejścia do masy lub VCC), toteż istnieje możliwość, że klikanie na przycisk do zgłaszania przerwania pozostanie bez reakcji.
Manual:
Nadeszła w końcu ta chwila, by zająć się stworzeniem softu dla generatora opartego na procku i8085. Ot wala mi się kilka takich w szufladzie, więc uznałem, że to dobry pomysł, by zatrudnić ich do jakiegoś działania. Sprzęciora już nawet zrobiłem, więc pora na kolejny krok do celu. Jakiś czas tam napisałem sobie program, który kompiluje program w asm i generuje kod binarny w formacie hex. Być może i są jakieś niekomercyjne narzędzia pozwalające na tworzenie softu dla tych procków. Prawdę mówiąc to specjalnie nie szukałem. Zacząłem nawet tworzyć kawałek softu, jednak zaczęło mi się trochę kaszanić w programie. Bo to człowiek już dawno nie pisał w asemblerze, a tu w dodatku jeszcze takim trochę dziwnym, gdyż będąc przyzwyczajony do składni zilogowej, która jest jasna i klarowna, to należy wrócić do składni inteloskiej. Ta już nie jest tak elegancka, ale nie ma co narzekać i wytykać intelowi jakieś uwagi. Chłopcy zrobili to jak zrobili i tyle.
Rozwiązaniem tego problemu jest posiadanie emulatora działania procka: czy to sprzętowego czy programowego. W kwestii emulatorów sprzętowych, to … są absolutnie poza zasięgiem. Ten procek był na topie jakieś 50 lat tamu i dzisiaj, nawet jeżeli takowe istnieją to będą kosztowały majątek. Pozostaje rozwiązanie w wariancie emulatora programowego. Generalnie nie jest to jakiś wielki problem, ot program jak program, jest to napisania. Pozostaje kwestia dostępu do właściwej wiedzy. Tu staje się przydatna moja stara książka, która wniosła wiele w rozumienie techniki mikroprocesorowej: praca zbiorowa, „Modułowe systemy mikrokomputerowe”.
W owej książce jest podana lista instrukcji procka i8080 i rozszerzenia dla procka i8085 (oczywista, że najwięcej miejsca jest poświęcone Z80). Ogólnie wiadomo, że Z80 jest kompatybilny pod względem kodów binarnych z prockami intela dysponując jednak znacząco większą liczbą instrukcji. Ano zostało to zrobione poprzez wykorzystanie „dziur” w kodach intelowych (tych od i8080). Procek i8085 również wykorzystał wolne miejsca, gdyż doszły dwie instrukcje (RIM i SIM). No więc będąc wyposażony w szczegółową wiedzę, postanowiłem stworzyć program emulatora.
Jednak coś mnie tknęło i postanowiłem podane informacje zweryfikować. Dotarłem do oryginalnej dokumentacji tego procka:
gdzie jasno jest postawiona sprawa, że praca zbiorowa jest polskim nadużyciem i mija się trochę z prawdą. Poza tym jest więcej istotnych szczegółów, których znajomość jest niezbędna do stworzenia poprawnie działającego programu.
No i oczywista, jest lista instrukcji wraz z ich kodami. No i nawet bez okularów widać, że procek nie realizuje instrukcji opisanych w polskiej książce.
Powstał mały dylemat: kto mówi prawdę? Tu nie wahałem się zbytnio i zaufałem oryginalnym publikacjom. Przykładowo kod CB hex będący dla ziloga prefiksem rozszerzenia do operacji bitowych, czy ED hex jako rozszerzenie do wielu ciekawych i przydatnych instrukcji czy DD hex i FD hex jako prefiksy do instrukcji operujących na rejestrach indeksowych, których w prockach intelowych nie ma. Te kody (i kilka innych) to są dziury dla procka i8085. Swoją drogą ciekawe co zrobi procek i8085, jak go się przymusi do wykonania tych instrukcji. To może być ciekawy temat badawczy, bo jak coś takiego zbadać? Procek może to olać, zawisnąć a może zrobić coś innego i tajemniczego. No może to kiedyś sprawdzę.
No więc stworzyłem sobie program do śledzenia wykonania programu dla procka i8085. Napisałem go sobie w pascalu (lazarus).
Moim celem jest stworzenie narzędzia pozwalającego na diagnostykę w szerokim zakresie. Wymaga to określenia dla programu wielu informacji, gdyż program wyłapuje przykładowo zapis do pamięci EPROM, odczyt/zapis z pamięci nieistniejącej (gdyż nie ma obowiązku, by do procka była przypięta pamięć wypełniająca całą przestrzeń adresową). Podobnie są monitorowane użycia portów we/wy. Należy wcześniej określić jakie adresy portów są używane i symulacja wykonania programu dla procka i8085 się zatrzyma, jeżeli nie zostaną wyspecyfikowane „legalne” adresy portów. By nie wklepywać tego za każdym razem, jest plik opisujący projekt (symulacji). Oczywiście, wszystkie szczegóły można w dowolnej chwili zmodyfikować.
Przykładowy projekt: w okienku projektu wyświetlone są wszystkie szczegóły dotyczące środowiska, w którym jest uruchamiany program.
System prockowy składa się z pamięci EPROM (lub innej nieulotnej) lokowanej w przestrzeni od 0000 hex do 7FFF hex oraz pamięć RAM lokowana od 8000 hex do FFFF hex. W sumie obie pamięci wypełniają całą przestrzeń. Dodatkowo występują porty wejścia, porty wyjścia (jak przykładowo i8212) czy porty wyjścia/wejścia (jak przykładowo i8255). Dla jednych dostępne są jedynie instrukcje IN, dla innych jedynie OUT lub dla tych trzecich zarówno IN jak i OUT. Również program emulatora wspiera obsługę przerwań. Może to być kontroler zbudowany na bazie i8214, który generuje instrukcje RST 1 … RST 7 lub przerwania połówkowe, które są zintegrowane w samym procku. No i oczywiście przerwanie niemaskowalne TRAP. Te przerwania (niemaskowalne oraz połówkowe) mogą być nieużywane w systemie (ze stałym sygnałem wymuszonym przez odpowiednie przyłączenie wejścia do masy lub VCC), toteż istnieje możliwość, że klikanie na przycisk do zgłaszania przerwania pozostanie bez reakcji.
Manual: