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 |
||
| (Nie pokazano 3 pośrednich wersji utworzonych przez tego samego użytkownika) | |||
| Linia 3: | Linia 3: | ||
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 7400 oraz 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 7400 oraz 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 złożyły się na poprawioną wersję procesora używanego w [[MX-16]]. | Na przestrzeni lat, głównie w Instytucie Okrętowym Politechniki Gdańskiej, w zespole rozwijającym system operacyjny CROOK, ale również w Amepol-u, 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 złożyły się na poprawioną wersję procesora używanego w [[MX-16]]. | ||
Przeróbki procesora dotyczą pakietów ''P-A'', ''P-D'', ''P-R'' i ''P-P'', a ich umiejscowienie związane jest z | Przeróbki procesora dotyczą pakietów ''P-A'', ''P-D'', ''P-R'' i ''P-P'', a ich umiejscowienie związane jest z obecnością wolnych bramek i przerzutników. Schematy przedstawione dalej pokazują zmiany (wyróżnione kolorem czerwonym) względem [http://mera400.pl/files/mera400-dtr-t4-cz2-mjc400-schematy.pdf schematów] znajdujących się w DTR. Nazwy nowych sygnałów, nie ujętych w dokumentacji, zostały nadane w celu ułatwienia przedstawienia zmian i nie pokrywają się z nazwami nadanymi przez autorów modyfikacji (te są nieznane). | ||
= Automatyczny bootstrap = | = Automatyczny bootstrap = | ||
| Linia 13: | Linia 13: | ||
Zostało to zrobione poprzez modyfikację procesora, która tuż po włączeniu zasilania ustawia licznik rozkazów na adres 0xf000. | Zostało to zrobione poprzez modyfikację procesora, która tuż po włączeniu zasilania ustawia licznik rozkazów na adres 0xf000. | ||
Przeróbka ta nie ma żadnego efektu, jeśli w systemie | Przeróbka ta nie ma żadnego efektu, jeśli w systemie nie jest zainstalowana pamięć MEGA, bądź bootstrap z pamięci MEGA nie został skonfigurowany. | ||
== Realizacja techniczna == | == Realizacja techniczna == | ||
| Linia 21: | Linia 21: | ||
[[File:cpumod-p-a-boot.png|650px|center]] | [[File:cpumod-p-a-boot.png|650px|center]] | ||
Układ '''M54''' to 4-bit rejestr przechowujący najstarszy kwartet bitów licznika rozkazów IC. Istniejące | Układ '''M54''' to 4-bit rejestr przechowujący najstarszy kwartet bitów licznika rozkazów IC. Istniejące połączenie jego wejścia '''CD''' (Count Down) do stanu wysokiego zostało przerwane i zastąpione iloczynem sygnałów '''+BOOTL''' i '''+PON'''. Aktywne "0" na wyjściu bramki NAND (układ '''M21''') powoduje zmniejszenie o jeden zawartości rejestru '''M54''', a co za tym idzie ustawienie licznika rozkazów na adres 0xf000. | ||
= Instrukcja włączająca modyfikacje = | = Instrukcja włączająca modyfikacje = | ||
| Linia 37: | Linia 37: | ||
Należy zauważyć, że instrukcja ta wciąż jest instrukcją nielegalną, co zapewnia kompatybilność wsteczną. Programista używający instrukcji CRON w systemie operacyjnym musi obsłużyć fakt, że po jej wydaniu zgłoszone zostanie przerwanie "niepoprawny rozkaz". | Należy zauważyć, że instrukcja ta wciąż jest instrukcją nielegalną, co zapewnia kompatybilność wsteczną. Programista używający instrukcji CRON w systemie operacyjnym musi obsłużyć fakt, że po jej wydaniu zgłoszone zostanie przerwanie "niepoprawny rozkaz". | ||
Rezultatem wydania instrukcji CRON musiało być "przełączenie" procesora w | Rezultatem wydania instrukcji CRON musiało być "przełączenie" procesora w tryb pracy z modyfikacjami aż do następnego zerowania, a więc sygnał '''+CRON''' musi zostać gdzieś zapamiętany. Dzieje się to na pakiecie P-P. | ||
[[File:cpumod-p-p-cpumod.png|550px|center]] | [[File:cpumod-p-p-cpumod.png|550px|center]] | ||
| Linia 47: | Linia 47: | ||
= 17-bitowe adresowanie bajtów = | = 17-bitowe adresowanie bajtów = | ||
W oryginalnej konstrukcji procesora adres bajtu jest 16-bitowy, z czego 15 najstarszych bitów adresuje słowo w pamięci, a najmłodszy bit wskazuje 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 odwołać się jedynie do pierwszych 32k słów w | W oryginalnej konstrukcji procesora adres bajtu jest 16-bitowy, z czego 15 najstarszych bitów adresuje słowo w pamięci, a najmłodszy bit wskazuje 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 odwołać się jedynie do pierwszych 32k słów w 64k bloku. Fakt ten jest również źródłem nieścisłości w dokumentacji (patrz [[Adresowanie pamięci]]). | ||
Adresowanie bajtu w nie zmodyfikowanym procesorze realizowane jest w następujący sposób: | Adresowanie bajtu w nie zmodyfikowanym procesorze realizowane jest w następujący sposób: | ||
| Linia 61: | Linia 61: | ||
Przykładowe konstrukcje używające 17-bit adresowania bajtów (w składni assemblera [[EMAS]]): | 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 | LW r2, 0x9400 ; 0x9400 to adres słowa, w którym adresujemy bajt | ||
MD 1 ; wskazanie bajtu w słowie | MD 1 ; wskazanie bajtu w słowie | ||
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 | ||
LW r5, 0xAAAA ; 0xAAAA to słowowy adres bazowy obszaru, który chcemy adresować | 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 | LW r6, r5+r1 ; w r6 do adresu bazowego dodajemy również przesunięcie (indeks) przechowywany w rejestrze r1 | ||
MD r6 ; pre-modyfikacja zapewnia dodanie do argumentu wartości r5+r1 | MD r6 ; pre-modyfikacja zapewnia dodanie do argumentu wartości r5+r1 | ||
RB r3, r5 ; zapamiętanie bajtu pod bajtowym adresem 2*0xAAAA+r1 | RB r3, r5 ; 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: | 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 r2, 0x3b00 | ||
LW r3, -12 | LW r3, -12 | ||
MD r2 | MD r2 | ||
LB r1, r2+r3 | 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: | 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: | ||
| Linia 109: | Linia 103: | ||
[[File:cpumod-p-r-bab17.png|780px|center]] | [[File:cpumod-p-r-bab17.png|780px|center]] | ||
Taktowany jest on sygnałem '''+STROB1''' w iloczynie z sygnałem '''+P4''', mówiącym o tym, że procesor jest w stanie P4, w którym | Taktowany jest on sygnałem '''+STROB1''' w iloczynie z sygnałem '''+P4''', mówiącym o tym, że procesor jest w stanie P4, w którym następuje pre- i B-modyfikacja argumentu normalnego. Na wejściu D pojawia się sygnał, który w rezultacie wpisuje do przerzutnika wartość '''-CARRY''', gdy spełnione są wszystkie niezbędne warunki: | ||
D = ~(CARRY & LRCBM & (~Q | ~BS)) | D = ~(CARRY & LRCBM & (~Q | ~BS)) | ||
| Linia 120: | Linia 114: | ||
Zapamiętywana w przerzutniku wartość jest zanegowana, stąd bramka NOT ('''M55''') na wyjściu. | Zapamiętywana w przerzutniku wartość jest zanegowana, stąd bramka NOT ('''M55''') na wyjściu. | ||
Na wejście S (które w związku z negacją na wyjściu '''M53''' jest efektywnie wejściem zerującym) podane są sygnały '''-P1''' (stan, w którym odczytywany jest rozkaz) i '''-P5''' (stan, w którym pobierany jest argument pośredni). Wystąpienie | Na wejście S (które w związku z negacją na wyjściu '''M53''' jest efektywnie wejściem zerującym) podane są sygnały '''-P1''' (stan, w którym odczytywany jest rozkaz) i '''-P5''' (stan, w którym pobierany jest argument pośredni). Wystąpienie któregokolwiek z nich powoduje zapamiętanie "1", czyli efektywne wyzerowanie zawartości przerzutnika. | ||
Ostatecznie sygnał '''+BAB17''' niesie informację o 17 bicie powstałym w wyniku B-modyfikacji lub pre-modyfikacji argumentu normalnego rozkazów bajtowych: | Ostatecznie sygnał '''+BAB17''' niesie informację o 17 bicie powstałym w wyniku B-modyfikacji lub pre-modyfikacji argumentu normalnego rozkazów bajtowych: | ||
| Linia 166: | Linia 160: | ||
Jeśli modyfikacja procesora jest aktywna, sygnał '''+ZI8''', oprócz swojej pierwotnej funkcji, powoduje też zamaskowanie przerwań w grupach 4, 5, 6 i 7. | Jeśli modyfikacja procesora jest aktywna, sygnał '''+ZI8''', oprócz swojej pierwotnej funkcji, powoduje też zamaskowanie przerwań w grupach 4, 5, 6 i 7. | ||
= Reakcja procesora na brak pamięci = | |||
'''Uwaga:''' Na istnienie poniższej zmiany silnie wskazuje analiza zawartości kości EPROM pamięci MEGA oraz inne zmiany w procesorze MX-16, jednak nie została ona definitywnie potwierdzona. | |||
Ponieważ MX-16 nie był wyposażony w pulpit techniczny, konieczna była zmiana w sposobie, w jaki procesor reaguje na odwołanie do nieskonfigurowanego segmentu pamięci w obszarze systemowym. Oryginalny procesor przechodził w stan STOP, z którego można go było wybudzić jedynie kluczem START/STOP. W MX-16 nie było takiej możliwości, więc obsługa takiego przypadku musiała być w pełni programowa i ograniczać się do zgłoszenia przerwania, podobnie jak w przypadku błędów dostępu do pamięci programów użytkowych. | |||
== Realizacja techniczna == | |||
Zostało to osiągnięte nie tyle przez modyfikację, co rekonfigurację procesora. Na pakiecie P-X istnieje zwora S-R (nie opisana w dokumentacji), która decyduje o tym, czy w opisanym wyżej przypadku wymuszany jest stan STOP. W komputerach MX-16 była ona najprawdopodobniej rozwarta. | |||
= Połączenia na platerze procesora = | = Połączenia na platerze procesora = | ||