Modyfikacje sprzętowe procesora

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.

Znanych jest kilka modyfikacji sprzętowych procesora minikomputera. Powstawały one na przestrzeni lat w Instytucie Okrętowym Politechniki Gdańskiej, w zespole rozwijającym system operacyjny CROOK. Były wykorzystywane zarówno przez CROOK-a jak i oprogramowanie na nim działajace.

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).

Adresowanie bajtu w nie zmodyfikowanym procesorze realizowane jest w następujący sposób:

• Użytkownik dostarcza adres bajtu w postaci: 15 bitów adresu słowa, 1 bit (najmłodszy) wskazujący bajt w słowie.
• Tak dostarczony adres procesor przesuwa o jeden bit w prawo. W wyniku otrzymuje poprawny, 16-bitowy adres słowa w pamięci, którego najstarszy bit jest zawsze zerem
• "Wypadający" najmłodszy bit zachowywany jest, aby później na podstawie jego wartości z komórki pamięci wybrać odpowiedni bajt (lewy bądź prawy).

Adres bajtu (jako argument normalny) podlega również pre- i B-modyfikacji. Obie te operacje są niczym innym, jak dodawaniem modyfikatora do argumentu, wykonywanym w arytmometrze procesora. W wyniku tej operacji może więc wystąpić przeniesienie, które w standardowym procesorze jest ignorowane.

Przeróbka procesora zmienia to zachowanie. Pierwszy etap obliczania argumentu efektywnego pozostaje bez zmian: do pierwotnego argumentu dodawana jest pre-modyfikacja, a ewentualne przeniesienie jest zaniedbywane. W następnym etapie dodawana jest B-modyfikacja, ale tym razem przeniesienie zapamiętywane jest w dodatkowym rejestrze. Później, kiedy adres bajtowy przesuwany jest w prawo, aby otrzymać docelowy adres słowa w pamięci, na najstarszy bit adresu, zamiast zera, wsuwana jest zawartość zapamiętanego przeniesienia. W ten sposób, używając B-modyfikacj można przygotować 17-bitowy adres bajtu tak, aby możliwe było zaadresowanie dowolnego bajtu w 64k słowowym bloku.

Przykładowe konstrukcje używające 17-bit adresowania bajtów (w składni assemblera EMAS):

 LW r2, 0x9400    ; 0x9400 to adres słowa, w którym adresujemy bajt
 MD 1             ; wskazanie bajtu w słowie
 LB r1, r2+r2     ; załadowanie bajtu; adresem bajtowym staje się 2*r2+1

 LW r5, 0xAAAA    ; 0xAAAA to słowowy adres bazowy obszaru, który chcemy adresować
 LW r6, r5+r1     ; w r6 do adresu bazowego dodajemy również przesunięcie (indeks) przechowywany w rejestrze r1
 RB r3, r5+r6     ; zapamiętanie bajtu pod bajtowym adresem 2*0xAAAA+r1

17-bitowe adresowanie bajtów może rodzić problemy w specyficznych przypadkach użycia go w oprogramowaniu pisanym na oryginalny procesor. Rozpatrzmy następujący przykład:

 LW r2, 0x3b00
 LW r3, -12
 MD r2
 LB r1, r2+r3

Jeśli przeniesienia przy obliczaniu argumentu normalnego są zaniedbywane (jak w oryginalnym procesorze), adres bajtowy zostanie obliczony zgodnie z intencją programisty w następujący sposób:

1. argument pierwotny = 0x3b00
2. dodanie pre-modyfikacji (0x3b00) = 0x7600 (przeniesienie = 0)
3. dodanie B-modyfikacji (-12) = 0x75f4 (przeniesienie = 1)
4. przesunięcie w prawo dla otrzymania adresu bajtowego = 0x3afa

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

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 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.

Istnieje jednak alternatywne jądro CROOK-5 w rewizjach 7 i 8, potrafiące pracować z procesorem z dodanymi dwiema nowymi, legalnymi instrukcjami: SINT i SIND. Zastępują one funkcjonalnie pseudo-instrukcję SIN.

Na tę przeróbkę procesora składały się zmiany w kilku jego obszarach:

1. W dekoderze rozkazów znaleziono "miejsce" na dwie nowe instrukcje: w grupie rozkazów bezargumentowych S (patrz: Skorowidz kodów rozkazów). Jest to jedyna grupa w obszarze rozkazów legalnych, gdzie część bitów kodu rozkazu nie jest w ogóle wykorzystana (odpowiednie linie dekodera rozkazów nie są użyte). Nowym rozkazom zostały nadane kody (ósemkowo):
   • SINT = 0166204
   • SIND = 0167204
2. Przerwanie zegarowe (pozycja 5) zostało przeniesione na pozycję 11, w standardowym procesorze nie skojarzoną z żadnym źródłem przerwania.
3. Przerwanie 5 zostało użyte jako przerwanie programowe o wysokim priorytecie, sterowane instrukcjami SINT i SIND.

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.

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ć automatyczny bootstrap systemu pracującego na takim komputerze.

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.

Instrukcja włączająca modyfikacje

Ostatnia modyfikacja pozwalała na programowe włączenie przeróbek 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 najprawdopodobniej przywracało działanie bez modyfikacji.

Potwierdzone jest, że rozkaz CRON włączał 17-bit adresowanie bajtów, zamieniał miejscami przerwania 5 i 11 oraz aktywował poszerzoną maskę dla przerwań kanałowych. Nie jest natomiast potwierdzone zachowanie instrukcji SINT i SIND przed włączeniem modyfikacji: czy były nielegalne, legalne, ale zgłaszały przerwanie 11, bądź legalne, ale nie miały żadnego skutku.

Źródło: Opracowanie własne