Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormono
   • CommentTime22 Dec 2012 14:12

    
   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.
2. • 2:
      
     CommentAuthortdc
   • CommentTime22 Dec 2012 19:12 zmieniony

    
   Bardzo fajny pomysł w sensie idei, zamysłu, celu i realizacji. To teoria, a ona nawet w inżynierii komputerowej bywa ciekawa i wbrew pozorom niepozbawiona sensu.
   
   Natomiast w praktyce to np. mnie zabolały dwa stwierdzenia: wirtualny system plików oraz "(...) podniesienia MEMLO".
   
   Pomysł ten jest niemal żywcem wyjęty z rozumowania na jakim opierają się rozbudowane systemy operacyjne komputerów 16, 32 i więcej bitowych. I w teorii brzmi to wyśmienicie, w praktyce wszystkie znane mi osoby dążą do tego aby albo kompletnie usunąć takie pojęcie (i funkcjonalność) jak MEMLO, albo starają się aby pod żadnym pozorem ono nie wzrosło choćby o kilka bajtów :P
   
   Przykładowo w grze Calamanis, programowałem tak aby kod był maksymalnie krótki (czyli więcej treści dało się wcisnąć w 64kb), bo zwykle koduję tak aby było wydajnie. Nie jestem jeszcze na tym etapie że pozostało mi jedynie ostatnie 500 bajtów pamięci, ale cały czas zastanawiam się co zrobić aby pamięć zaoszczędzić, jakby mi tylko ktoś powiedział jak tego dokonać to wywaliłbym choćby stos CPU (np. aby procesor sobie dobudował dodatkową własną pamięć ale nie na cache ale na stos :P), bo SO poleciał w pierwszej kolejności, a DOS poleci pewnie jutro lub pojutrze :P
   
   Dlatego w pierwszej kolejności wirtualny system plików, należałoby umieścić gdzieś daleko w rozszerzonej pamięci. To dobra droga, ale im bardziej będzie się ten pomysł rozwijać, ujednolicać oraz uniwersalniać to tym bardziej stanie się on bezużyteczny. Bo przeciętny gracz nie skorzysta z niego, a bardziej zaawansowanych użytkowników będzie tylko część z tych którzy mają rozbudowaną pamięć - czyli w praktyce będzie to kilka osób.
   
   Nie chcę tragizować, ale zastanów się co można zrobić aby ten problem rozwiązać, może się jakoś da? Przykładowo problemem może być wirtualny system plików, jak się okaże że dodamy do niego opisy wszystkich zainstalowanych w systemie urządzeń to pytanie ile to w sumie zajmie RAMu? (włącznie z całą resztą danych i obsługi).
3. • 3: CommentAuthormono
   • CommentTime22 Dec 2012 20:12 zmieniony

    
   Handler @: zajmuje prawie 2 strony RAM, ale daje całą infrastrukturę związaną z CIO. Programista implementujący własny plik zostawia w RAM tylko zawartość pliku, strukturę linkującą pliki (8 bajtów + nazwa z EOLem) i kod podnoszący MEMLO - w przypadku SYSDEF wygląda to tak:
   

   jsr poprzedni_TSR
   ldx #<newmemlo
   ldy #>newmemlo
   stx MEMLO
   sty MEMLO+1
   rts
   ;struktura linkująca pliki
   link:
     .dw prev
     .dw next
     .dw file
     .dw filelen
     .db 'SYSDEF',eol
   ;a tutaj znajdują się tylko dane będące zawartością pliku
   file:
     .ds ?
   filelen = *-file
   newmemlo:
   

   
   cała reszta detekcji i uzupełniania informacji dostarczanych przez plik SYSDEF odbywa się podczas inicjalizacji TSRa a więc nie zajmuje finalnie RAM.
   Czy to dużo? Mniej już chyba być nie może...
   
   Edit: Być może dałoby się jeszcze zrezygnować z kodu podnoszącego MEMLO, który zazwyczaj będzie identyczny.
   
   Edit 2: Oczywiście same wywołania CIO są dość kosztowne, ale nic nie stoi na przeszkodzie, żeby właśnie korzystać z zawartości konkretnych plików do adresowania funkcjonalności udostępnianej w systemie.
   Wyobrażam sobie to tak, że program inicjalizując się wywołuje CIO i dostaje adresy do konkretnych plików, lub wybiera z nich informacje, których będzie potrzebował w późniejszej pracy. Mając te dane może z nich już korzystać i nigdy więcej nie użyć CIO. W zamyśle dane ustostępniane przez te pliki mają być statyczne, bo przecież nie mamy systemu wielozadaniowego.
4. • 4: CommentAuthorxxl
   • CommentTime22 Dec 2012 20:12

    
   Tdc mam dla Ciebie rozwiazanie wszelkich problemow :D nie zasmiecam watku. pisz na maila
5. • 5: CommentAuthormono
   • CommentTime22 Dec 2012 20:12

    
   True. xBIOS Ci się bardziej przyda jeśli chces się zmieścić w 64k :) I MapRAM.
   
   Moje rozwiązanie adresuje trochę inne problemy. Pozwala swobodnie rozszerzać system i uwolnić programy od kodu każdorazowo wykrywającego konfigurację sprzętu i oprogramowania systemowego.
6. • 6: CommentAuthorpin
   • CommentTime22 Dec 2012 20:12

    
   ...dla programów użytkowych jest to dość ciekawa alternatywa, przyznam.
7. • 7: CommentAuthor0xF
   • CommentTime22 Dec 2012 21:12

    
   Widzę tu przerost formy nad treścią. Jak chcę wykryć wersję ROM, to zaglądam pod określony adres. Jak chcę wykryć VBXE to odpalam kilkulinijkową prockę. Miałbym zamiast tego przez CIO czytać binarne dane w niestandardowym formacie? I jeszcze oczekiwać, że ten dziwny handler jest zainstalowany?
8. • 8: CommentAuthormono
   • CommentTime23 Dec 2012 06:12

    
   Tak. Właśnie chodzi o to, żeby mieć gotowe dane, zamiast we wszystkich programach duplikować te same procedury detekcji czy inne funkcje użytkowe. @: ma spełniać funkcje rejestru z informacjami o konfiguracji systemu oraz pozwalać na łatwe rozszerzanie jego możliwości.
   Czemu CIO? Bo to jedyny elastyczny sposób w OSie na to, żeby nie zastanawiać się pod jakim adresem umieścić swoją bibliotekę żeby nie kolidowała z innymi - CIO uwalnia od stałych adresów. Bibliotekę z funkcjami obsługującymi dane urządzenie, jak i dane można zrelokować w dowolne miejsce.
   Handler implementuje podstawowe funkcje CIO i kilka XIO po to, żeby można było łatwo korzystać z tych informacji w dowolnym języku programowania, nie tylko w asm. Może lepiej (prościej, a na pewno krócej) byłoby zrobić tylko prostą funkcję XIO do pobrania adresu i rozmiaru "pliku" w pamięci.
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime23 Dec 2012 18:12

    
   taki /proc
   IMHO bardzo fajne - dla użytków.
   Jednak 017 (0xF) ma też rację - wczytać takie coś i porównać ze stringiem to dużo więcej bajtów, niż obsługa wewnętrzna (otwarcie pliku, odczyt, porównanie, zamknięcie, daję ok. 100 bajtów, aby sprawdzić jedną rzecz)
10. • 10: CommentAuthormono
    • CommentTime23 Dec 2012 18:12 zmieniony

     
    Jest przecież droga na skróty - XIO 39 (GET LENGTH):
    

    ldx #IOCB
      lda #$27  ;LENGTH
      sta iccmd,x
      lda #<filename
      sta icbufa,x
      lda #>filename
      sta icbufa+1,x
      jsr jciomain
      bmi ?error
      
    filename .db '@:MYFILE',eol
    

    
    Jako wynik zwaracane są:
    - w ICAX3/4 - ilość danych
    - w ICAX5/6 - adres danych
    Circa about 40 bajtów.
    
    Edit: Dane w pliku są przecież binarne...
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime23 Dec 2012 19:12

     
    Jak to "przecież"?
    
    Przecież w uniksie dane są tekstowe :)
    
    
    :P
12. • 12: CommentAuthorbob_er
    • CommentTime23 Dec 2012 23:12

     
    zależy jakim :P.
    linux ma tekstowo.
    solaris binarnie.
    
    swoją drogą - ciekawi mnie ilość użytków na malucha, które napisane będą.
13. • 13: CommentAuthorwieczor
    • CommentTime24 Dec 2012 01:12

     
    A ile ostatnio nowych widziałeś? :)
14. • 14: CommentAuthorpin
    • CommentTime25 Dec 2012 14:12

     
    ... w cholerę użytków pod Sparta DOS X. Playery, sterowniki do przeróżnego hardware'u, i inne utilsy ;)- Tak mało, to tego nie jest wcale.