3012
edycji
Modyfikacje sprzętowe procesora: Różnice pomiędzy wersjami
Przejdź do nawigacji
Przejdź do wyszukiwania
brak opisu edycji
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
Procesor MERY-400 nie jest pojedynczym układem scalonym, a modułem, składającym się z pakietów (płyt o wymiarach 300x300mm). Pakiety zbudowane są z układów scalonych z serii 74 oraz innych elementów dyskretnych. Taka konstrukcja powoduje, że stosunkowo łatwo jest wprowadzać w nim modyfikacje sprzętowe. Zadanie ułatwia dodatkowo fakt, że na poszczególnych pakietach procesora można znaleźć "wolne" bramki i przerzutniki. | Procesor MERY-400 nie jest pojedynczym układem scalonym, a sporym modułem, składającym się z pakietów (płyt o wymiarach 300x300mm). Pakiety zbudowane są z układów scalonych z serii 74 oraz innych elementów dyskretnych. Taka konstrukcja powoduje, że stosunkowo łatwo jest wprowadzać w nim modyfikacje sprzętowe. Zadanie ułatwia dodatkowo fakt, że na poszczególnych pakietach procesora można znaleźć "wolne" bramki i przerzutniki. | ||
Na przestrzeni lat, w Instytucie Okrętowym Politechniki Gdańskiej, w zespole rozwijającym system operacyjny CROOK powstało kilka modyfikacji procesora MERY-400. Wykorzystywał je zarówno CROOK jak i oprogramowanie na nim działające. Były one implelentowane w istniejących instalacjach MERY-400, a ostatecznie wszystkie one złożyły się na poprawioną wersję procesora używanego w [[MX-16]]. | |||
= 17-bitowe adresowanie bajtów = | = Opis funkcjonalny = | ||
== Automatyczny bootstrap == | |||
[[Pamięć MEGA]] zawierała bootloader(-y) zapisane w pamięci EPROM, dostępne po starcie systemu pod adresem 0xf000. Można było uruchomić zawarty tam kod ustawiając z pulpitu technicznego zawartość licznika rozkazów i startując maszynę. Jednak w przypadku komputerów MX-16 nie było to możliwe - były one dostarczane bez pulpitu technicznego. Trzeba było więc zapewnić możliwość automatycznego bootstrapu systemu na komputerze w takiej konfiguracji. | |||
Zostało to zrobione oprzez modyfikację procesora, która tuż po starcie maszyny zmniejszała o 1 zawartość czterobitowego rejestru, w którym przechowywane są cztery najstarsze bity IC. W ten sposób adres startowy z 0x0000 zmieniał się na 0xf000 i maszyna rozpoczynała pracę uruchamiając bootloader. | |||
Przeróbka ta nie miała żadnego efektu, jeśli w systemie nie była zainstalowana pamięć MEGA, bądź bootstrap z pamięci MEGA nie został skonfigurowany (fizycznie). | |||
== Instrukcja włączająca modyfikacje == | |||
Ponieważ należało zapewnić możliwie najpełniejszą kompatybilność wsteczną z oryginalnym procesorem MERY-400, funkcjonalność opisanych dalej przeróbek była dostępna dopiero po programowym aktywowaniu ich specjalną, nową instrukcją procesora | |||
W grupie rozkazowej S utworzono kolejną nową instrukcję CRON o kodzie 0166500. Maszyna zmodyfikowana uruchamiała się w trybie kompatybilności z oryginalnym procesorem, a dopiero jej wywołanie aktywowało modyfikacje. Zerowanie maszyny kluczem CLEAR bądź rozkazem MCL przywracało procesor do pierwotnego stanu kompatybilności. | |||
== 17-bitowe adresowanie bajtów == | |||
W oryginalnej konstrukcji procesora adres bajtu był 16-bitowy, z czego 15 najstarszych bitów adresowało słowo w pamięci, a najmłodszy bit wskazywał lewy lub prawy bajt w 16-bitowym słowie maszyny. Oznacza to, że za pomocą instrukcji używających adresowania bajtowego (LB, RB, CB) można było odwołać się jedynie do pierwszych 32k słów w maksymalnie 64k słowowym bloku. Fakt ten powodował również nieścisłości w dokumentacji (patrz [[Adresowanie pamięci]]). | W oryginalnej konstrukcji procesora adres bajtu był 16-bitowy, z czego 15 najstarszych bitów adresowało słowo w pamięci, a najmłodszy bit wskazywał lewy lub prawy bajt w 16-bitowym słowie maszyny. Oznacza to, że za pomocą instrukcji używających adresowania bajtowego (LB, RB, CB) można było odwołać się jedynie do pierwszych 32k słów w maksymalnie 64k słowowym bloku. Fakt ten powodował również nieścisłości w dokumentacji (patrz [[Adresowanie pamięci]]). | ||
| Linia 24: | Linia 40: | ||
LB r1, r2+r2 ; załadowanie bajtu; adresem bajtowym staje się 2*r2+1 | LB r1, r2+r2 ; załadowanie bajtu; adresem bajtowym staje się 2*r2+1 | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<syntaxhighlight lang="asm"> | <syntaxhighlight lang="asm"> | ||
| Linia 49: | Linia 66: | ||
W kroku 3 występuje przeniesienie, ponieważ arytmometr do argumentu dodaje B-modyfikację, która w zapisie U2 wygląda: 0xfff4. Jeśli procesor jest zmodyfikowany, to zapamiętane przeniesienie zostanie w ostatnim kroku użyte i wsunięte na najstarszą pozycję ostatecznego wyniku, dając w efekcie adres '''0xbafa'''. | W kroku 3 występuje przeniesienie, ponieważ arytmometr do argumentu dodaje B-modyfikację, która w zapisie U2 wygląda: 0xfff4. Jeśli procesor jest zmodyfikowany, to zapamiętane przeniesienie zostanie w ostatnim kroku użyte i wsunięte na najstarszą pozycję ostatecznego wyniku, dając w efekcie adres '''0xbafa'''. | ||
= Przerwanie programowe o wysokim priorytecie = | Należało więc zapewnić możliwość uruchamiania również i takich programów na zmodyfikowanym procesorze, pod kontrolą systemu operacyjnego, który aktywował modyfikacje. Zostało to osiągnięte przez ustalenie następujących warunków, w których 17-bit adresowanie bajtów jest możliwe: | ||
* wykonywany jest program w trybie systemu operacyjnego (Q=0) | |||
* lub wykonowyany jest program w trybie użytkownika, i nie jest ustawiony bit specjalny (BS=0) | |||
Dzięki temu, dla programów, o których wiadomo było, że nie pracują poprawnie z 17-bit adresowaniem, system operacyjny mógł je dla danego procesu dezaktywować, ustawiając przed przełączeniem kontekstu bit BS w rejestrze SR na 1. Takie zachowanie było kompatybilne z oryginalnym procesorem, ponieważ na takim sprzęcie bit BS nie ma znaczenia, gdy wykonywany jest program w jednym z bloków użytkowych. | |||
== Przerwanie programowe o wysokim priorytecie == | |||
System operacyjny CROOK wymaga istnienia przerwania programowego, którego priorytet byłby wyższy niż przerwań pochodzących z urządzeń zewnętrznych (kanałowych) i z zegara systemowego. W [[Przerwania|systemie przerwań MERY-400]] takie przerwanie nie istnieje. Wersje systemu CROOK od 1 do 5 obchodziły ten problem następująco: W jądrze systemu używana była pseudo-instrukcja SIN o kodzie (ósemkowo) 036000. Z punktu widzenia procesora jest to instrukcja niepoprawna, generująca przerwanie "nieprawidłowy rozkaz". Jednocześnie procedura obsługi tego przerwania w CROOK-u skonstruowana jest tak, aby w przypadku pseudo-rozkazu SIN zapewnić jego obsługę jak przerwania programowego o wysokim priorytecie. To obejście wykorzystywane jest we wszystkich wersjach systemu, aż do ostatniej rewizji CROOK-5. | System operacyjny CROOK wymaga istnienia przerwania programowego, którego priorytet byłby wyższy niż przerwań pochodzących z urządzeń zewnętrznych (kanałowych) i z zegara systemowego. W [[Przerwania|systemie przerwań MERY-400]] takie przerwanie nie istnieje. Wersje systemu CROOK od 1 do 5 obchodziły ten problem następująco: W jądrze systemu używana była pseudo-instrukcja SIN o kodzie (ósemkowo) 036000. Z punktu widzenia procesora jest to instrukcja niepoprawna, generująca przerwanie "nieprawidłowy rozkaz". Jednocześnie procedura obsługi tego przerwania w CROOK-u skonstruowana jest tak, aby w przypadku pseudo-rozkazu SIN zapewnić jego obsługę jak przerwania programowego o wysokim priorytecie. To obejście wykorzystywane jest we wszystkich wersjach systemu, aż do ostatniej rewizji CROOK-5. | ||
| Linia 62: | Linia 86: | ||
# Przerwanie 5 zostało użyte jako przerwanie programowe o wysokim priorytecie, sterowane instrukcjami SINT i SIND. | # Przerwanie 5 zostało użyte jako przerwanie programowe o wysokim priorytecie, sterowane instrukcjami SINT i SIND. | ||
= Zmiana maskowania przerwań = | == Zmiana maskowania przerwań == | ||
CROOK-5 miał jeszcze jedno wymaganie, które ostatecznie zostało spełnione za pomocą modyfikacji sprzętowej. Należało zapewnić, aby w trakcie obsługi przerwania kanałowego nie pojawiło się przerwanie o wyższym priorytecie (w szczególności zegarowe). W procesorze bez przeróbek wymuszane to było przez programowe maskowanie przerwań na początku procedury obsługi przerwań kanałowych. W procesorze przerobionym zrealizowane to było sprzętowo: Przyjęcie przerwania kanałowego powodowało automatyczne zamaskowanie przerwań od 5 do 31. | CROOK-5 miał jeszcze jedno wymaganie, które ostatecznie zostało spełnione za pomocą modyfikacji sprzętowej. Należało zapewnić, aby w trakcie obsługi przerwania kanałowego nie pojawiło się przerwanie o wyższym priorytecie (w szczególności zegarowe). W procesorze bez przeróbek wymuszane to było przez programowe maskowanie przerwań na początku procedury obsługi przerwań kanałowych. W procesorze przerobionym zrealizowane to było sprzętowo: Przyjęcie przerwania kanałowego powodowało automatyczne zamaskowanie przerwań od 5 do 31. | ||
= Realizacja techniczna = | |||
{{source|title=Opracowanie własne}} | {{source|title=Opracowanie własne}} | ||