Historycznie rzecz biorąc, pierwszym masowo produkowanym amatorskim komputerem radiowym był Radio-86RK, którego zbudowanie wymagało zaledwie 29 mikroukładów. Jego znaczącym ograniczeniem było to, że obsługiwał tylko tryb tekstowy. Orion-128 - był logiczną kontynuacją - przeznaczony także do montażu przez radioamatorów, miał większą pamięć (128kb w porównaniu z 16) i obsługiwał tryb graficzny: 384×256 (w 2 kolorach, 4 kolorach i 2 kolorach z palety 16 kolorów na każde 8 pikseli). Szacunkowa wielkość populacji Orionów w okresie największej popularności wynosi około 30-40 tysięcy komputerów.

Oriona dostałem w 1994 roku i to właśnie na Orionie napisałem swoje pierwsze programy. Zanim kupiłem swój pierwszy komputer w 1997 r., w Orionie zaczęły pojawiać się coraz większe zakłócenia (nie uruchamiał się za pierwszym razem, musiałem wielokrotnie restartować...), aż w końcu przestał działać całkowicie. Nie mogłem wtedy go naprawić i przez te wszystkie lata leżał nieruchomy, ale nie zapomniany.

Latem tego roku w końcu zdecydowałem się spróbować go naprawić - co z tego wyszło (oraz przegląd architektury i niektórych funkcji oprogramowania) - poniżej cięcia.

Architektura

Sercem komputera jest procesor KR580VM80A, odpowiednik Intel 8080. Aby uprościć konstrukcję, nie przechwycono słowa statusu procesora (gdzie procesor „mówi” podczas zapisu na stos, odczytu lub zapisu na I/ O porty). Nie ma również kontrolera przerwań.

Na najwyższych adresach znajduje się BIOS monitora. Jest to wykonane w ciekawy sposób - wszystkie jej funkcje wywoływane są poprzez tablicę w najwyższych adresach pamięci, które po prostu wykonują bezwarunkowy skok do miejsca faktycznej realizacji funkcji, dzięki czemu przy zmianie implementacji funkcji adresy wywołań pozostają takie same i nadal można je dodawać (tabela rośnie „w dół”).

Porty I/O - zostały zmapowane do pamięci, tj. jeśli przy dekodowaniu adresu zobaczyliśmy, że adres = adres portu, to nastąpił zapis do rejestru portu. Adresy portów znajdowały się w obszarze Monitora, gdzie i tak nie można było pisać. Porty zostały wykonane:

0F400H - port klawiatury 0F500H - port użytkownika nr 1 0F600H - port użytkownika nr 2 0F700H - port karty rozszerzeń 0F800H - sterowanie trybem graficznym (tylko zapis) 0F900H - przełączanie stron pamięci (tylko zapis) 0FA00H - przełączanie adresu pamięci ekranu (tylko zapis) ) do nagrywania) 0FB00H - port systemowy nr 4 (tylko do nagrywania, nie używany)

Procesor KR580VM80A ma 16-bitową szynę adresową i dlatego może zaadresować tylko 64 KB pamięci; port przełączania stron umożliwia procesorowi wybór bieżącej strony pamięci. Ale jeśli zmienimy stronę, program zostanie wykonany z innej strony pod tym samym adresem! Ponieważ Trudno w takich warunkach pracować, zwykle całą pracę z dodatkowymi stronami wykonuje monitor (bo na wszystkich stronach jest „widoczny w pamięci”), ale na pewno nie jest to zbyt szybkie.

Wyjście graficzne jest realizowane w następujący sposób: liczniki binarne stale przeglądają bieżący adres pamięci wideo. Multipleksery mogą podłączyć albo szynę adresową procesora (kiedy jest taka potrzeba), albo adres posortowany według liczników do pinów adresu pamięci. Każdy adres pamięci wideo jest odczytywany 2 razy, ale jeśli wystąpił konflikt z procesorem, wówczas odczytana wartość nie zostaje zapisana (tj. raz na dwa - konflikt nie występuje, ponieważ procesor uzyskuje dostęp do pamięci stosunkowo rzadko).

Pamięć wideo odczytywana jest jednocześnie z obu stron, a odczytane 16 bitów trafia następnie do rejestrów przesuwnych (ładowanie równoległe - wyjście szeregowe), na podstawie którego generowany jest sygnał wideo. W trybie monochromatycznym druga strona pamięci nie jest używana, natomiast w trybie kolorowym należy zapisywać na drugiej stronie. A to, jak pamiętamy, jest powolne, bo... możliwe tylko poprzez wywołania procedur monitorowania.

Na tym właśnie polega główna wada Oriona - prędkość wyświetlania tekstu jest bardzo niska (około sekundy na stronę tekstu w trybie kolorowym), szczególnie w porównaniu do Radio-86RK.

Naprawa

Miałem fabryczną wersję Oriona, w przypadku UKNC:

Ponieważ komputer był fabrycznie wykonany, płytka drukowana różniła się od wersji magazynowej, były też pewne różnice w obwodzie, co nie ułatwiało zadania. Na przewodach (po lewej stronie płytki) wisiał też licznik K155IE5 - oczywiście nie miałem pojęcia po co tam wisiał, kolejna zagadka.

Zgodnie z radą wymieniłem radzieckie kondensatory ceramiczne na nowe. Bolącym punktem Oriona był zasilacz (a generował złe napięcia) - wymieniłem go całkowicie na nowy impulsowy. Orion wymagał napięć +5, +12 i -5 V (a raczej tych napięć wymagał procesor KR580VM80A; wszystko inne wymagało +5).

Ale komputer nie działał: do procesora dotarł dwufazowy sygnał zegara, było jasne, że coś się dzieje na szynie adresowej i danych, ale komputer nie działał, na ekranie były śmieci bez oznak świadomej aktywności .

Moja pierwsza myśl była taka, że ​​przez 20 lat zawartość Monitora uległa zniszczeniu (szybka ochronna nie została zaklejona taśmą izolacyjną) - zamówiłem programator TL866, scaliłem firmware - i ku mojemu żalowi dopasował logi co do bajtu. Smutek. Nie było żadnych pomysłów.

Wiedziałem, że jeśli będą problemy z napięciami -5 i 12V, procesor może się spalić. Dlatego wymieniłem procesor i sterownik magistrali na magistrali danych - ale to nie dało żadnego rezultatu.

Sygnały RAS i CAS są zbliżone do prawdy (ponieważ są to sygnały o najwyższej częstotliwości - z nimi też są problemy).

Zauważyłem, że jeden z bitów szyny danych ma zawsze wartość 1. Okazało się, że przy lutowaniu kondensatorów przez przypadek zwarłem go do +5V. Dopiero teraz zacząłem rozumieć po co na płytkach drukowanych jest maska ​​lutownicza :)

Test pamięci zadziałał, ale co dziwne, po przetestowaniu pierwszej strony pamięci, ponownie przetestowałem pierwszą, a nie drugą. Podejrzenie padło na rejestr aktualnej strony pamięci (port 0F900H) - albo zapis nie działa, albo wtedy ta wartość nie przełącza strony.

Aby ułatwić debugowanie, zamiast Monitora napisałem program, który stale przełącza stronę pamięci. Wyjąłem starą EEPROM KS573RF2 od Oriona i zacząłem kasować... Po pół godzinie pod lampą kwarcową firmware nadal dopasowywał bajt po bajcie (nowsza EEPROM 27512 kasowana w 35-45 sekund)... Dopiero po godzinie smażenia mikroukład był czysty. Ale kiedy próbowałem to zapisać, spotkała mnie epicka porażka; jak się okazało, programator jest w stanie wytworzyć napięcie programujące nie wyższe niż 21 V, podczas gdy KS573RF2 wymaga 26.

Można było oczywiście zhakować programistę, ale zdecydowałem się przylutować nowocześniejszy pendrive z kasowaniem elektrycznym - położenie pinów oczywiście nie pasowało i musiałem przylutować przewody („ wielopiętrowa” płytka drukowana nie mieściła się na wysokość). Przełączniki - pozwalają na wybór jednego z kilku wypełnionych Monitorów i są przylutowane do pierwszych niewykorzystanych bitów adresu z podciągnięciem na 0 (KS573RF2 - 2kb, 11 bitów, czyli włącza 12-13-14 bitów):

Okazało się, że w momencie, gdy dekoder pracuje, wydając jedynkę do zapisu na port przełączania stron - szyna danych natychmiast przyjmuje stan 0, a rejestr nie ma czasu na zapisanie numeru nowej strony pamięci (na prawy - żółty - bit magistrali danych, niebieski - zapis stroboskopowy do portu).

Jeśli nieco opóźnisz stroboskop nagrywający za pomocą kondensatora, wówczas nastąpi nagrywanie i zapisana zostanie wymagana strona pamięci, ale to zbyt brudny hack i nie wierzyłem w to.

Więcej pomysłów nie było. Zauważyłem, że na wyjściach dwóch kości pamięci nie było danych, więc je wymieniłem. Stara PCB pokazała swoją najgorszą stronę - po lutowaniu suszarką do włosów zrobiła się czarna (moja mama opowiadała mi straszne bajki o PCB czerniącej się od suszarki - ale ja w to nie wierzyłam), ścieżki odpadły... A przygnębiający widok. W rozlutowaniu bez suszarki pomogła lutownica z pompką do rozlutowywania (cudowny wynalazek, roztapiasz lut, wciskasz przycisk - i wszystko wysysa, najważniejsze, żeby później nie zabrudzić płytki) oraz oplot miedziany (knot lutowniczy), który był używany przez całą masę:

Po wymianie kości pamięci wszystko nagle przestało działać. Znów na ekranie pojawiają się śmieci bez oznak życia. Szczerze mówiąc, w tym momencie byłam gotowa się poddać i przyznać, że nie wszystko w tym życiu da się zrobić.

Po dokładnym zbadaniu płytki przez szkło powiększające udało mi się znaleźć jeszcze 2 zwarcia, co też zrobiłem, jednak test pamięci nie zaczął działać. Potem odkryłem, sprawdzając, czy na szynie danych wystąpiło kolejne zwarcie - ale po przejrzeniu całej szyny danych nie znalazłem go. Aby zawęzić wyszukiwanie, musiałem pociąć określony fragment magistrali danych na kawałki. W końcu udało się znaleźć zwarcie - okazało się tak mikroskopijne, że ledwo widoczne przez szkło powiększające. Powód dla którego udało mi się tak łatwo uzyskać zwarcia okazał się prosty - omyłkowo wziąłem lut niskotopliwy z bizmutem (temperatura topnienia 144 stopnie) zamiast zwykłego lutu POS60. Po zetknięciu z lutownicą o temperaturze 250 stopni topnik natychmiast się zagotował i rozproszył dookoła maleńkie kropelki lutowia. A jeszcze się zastanawiałem dlaczego po lutowaniu powierzchnia okazuje się matowa...

Test pamięci zadziałał i wygląda na to, że stwierdzone podczas kontroli zwarcie rozwiązało problem z przełączaniem stron, teraz szyna danych nie została zresetowana do 0 w najważniejszym momencie, a przełączanie stron działa stabilnie:

Jednak ładowanie ORDOS z zewnętrznego napędu ROM nadal nie działało. Po ręcznym odczytaniu 3 bajtów z dysku ROM przez porty (polecenia do tego znajdują się w Monitorze-1), zauważyłem, że 2 bity danych docierały niepoprawnie (w porównaniu z obrazem dysku ROM połączonym w programatorze). Po wlutowaniu romdysku ORDOS uruchomił się! Radość nie znała granic:

Jednak problemy nadal pozostały: test pamięci pokazał błąd pamięci na drugiej stronie po rozgrzaniu, czasami obraz na telewizorze znikał, szczególnie często podczas testowania drugiej strony pamięci i trzeba było coś zrobić z mistycznym zawieszaniem się K155IE5 na przewodach:

Wymiana chipa pamięci była łatwa, ale musiałem cierpieć z powodu zaniku obrazu. Podejrzenie padł na sygnał umożliwiający zapis danych z pamięci wideo do rejestrów generacji sygnału wideo (zapis tam jest zabroniony, gdy procesor uzyskuje dostęp do pamięci). Ścieżka była długa (~50cm), a ponieważ nie było dopasowania impedancji – sygnał odbił się od końców ścieżki, przekraczając dopuszczalny poziom 0 w logice TTL (0,4V) – to mogło powodować problemy. Dlatego zastosowałem terminację szeregową - rezystor 220 Ohm obok źródła sygnału - dzwonienie zniknęło, ale problem pozostał:

Mistycyzmu dodawało to, że po podłączeniu masy oscyloskopu zanikanie obrazu ustało. Okazało się, że problem tkwił w kiepskim zasilaniu sieciowym 12V, w którym widocznie skąpiono na filtrowaniu - na ziemi było dużo śmieci (tj. między masą a szyną 12V jest zawsze 12V, ale w stosunku do masy telewizora lub oscyloskopu występuje ogromny hałas). Dzięki wymianie zasilacza na lepszy (z płyt demonstracyjnych FPGA) problem został całkowicie rozwiązany.

Po namierzeniu na przewodach K155IE5 okazało się, że częściowo zastępuje on wlutowany w płytkę K1533IE5. Dlaczego konieczne było pozostawienie jej wiszącej na drutach, nie jest dla mnie jasne. Wyjąłem K1533IE5, przylutowałem K155IE5 - i wszystko działa! Seria 1533 to burżuazyjny ALS, 155 to zwykły TTL. ALS ma zmniejszoną nośność i prędkość, najwyraźniej to był pierwotny powód wymiany.

Widok ogólny w gotowej formie:

Mały szalik po lewej stronie -

schemat przesunięcia ekranu w dół (w przeciwnym razie pierwsza linia w telewizorach LCD zostanie obcięta)

Historycznie rzecz biorąc, pierwszym masowo produkowanym amatorskim komputerem radiowym był Radio-86RK, którego zbudowanie wymagało zaledwie 29 mikroukładów. Jego znaczącym ograniczeniem było to, że obsługiwał tylko tryb tekstowy i wymagał trudnych do zdobycia chipów. Orion-128 - był logiczną kontynuacją - przeznaczony także do montażu przez radioamatorów, miał większą pamięć (128kb w porównaniu do 16/32kb) i obsługiwał tryb graficzny: 384×256 (w 2 kolorach, 4 kolorach i 2 kolorach z palety 16 kolorów na każde 8 pikseli). Szacunkowa wielkość populacji Orionów w okresie największej popularności wynosi około 30-40 tysięcy komputerów.

Oriona dostałem w 1994 roku i to właśnie na Orionie uruchamiałem swoje pierwsze programy (wcześniej musiałem je spisywać „na stole”). Zanim kupiłem swój pierwszy komputer w 1997 r., w Orionie zaczęły pojawiać się coraz większe zakłócenia (nie uruchamiał się za pierwszym razem, musiałem wielokrotnie restartować...), aż w końcu przestał działać całkowicie. Nie mogłem wtedy go naprawić i przez te wszystkie lata leżał nieruchomy, ale nie zapomniany.

Latem tego roku w końcu zdecydowałem się spróbować go naprawić - co z tego wyszło (oraz przegląd architektury i niektórych funkcji oprogramowania) - poniżej cięcia.

Architektura

Sercem komputera jest procesor KR580VM80A, radziecki odpowiednik Intela 8080. Aby uprościć projekt, nie przechwycono słowa statusu procesora (gdzie procesor „mówi” podczas zapisu na stos, odczytu lub zapisu do portów I/O). Nie ma również kontrolera przerwań.

Na najwyższych adresach znajduje się BIOS monitora. Jest to wykonane w ciekawy sposób - wszystkie jej funkcje wywoływane są poprzez tablicę w najwyższych adresach pamięci, które po prostu wykonują bezwarunkowy skok do miejsca faktycznej realizacji funkcji, dzięki czemu przy zmianie implementacji funkcji adresy wywołań pozostają takie same i nadal można je dodawać (tabela rośnie „w dół”).

Porty I/O - zostały zmapowane do pamięci, tj. jeśli przy dekodowaniu adresu zobaczyliśmy, że adres = adres portu, to nastąpił zapis do rejestru portu. Adresy portów znajdowały się w obszarze Monitora, gdzie i tak nie można było pisać. Porty zostały wykonane:

0F400H - port klawiatury 0F500H - port użytkownika nr 1 0F600H - port użytkownika nr 2 0F700H - port karty rozszerzeń 0F800H - sterowanie trybem graficznym (tylko zapis) 0F900H - przełączanie stron pamięci (tylko zapis) 0FA00H - przełączanie adresu pamięci ekranu (tylko zapis) ) do nagrywania) 0FB00H - port systemowy nr 4 (tylko do nagrywania, nie używany)

Procesor KR580VM80A ma 16-bitową szynę adresową i dlatego może zaadresować tylko 64 KB pamięci; port przełączania stron umożliwia procesorowi wybór bieżącej strony pamięci. Ale jeśli zmienimy stronę, program zostanie wykonany z innej strony pod tym samym adresem! Ponieważ Trudno w takich warunkach pracować, zwykle całą pracę z dodatkowymi stronami wykonuje monitor (bo na wszystkich stronach jest „widoczny w pamięci”), ale na pewno nie jest to zbyt szybkie.

Wyjście graficzne jest realizowane w następujący sposób: liczniki binarne stale przeglądają bieżący adres pamięci wideo. Multipleksery mogą podłączyć albo szynę adresową procesora (kiedy jest taka potrzeba), albo adres posortowany według liczników do pinów adresu pamięci. Każdy adres pamięci wideo jest odczytywany 2 razy, ale jeśli wystąpił konflikt z procesorem, wówczas odczytana wartość nie zostaje zapisana (tj. raz na dwa - konflikt nie występuje, ponieważ procesor uzyskuje dostęp do pamięci stosunkowo rzadko).

Pamięć wideo odczytywana jest jednocześnie z obu stron, a odczytane 16 bitów trafia następnie do rejestrów przesuwnych (ładowanie równoległe - wyjście szeregowe), na podstawie którego generowany jest sygnał wideo. W trybie monochromatycznym druga strona pamięci nie jest używana, natomiast w trybie kolorowym należy zapisywać na drugiej stronie. A to, jak pamiętamy, jest powolne, bo... możliwe tylko poprzez wywołania procedur monitorowania.

Na tym właśnie polega główna wada Oriona - prędkość wyświetlania tekstu jest bardzo niska (około sekundy na stronę tekstu w trybie kolorowym), szczególnie w porównaniu do Radio-86RK. Procesor wykonuje 300-500 tysięcy operacji na sekundę (przy częstotliwości taktowania 2,5 MHz), a zapis na dodatkową stronę pamięci wymaga co najmniej kilkunastu operacji.

Zastanówmy się, co nie działa

Miałem fabryczną wersję Oriona:

Ponieważ komputer był fabrycznie wykonany, płytka drukowana różniła się od wersji magazynowej, były też pewne różnice w obwodzie, co nie ułatwiało zadania. Na przewodach (po lewej stronie płytki) wisiał też licznik K155IE5 - oczywiście nie miałem pojęcia po co tam wisiał, kolejna zagadka.

Zgodnie z radą wymieniłem radzieckie kondensatory ceramiczne na nowe. Bolącym punktem Oriona był zasilacz (a generował złe napięcia) - wymieniłem go całkowicie na nowy impulsowy. Orion wymagał napięć +5, +12 i -5 V (a raczej tych napięć wymagał procesor KR580VM80A; wszystko inne wymagało +5).

Ale komputer nie działał: do procesora dotarł dwufazowy sygnał zegara, było jasne, że coś się dzieje na szynie adresowej i danych, ale komputer nie działał, na ekranie były śmieci bez oznak świadomej aktywności .

Moja pierwsza myśl była taka, że ​​przez 20 lat zawartość Monitora uległa zniszczeniu (szybka ochronna nie została zaklejona taśmą izolacyjną) - zamówiłem programator TL866, scaliłem firmware - i ku mojemu żalowi dopasował logi co do bajtu. Smutek. Nie było żadnych pomysłów.

Wiedziałem, że jeśli będą problemy z napięciami -5 i 12V, procesor może się spalić. Dlatego wymieniłem procesor i sterownik magistrali na magistrali danych - ale to nie dało żadnego rezultatu.

Sygnały RAS i CAS są zbliżone do prawdy (ponieważ są to sygnały o najwyższej częstotliwości - z nimi też są problemy).

Zauważyłem, że jeden z bitów szyny danych ma zawsze wartość 1. Okazało się, że przy lutowaniu kondensatorów przez przypadek zwarłem go do +5V. Dopiero teraz zacząłem rozumieć, dlaczego na płytkach drukowanych znajduje się maska ​​lutownicza :-)

Test pamięci zadziałał, ale co dziwne, po przetestowaniu pierwszej strony pamięci, ponownie przetestowałem pierwszą, a nie drugą. Podejrzenie padło na rejestr aktualnej strony pamięci (port 0F900H) - albo zapis nie działa, albo wtedy ta wartość nie przełącza strony.

Aby ułatwić debugowanie, zamiast Monitora napisałem program, który stale przełącza stronę pamięci. Wyjąłem starą EEPROM KS573RF2 od Oriona i zacząłem kasować... Po pół godzinie pod lampą kwarcową firmware nadal dopasowywał bajt po bajcie (nowsza EEPROM 27512 kasowana w 35-45 sekund)... Dopiero po godzinie smażenia mikroukład był czysty. Ale kiedy próbowałem to zapisać, spotkała mnie epicka porażka; jak się okazało, programator jest w stanie wytworzyć napięcie programujące nie wyższe niż 21 V, podczas gdy KS573RF2 wymaga 26.

Można było oczywiście zhakować programistę, ale zdecydowałem się przylutować nowocześniejszy pendrive z kasowaniem elektrycznym - położenie pinów oczywiście nie pasowało i musiałem przylutować przewody („ wielopiętrowa” płytka drukowana nie mieściła się na wysokość). Przełączniki - pozwalają na wybór jednego z kilku wypełnionych Monitorów i są przylutowane do pierwszych niewykorzystanych bitów adresu z podciągnięciem na 0 (KS573RF2 - 2kb, 11 bitów, czyli włącza 12-13-14 bitów):

Okazało się, że w momencie, gdy dekoder pracuje, wydając jedynkę do zapisu na port przełączania stron - szyna danych natychmiast przyjmuje stan 0, a rejestr nie ma czasu na zapisanie numeru nowej strony pamięci (na prawy - żółty - bit magistrali danych, niebieski - stroboskop do zapisu do portu).

Jeśli nieco opóźnisz stroboskop nagrywający za pomocą kondensatora, wówczas nastąpi nagrywanie i zapisana zostanie wymagana strona pamięci, ale to zbyt brudny hack i nie wierzyłem w to.

Więcej pomysłów nie było. Zauważyłem, że na wyjściach dwóch kości pamięci nie było danych, więc je wymieniłem. Stara PCB pokazała swoją najgorszą stronę - po lutowaniu suszarką do włosów zrobiła się czarna (moja mama opowiadała mi straszne bajki o PCB czerniącej się od suszarki - ale ja w to nie wierzyłam), ścieżki odpadły... A przygnębiający widok. W rozlutowaniu bez suszarki pomogła lutownica z pompką do rozlutowywania (cudowny wynalazek, roztapiasz lut, wciskasz przycisk - i wszystko wysysa, najważniejsze, żeby później nie zabrudzić płytki) oraz oplot miedziany (knot lutowniczy), który był używany przez całą masę:

Po wymianie kości pamięci wszystko nagle przestało działać. Znów na ekranie pojawiają się śmieci bez oznak życia. Szczerze mówiąc, w tym momencie byłam gotowa się poddać i przyznać, że nie wszystko w tym życiu da się zrobić.

Po dokładnym zbadaniu płytki przez szkło powiększające udało mi się znaleźć jeszcze 2 zwarcia, co też zrobiłem, jednak test pamięci nie zaczął działać. Następnie dokładnie sprawdziłem czy doszło do kolejnego zwarcia na szynie danych - jednak po przejrzeniu całej szyny danych nie znalazłem. Aby zawęzić wyszukiwanie, musiałem pociąć określony fragment magistrali danych na kawałki. W końcu udało się znaleźć zwarcie - okazało się tak mikroskopijne, że ledwo widoczne przez szkło powiększające. Powód dla którego udało mi się tak łatwo uzyskać zwarcia okazał się prosty - omyłkowo wziąłem lut niskotopliwy z bizmutem (temperatura topnienia 144 stopnie) zamiast zwykłego lutu POS60. Po zetknięciu z lutownicą o temperaturze 250 stopni topnik natychmiast się zagotował i rozproszył dookoła maleńkie kropelki lutowia. A jeszcze się zastanawiałem dlaczego po lutowaniu powierzchnia okazuje się matowa...

Test pamięci zadziałał i wygląda na to, że stwierdzone podczas kontroli zwarcie rozwiązało problem z przełączaniem stron, teraz szyna danych nie została zresetowana do 0 w najważniejszym momencie, a przełączanie stron działa stabilnie:

Jednak ładowanie ORDOS z zewnętrznego napędu ROM nadal nie działało. Po ręcznym odczytaniu 3 bajtów z dysku ROM przez porty (polecenia do tego znajdują się w Monitorze-1), zauważyłem, że 2 bity danych docierały niepoprawnie (w porównaniu z obrazem dysku ROM połączonym w programatorze). Po wlutowaniu romdysku ORDOS uruchomił się! Radość nie znała granic:

Jednak problemy nadal pozostały: test pamięci pokazał błąd pamięci na drugiej stronie po rozgrzaniu, czasami obraz na telewizorze znikał, szczególnie często podczas testowania drugiej strony pamięci i trzeba było coś zrobić z mistycznym zawieszaniem się K155IE5 na przewodach:

Wymiana chipa pamięci była łatwa, ale musiałem cierpieć z powodu zaniku obrazu. Podejrzenie padł na sygnał umożliwiający zapis danych z pamięci wideo do rejestrów generacji sygnału wideo (zapis tam jest zabroniony, gdy procesor uzyskuje dostęp do pamięci). Ścieżka była długa (~50cm), a ponieważ nie było dopasowania impedancji – sygnał odbił się od końców ścieżki, przekraczając dopuszczalny poziom 0 w logice TTL (0,4V) – to mogło powodować problemy. Dlatego zastosowałem terminację szeregową - rezystor 220 Ohm obok źródła sygnału - dzwonienie zniknęło, ale problem pozostał:

Istota terminacji sekwencyjnej

Załóżmy, że impedancja charakterystyczna toru wynosi 220 omów. Bez zakończenia impuls 5 V dotrze do końca ścieżki, zostanie odbity, a chwilowe napięcie wyniesie tam 10 V. Większość z nich zostanie oczywiście odcięta przez diody ochronne wewnątrz mikroukładu, ale nastąpi skok do 10 V. Jeśli obok źródła sygnału umieścimy rezystor 220 Ohm, to wzdłuż toru popłynie 2,5 V (ponieważ mamy dzielnik napięcia), gdy 2,5 V dotrze do końca toru i zostanie odbite, otrzymamy dokładnie 5 V tyle ile potrzeba.

Impedancja charakterystyczna toru zależy od jego szerokości i odległości od podłoża; w przypadku cienkich torów bez ziemnego wielokąta pod spodem jest wysoka i wynosi setki omów.

Mistycyzmu dodawało to, że po podłączeniu masy oscyloskopu zanikanie obrazu ustało. Okazało się, że problem tkwił w kiepskim zasilaniu sieciowym 12V, w którym widocznie skąpiono na filtrowaniu - na ziemi było dużo śmieci (tj. między masą a szyną 12V jest zawsze 12V, ale w stosunku do masy telewizora lub oscyloskopu występuje ogromny hałas). Dzięki wymianie zasilacza na lepszy (z płyt demonstracyjnych FPGA) problem został całkowicie rozwiązany.

Po namierzeniu na przewodach K155IE5 okazało się, że częściowo zastępuje on wlutowany w płytkę K1533IE5. Dlaczego konieczne było pozostawienie jej wiszącej na drutach, nie jest dla mnie jasne. Wyjąłem K1533IE5, przylutowałem K155IE5 - i wszystko działa! Seria 1533 to burżuazyjny ALS, 155 to zwykły TTL. ALS ma zmniejszoną nośność i prędkość, najwyraźniej to był pierwotny powód wymiany.

Historycznie rzecz biorąc, pierwszym masowo produkowanym amatorskim komputerem radiowym był Radio-86RK, którego zbudowanie wymagało zaledwie 29 mikroukładów. Jego znaczącym ograniczeniem było to, że obsługiwał tylko tryb tekstowy i wymagał trudnych do zdobycia chipów. Orion-128 - był logiczną kontynuacją - przeznaczony także do montażu przez radioamatorów, miał większą pamięć (128kb w porównaniu do 16/32kb) i obsługiwał tryb graficzny: 384×256 (w 2 kolorach, 4 kolorach i 2 kolorach z palety 16 kolorów na każde 8 pikseli). Szacunkowa wielkość populacji Orionów w okresie największej popularności wynosi około 30-40 tysięcy komputerów.

Oriona dostałem w 1994 roku i to właśnie na Orionie uruchamiałem swoje pierwsze programy (wcześniej musiałem je spisywać „na stole”). Zanim kupiłem swój pierwszy komputer w 1997 r., w Orionie zaczęły pojawiać się coraz większe zakłócenia (nie uruchamiał się za pierwszym razem, musiałem wielokrotnie restartować...), aż w końcu przestał działać całkowicie. Nie mogłem wtedy go naprawić i przez te wszystkie lata leżał nieruchomy, ale nie zapomniany.

Latem tego roku w końcu zdecydowałem się spróbować go naprawić - co z tego wyszło (oraz przegląd architektury i niektórych funkcji oprogramowania) - poniżej cięcia.

Architektura

Sercem komputera jest procesor KR580VM80A, radziecki odpowiednik Intela 8080. Aby uprościć projekt, nie przechwycono słowa statusu procesora (gdzie procesor „mówi” podczas zapisu na stos, odczytu lub zapisu do portów I/O). Nie ma również kontrolera przerwań.

Na najwyższych adresach znajduje się BIOS monitora. Jest to wykonane w ciekawy sposób - wszystkie jej funkcje wywoływane są poprzez tablicę w najwyższych adresach pamięci, które po prostu wykonują bezwarunkowy skok do miejsca faktycznej realizacji funkcji, dzięki czemu przy zmianie implementacji funkcji adresy wywołań pozostają takie same i nadal można je dodawać (tabela rośnie „w dół”).

Porty I/O - zostały zmapowane do pamięci, tj. jeśli przy dekodowaniu adresu zobaczyliśmy, że adres = adres portu, to nastąpił zapis do rejestru portu. Adresy portów znajdowały się w obszarze Monitora, gdzie i tak nie można było pisać. Porty zostały wykonane:

0F400H - port klawiatury 0F500H - port użytkownika nr 1 0F600H - port użytkownika nr 2 0F700H - port karty rozszerzeń 0F800H - sterowanie trybem graficznym (tylko zapis) 0F900H - przełączanie stron pamięci (tylko zapis) 0FA00H - przełączanie adresu pamięci ekranu (tylko zapis) ) do nagrywania) 0FB00H - port systemowy nr 4 (tylko do nagrywania, nie używany)

Procesor KR580VM80A ma 16-bitową szynę adresową i dlatego może zaadresować tylko 64 KB pamięci; port przełączania stron umożliwia procesorowi wybór bieżącej strony pamięci. Ale jeśli zmienimy stronę, program zostanie wykonany z innej strony pod tym samym adresem! Ponieważ Trudno w takich warunkach pracować, zwykle całą pracę z dodatkowymi stronami wykonuje monitor (bo na wszystkich stronach jest „widoczny w pamięci”), ale na pewno nie jest to zbyt szybkie.

Wyjście graficzne jest realizowane w następujący sposób: liczniki binarne stale przeglądają bieżący adres pamięci wideo. Multipleksery mogą podłączyć albo szynę adresową procesora (kiedy jest taka potrzeba), albo adres posortowany według liczników do pinów adresu pamięci. Każdy adres pamięci wideo jest odczytywany 2 razy, ale jeśli wystąpił konflikt z procesorem, wówczas odczytana wartość nie zostaje zapisana (tj. raz na dwa - konflikt nie występuje, ponieważ procesor uzyskuje dostęp do pamięci stosunkowo rzadko).

Pamięć wideo odczytywana jest jednocześnie z obu stron, a odczytane 16 bitów trafia następnie do rejestrów przesuwnych (ładowanie równoległe - wyjście szeregowe), na podstawie którego generowany jest sygnał wideo. W trybie monochromatycznym druga strona pamięci nie jest używana, natomiast w trybie kolorowym należy zapisywać na drugiej stronie. A to, jak pamiętamy, jest powolne, bo... możliwe tylko poprzez wywołania procedur monitorowania.

Na tym właśnie polega główna wada Oriona - prędkość wyświetlania tekstu jest bardzo niska (około sekundy na stronę tekstu w trybie kolorowym), szczególnie w porównaniu do Radio-86RK. Procesor wykonuje 300-500 tysięcy operacji na sekundę (przy częstotliwości taktowania 2,5 MHz), a zapis na dodatkową stronę pamięci wymaga co najmniej kilkunastu operacji.

Zastanówmy się, co nie działa

Miałem fabryczną wersję Oriona:

Ponieważ komputer był fabrycznie wykonany, płytka drukowana różniła się od wersji magazynowej, były też pewne różnice w obwodzie, co nie ułatwiało zadania. Na przewodach (po lewej stronie płytki) wisiał też licznik K155IE5 - oczywiście nie miałem pojęcia po co tam wisiał, kolejna zagadka.

Zgodnie z radą wymieniłem radzieckie kondensatory ceramiczne na nowe. Bolącym punktem Oriona był zasilacz (a generował złe napięcia) - wymieniłem go całkowicie na nowy impulsowy. Orion wymagał napięć +5, +12 i -5 V (a raczej tych napięć wymagał procesor KR580VM80A; wszystko inne wymagało +5).

Ale komputer nie działał: do procesora dotarł dwufazowy sygnał zegara, było jasne, że coś się dzieje na szynie adresowej i danych, ale komputer nie działał, na ekranie były śmieci bez oznak świadomej aktywności .

Moja pierwsza myśl była taka, że ​​przez 20 lat zawartość Monitora uległa zniszczeniu (szybka ochronna nie została zaklejona taśmą izolacyjną) - zamówiłem programator TL866, scaliłem firmware - i ku mojemu żalowi dopasował logi co do bajtu. Smutek. Nie było żadnych pomysłów.

Wiedziałem, że jeśli będą problemy z napięciami -5 i 12V, procesor może się spalić. Dlatego wymieniłem procesor i sterownik magistrali na magistrali danych - ale to nie dało żadnego rezultatu.

Sygnały RAS i CAS są zbliżone do prawdy (ponieważ są to sygnały o najwyższej częstotliwości - z nimi też są problemy).

Zauważyłem, że jeden z bitów szyny danych ma zawsze wartość 1. Okazało się, że przy lutowaniu kondensatorów przez przypadek zwarłem go do +5V. Dopiero teraz zacząłem rozumieć, dlaczego na płytkach drukowanych znajduje się maska ​​lutownicza :-)

Test pamięci zadziałał, ale co dziwne, po przetestowaniu pierwszej strony pamięci, ponownie przetestowałem pierwszą, a nie drugą. Podejrzenie padło na rejestr aktualnej strony pamięci (port 0F900H) - albo zapis nie działa, albo wtedy ta wartość nie przełącza strony.

Aby ułatwić debugowanie, zamiast Monitora napisałem program, który stale przełącza stronę pamięci. Wyjąłem starą EEPROM KS573RF2 od Oriona i zacząłem kasować... Po pół godzinie pod lampą kwarcową firmware nadal dopasowywał bajt po bajcie (nowsza EEPROM 27512 kasowana w 35-45 sekund)... Dopiero po godzinie smażenia mikroukład był czysty. Ale kiedy próbowałem to zapisać, spotkała mnie epicka porażka; jak się okazało, programator jest w stanie wytworzyć napięcie programujące nie wyższe niż 21 V, podczas gdy KS573RF2 wymaga 26.

Można było oczywiście zhakować programistę, ale zdecydowałem się przylutować nowocześniejszy pendrive z kasowaniem elektrycznym - położenie pinów oczywiście nie pasowało i musiałem przylutować przewody („ wielopiętrowa” płytka drukowana nie mieściła się na wysokość). Przełączniki - pozwalają na wybór jednego z kilku wypełnionych Monitorów i są przylutowane do pierwszych niewykorzystanych bitów adresu z podciągnięciem na 0 (KS573RF2 - 2kb, 11 bitów, czyli włącza 12-13-14 bitów):

Okazało się, że w momencie, gdy dekoder pracuje, wydając jedynkę do zapisu na port przełączania stron - szyna danych natychmiast przyjmuje stan 0, a rejestr nie ma czasu na zapisanie numeru nowej strony pamięci (na prawy - żółty - bit magistrali danych, niebieski - stroboskop do zapisu do portu).

Jeśli nieco opóźnisz stroboskop nagrywający za pomocą kondensatora, wówczas nastąpi nagrywanie i zapisana zostanie wymagana strona pamięci, ale to zbyt brudny hack i nie wierzyłem w to.

Więcej pomysłów nie było. Zauważyłem, że na wyjściach dwóch kości pamięci nie było danych, więc je wymieniłem. Stara PCB pokazała swoją najgorszą stronę - po lutowaniu suszarką do włosów zrobiła się czarna (moja mama opowiadała mi straszne bajki o PCB czerniącej się od suszarki - ale ja w to nie wierzyłam), ścieżki odpadły... A przygnębiający widok. W rozlutowaniu bez suszarki pomogła lutownica z pompką do rozlutowywania (cudowny wynalazek, roztapiasz lut, wciskasz przycisk - i wszystko wysysa, najważniejsze, żeby później nie zabrudzić płytki) oraz oplot miedziany (knot lutowniczy), który był używany przez całą masę:

Po wymianie kości pamięci wszystko nagle przestało działać. Znów na ekranie pojawiają się śmieci bez oznak życia. Szczerze mówiąc, w tym momencie byłam gotowa się poddać i przyznać, że nie wszystko w tym życiu da się zrobić.

Po dokładnym zbadaniu płytki przez szkło powiększające udało mi się znaleźć jeszcze 2 zwarcia, co też zrobiłem, jednak test pamięci nie zaczął działać. Następnie dokładnie sprawdziłem czy doszło do kolejnego zwarcia na szynie danych - jednak po przejrzeniu całej szyny danych nie znalazłem. Aby zawęzić wyszukiwanie, musiałem pociąć określony fragment magistrali danych na kawałki. W końcu udało się znaleźć zwarcie - okazało się tak mikroskopijne, że ledwo widoczne przez szkło powiększające. Powód dla którego udało mi się tak łatwo uzyskać zwarcia okazał się prosty - omyłkowo wziąłem lut niskotopliwy z bizmutem (temperatura topnienia 144 stopnie) zamiast zwykłego lutu POS60. Po zetknięciu z lutownicą o temperaturze 250 stopni topnik natychmiast się zagotował i rozproszył dookoła maleńkie kropelki lutowia. A jeszcze się zastanawiałem dlaczego po lutowaniu powierzchnia okazuje się matowa...

Test pamięci zadziałał i wygląda na to, że stwierdzone podczas kontroli zwarcie rozwiązało problem z przełączaniem stron, teraz szyna danych nie została zresetowana do 0 w najważniejszym momencie, a przełączanie stron działa stabilnie:

Jednak ładowanie ORDOS z zewnętrznego napędu ROM nadal nie działało. Po ręcznym odczytaniu 3 bajtów z dysku ROM przez porty (polecenia do tego znajdują się w Monitorze-1), zauważyłem, że 2 bity danych docierały niepoprawnie (w porównaniu z obrazem dysku ROM połączonym w programatorze). Po wlutowaniu romdysku ORDOS uruchomił się! Radość nie znała granic:

Jednak problemy nadal pozostały: test pamięci pokazał błąd pamięci na drugiej stronie po rozgrzaniu, czasami obraz na telewizorze znikał, szczególnie często podczas testowania drugiej strony pamięci i trzeba było coś zrobić z mistycznym zawieszaniem się K155IE5 na przewodach:

Wymiana chipa pamięci była łatwa, ale musiałem cierpieć z powodu zaniku obrazu. Podejrzenie padł na sygnał umożliwiający zapis danych z pamięci wideo do rejestrów generacji sygnału wideo (zapis tam jest zabroniony, gdy procesor uzyskuje dostęp do pamięci). Ścieżka była długa (~50cm), a ponieważ nie było dopasowania impedancji – sygnał odbił się od końców ścieżki, przekraczając dopuszczalny poziom 0 w logice TTL (0,4V) – to mogło powodować problemy. Dlatego zastosowałem terminację szeregową - rezystor 220 Ohm obok źródła sygnału - dzwonienie zniknęło, ale problem pozostał:

Istota terminacji sekwencyjnej

Załóżmy, że impedancja charakterystyczna toru wynosi 220 omów. Bez zakończenia impuls 5 V dotrze do końca ścieżki, zostanie odbity, a chwilowe napięcie wyniesie tam 10 V. Większość z nich zostanie oczywiście odcięta przez diody ochronne wewnątrz mikroukładu, ale nastąpi skok do 10 V. Jeśli obok źródła sygnału umieścimy rezystor 220 Ohm, to wzdłuż toru popłynie 2,5 V (ponieważ mamy dzielnik napięcia), gdy 2,5 V dotrze do końca toru i zostanie odbite, otrzymamy dokładnie 5 V tyle ile potrzeba.

Impedancja charakterystyczna toru zależy od jego szerokości i odległości od podłoża; w przypadku cienkich torów bez ziemnego wielokąta pod spodem jest wysoka i wynosi setki omów.

Mistycyzmu dodawało to, że po podłączeniu masy oscyloskopu zanikanie obrazu ustało. Okazało się, że problem tkwił w kiepskim zasilaniu sieciowym 12V, w którym widocznie skąpiono na filtrowaniu - na ziemi było dużo śmieci (tj. między masą a szyną 12V jest zawsze 12V, ale w stosunku do masy telewizora lub oscyloskopu występuje ogromny hałas). Dzięki wymianie zasilacza na lepszy (z płyt demonstracyjnych FPGA) problem został całkowicie rozwiązany.

Po namierzeniu na przewodach K155IE5 okazało się, że częściowo zastępuje on wlutowany w płytkę K1533IE5. Dlaczego konieczne było pozostawienie jej wiszącej na drutach, nie jest dla mnie jasne. Wyjąłem K1533IE5, przylutowałem K155IE5 - i wszystko działa! Seria 1533 to burżuazyjny ALS, 155 to zwykły TTL. ALS ma zmniejszoną nośność i prędkość, najwyraźniej to był pierwotny powód wymiany.

W tej sekcji opisano opcję komputerową dla przypadku UKNC. Nadal rozumiem treść tej strony :)

Krótka specyfikacja:

procesor	KR580VM80A
Głębia bitowa
Wydajność (OP./SEC.)	0,5 mln operacji między rejestrami
Baran	128 kB
ROM	2KB
Grafika	384x256 pikseli, do 16 kolorów
Generator znaków	do pobrania
Urządzenie wyświetlające	telewizor domowy
Pamięć zewnętrzna	magnetofon kasetowy, dysk ROM
Dźwięk	sygnał dźwiękowy jednokanałowy
system operacyjny	MONITOR systemu

Projekt:

1. Oryginalny schemat obwodu elektrycznego w formacie PCAD 4.5 - pobierz
2. Oryginalna płytka drukowana w formacie PCAD 4.5 - pobierz
3. Oryginalna biblioteka elementów w formacie PCAD 4.5 - pobierz
4. Oryginalny schemat obwodu, płytka drukowana i rysunek złożeniowy w formacie PNG - pobierz
5. Konwersja oryginalnej płytki drukowanej do formatu PCAD2002, - pobierz
6. Przerysowany oryginalny schemat obwodu elektrycznego w formacie PCAD2002 - pobierz
7. Oryginalna płytka drukowana w formacie PCAD2002, podłączona do schematu z punktu 6 - pobierz
8. Przerysowany oryginalny schemat obwodu elektrycznego w formacie pdf - pobierz
9. Krótkie uwagi dotyczące składania komputera według oryginalnego schematu w formacie pdf. Zdecydowanie zaleca się zapoznanie z nimi przed rozpoczęciem procesu montażu. - pobierać
10. Poprawiono rysunek złożeniowy oryginalnego obwodu w formacie pdf. Zdecydowanie zaleca się zbudowanie komputera przy jego użyciu. - pobierać
11. Biblioteka elementów w formacie PCAD2002 - pobierz

Uwaga: oryginalny obwód i płytka zawierają błędy, w wyniku których komputer nie będzie działał, dotyczy to punktów 1..8. Nie zaleca się ich stosowania do produkcji desek. Dzięki:

Sugonyako V., Safronov V., Konenkov K.- do stworzenia komputera Orion-128
Chunin Roman (CHRV)- za zachowanie dziedzictwa Oriona
Akimow Siergiej (Błąd 404)- za oddanie Orionowi i za to, że swoją działalnością nie pozwala nam zapomnieć o tym chwalebnym komputerze

Emulator 3000

Tutaj możesz pobrać nową wersję programu Emulator 3000 [Wersja 6.1 z 03.04.2004].
Możesz także spojrzeć na wygląd emulatora:

Jeśli posiadasz jakiekolwiek informacje na temat poniższych komputerów, skontaktuj się z ich autorem (eugeneprogrammer !@! mail.ru):

• Korweta
• BK-0010
• BK-0011M
• Wielka Brytania-NC
• Agat-7
• Agat-9
• Orion-128
• Partner 01.01
• Apogeum BK-01
• Wszelkie inne, których nie ma na liście emulowanych

Opis

Emulator 3000 (lub E3000) to emulator komputerów radzieckich i zagranicznych, takich jak Mikrosha, Vector-06Ts, Pyldin-601 i inne. Program działa na systemach operacyjnych Windows 95/98/NT/ME/2000/XP.

Możliwości

Obecnie program emuluje:

• Mikro-80
• Radio-86RK
• Mikrosza
• YUT-88
• Partner 01.01
• Apogeum BK-01
• Specjalista
• Specjalista MX
• Orion-128
• Vector-06TS, [Programy i gry w formacie WinRAR 3.0]
• Baszkiria-2M
• Lwów PK-01
• ZX Spectrum 48
• ZX Spectrum 128
• ZX Spectrum +2
• ZX Spectrum +2A
• ZX Spectrum +3
• ZX Spectrum +3E
• ZX Spectrum +4
• ZX Pentagon 512K (obecnie wyłączony)
• ZX Scorpio 256K (na razie wyłączony)
• ZX Pro 1024K (na razie wyłączony)
• Komodor 64
• Elektronika BK-0010
• Elektronika BK-0010.01
• Elektronika BK-0011M
• Pyldin-601
• Pyldin-601U
• Pyldin-601A
• Pyldin-601M
• Pyldin-601T
• Agat-7 (obecnie analog Agat-9)
• Agat-9
• Wizja Koleko
• Elegant

Wymagania systemowe

Do uruchomienia programu zaleca się:
Procesor: Pentium II 233 MHz i wyższy.
Pamięć: 32 MB lub więcej.
Wideo: dowolny tryb wideo 16/24/32-bitowy, dowolny akcelerator wideo.
Wymagana jest także obsługa DirectDraw.
Obsługa DirectSound jest zalecana, ale nie wymagana.

Ładowanie

Uwaga: Nową wersję należy rozpakować do nowego, pustego katalogu, czyli bez starej wersji.

Oprogramowanie dla wszystkich emulowanych komputerów można znaleźć na innych stronach poświęconych emulatorom. Tutaj możesz pobrać programy i gry na niektóre komputery:

• Specjalista MX
  Pobierz archiwum WinRAR 3.0. Rozmiar 600 KB. Wszystkie programy w tym archiwum pochodzą ze strony internetowej Aleksandra Szewcowa (http://avshsoftware.by.ru/). Pobierz WinRAR 3.20 z archiwum. Rozmiar 363 KB. Wszystkie obrazy dyskietek w tym archiwum pochodzą ze strony internetowej Aleksandra Szewcowa (http://avshsoftware.by.ru/).
• Wektor-06TS
  Pobierz archiwum WinRAR 3.0. Rozmiar 2,6MB. Wszystkie programy w tym archiwum pochodzą ze strony internetowej Aleksandra Tymoszenki (http://www.vector06c.narod.ru/). Pobierz WinRAR 3.20 z archiwum. Rozmiar 2,8 MB. Wszystkie obrazy dyskietek w tym archiwum pochodzą ze strony internetowej Aleksandra Tymoszenki (http://www.vector06c.narod.ru/).
• Orion-128
  Pobierz WinRAR 3.20 z archiwum. Rozmiar 1,9 MB. Wszystkie programy znajdujące się w tym archiwum zostały przesłane przez Andreya Markelova (http://www.markelov.net/, http://www.rus-emulators.ru/).
• BK-0010 i BK-0011
  Można zapisać się do newslettera poświęconego komputerom serii BC. Aby to zrobić, najpierw wyślij e-mail na adres [e-mail chroniony]. Temat i treść tego listu może być dowolna. Następnie otrzymasz potwierdzenie. Następnie zgodnie z instrukcją wyślij kolejny list. To wszystko, subskrybujesz!

Słowa kluczowe

emulator komputera, komputer domowy, komputery domowe, emulator komputera domowego, emulator komputera domowego, komputery domowe, komputer domowy.