No może i tak. Ale taka polityka powoduje, że niedługo pół ROM-u trzeba będzie wypełnić takimi skokami. Już utrzymanie adresów XL OS-u to jest marnotrawstwo miejsca, a przecież są w nim tez jakieś wynalazki z 400/800. Efekt jest taki, że mozna byłoby mieć ładny pusty obszar np. trzystu bajtów na jakies rozszerzenie, a w rzeczywistości jest to rozrzucone w stu miejscach po trzy bajty, kompletnie nie do użytku.

Pod tym względem największa porażka to pakiet matematyczny, ale akurat w przypadku reszty ROM-u tak nie musiałoby być. Ehhh, szkoda słów  :?

Lizard: z ostatnim przykładem siem zgodze. Jest elegancki i w 100% kompatybilny praktycznie z każdym systemem. Ale z tym 1-szym jest tak samo jak z moim jsr $f302.

"Kliku" nie było w procce TeBe. Więc sorki Lizard - sam przecież o tym pisałeś. Ślepota nie boli.

Ze źródłami OS-ROM'u Atari niepowinno być problemu, gdyż gdzieś je mam - w postaci *.M65 (Mac65).

Dokładny i szczegółowy opis wszystkich procedur systemu operacyjnego - nie tylko wejścia wyjścia też posiadam - wygrzebywałem je tylko dla celów HiDOS'a, gdyż gdyby nie fakt że dobrze wiem, iż system operacyjny powinien kożystać tylko i wyłącznie z legalnych skoków z tablicy skoków, to bym sie w to w ogóle niebawił. Dla mnie wystarczy to co jest i robie tak jak robie. Natomiast dla systemu operacyjnego zamierzam robić w jak największym stopniu "legalnie". Jak już pisałem, jeśli bede miał jakiś dylemat, czy użyć coś w jakimś stopniu "nielegalne" wykożystywanie OS'a, to zapodam pytanie i opre siem na tym co ludzie mówią!!!

ps. niemówiłem o tabeli, tylko o tym:

 
getchar lda $E425 
        pha 
        lda $E424 
        pha 
        rts 

odp. 1

a to jest nielegalne i NIE jest "1legalne" czy "udokumantowane"- tak jak moje jsr $c642 czy jsr $f302 czy jsr $f556 (...) - to co napisał, odczytując te wartości z bezpośrednio z tabeli HATABS, to jest legalne!!! Ja również mogę odczytać to z tabeli HATABS dodać jeden i zmodyfikować swój kod dynamicznie. Wyjdzie na to samo. Chyba że w jakimś "nowym" OS'ie zmieni się sposób komunikacji w tych procedurach.

odp. 2

używając adresów $c642, $f302, $f556, etc. zreguły piszę programy dla XL/XE z 64kB RAM'u - (z RAM'em pod OS-ROM). Chyba w większości przypadków jest że wiara ma rev. B OS-ROM'u.

odp. 3

chyba większość systemów jest w ten sposób pisana - że jest modyfikacją OS-ROM rev. B

odp. 4

no cóż.. Niewiem jak inni, ja postaram się już niekożystać z tych skoków.
Zęby to co napiszę działało ok.

odp 5

mogę sobie wyobrazić. Problem rozwiąże się jak Pasiu wprowadzi w życie ROM 512kB dla 65c816 - wtedy obszar $c000 - $ffff można "poświęcić" na wypełnienie NOP'ami i skokami JSR do "nowego" ROM'u.

A autor QMEGA - postarał sie o zgodność z 400/800, a zapomniał o ludziach XL/XE i zgubił "nowe urządzenia" - czyli nie w te stronę to w drugą. ale mniejsza z tym.

pakiet matematyczny - niestey fakt - porażka. ktoś, kto przerobił go kiedyś przyspieszając go znacznie - umieścił reszte kodu na miejscu zestawu znaków międzynarodowych. Draco może w nowym ROM'ie dla 65c816  zrobisz jakąś tablice skoków na przyszłość.

W związku powyższym mam kilka pytań:

czy warto przerobić AtariOS-ROM rev. B (800XE, 1985-03-01) wyżucając z niej obsługę C:, zestaw międzynarodowy i SelfTest'a, celem dodania obsługi obu tabeli partycji dla IDE KMK? Z posiadaczy IDE KMK i tak z innego OS-ROM nikt niekożysta - chyba, że jest to nowy  DracOS dla 65c816.

czy odczyt klawiatury w podany PRZE ZEMNIE SPOSÓB jest wkońcu legalny, czy też mam go nieużywać - w RAM'ie pod OS-ROM inaczej sie nieda, chyba ze przeskoczymy do zwykłej pamięci włączymy OS-Rom "odwołamy" się do CIO i powrócimy do programu w pamięci pod ROM'em. (roche długie i dla mnie bezsensowne marnowanie pamięci, ale coż).

getchr equ *

 lda $d20f 
 and #$0c 
 eor #$0c 
 bne *+4 
 clc 
 rts 
 ldy $d209 
 lda ($79),y 
 ldx #$50 
 stx $d40a 
 stx $d01f 
 dex 
 dex 
 bpl *-8 
 sec 
 rts

W Linii poleceń HiDOS'a chciałem zrobić obsługę np. historii poleceń, tylko że jeżeli użyję "E:", to bede ograniczony - nic niebede mógł robić jak OS'ROM czeka na naciśnięcie klawisza. Więc pytanie: Czy można zrobić w ten sposób, że kod klawisza odczytuję sobie po "swojemu" (tzn. jak wyżej), a wyświetlam poprzez E: lub bezpośrednio w pamięci ekranu - tylko że bezpośrednio w pamięci ekranu, to znowu nieda sie używać XEP80 - jeśłi ktoś tego używa. Więc pytam się za wczasu - może coś w rodzaju ładowalnego modułu - jeśli ktoś chce, to do wszystkiego używa zwykłego "E:" (lub własnego sterownika "E:" (np. QuickEdit) lub "mojego" z bezpośrednim dostępem do pamięci ekranu i klawiatury z rozszeżonymi funkacjami klawiatury - np. historia poleceń - pytam za wczasu. żeby potem niebyło.

O kurde - ktoś sobie zadał proste pytanie na forum (jak czytać klawisze w ASM), a tu niezła burza wyszła nt. (nie)legalnego używania procedur OS'u  :lol:

Pewnie ścigać się z userem. Czy user zdąży wcisnąć następny klawisz, czy ja szybciej zgadnę i wyświetlę na ekranie. :D

[ Dodano: 16.11.2004 15:45:26 ]
Casper: jak już Draco wspomniał, "legalna" jest nie tylko tablica skoków pod $E450, ale też parę innych rzeczy. Np. pamięć od $0000 - $05FF, $E000 - $E44F, $FFFA - $FFFF. ;)

Zientara zrobił błąd podając adresy procedur systemowych. Każdy myśli, że jak WZ napisał, to moż skakać do $Fxyz i zawsze będzie działać. :/

Mówi się, że to co dla jednych zaletą, dla drugich wadą.

Zaletą jest dla ludzi mądrych - potrafią skorzystać, wadą - dla pozostałych. :twisted:

Jasne, że nie można winić Zientary za to, że książka, którą przepisywał zawiera błędy. ;) Zwróć uwagę, że mowa tu o głównych procedurach. Funkcje wskazywane przez wskaźniki zawarte w tablicy wektorów obsługi urządzeń nie są procedurami głównymi. Dostęp do nich wszystkich uzyskuje się przez skok do $E456. Dla operacji na pojedyńczych bajtach jest to jednak rozwiązanie najwolniejsze i dlatego stosuje się wektory pod $E400. Dla przykładu odczyt/zapis pliku na dysku:
wykonanie BGET #kanał, adres, długość spowoduje wywołanie przez główną procedurę CIO (tę w ROM-ie) procedury odczytu/zapisu pojedynczego bajtu przez sterownik dyskowy (czyli DOS). DOS sprawdza wtedy, czy rzeczywiście chodzi o jeden bajt, czy cały blok. Jeśli blok, to przeprowadza transmisję całości, a następnie poprzez modyfikację rejestrów systemowych oszukuje CIO tak, że ta myśli, że już wywołała Get/Put Byte odpowiednią ilość razy. Gdyby nie ta sztuczka, to byśmy sobie czekali i czekali. Nawet najszybszy twardziel niewiele by tu pomógł.

To, że koledzy, którzy lubią skoki na lewo stali się nagle purystami, gdy chodzi o wytykanie cudzych pomyłek i "lewackości". ;)