1

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.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

2 Ostatnio edytowany przez Pin (2012-12-22 21:27:36)

.. pomysł dobry, lecz jest do wykorzystania dopiero w nowych programach i zasadniczo było by to wymaganym przez owy program elementem w takim przypadku.

... czyli, np. napisałeś playery, które można zpaczować tak, by nie robiły same detekcji np. stereo, tylko pobierały by dane z @: Zastanawiam się tylko nad MemLo ;) -

Kontakt: pin@usdk.pl

3

Pin napisał/a:

można zpaczować tak, by nie robiły same detekcji np. stereo, tylko pobierały by dane z @:

Po co?

https://www.youtube.com/watch?v=jofNR_WkoCE

4 Ostatnio edytowany przez Pin (2012-12-22 23:43:25)

właśnie sam się zastanawiam nad tym, co napisałem gdyż playery to raczej bardzo zły przykład wykorzystania urządzenia @: ;)-

Kontakt: pin@usdk.pl

5

No właśnie po to, żeby programy mogły korzystać z pracy innych programów. Przecież po to właśnie pisze się drivery do różnych rzeczy, żeby programista nie musiał samemu grzebać po sprzęcie i przeprowadzać detekcji czy innych operacji.
Playery - może i zły przykład, choć łatwiej chyba sięgnąć po konkretny adres bazowy i liczbę pokeyów, niż samemu je wykrywać.
Łatwiej chyba pozyskać adres procedury flashującej VBXE niż samodzielnie pisać flasher.
Łatwiej chyba mieć informację gdzie jest zainstalowany Covox niż malować menu z wyborem n opcji.
Łatwiej chyba sięgnąć po nry banków, które zajmuje SDX lub ramdysk niż wyświetlać wybieraczkę banków.
Tak mi się wydawało... no i stąd rozszerzony @:
2 strony pamięci - fakt to dużo, ale może można to zrobić inaczej?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

6

sugerowałbym możliwość rozdzielenia w postaci modułów, do własnego wykorzystania takiego zbioru procedur dokonujących detekcji sprzętu, jeśli ktoś chce korzystać z handlera @: to asembluje sobie handler, albo bierze tylko osobny moduł realizujący samą detekcję

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

7

moznaby jeszcze dodac sprawdzanie GTIA - mozna programowo sprawdzic czy GTIA jest uszkodzone.

http://atari.pl/hsc/ad.php?i=1.

8

Muszę nadmienić, że pomysł o tyle nie jest mój, że był poniekąd inspirowany czymś, co jest znane na Atari ST/TT/Falcon, mianowicie niejakim Cookie Jarem. Jest to kawałek pamięci (o rozmiarze deklarowanym w minimalnym rozmiarze przez TOS, ale możliwym do zmiany przez użytkownika) należący do BIOS-u, który ma za zadanie zasygnalizować, jakie zasoby sprzętowe wykrył tenże BIOS oraz ładowane podczas startu systemu programy.

Cookie Jar zawiera iks wpisów po 8 bajtów. Pierwsze 4 bajty to identyfikator zasobu, następne 4 to wartość zależna od zasobu, definiująca jego jakość. Np. $5F, $43, $50, $55, $00, $00, $00, $1E oznacza: 1) pierwsze cztery bajty to znaki ASCII "_CPU", 2) drugie cztery bajty to wartość sygnalizująca z czym mamy do czynienia w danej dziedzinie, przykład mówi $0000001E = $1E = 30, znaczy, CPU = 68030.

Oczywistą korzyścią jest to, że programy nie muszą (jakkolwiek oczywiście mogą) wykrywać sprzętu na własną rękę, wystarczy krótka procedurka zaglądająca do Cookie Jaru. Oczywistą korzyścią następnego rzędu jest to, że przez ingerencję w Cookie Jar można (jeśli zachodzi potrzeba) spowodować wyłączenie pewnych zasobów sprzętowych, nawet jeśli fizycznie są dostępne - np. autor programu może być ciekaw, jak się zachowa jego dzieło bez dodatkowej pamięci, bez stereo, bez VBXE itp.

Tablica danych dostępna dla takiego urządzenia @: może być oczywiście uzupełniana/modyfikowana przez nierezydenty ładowane przy starcie systemu. Np. wielkość i typ pamięci dodatkowej raczej nie zmieni się bez zimnego startu, zatem można załadować kawałek nierezydentnego programu, który przy starcie systemu przetestuje pamięć i zapisze odpowiednie wartości w tablicy, a potem zakończy się nie pozostawiając innych śladów.

KMK
? HEX$(6670358)