microgeek.eu

Skoro mamy już uwolniony ten system do własnych zastosowań, to może warto byśmy stworzyli swoją własną jego kopię. Opis będzie dotyczył CP/M v 2.2 i zapewne będzie on chaotyczny i miejscami pobieżny, ale powinien dać nam ogólną wiedzę jak takie coś przygotować do własnego sprzętu. Fundamentalnym wymaganiem jest mapowanie pamięci RAM od samego jego początku, gdzie zwykle rezyduje pamięć ROM, więc wymagane są sztuczki wyłączające ROM i w jej miejsce umieszczenie RAM w trackie inicjacji systemu operacyjnego. Sam system składa się z dwóch elementów: BDOS i uzależnionego od sprzętu CBIOS. BDOS z wbudowanym interpreterem poleceń CCP jest ogólnie dostępny dzięki rekonstrukcji jakiej dokonał Clark A. Calkins w poprzednim stuleciu (jak to brzmi! ), a szkielet CBIOS który tu udostępniam będziemy musieli dostosować do posiadanych urządzeń. Dla uproszczenia przyjąłem adresację standardu RC2014 i jako pamięć masową interface CF (wyłącznik ROM - 0x38, moduł CF - 0x10). Do napisania pozostanie nam tylko inicjacja i obsługa portu szeregowego jako terminala. Wybór konkretnego układu jest uwarunkowany od własnych preferencji i zasobów w szufladzie . Sam CBIOS to zbiór 16 funkcji, które w większości już są napisane.

Nasza inicjatywa jest tylko skupiona wokół funkcji 0 - boot, gdzie powinniśmy umieścić kod inicjujący nasz port szeregowy, oraz funkcje 2 - Console status (gotowy/nie), 3 - Console input (sprawdzenie czy coś zostało przyjęte) i 4 - Console output (wysyłanie danych). Pozostałe funkcje są już gotowe! Obsługa przerwań portu szeregowego nie jest wymagana, system i tak korzysta z metody odpytywania i jedyne do czego może się przydać aktywny system przerwań jest sterowanie kontrolą przepływu RTS/CTS dla wyższych prędkości transmisji. Jak widać nie jest to dużo pracy, by móc samodzielnie przygotować ten system do własnego sprzętu. Nie taki diabeł straszny jak go malują

Oj tak, wsparcie się przyda. Ja zamierzam połączyć tą koncepcję z nowym wyposażeniem sprzętowym pod tytułem Motorola 68k. To są dalekosiężne plany i wiem, że czeka mnie sporo pracy. Na początek idzie MC68008, procek 16/32-bitowy z 8-bitową szyną danych. Mam już trochę detali do tego systemu, ale trzeba będzie trochę doprojektować nowego wyposażenia.

Jest nawet literatura.

No, w kwestii CP/M-68k to wiele nie jestem w stanie pomóc, to już jest inna filozofia systemu, ale sprawdzając pobieżnie to zapewne jest to do ogarnięcia, tylko ilość funkcji BIOS rośnie do 21. Podejrzewam że warto się przyjrzeć jak to zostało zrobione w 68k-MBC, tam może być wiele wskazówek.

@Zegar - Tak! Literatura. Obowiązkową pozycją jest CPM_2.2_Alteration_Guide_1979, tam jest dość dobrze wyjaśnione jak budować system i czym jest ta zawiła procedura "deblocking".

tapy pisze:Podejrzewam że warto się przyjrzeć jak to zostało zrobione w 68k-MBC, tam może być wiele wskazówek.

Już się temu przyjrzałem i nie wszystko mi odpowiada. Zostaje realizacja własnej koncepcji.

Takie są uroki grzebania w 40 letnich systemach operacyjnych. To nie będzie tak ładnie wyglądać jak w przypadku CP/M 2.2, który się doczekał dziesiątków implementacji i można wybierać co ładniejsze kawałki kodu. Tu się ma tylko skrawki które nie wylądowały w koszu, koncepcje i należy się cieszyć że można popatrzeć na coś co działa, nie ważne jak. Moja przygoda z MP/M i CP/Net to pół roku szukania czegokolwiek co sprawiało wrażenie, że opiera się na specyfikacji i niesie jakąś wartościową treść. To dokumentacja z plików txt lub pdf z czcionką maszyny do pisania, rysunki to były perełki ręcznej roboty

tapy pisze:Takie są uroki grzebania w 40 letnich systemach operacyjnych

Przynajmniej zabawa jest fajna i jest trochę "rozkoszy łamania głowy" (co z kolei nie pozwala rdzewieć dla mózgu).
Generalnie nie boję się roboty. Potrzebny jest dostęp do porządnej biblioteki. Książek z CP/M jest też tak trochę, ale chyba nie mam farta, bo to co ściągnąłem to większość jest po francusku, niemiecku lub włosku

Nie wiem jakie są tu limity załączników, więc interesujący Cię odnośnik z kompletem po angielsku: https://www.ndr-nkc.de/compo/68000/cpm68k6.htm

tapy pisze: Moja przygoda z MP/M i CP/Net to pół roku szukania czegokolwiek co sprawiało wrażenie, że opiera się na specyfikacji i niesie jakąś wartościową treść.

A to znalazłeś?
http://www.cpm.z80.de/source.html
http://www.cpm.z80.de

tapy pisze:Nie wiem jakie są tu limity załączników, więc interesujący Cię odnośnik z kompletem po angielsku: https://www.ndr-nkc.de/compo/68000/cpm68k6.htm

Oooo, tego nie znałem, dzięki.

Tak, był jednym z wielu. Prawdziwą kopalnią wiedzy (softu) okazał się ten plik DRIPAK.ZIP oraz źródła projektów P112 i YAZ180 (tu ciekawe wykorzystanie kanałów DMA do transmisji), oraz wiele innych które już nawet nie wiem skąd pobrałem. Problemem okazały się nie kody źródłowe, a pliki binarne które często były wymieszane z wersji 2.0 i 2.1 i tu trzeba było je po kolei porównywać. Jądro MP/M to wiele modułów, a XIOS (odpowiednik CBIOS z CP/M) był jednym z nich. Źródeł było wiele, więc budowa samego systemu nie była szczególnie uciążliwa, prawdziwe schody to był CP/Net. Tu posiłkowałem się przykładami zawartymi w jedynym dokumencie o CP/NET jaki istnieje, mozolnie odtworzonym z plików txt przez Douglasa Millera i pomocy w odszukaniu do niego noty aplikacyjnej przez nieżyjącego już Emmanuela Roche (był prawdziwą skarbnicą dokumentacji) bo musiałem zmodyfikować plik binarny modułu serwera zgodnie z zaleceniami Digital Research. Aplikacja sieciowa dla CP/M i sam CP/NOS to już była bułka z masłem.

tapy pisze:Skoro mamy już uwolniony ten system do własnych zastosowań, to może warto byśmy stworzyli swoją własną jego kopię...

Ciekawie się zapowiada, czymam kcuki i czekam na więcej

phill2k pisze:Ciekawie się zapowiada, czymam kcuki i czekam na więcej

Cóż tu więcej opisać, jest działający szkielet w którym brakuje tylko inicjacji oraz obsługi portu szeregowego. Możemy się skupić na jakimś konkretnym układzie (Z80SIO, ACIA, 16C550, DUART,...), to już jest zależne od posiadanego scalaka. Zaznaczam też, że w tym kodzie jest spore pole do popisu w kwestii optymalizacji, przykładowo procedura 'sectran' służąca do translacji sektorów w archaicznych stacjach dyskietek, które nie nadążały za procesorem 2,5MHz . W przedstawionym źródle wygląda tak:

co można zastąpić następującą sekwencją oszczędzającą parę taktów procesora, bo tu jest użyta szybka pamięć CF i nie ma potrzeby dokonywać takiej operacji, lecz system operacyjny jej obecności wymaga:

Miejsc w których można dokonać optymalizacji jest tam wiele, źródło to zlepek istniejących kodów gwarantujących jego działanie, bez szczególnego nacisku na jego wydajność.
Jeśli jest taka potrzeba, to możemy się zająć konkretnym rozwiązaniem sprzętowym, w miarę dostępności czasu jakim dysponuję, bo obecnie mam tak długą listę TODO, że nie wiem czy nie postulować o wydłużenie doby , ale na to zawsze będzie można uszczknąć parę chwil, by ten system cieszył i naszych użytkowników.

Sezon ogórkowy, więc można dalej ciągnąć opowieści z mchu i paproci o optymalizacji (a co to jest?! ).
W każdym systemie operacyjnym krytycznym procesem jest obsługa dysków oraz jego wydajność. W CP/M niskopoziomową obsługą zajmuje się CBIOS systemu który komunikuje się z jądrem BDOS poprzez 128 bajtowy bufor. Dla procesorów Z80 oczywistym i eleganckim wyborem jest użycie instrukcji LDIR, dzięki której przygotowane adresy źródła i celu, oraz ilości przesłanych danych mogą z powodzeniem zastąpić brak układu DMA w typowych konstrukcjach komputerów zbudowanych na tym procesorze. Warto uważnie się jednak przyjrzeć tej instrukcji, przesłanie jednego bajtu zużywa 21 taktów zegara i 16 dla ostatniego. Przesłanie owych 128 bajtów pomiędzy buforem dysku, a systemu operacyjnego zajmuje w tym przypadku 2683 cykle zegara. Da się to zrobić szybciej wykorzystując również specyficzną dla Z80 instrukcję LDI, która jest zawsze wykonywana w 16 taktów, ale ma tą wadę, że przesyła tylko jeden bajt.

Przedstawiona procedura jest zamienna z instrukcją LDIR i w jednym przebiegu przesyła 4 bajty zużywając 74 takty zegara, więc przesłanie bloku 128 bajtów zużyje 2368 taktów zegara - jest to prawie 12% zysk czasowy, choć kod binarny będzie o 9 bajtów dłuższy.

Kolejną wartą uwagi kwestią jest to, że instrukcje JR cc są szybsze od instrukcji JP cc tylko wtedy, gdy w pętli częściej "skaczą do przodu", gdyby dla przedstawionego przykładu istniała instrukcja JR PE była by w nim nieefektywna.