Witam Szanownych Forumowiczów.
Jakiś czas temu przeglądając informacje nt DracOS, którego Autorem jest Drac030 trafiłem na opis handlera urządzenia @:. Urządzenie to służy do pozyskiwania informacji o różnych rzeczach związanych z systemem: CPU, FPU, dodatkowy RAM, ilość urządzeń SIO, operacje XIO i inne takie. DracOS został oczywiście stworzony dla 65C816, ale stwierdziłem że fajnie byłoby mieć i w XLOS@6502 mechanizm pozwalający na łatwe stwierdzenie z poziomu dowolnego języka programowania co w systemie siedzi i z czego można korzystać i jak.
Sam handler @: w DracOS implementuje tylko jeden plik SYSDEF przeznaczony tylko do odczytu. Ponieważ uważam, że pomysł ma znacznie większy potencjał swoją implementację rozdzieliłem na dwie części:
* handler obsługi urządzenia @:,
* handler obsługi pliku @:SYSDEF.
Samo urządzenie @: jest wirtualnym dyskiem, który potrafi zarządzać plikami w pamięci RAM. Pierwszym z nich jest SYSDEF zawierający informacje o systemie zgodne z tym zaimplementowanym w DracOS.
Nic jednak nie stoi na przeszkodzie, żeby Twórcy rozszerzeń stworzyli proste TSRy do obsługi własnych plików:
- VBXE,
- SB,
- COVOX,
- POKEY,
- RTC,
- WERONIKA
i innych, które udostępniały by programiście różne przydatne informacje - a to wektory procedur użytkowych (np. do wyboru lub flashowania rdzeni VBXE), a to ilość i adresy POKEYów czy COVOXa.
Urządzenie ma o tyle duży potencjał, że pozwala prosto dodać dodatkowe możliwości dla projektantów rozszerzeń OSXL. Np. przenieść tablicę skoków do RAM, co pozwoliłoby:
- modyfikować niektóre procedury OSa np. implementować szybkie SIO w RAM,
- skrócić tablicę skoków do samych wektorów (odwołania jmp (vector)),
- rozszerzyć tablicę skoków o dodatkowe procedury (np. mechanizm relokacji),
- lub wręcz stworzyć oficjalne tablice skoków dla części systemu, które jej jak dotąd nie mają (pakiet FP + procedury trygonometryczne w BASICu),
- rozszerzyć procedury obsługi przerwań o wektory dla nowo tworzonych urządzeń.
- udostępnić nowy mechanizm dodawania urządzeń do OS - CIO pozwala umieścić tylko kilka wpisów w HATABS.
Nowy sposób wywoływania funkcji OSa odbywałby się poprzez wektory udostępniane przez @:. Stary sposób (przez tablicę skoków) działałby oczywiście nadal, lecz bez udostępniania dodatkowych funkcjonalności.
Ponieważ handler urządzenia @: ma komplet mechanizmów pozwalających na tworzenie nowych plików, ich odczyt/zapis oraz usuwanie, implementacja własnego pliku nie wymaga wielkiego kodowania i można to zrobić z poziomu dowolnego języka programowania. Program instalujący plik miałby po prostu sprawdzić czy:
1. W OS istnieje urządzenie @: wraz z interesującym go plikiem.
2. W razie potrzeby utworzyć przez urządzenie @: plik opisujący odpowiednie rzeczy.
3. Zainstalować udostępniane funkcje, przerwania, informacje o featurach, wektory, itp.
4. Zostawić w RAM procedurę wywoływaną po RESET (minimalna wymaga jedynie podniesienia MEMLO, tak żeby nie zatrzeć zawartości pliku).
Zaletą TSRa jest to, że procedury detekcji lub konfiguracji różnych featur nie muszą siedzieć w systemie na stałe - mogą się uruchomić przy inicjalizacji TSR, przygotować odpowiednie informacje, zostawić je w systemie i się zakończyć.
Program, który chciałby skorzystać z takich informacji po prostu za pomocą CIO odczytywałby zawartość pliku @:COŚTAM. Handler @: obsługuje funkcje NOTE/POINT więc bez problemu można z miejsca sięgnąć do interesujących rzeczy.
W ATRze załączam implementacje @: i pliku SYSDEF, dokumentację opisującą mechanizmy i sposób użycia, oraz przykładowe programiki w BASICu prezentujące sposób użycia (*info.lst), jak również sposób instalacji własnego pliku w systemie (allxio.lst - wykorzystanie CIO do zarządzania plikiem; nie ma procedur instalacji TSR).
Źródła wykorzystują relokator JBW do instalacji TSRa i pozwalają się zorientować jak implementować obsługę własnego pliku na przykładzie SYSDEF.
Zapraszam do dyskusji.
P.S. Dzięki Drac030 za uwagi i świetny pomysł.
P.P.S. Obecna implementacja nie będzie poprawnie instalować się w SDX - wersja uniwersalna jest w przygotowaniu.