Autor Wątek: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3  (Przeczytany 5924 razy)

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Hello wiara!

Starzy bywalcy forum wiedzą, że raz na ruski rok dopada mnie bezsenność i piszę wtedy na forum jakiegoś tasiemca ;)
Tym razem może nie będzie to tasiemiec, ale szkic wstępu do zarysu studium wykonalności pewnego mariażu sprzętowo-programowego, który już po części zdradziłem w tytule wątku. Ale po kolei :)
Nie jest tajemnicą, że jestem wielkim miłośnikiem gratów z logo Timexa. A w szczególności - TC2048 oraz FDD3000. Zestaw ten pozwalał mi niegdyś odkrywać świat systemu CP/M (niestety tylko w wersji 2.2, co ma związek z ograniczoną pojemnością pamięci stacji FDD3000 - 64KB). System ten był kiedyś uważany za profesjonalny, w zasadzie pełnił rolę analogiczną do MS-DOS, ale dla komputerów 8-bitowych z procesorami i8080/Z80. Kto kojarzy film "Gry Wojenne", ten wie, o co chodzi.
Pod CP/M istnieje olbrzymia biblioteka poważnego oprogramowania. Edytory/procesory tekstu, arkusze kalkulacyjne, bazy danych, oprogramowanie komunikacyjne, języki programowania, programy rachunkowe, kadrowo-płacowe, statystyczne... raczej nie do wykorzystania w dzisiejszych czasach, niemniej jest to olbrzymia skarbnica softu, do której można się dokopać online. FDD3000 z komputerem TC2048 (jak również TC2068, UK2086 - generalnie chodzi o tryb 512x192) to minimum potrzebne do  miarę komfortowej pracy z CP/M, Amstradowcy mają nieco łatwiej i lepiej, no ale nie o Amstrady mi chodzi.
Gdy pojawiły się interfejsy divIDE i divMMC, żałowałem, że nie współpracują one z FDD3000. Nie ma takiej możliwości, by oba interfejsy działały ze sobą, bo wykorzystują ten sam mechanizm pułapkowania błędów do obsługi dodatkowych poleceń. Są też inne problemy natury technicznej - tych dwóch urządzeń nie da się prosto pożenić i koniec. Najbliższy ideałowi staje się więc model 128K +3, mający napęd dyskietek oraz możliwość instalacji interfejsu kart CF. Wymaga to oczywiście wymiany kostek ROM na wersję +3E. Ale jest też możliwość zastosowania interfejsu divMMC (z nowszą wersją drivera podobno również divIDE, czy może na odwrót). Pewien Hiszpan solidnie do tego przysiadł i naklepał brakujące kawałki kodu. Całość jest opisana na forum, niestety w języku Inkwizycji:

https://www.va-de-retro.com/foros/viewtopic.php?f=62&t=5605

Jednak procedura przygotowania CP/M dla wersji dyskowej (tzn. dla karty pamięci) jest dość skomplikowana i jakoś nie przypadło mi to do gustu. I zacząłem się zastanawiać, czy to w ogóle ma sens...
CP/M, jak każdy inny "prawdziwy" system operacyjny, to generalnie dwie integralne rzeczy - środowisko (runtime) do odpalania aplikacji oraz zestaw narzędzi do posługiwania się środowiskiem. Tymi narzędziami są m.in. wszystkie komendy służące obsłudze plików, folderów, urządzeń wejścia/wyjścia, parametryzacji środowiska itp. I właśnie te komendy to najbardziej kulawa część systemu CP/M - jest to spuścizna po jakichś jeszcze starszych systemach, pamiętających karty i taśmy perforowane. MS-DOS wprowadził de facto nową jakość, zmieniając składnię i nazwy poleceń. Podobnie uczynił światek unix/linux. A właśnie esxDOS ma tę część znacznie lepszą, niż CP/M - więc po co tak naprawdę używać czegoś, co jest gorsze? Może wystarczy umożliwić uruchamianie aplikacji CP/M, czyli stworzyć odpowiedni runtime, a powłokę (shell) zostawić taki, jakiego używa esxDOS? Ten runtime to oczywiście kod BDOS, który by przekierowywał wszystkie wywołania z aplikacji CP/M w odpowiednie miejsca esxDOS-u. Plus odpowiednie przygotowanie konfiguracji pamięci, bo CP/M wymaga pamięci RAM od samego "dołu" i najlepiej do samej "góry". Tak więc dysponując odpowiednim sprzętem - modelem 128K +2A/B lub +3 - oraz rzeczonym interfejsem divIDE lub divMMC, teoretycznie jest możliwe stworzenie loadera programów dla CP/M-u, być może nawet w wersji 3, skoro jest dostępny mechanizm stronicowania pamięci RAM.
I po co to wszystko, tak naprawdę?
Bo chciałbym np. móc załadować Turo Pascala 3.0 Borlanda, albo korzystać z innych kompilatorów, bez martwienia się, gdzie co leży w pamięci i czy jej wystarczy. Bo chciałbym używać czegoś klasy WordStara, co nie zacznie kwiczeć, że tekst jest za długi, by się zmieścić w pamięci.
No i kluczowa jest możliwość wykorzystania kart pamięci zamiast dyskietek - z eleganckim obejściem ograniczeń systemu CP/M, czyli maksymalnej liczby plików, oraz 8MB na dysk/partycję i braku folderów w przypadku CP/M 2.2. Mariaż z esxDOS pozwalałby korzystać z FAT, z jego folderami i setkami plików w każdym z nich.
Podobno wystarczy też Dandanator. Co prawda jest on urządzeniem tylko do odczytu (doczytałem tutaj, że istnieje wersja z reprogramowaniem EEPROM), ale za to nie koliduje z interfejsami stacji dysków.
Jednak największym minusem modeli +2A/B/+3 jest brak trybu hires (512x192). Z drugiej strony, divIDE (więc pewnie i divMMC) potrafi pracować w trybie all-RAM - może tędy droga? Może wystarczy Timex z interfejsem kart pamięci?
Rozwiązanie idealne jest gdzieś w zasięgu możliwości technicznych (i ekonomicznych), ale... jeszcze go nie widać, moim zdaniem.

No i wyszło tasiemcowo :)
« Ostatnia zmiana: 2019.07.04, 02:23:16 wysłana przez trojacek »

steev

  • *****
  • Wiadomości: 1362
  • Miejsce pobytu:
    inode 42
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #1 dnia: 2019.07.04, 09:33:28 »
Gdy pojawiły się interfejsy divIDE i divMMC, żałowałem, że nie współpracują one z FDD3000. Nie ma takiej możliwości, by oba interfejsy działały ze sobą, bo wykorzystują ten sam mechanizm pułapkowania błędów do obsługi dodatkowych poleceń. Są też inne problemy natury technicznej - tych dwóch urządzeń nie da się prosto pożenić i koniec.
Ummm.
Interface FDD nie robi nic innego, tylko gada ze stacją po porcie $ef.
Są jakieś przeciwwskazania, żeby wydawać komendy stacji poprzez polecenia exDOSu?
Sprzętowo wystarczy dowolny wolny 8 bitowy port (lub dwa. tak, wiem że nie wszystkie bity są wykorzystane)
Protokół jest rąbnięty, ale dość prosty.
Listy poleceń wewnętrznych TOS ktoś kiedyś zamieszczał w Bajtku, niech sobie przypomnę...

Rozwiązanie idealne jest gdzieś w zasięgu możliwości technicznych (i ekonomicznych), ale... jeszcze go nie widać, moim zdaniem.
Tak na szybko, więc raczej źle (o CP/M 3 czytałem dawno temu) to mogła by zadziałać konfiguracja :
ZX128 (można wykolegować obszar pamięci ekranu z przestrzeni adresowej), interface z ALLRAM i bios CP/M napisany praktycznie od nowa (żeby wykorzystywał ile się da ROM divMMC i być może Spectrum, opcjonalnie umieszczony w pamięci divMMC - nie trzeba będzie wtedy swapować pamięci ekranu)

Prostszy pomysł to wziąć ZX+3 (który ma CP/M 3) i spatchować BIOS tak, by korzystał z divMMC (lub samej karty via porty i/o) jako dysku (do 512M zdaje się)
Tu największym problemem będzie zapewne zdobycie źródeł BIOSu. Pewnie skończyłoby się na deasemblacji :)

No i wyszło tasiemcowo :)
TL;DR ;)
A nie lepiej nową wersję FDD3 z 1M RAM i stronicowaniem skrojonym pod CP/M?
Spec niech się zajmuje tym co robił do tej pory, czyli obsługą klawiatury i ekranu :)
Machines should work. People should think.

rzookol

  • ***
  • Wiadomości: 214
  • Miejsce pobytu:
    Lublin/Stasin
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #2 dnia: 2019.07.04, 10:54:20 »
Rom 3e przy wyłączonym romie Divmmc przejmuje  kontrolę nad divmmc i pełny dos z ZX+3 jest dostępny dla dysków. http://octocom.speccy.org/workbench_en.html z tego korzysta.
+2, +3, CPC128Plus, kilka Amigi, kilkadziesiąt Maków, walające się Commodore

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #3 dnia: 2019.07.04, 11:15:31 »
Interface FDD nie robi nic innego, tylko gada ze stacją po porcie $ef.
Są jakieś przeciwwskazania, żeby wydawać komendy stacji poprzez polecenia exDOSu?
Sprzętowo wystarczy dowolny wolny 8 bitowy port (lub dwa. tak, wiem że nie wszystkie bity są wykorzystane)
Protokół jest rąbnięty, ale dość prosty.

Tak, ale... nie. Chodzi o zachowanie dotychczasowych funkcjonalności, a są one obsługiwane przez RST 8 w obu urządzeniach. Najlepiej by było, jakby ktoś napisał wspólny ROM M397+esxDOS, ale jakoś w to nie wierzę.

Cytuj
Listy poleceń wewnętrznych TOS ktoś kiedyś zamieszczał w Bajtku, niech sobie przypomnę...

Serio? :P
:D

Cytuj
Tak na szybko, więc raczej źle (o CP/M 3 czytałem dawno temu) to mogła by zadziałać konfiguracja :
ZX128 (można wykolegować obszar pamięci ekranu z przestrzeni adresowej), interface z ALLRAM i bios CP/M napisany praktycznie od nowa (żeby wykorzystywał ile się da ROM divMMC i być może Spectrum, opcjonalnie umieszczony w pamięci divMMC - nie trzeba będzie wtedy swapować pamięci ekranu)

Nie tyle BIOS, co BDOS przepisany w ten sposób, by zamiast procedur BIOS wołać procedury w ROM esxDOS.
Zachowanie zgodności na poziomie BIOS to pogodzenie się z wszystkimi ograniczeniami danej implementacji CP/M.

Cytuj
Prostszy pomysł to wziąć ZX+3 (który ma CP/M 3) i spatchować BIOS tak, by korzystał z divMMC (lub samej karty via porty i/o) jako dysku (do 512M zdaje się)
Tu największym problemem będzie zapewne zdobycie źródeł BIOSu. Pewnie skończyłoby się na deasemblacji :)

Ale ten temat rozumiem, że załatwia ROM +3e (w przypadku wewnętrznego adaptera CF) lub divXXX z driverem z hiszpańskiej strony, którą linkowałem. Tylko - jak pisałem - nie podoba mi się do końca to rozwiązanie z przyczyn praktycznych (kłopotliwe przygotowanie, specjalna partycja tylko na start CP/M itp.) i technicznych (brak hires).


Cytuj
A nie lepiej nową wersję FDD3 z 1M RAM i stronicowaniem skrojonym pod CP/M?
Spec niech się zajmuje tym co robił do tej pory, czyli obsługą klawiatury i ekranu :)

Tak, ale... nie ;) Po pierwsze - mnoży się byty, bo większość z nas ma jakiś divXXX, a tu trzeba jego odpowiednik wkładać do FDD3000. Po drugie - spiralny kabel pozostaje wąskim gardłem, czyli można zapomnieć o jakichś żwawszych zastosowaniach typu animacje z karty pamięci itp. Ale może to po prostu z definicji nie ma sensu, nie wiem, może faktycznie wypasiony FDD3000, ale znów pojawiają się problemy - karta pamięci FAT? Katalogi? Limit plików? Co to obsłuży? Jakiś port esxDOS doklejony do CP/M 3.x? Ile osób będzie zainteresowanych taką konfiguracją, dziesięć? Pięć? Dwie?...
Jakiś czas temu, w ramach ćwiczenia wiotczejącego umysłu, zacząłem badać studium wykonalności scalenia FDD3000 z klonem Spectrum w ten sposób, by oba światy korzystały z jednego procesora i jednej puli stronicowanej pamięci. O ile technicznie byłoby to dość skomplikowane, o tyle logicznie rozwiązuje większość problemów, o których wspominałem (z wyjątkiem ostatniego - tzn. liczby zainteresowanych potencjalnych użytkowników :D).
Działałoby to mniej więcej w następujący sposób:
- linia NMI sterowana byłaby albo przyciskiem (jak w divXXX), albo timerem, albo dostępem do określonych portów (np. #EF). Wszystkie możliwości maskowalne z poziomu portu konfiguracji.
- nowy port I/O trzymałby informację o bieżącym kontekście procesora (Spectrum/FDD3000/możliwe inne, nawet dla poszczególnych aplikacji).
- urządzenia we/wy miałyby oddzielne mechanizmy adresowania dla Spectrum i FDD, zrealizowane przy użyciu dwóch oddzielnych linii /IORQ1 i /IORQ2 - tak, by w obu kontekstach nie właziły sobie w paradę. Podobnie można zrobić z ROM i RAM, choć nie trzeba.
- pamięć RAM stronicowana w blokach 16KB, ile, 512KB? Może być 512. Może być użytkowana przez divXXX w razie potrzeby.
- pamięć ROM podobnie.
- wywołanie NMI włącza specjalny ROM, który zapamiętuje bieżący kontekst i ładuje docelowy (np. zapis do portu #EF przełącza na kontekst FDD3000). Trochę jak przełączanie procesów w systemach z multitaskingiem, ale... trochę więcej :)
- na potrzeby wirtualnego M397 dodajemy dwukierunkowy port, widziany od jednego końca jako #EF, a od drugiego - jako #2F, jeśli mnie pamięć nie myli.
No i jeszcze na koniec, niekoniecznie potrzebny bajer:
- CPU z programowo przełączanym CLK 3,5/7/14/... MHz.

Jak to działa? Na przykład - wydanie jakieś komendy TOS (CAT*...) spowoduje wywołanie odpowiedniego kodu w pamięci ROM wirtualnego interfejsu M397, co doprowadza do wysłania komendy TOS do portu #EF. Dane te są zatrzaskiwane w rejestrze i jednocześnie następuje przełączenie kontekstu na FDD3000. Tam pętla oczekiwania na komendę odczytuje dane z rejestru (tym razem pod adresem #2F) i wykonuje polecenie, po czym zapisuje dane wynikowe do portu, przełączenie kontekstu, odczyt danych.... i tak w kółko. W tak prostym przypadku użytkownik nie odczuwa żadnych lagów, bo komunikacja przez M397 to tak naprawdę pętle oczekiwania.

I w to wszystko wkomponowujemy divXXX, które dla każdego kontekstu ma inne adresy I/O i inny ROM - ale po żadnej stronie nie mamy wąskich gardeł, bo danych z/na kartę pamięci nie trzeba przepychać przez port #EF/#2F. Tak naprawdę komunikację przez ten port można przyspieszyć, przełączając CLK na szybszy - a timeouty i tak przecież nie grożą :). Można też przerobić ROM M397 i TOS (oraz CP/M), by zamiast tego portu używały jakiejś lokacji we współdzielonej pamięci. I to nie 4 bitów czy całego bajtu, ale nawet dużego bufora.

Łomatko... Jak człowiek nie pracuje, to nadmiar mocy obliczeniowej swojej sieci neuronowej przeznacza na jakieś nieużyteczne dziwactwa ;)

steev

  • *****
  • Wiadomości: 1362
  • Miejsce pobytu:
    inode 42
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #4 dnia: 2019.07.04, 12:02:39 »
Tak, ale... nie. Chodzi o zachowanie dotychczasowych funkcjonalności, a są one obsługiwane przez RST 8 w obu urządzeniach. Najlepiej by było, jakby ktoś napisał wspólny ROM M397+esxDOS, ale jakoś w to nie wierzę.
Ale co złego jest w używaniu load*"nazwa" dla esxDOSa i .load"nazwa" dla FDD?
Zamiast wołać ROM TI masz wszystko co trzeba w kodzie polecenia z kropką i już...

Cytuj
Nie tyle BIOS, co BDOS przepisany w ten sposób, by zamiast procedur BIOS wołać procedury w ROM esxDOS.
Zachowanie zgodności na poziomie BIOS to pogodzenie się z wszystkimi ograniczeniami danej implementacji CP/M.
A to nie tak, że cała idea przenośności i uniwersalności CP/M polegała m.in. na tym, że BDOS był stały i niezmienny, a maszyny różniły się własnie BIOSem?

Cytuj
ciach
Łomatko że zacytuję.
Primo, przypuszczam że mogą być problemy z synchronizacją komunikacji.
Do stacji nie jest przekazywany jedynie kod polecenia, tylko (w przypadku TOS) jeden lub dwa bufory - danych i polecenia - a potem odbierany jest status/wyniki.
Komunikacja to ciągłe i naprzemienne wysyłanie półbajtów i flag.
Owszem, zmiana kontekstu przy każdej operacji I/O zadziała - tak z grubsza pracuje pierwsza wersja mojego emulatora.
I niestety ta ona wersja lubi się czasem zwiesić - nie mówiąc o tym, że nie działa na niej CP/M (tam protokół komunikacji jest jednak nieco inny...)
Więc węszę problemy :)

Secundo, ja jestem prosty człowiek. Wolałbym chyba wziąć małego FPGA, wepchnąć mu w strukturę CPU, oba ROMy, 1770 i na co tam jeszcze miejsce pozwoli i przejmować się tylko dopasowaniem napięć :)
Machines should work. People should think.

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #5 dnia: 2019.07.04, 12:15:11 »
Ale co złego jest w używaniu load*"nazwa" dla esxDOSa i .load"nazwa" dla FDD?
Zamiast wołać ROM TI masz wszystko co trzeba w kodzie polecenia z kropką i już...

Utrata kompatybilności z istniejącym oprogramowaniem dla FDD3000. Dlatego wolałbym odwrotnie - komendy z gwiazdką dla FDD3000, a z kropką - dla divXXX. No ale technicznie trudniej to zrobić.

Cytuj
A to nie tak, że cała idea przenośności i uniwersalności CP/M polegała m.in. na tym, że BDOS był stały i niezmienny, a maszyny różniły się własnie BIOSem?

Generalnie tak, a w szczególności - zestaw i sposób wołania funkcji BDOS jest niezmiennikiem. Co jest w środku, nie jest tak naprawdę problemem dla aplikacji.

Cytuj
Owszem, zmiana kontekstu przy każdej operacji I/O zadziała - tak z grubsza pracuje pierwsza wersja mojego emulatora.
I niestety ta ona wersja lubi się czasem zwiesić - nie mówiąc o tym, że nie działa na niej CP/M (tam protokół komunikacji jest jednak nieco inny...)
Więc węszę problemy :)

Ja je czuję na kilometr, i to mając katar!
Dlatego sugeruję, by CP/M korzystał z innej formy komunikacji core-terminal, np. przez współdzielony bufor.
Zachowując jako backup stary styl komunikacji, no ale pytanie, czy będzie on działał i dlaczego nie ;)

Cytuj
Secundo, ja jestem prosty człowiek. Wolałbym chyba wziąć małego FPGA, wepchnąć mu w strukturę CPU, oba ROMy, 1770 i na co tam jeszcze miejsce pozwoli i przejmować się tylko dopasowaniem napięć :)

Et tu, Brute?... FPGA zabija ducha retro :(

steev

  • *****
  • Wiadomości: 1362
  • Miejsce pobytu:
    inode 42
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #6 dnia: 2019.07.04, 12:45:48 »
Utrata kompatybilności z istniejącym oprogramowaniem dla FDD3000. Dlatego wolałbym odwrotnie - komendy z gwiazdką dla FDD3000, a z kropką - dla divXXX. No ale technicznie trudniej to zrobić.
O, ja czerwony kapturek...
Od tej strony nie pomyślałem :)
Mniejsza o basic, bo to można zmienić, ale z poziomu asemblera... auć...

Cytuj
Et tu, Brute?... FPGA zabija ducha retro :(
Zawsze można wziąć jakiegoś retro FPGA ;)
Wszystko zależy jak kto ma ustawioną granicę 'retro'.
I ile miejsca pozostało w szafie.
Machines should work. People should think.

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #7 dnia: 2019.07.04, 13:11:13 »
Mniejsza o basic, bo to można zmienić, ale z poziomu asemblera... auć...

Problem jest nietrywialny. Nawet jak ograniczymy się do używania RST 8 + hook code zamiast bezpośrednich skoków do ROM, nadal jest problem - jak sprawdzać, czy komenda dotyczy TOS, czy esxDOS.


Cytuj
Wszystko zależy jak kto ma ustawioną granicę 'retro'.

Ja mam ustawioną na 5V.

Cytuj
I ile miejsca pozostało w szafie.

O, na ten temat mamy już odpowiedni wątek :)

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Odp: Dywagacje o CP/M, esxDOS, divMMC, divIDE i... 128K +2A/B/+3
« Odpowiedź #8 dnia: 2019.08.24, 21:12:15 »
Rom 3e przy wyłączonym romie Divmmc przejmuje  kontrolę nad divmmc i pełny dos z ZX+3 jest dostępny dla dysków. http://octocom.speccy.org/workbench_en.html z tego korzysta.

Sorki, zapomniałem Ci odpisać...
Moje rozważania dotyczyły generalnie komunikacji z FDD3000, nie stacją w +3. Po prostu +3 jest poza sferą moich zainteresowań ze względu na brak rozdzielczości hi-res. A szkoda, bo port #1FFD daje fajne możliwości konfigurowania pamięci RAM. ROM +3e to też kawał fajnej roboty.