Odpalanie gier na CP/M

[Atlantis]

Powoli uruchamiam obecnie CP/M na komputerku własnej konstrukcji. A tak właściwie na kilku komputerkach, bo na przestrzeni kilku ostatnich lat powstało kilka wersji hardware'u:

• Konstrukcja oparta o polski mikroprocesor MCY7880, sklecona na płytce prototypowej, z połączeniami wykonanymi kynarem. Ta wersja jako jedyna posiada układ graficzny (TMS9918).
• Nowsza wersja powyższego, już zbudowana na dwóch wytrawianych płytkach. Na razie nie ma jeszcze trzeciej płytki, która ma zawierać układ graficzny.
• Nieco uproszczona wersja na 8085.

Wszystkie wersje posiadają podobna architekturę, ale jest też kilka drobnych różnic. Identyczna jest organizacja pamięci, ale pojawiają się różnice w mapowaniu urządzeń w przestrzeni I/O. Z tego powodu niektóre komponenty oprogramowania trzeba budować osobno dla każdej rewizji.

Eksperymenty zaczynałem od TinyBasica, jednak potem przerzuciłem się na CP/M. Każdy komputerek posiada gniazdo karty CF, z którego zczytywany jest obraz systemu, zapisywany do pamięci RAM.
W chwili obecnej jestem na etapie pisania własnego BIOS-a. Sporą część udało mi się już napisać - działa konsola. jestem w stanie czytać zawartość partycji systemowej i uruchamiać (niektóre) programy. Nie działa jeszcze m.in. obsługa przełączania się na inne "dyski" (a właściwie partycje na tej samej karcie) oraz zapisywania danych na dysku.

Zaczynając pracę nad projektem przyjąłem następujące założenia co do organizacji pamięci:

• 0x0000 - 0x7FFF - główna pamięć RAM (32kB)
• 0x8000 - 0xBFFF - dodatkowa pamięć RAM, dostępna w postaci dwóch przełączanych banków po 16kB
• 0xC000 - 0xFFFF - pamięć EPROM

Takie rozwiązanie potem stosowałem w kolejnych wersjach komputerka. Nie mam tu żadnego ROM shadowingu, więc EPROM jest cały czas dostępny w przestrzeni adresowej. Z jednej strony jest to ułatwieniem (mogę wołać trzymane w nim funkcje pomocnicze z poziomu BIOS-a CP/M-u) z drugiej strony ogranicza ilość pamięci dostępnej po zbootwaniu systemu. Tak naprawdę cały system operacyjny i/lub używany program i stos muszę zmieścić w pierwzych 32kB. Pamięć podzieloną na banki wykorzystuję w tej chwili na bufory pomocnicze/cache wykorzystywany przy operacjach dyskowych.

Wyszedłem z założenia, że kiedy wychodził CP/M 2.2, pamięć była droga i sporo komputerów miało nawet mniejszy RAM.
Teraz jednak zabrałem się za próby uruchamiania gier i widzę, że sporo z nich nie chce działać.

• Collosal Cave Adventure przez chwile się ładuje, ale po chwili wywala komunikat "BAD LOAD".
• Zork1 wpada w jakąś pętlę podczas próby załadowania - dioda aktywności karty CF pulsuje, ale nic się nie dzieje.
• Sargon przy próbie załadowania zawiesza komputer - niby dioda przestaje migać, ale nic się nie dzieje.

I teraz zastanawiam się, czy problemy wynikają ze zbyt małej pamięci, czy tej przyczyna leży gdzie indziej, np. w niepełnej implementacji BIOS-u.
Czy ktoś mógłby polecić jakąś grę (najlepiej tekstówkę), która będzie działała przy takiej ilości RAM-u, a jednocześnie nie korzysta z callbacka do zapisywania danych na dysku?

[tapy]

Pod "czysty" CP/M powstało niewiele gier, a gdy się rozpowszechnił standard VT100/ANSI to królował już Z80, więc wybór masz więcej niż skromy. Może spróbuj coś w BASIC? 

[Atlantis]

Pod "czysty" CP/M powstało niewiele gier, a gdy się rozpowszechnił standard VT100/ANSI to królował już Z80, więc wybór masz więcej niż skromy. Może spróbuj coś w BASIC?

Hmm... Miałem ochotę pograć w jakieś klasyczne tekstówki, ale w takim razie rozszerzę kategorię poszukiwanego softu także do innych programów. Chciałem po prostu na czymś przetestować działanie systemu.
Wymagania na chwilę obecną są następujące:

• Kompatybilność z 8080/8085 (a więc bez korzystania z instrukcji Z80).
• Relatywnie małe wymagania co do pamięci - w tej chwili system jest upchnięty w 32kB.
• Brak odwołań do procedury BIOS_WRITE, bo ta nie jest jeszcze zaimplementowana. To znaczy na chwilę obecna każda próba odczytu zwróci błąd.

Na chwilę obecną sytuacja wygląda w ten sposób, że sam system działa. Jestem w stanie wywoływać polecenie zaszyte w samym CCP (jak DIR lub TYPE). Działają także programy dostarczone z systemem (DDT, DUMP, PIP, STAT). Inne wywalają się z błędem, najwyraźniej z powodu braku możliwości sapisu (ED, ASM).
Spora część zewnętrznego oprogramowania jednak powoduje inne błędy. Często dostaję "BAD LOAD" (Collosal Cave Adventure, MBASIC), innym razem system się zawiesza (czyta w pętli jakieś dane z karty, nie robi nic albo wywala na terminal pozbawioną znaczenia sekwencję znaków).
Chciałem mieć na czym zdebugować ten problem. Możliwe, że część z tego oprogramowania to binarki dla Z80, więc system głupieje. Możliwe też, że mam za mało RAM-u, albo mój BIOS nie jest dostatecznie dopracowany. Przy czym jeszcze niezaimplementowane procedury zwracają w tej chwili kod błędu, więc nie powinienem mieć niezdefiniowanych zachowań - oprogramowanie powinno po prostu zgłaszać odpowiedni problem.

Jaki interpreter basica jest potrzebny do odpalenia tego "Star Treka"?

[tapy]

Dla procesorów 8080/85 jest "jedyny słuszny" Basic  czyli Microsoft Basic (MBASIC.COM) i pod nim uruchomisz tą gierkę.

[Atlantis]

Dla procesorów 8080/85 jest "jedyny słuszny" Basic  czyli Microsoft Basic (MBASIC.COM) i pod nim uruchomisz tą gierkę.

Hmm... Jestem tak na 90% pewien, że plik MBASIC.COM właśnie z tej strony próbowałem odpalać na swoich komputerkach i za każdym razem kończyło się to komunikatem "BAD LOAD". Sądząc po rozmiarze pliku nie wydaje mi się, żeby to była kwestia braku pamięci. Kojarzysz co może powodować takie zachowanie CP/M?
Raczej nie sądzę, żeby były za to odpowiedzialne jakieś problemy z odczytem z karty, bo:

• MBR jest prawidłowo odczytywany za każdym razem
• System jest prawidłowo ładowany za każdym razem (pierwsze 63 sektory z pierwszej partycji). Żeby być pewnym zaimplementowałem sprawdzanie CRC - nigdy nie miałem problemów.
• Prawidłowo działa polecenie "DIR", a więc również struktura DIR musi być prawidłowo odczytywana.
• Polecenie type też poprawnie zwraca zawartość plików z dysku. Nie więc powodu, żeby pliki. COM miały się niepoprawnie czytać.

[Atlantis]

Ok, wykonałem test za pomocą programu SURVEY.COM.

Kod: [Zaznacz]

                *** System Survey (June 82) ***

Drive A: 318K bytes in 36 files with 7810K bytes remaining

Memory map:
0       8       16      24      32      40      48      56      64
|       |       |       |       |       |       |       |       |
 TTTTTTTTTTTTTTTTTTTTTTTTTCCCBBBBBBBBBBBBBBBBBBBBRRRRR          R
T=TPA   C=CPM   B=BIOS or unassigned    R=ROM or bad
BIOS at 7203    iobyte 00       drive 00        BDOS at 6406

49151 Bytes RAM         5152 Bytes ROM          25606 Bytes in TPA
11232 Bytes Empty       54303 Total Active Bytes

Active I/O ports:
40 41 42 43 44 45 46 47 48 4ÿ 

Jak widać program sie odpala, w pewnym momencie zawiesza się na "Active I/O ports". Niemniej udaje mu się sprawdzić pamięć. Widać, że mam 25kB w TPA. To całkiem sporo miejsca na programy, a do tego w grę wchodzi jeszcze możliwość nadpisania CCP. Cała górna przestrzeń RAM-u do 48k jest rozpoznawana jako BIOS, jednak w rzeczywistości zajmuje on jedynie kawałek poniżej 32kB. W teorii mógłbym przenieść BIOS wyżej i zrobić z tego system 48k, wtedy jednak straciłbym możliwość przełączania banków, a tego nie chcę robić. Płytka jest zaprojektowana w ten sposób, że jeden z banków będzie docelowo wykorzystywany jako pamięć video, z automatycznym przełączaniem w przypadku dostępu przez DMA.
Jednak za mało RAM-u, czy może szukać przyczyny gdzie indziej?
Heh... Chyba faktycznie w kolejnej rewizji będe musiał zrobić ROM shadowing, żeby mieć dostęp do pełnych 64kB RAM-u. Nie wiem czy kolejna rewizja nie powinna być już na Z80, ale z drugiej strony mam słabość do 8085.

Jeszcze jedno pytanie. Czy istnieje możliwość, żeby program ładowany za pośrednictwem CP/M nadpisał nie tylko CCP, ale także BDOS i BIOS? Doskonale zdaje sobie sprawę z tego, że wtedy nie będzie mógł korzystać z wywołań systemowych. Jednak gdyby taka możliwość istniała, to mógłbym faktycznie przesunąć BIOS w okolice 48k i rozszerzyć TPA uznając, że taki jest rozmiar RAM-u w trybie CP/M. Z przełączania banków mógłbym korzystać nadal w programach, które nie korzystałyby z systemowych procedur.

[dely]

Widać, że mam 25kB w TPA. To całkiem sporo miejsca na programy

Polaryzowałbym, że to całkiem sporo. Na podstawowe programy to może tak, ale obawiam się, że za dużo nie poszalejesz.

[Atlantis]

Polaryzowałbym, że to całkiem sporo. Na podstawowe programy to może tak, ale obawiam się, że za dużo nie poszalejesz.

Chyba masz rację. Zrobiłem w ramach eksperymentu i przeniosłem system o 16kB w górę, wchodząc w zakres pamięci, która w domyśle miała składać się z dwóch banków po 16kB. Po takiej zmianie byłem w stanie odpalić MBASIC. Collosal Cave Adventure wywalił się, ale już na innym etapie - już nie "BAD LOAD" ale informacja o niemożliwości załadowania danych z osobnego pliku. Pewnie ciągle mało pamięci, może z Zorkiem lepiej pójdzie.
Oczywiście teraz proste przełączanie banków odpada, bo w tej części pamięci siedzi stos. Możliwe jednak, że ciągle będę mógł użyć drugiego banku jako pamięci wideo (obsługiwanej za pośrednictwem DMA) o ile tylko podczas korzystania z niej nie będę korzystał ze stosu (a więc także instrukcji CALL i przerwań).

[tapy]

Nie chcę ingerować w Twoją wizję architektury własnego komputera, ale zastanawia mnie dlaczego przyjąłeś takie założenia, które mocno ograniczają jego możliwości w roli maszyny CP/M. Generalnie 64kb pamięci to niewiele, a tu system operacyjny też swoje pochłania. Owszem, bardzo atrakcyjna jest wizja wydzielonego, bankowego obszaru na pamięć obrazu z założeniem jej zamiany i uaktualnieniem zawartości przy pomocy DMA, ale wysiłki większości twórców skupiają się raczej nad maksymalizacją dostępnego TPA. Może warto skupić się możliwościami jakie daje przewidywany w systemie układ DMA, bo przy odpowiednio skonstruowanym MMU (przełączniku banków pamięci), wydzielenie osobnego obszaru adresowanej przez CPU pamięci na bufor ekranu może nie być konieczny. Również uważam, że 8085 ma ogromny potencjał który został przez jego twórców pogrzebany (choć tu podejrzewam, że w tym procederze najsilniej maczał palce ich marketing). Tu warto zainteresować się nieujawnionymi instrukcjami zawartymi w tym procesorze, bo ich użycie w wielu kwestiach pozwala na uzyskanie wyższej wydajności niż na Z80.

[Atlantis]

Nie chcę ingerować w Twoją wizję architektury własnego komputera, ale zastanawia mnie dlaczego przyjąłeś takie założenia, które mocno ograniczają jego możliwości w roli maszyny CP/M.

Generalnie początkowo moją ambicją nie było uruchamianie na tym CP/M-a. Zacząłem po prostu eksperymenty z polskim mikroprocesorem MCY7880 (klon 8080), montując podstawowy system na płytce prototypowej i dodając po kolei do niego rozmaite peryferia. W jakimś projekcie podpatrzyłem rozwiązanie polegające na tymczasowym ustawianiu linii A14 i A15, żeby po resecie komputer startował z EPROM-u. Ponieważ w przestrzeni adresowej nie mieścił mi się pełen układ 62256, zastosowałem przełączanie banków. Na tym etapie moją ambicją było stworzenie komputera do odpalania jakiegoś BASIC-a.
W międzyczasie powstała nowsza wersja, złożona na płytce, która docelowo miała działać z bardziej pasującym do epoki kontrolerem wideo (8275). Tutaj też podpatrzyłem w jakimś innym projekcie rozwiazanie polegające na autoamtycznym ustawianiu banku na ten, w którym mieści się pamięć video, gdy sterownik ekranu zyskiwał dostęp do niej za pośrednictwem DMA.
Pomysł na odpalenie na tym CP/M pojawił się dopiero w międzyczasie. Zacząłem tworzyć własny BIOS i jak widać na tym etapie pojawił się problem z ograniczeniami hardware'u. W tej wersji hardware'u ani DMA, ani sterownik ekranu nie zostały jeszcze zaimplementowane (docelowo będą na osobnych płytkach). Po prostu taka możliwość została przewidziana i mamy odpowiedni sygnał doprowadzony do układu przełączania banków na płytce CPU.
Na razie z tego co widzę system działa całkiem nieźle w trybie 48k. Straciłem co prawda swobodny dostęp do drugiego banku 16kB, ale może jeszcze nie do końca. Muszę jeszcze dokładniej przeanalizować sytuację, ale możliwe, że nadal będę mógł używać go w roli pamięci wideo dostępnej przez DMA. Trzeba będzie tylko zachować ostrożność podczas aktualizowania jej zawartości, żeby nie dochodziło do konfliktów ze stosem.
Gdybym zaczynał budować ten projekt dzisiaj, od razu z myślą o CP/M, to najprawdopodobniej zastosowałbym jakiś system ROM shadowingu, żeby po zbootowaniu systemu cała przestrzeń adresowa składała się tylko i wyłącznie z RAM-u. Możliwe, że w wolnej chwili sklecę taką wersję płytki CPU i odpowiednio modyfikując bootloader i BIOS.
Jeśli chodzi o bardziej zaawansowane systemy, z większą ilością RAM-u to po głowie chodzi mu zbudowanie czegoś na 68k. Na początek pewnie MC68008 i CP/M w wersji pod te procesory, potem jakiś lepszy procesor i jakiś Unix z epoki.

[Atlantis]

Tak swoją drogą, mam jeszcze jedno pytanie.
Jaką szerokość ekranu (w znakach) standardowo obsługiwał CP/M i pisane pod niego programy?
W przypadku wersji sprzętu wyposażonej w kontroler ekranu, korzystam z TMS9918 skonfigurowany w Mode 0 (tekst 40 kolumn x 24 wiersze). Pomimo tego obserwuję jednak zawijanie wierszy w programach wyrzucających na ekran więcej tekstu (Zork, Survey, wynik polecenia DIR też nie wygląda zbyt ładnie).
Problem nie występuje w przypadku komputerków obsługiwanych przez port szeregowy, bo emulator terminala daje im pod dostatkiem miejsca
Czyżby CP/M był tworzony z myślą o pracy z terminalami pracującymi w trybie 80 kolumn i/lub terminalami dalekopisowymi?

[damik]

Optymalna liczba kolumn dla CP/M to 80 najlepiej 24-25 wierszy.
Typowy terminal tak właśnie wyświetla i większość oprogramowania jest dostosowana do takich parametrów.
Kody sterujące często można konfigurować w programach dla różnych rodzajów terminali jednak najczęściej chyba używa się VT100.

[dely]

Standardem jest 80 kolumn. Najpopularniejsze programy niemal wymagają terminala z taką liczbą znaków w linii i są nieużywalne jeśli jest mniej. W niektórych przed uruchomieniem wyświetlana jest prośba o podanie typu terminala, z którym będziemy pracować. Dodatkowo trzeba wziąć pod uwagę kody sterujące terminala, takie jak np. czyszczenie ekranu, włączenie rewersu znaków itp., ponieważ pomimo odpowiedniej liczby kolumn można widzieć krzaki i rozpadające się linie.

[Atlantis]

Standardem jest 80 kolumn. Najpopularniejsze programy niemal wymagają terminala z taką liczbą znaków w linii i są nieużywalne jeśli jest mniej.

Czyli jednak będę musiał zrezygnować z pomysłu stosowania TMS9918 w komputerkach przeznaczonych do odpalania CP/M.
Użycie jakiego układu graficznego polecacie w tego typu konstrukcji? Standardowy 8275 będzie ok? A może jest coś prostszego w implementacji?

Dodatkowo trzeba wziąć pod uwagę kody sterujące terminala, takie jak np. czyszczenie ekranu, włączenie rewersu znaków itp., ponieważ pomimo odpowiedniej liczby kolumn można widzieć krzaki i rozpadające się linie.

Kodów sterujących nawet jeszcze nie zaimplementowałem. W chwili obecnej obsługa TMS9918 jest mocno uproszczona. Mam po prostu wyrzucanie kolejnych znaków na ekran, obsługę przejścia do nowej linii i powrotu do początku wiersza. Działa też przewijanie ekranu po jego zapełnienieniu. Przy czym na problemy związane z brakiem obsługi kodów jeszcze nie trafiłem - widzę głównie rozjeżdżanie się tekstu, które wynika ze zbyt dużej liczby znaków na linię. Nie wiem czy implementowanie kodów sterujących w przypadku tego układu w ogóle ma sens, skoro nie będzie on w stanie prawidłowo emulować terminala CP/M.

[tapy]

Czyżby CP/M był tworzony z myślą o pracy z terminalami pracującymi w trybie 80 kolumn i/lub terminalami dalekopisowymi?

Dokładnie tak.

Możesz sobie zmodyfikować BDOS CP/M 2.2 tak aby obsługiwał 40 kolumn, ale to nie wpłynie na aplikacje które napisane zostały do standardowej ich liczby. Należy w procedurze "direct3" zmienić instrukcję:
and   03h      ;at end of line?
na:
and   01h      ;at end of line? Was 03h but VFD is only 40 characters wide.