Thunder Command Processor 1.0beta


       DUP.SYS jaki jest - każdy widzi. Szczególnie wtedy, kiedy takie cudo jak MYDOS traci wiele przez swojego dupa (bez skojarzeń).

       Dlatego postanowiłem swego czasu napisać programik, który zastąpi DUP.SYS, ale jego obsługa będzie nieco bardziej "qlturalna". Tzn. będzie on działał na zasadach ogólnie przyjętych dla "normalnych" Command Processorów - rezydentny CP pracujący w tzw trybie konwersacyjny: komenda - odpowiedź, itd. W podobny sposób wygląda praca w SpartaDOSie, CP DOS 2.5 (z Avalonu), DOS II+/D, etc...

       TCP jest rezydentnym Command Processorem przeznaczonym dla MYDOS-a 4.50. Moim zdaniem jest to najpopularniejsza wersja tego DOS-a, a z przerobieniem na inne nie powinno być problemów... Jego największą wadą jest bardzo wysokie MEMLO (aktualnie prawie $2600) charakterystyczne dla rezydentnych Command Processorów.

       Jednak programu nie kończyłem. Zostawiłem go takim, jakim był, bo już istniejący fragment wystarczył do wykonywania podstawowych operacji dyskowych. W końcu postanowiłem puścić niedokończony program jako Public Domain. Może ktoś go dokończy?

KOMENDY TCP

Aktualnie TCP wykonuje komendy:

polecenie zewnętrzne
nazwa
uruchomienie polecenia zewnętrznego czyli pliku wykonywalnego DOS. Brak rozszerzenia powoduje automatyczne dodanie .COM
np.: ST.EXE
PANTHER
PATH PATH ścieżka
    lub
ścieżka

zmienia aktualną ścieżkę dostępu.
ścieżka - nazwa zakończona dwukropkiem
np.: PATH D1:
D4:LISTY:ZENON:
DIR DIR (maska)

katalog dyskietki według podanej maski.
Brak maski daje spis *.* w aktualnym katalogu.
np.: DIR D2:SAMPLE:*.D15
DIR
* 1...8, *
* spis katalogu głównego stacji 1...8,
gwiazdka "*" daje spis katalogu głównego aktualnej stacji.
MD MD nazwa

utworzenie podkatalogu w aktualnym katalogu.
np.: MD PLIKI
CD CD nazwa|..

przejście do podkatalogu o podanej nazwie lub
do katalogu macierzystego (po podaniu ".." zamiast nazwy)
np.: CD ..
CD PLIKI
DEL DEL nazwa

skasowanie plik(ów) w/g podanej maski
np.: DEL PLIK.TXT
DEL *.BAS
LOCK LOCK nazwa

zabezpieczenie plik(ów) w/g podanej maski
np.: LOCK PLIK.TXT
LOCK *.BAS
UNL UNL nazwa

odbezpieczenie plik(ów) w/g podanej maski
np.: UNL PLIK.TXT
UNL *.BAS
REN REN stara_nazwa, nowa_nazwa

zmiana nazwy pliku (plików)
np.: REN PLIK.DOC PLIK.TXT
REN *.EXE *.COM
MON MON

przejście do MLM Q-Mega lub Self Testu (zależnie od używanego systemu)
VIEW VIEW nazwa(@)

wyświetlenie zawartości pliku o podanej nazwie. Małpa umieszczona po nazwie sygnalizuje, że kody sterujące mają być wyświetlane, a nie wykonywane.
np.: VIEW PLIK.TXT
VIEW FILE.DAT@
RUN RUN (adres)

uruchomienie programu od podanego adresu (hex). Brak adresu powoduje uruchomienie programu od adresu zapisanego w RUNAD. Przydaje się, bo czasami program po wczytaniu nie uruchamia się :( Wiem że to mój błąd. Dobre, nie!?
np.: RUN 8000
RUN
RUN E477
CLS CLS

wyczyszczenie ekranu.
MEM MEM

podaje wolną pamięć (MEMLO -> MEMHI)
Kilku komend brakuje, chociaż są one umieszczone w tablicy. Są to: (składnia i opis podane według tego, co miałem zaplanowane)
INIT INIT (dysk)(CD:gęstość|CT:l_ścieżek S:l_stron F:l_sektorów L:dł_sektora)

formatowanie dysku w podanej stacji oraz gęstości. Można podać gęstość literowo: S (single), E (enhanced), D (double), I (ibm s-9), Q (quadruple) ewentualnie dokładnie określić parametry formatu (liczba ścieżek, stron, sektorów/ścieżkę, długość sektora)
np.: INIT
INIT 1
INIT CD:E
INIT CT:40 S:1 F:18 L:256
INIT 2 CD:D
INIT 2 CS:1 CT:40 CL:256 CF:18
SYS SYS (dysk)

zapis plików systemowych na dysk o podanym numerze.
np.: SYS
SYS 3
CAR CAR (on|off)

uruchomienie cartdridge-a. Z komendą on lub off włącza lub wyłącza wbudowany interpreter Basica. Sam nie wiem czemu tego jeszcze nie napisałem...

PRZEKAZYWANIE PARAMETRÓW

       Dekoder rozkazów TCP jest tak skonstruowany, że umożliwia przekazywanie parametrów do poleceń zewnętrznych. Cały tekst zapisany za nazwą pliku jest kopiowany od adresu $0530. Daje to łatwy dostęp do treści parametru we wczytywanym programie.

       Kto bawił się np. DSD z TA 2/91, pamięta, jak wczytywanie tego programu w Chaos CP, z podanymi parametrami, wymuszało podanie rozszerzenia. Wyglądało to tak:

DSD ale DSD.COM /T

W TCP nie ma takiego ograniczenia, bo polecenie jest interpretowane po podziale na instrukcję i parametr i TCP dodaje ".COM" na końcu samej nazwy, zostawiając parametr w spokoju.

JAK TO SIĘ JE?

       Adres kompilacji jest ustalony sztywno. Musi to być 8169 (dec), niższy może powodować nieprawidłowe działanie całości (kod TCP będzie pokrywał się z buforem MYDOS-a), wyższy niepotrzebnie podniesie i tak już wysokie MEMLO.

       Należy pamiętać o inicjalizacji D: po reset (Init - $07E0). Ładowanie DUP.SYS przy starcie komputera odbywa się w specyficzny sposób. Program uruchamiany jest tylko raz - według adresu w INITAD, a więc nie odpalicie żadnego intra, wpisywanie czegokolwiek do RUNAD też nie odniesie skutku.

       TCP obsługuje przerwanie BRK, przy czym nie ma żadnej pewności, że zawsze robi to poprawnie.

       Opcja wczytywania plików binarnych nie działa do końca poprawnie - tj. nie zawsze jest wykonywany skok pod adres w RUNAD po wczytaniu programu. Dzieje się tak m.in. przy próbie wczytania programu zaraz po komendzie DIR, zaś jeśli przy wykonaniu poprzedniej komendy wystąpił błąd I/O, to są duże szanse na poprawne wykonanie tej komendy. Nie mam pojęcia od czego to zależy.

       Zdaję sobie sprawę z tego, że zmiana bieżącego katalogu mogła być wykonana w inny (czytaj: lepszy) sposób. Obecnie przy zmianie ścieżki TCP nie sprawdza, czy podana ścieżka istnieje, a przy odczycie przedziera się przez całe drzewo, zanim dotrze do właściwego katalogu. Ten sposób działania komendy CD został wymuszony przez istnienie komenty PATH, a nie wiem gdzie MYDOS przechowuje ścieżkę dostępu (D: = ....). Lepiej byłoby to zrobić właśnie przez zmianę ścieżki w samym DOSie a nie tylko w CP. Ułatwiłoby to pracę z programami nie przystosowanymi do operacji na dyskietkach z podkatalogami.

       No i oczywiście brakuje kopiowania. Procedurka kopiująca zajęłaby sporo miejsca i praktycznie lepiej jest użyć zewnętrznego kopiera, których powstała masa.

       Tyle w każdym razie wynika z moich eksperymentów. Ponieważ każdy może się mylić (a ja w szczególności), więc bardzo prawdopodobne jest, że część z tych zastrzeżeń nie jest do końca prawdziwa, tym bardziej, że są one oparte wyłącznie na doświadczeniach metodą prób i błędów i domysłach: dlaczego tak a nie inaczej. Przy pisaniu TCP nie miałem dostępu do żadnej, nawet najbardziej ogólnej dokumentacji MYDOS-a. A szkoda, bo może oszczędziłbym sobie sporo nerwów i skończyłbym całość.

PROPOZYCJE

       Jeżeli ktoś będzie miał ochotę zająć się rozwijaniem idei TCP, to mam kilka propozycji. Oto i one:

  • MEMLO można obniżyć przez podział kodu TCP na jądro systemu oraz kod poleceń. System mógłby np. przy wczytywaniu kopiować kod poleceń wewnętrznych (no, już nie tak całkiem wewnętrznych) do XMS. Jądro składałoby się z interpretera poleceń, który sprawdzałby, czy instrukcja jest w XMS, czy też należy jej szukać na dysku.
  • Sposób zmiany aktualnej ścieżki dobrze byłoby zmienić w taki sposób, żeby TCP cały czas operował na "D:", a dostępem do odpowiednich dysków i katalogów zajmował się sam MYDOS. Jak to zrobić? To proste! Wystarczy wywalić polecenie PATH, bo jego przydatność jest nikła a zmienić działanie instrukcji CD tak, żeby nazwa katalogu do którego ma nastąpić przeniesienie była przekazywana do DOS-u z wykonaniem odpowiedniej komendy (o ile dobrze pamiętam, ChDir to w MYDOS-ie #41). No i nazwę pliku należy zawsze kopiować po samym "D:".
  • Oczywiście po wykonaniu punktu pierwszego można iść na całość. Dodanie poleceń typu: kopiowanie plików czy całodysków, ustawienia konfiguracji, etc. nie wpłynie na MEMLO, więc można sobie szaleć...

       Pytanie: Dlaczego sam tego nie zrobiłem? ;) Już odpowiadam: Bo mi się autentycznie nie chce.. LENISTFO ROOLZ

       Ofukajcie mnie za to, ale po prostu nie mam do tego cierpliwości. Niedługo będę instalował sobie HDD i do tego już na 100% będę pisał DOS obsługujący cały potencjał interface'u J. Żuka - czyli dwa dyski po 8GB. I najprawdopodobniej będzie to coś więcej niż sam DOS - coś na kształt skrzyżowania najlepszych cech SDX i QMEG-a... Nic więcej nie powiem. A na razie i tak muszę skończyć OSADNIKÓW. Są postępy...

       I to chyba wszystko. Myślę, że choć nie jest to nic wielkiego, to jednak gra może być warta świeczki. Byłbym niezmiernie szczęśliwy, gdyby TCP dalej się rozwijał.

epi/Allegresse^AeR^LSD

p.s. Mam nadzieję, że wszyscy wiedzą, co należy zrobić z plikiem TCP.SYS... Kto nie wie, to służę pomocą. Oczywiście TCP po zassemblowaniu zapisujemy jako DUP.SYS zamiast oryginalnego pliku o tej samej nazwie.