to nie jest dobry pomysl Sikor. obecnie mozna sobie napisac program ktory bedzie ladowal po kolei pliki z dysku (sa funkcje binary_load i load_file)...

teraz nawet w Basicu mozna sobie napisac FileLoadera ktory bedzie uruchamial programy binarne np. gry

udogodnienia dla uzytkownikow sa wazne ale rozwoj biblioteki pojdzie w kierunku udogodnien dla programistow.

1. oddzielenie menu od biblioteki
2. przekazanie kontroli nad konfiguracja biblioteki programiscie (to bedzie mialo konsekwencje dla usera, biblioteka konfigurowana na SIO/US, OS/:D, CAR/RAM)
3. najprawdopodobniej relokacja biblioteki wraz z mozliwoscia zmiany modulu I/O w samym ciele xB (obecnie mozna wskazac pamiec poza xB)
4. dla obslugi biblioteki z Basica lub Action! memlo identyczne jak dla programow maszynowych czyli $c00 (dla maszynowych dodatkowo 1,5 KB ponizej nierelokowanej biblioteki jest wolne)

w skrocie co jest najbardziej widoczna zmiana, przykladowo jesli uzyjemy odtwarzania muzyki podczas ladowania/zapisu to mozemy wskazac na ktorym module xB to robimy i user nie bedzie mial mozliwosci zmiany (obecnie moze co prowadzi do nieporozumien) oczywiscie jesli programista niczego nie wskarze bedzie dzialalo jak do tej pory.

Zgadza sie, TopDOS tez ma obsluge powyzej 64 wpisy w katalogu, co ciekawe oprocz QD rowniez dla dyskietek DD (BiboDOS tylko QD)

xBIOS obsluguje format TopDOS (xBOOT zreszta tez)

Ja nie posiadam komputera Atari, mam jakiś (anus) emulator. Dziękuję za możliwość wysłuchania ;)

- tuning biblioteki xB,

a w ramach testu do MENU dodane urzadzenie D: memlo $0c00 ("B" - wejscie do Basica) - nie przywiazywalbym sie, do czasu wydzielenia MENU z xB.

poprawka poszla na maila :-)

dla userow WUDSN IDE i MADS:

.enum xbios
rename                 = $0803 ;IN: <Y>= <filename, <X>= >filename, OUT: C=1 in case of error
load_file              = $0806 ;IN: <Y>= <filename, <X>= >filename, OUT: C=1 in case of error
open_file              = $0809 ;IN: <Y>= <filename, <X>= >filename, OUT: C=1 in case of error
load_data              = $080c ;IN: <Y>= <adr, <X>= >adr, OUT: C=1 in case of error
write_data             = $080f ;IN: <Y>= <adr, <X>= >adr, OUT: C=1 in case of error
open_current_dir       = $0812 ;IN: -, OUT: C=1 in case of error
get_byte               = $0815 ;IN: -, OUT: C=1 in case of error
put_byte               = $0818 ;IN: <A>= byte, OUT: C=1 in case of error
flush_buffer           = $081b ;IN: -, OUT: C=1 in case of error
set_length             = $081e ;IN: <Y>= <length, <X>= >length, OUT: -
get_file_offset        = $0821 ;IN: -, OUT: <Y>= <offset, <X>= >offset, <A>= ^offset
set_file_offset        = $0824 ;IN: <Y>= <offset, <X>= >offset, <A>= ^offset OUT: C=1 in case of error
set_params             = $0827 ;IN: <Y>= <adr, <X>= >adr, <A>= byte, OUT: -
set_default_device     = $082a ;IN: -, OUT: -
change_dir             = $082d ;IN: <Y>= <filename, <X>= >filename, OUT: C=1 in case of error
load_binary_file       = $0830 ;IN: -, OUT: C=1 in case of error
open_default_dir       = $0833 ;IN: -, OUT: C=1 in case of error
set_device             = $0836 ;IN: <Y>= <adr, <X>= >adr, OUT: -
relocate_buffer        = $0839 ;IN: <X>= >adr, OUT: -
list_dir               = $083c ;IN: -, OUT: <X>= byte, <A>= byte, C=1 in case of eof
open_default_file      = $083f ;IN: -, OUT: C=1 in case of error
.ende

w zalaczniku screen

od piateku zaczynamy wprowadzac zmiany w xB, mozna jeszcze na to wplynac (jesli ktos ma uwagi). tematy:

1. wprowadzenie podzialu na xB i MENU - ale caly czas to jest jeden plik. polaczone dwa pliki binarne: xB i "Menu". jesli ktos nie chce placic cennym miejscem na dysku za "Menu" bo jest mu zbedne moze bezpiecznie podzielic plik po pierwszym runad,

2. nazwa pliku xautorun znajdzie sie na poczatku pliku, jesli komus przeszkadza bedzie mogl to teraz latwo zmienic.

3. domyslnym modulem I/O bedzie teraz OS - to jest spora zmiana. decyzja programisty jest wejscie w tryb SIO xBiosa (czyli full wypasik). mozna bedzie wywolac xB z dowolnego urzadzenia odrazu. QMEG, patche OSa beda obslugiwane. takze furtka dla programistow: przykladowo mozna uruchamiac gre plikowa z hdd albo np. przekopiowac pliki do ramdysku i odpalic xB z ramdysku z modulem RAM...

4. user nie bedzie mial mozliwosci recznego ustawienia modulu I/O w "menu", przekazujemy pelna kontrole programiscie.

5. nie bedzie tez automatycznie wylaczany BASIC. traktujemy usera powaznie, jesli nie wylaczy BASICa znaczy nie chcial tego zrobic - w tym wypadku nie bedzie tez wywolywany zimny start po resecie. "B" w Menu przechodzi do Basica, bez Menu wejdzie automatycznie do Basica.
 
6. urzadzenie "D:" rejestrowane automatycznie - zobaczymy czy bedzie to dalej wspierane (potrzebny bedzie jakis krotki progrmamik testowy czytajacy/zapisujacy dane z/na D:)

7. skrocenie kodu

bez znaczenia, mozesz uzywac D: lub D3: (ogolnie Dx:) - zawsze trafi do urzadzenia z ktorego uruchomiona zostala Twoja gra.

Jedyne zastrzeżenie jakie mam to narzut pamięciowy na niewykorzystane urządzenie systemowe, ale tę opinię już znasz od jakiegoś czasu... Przydałoby się, aby przynajmniej w wersji developerskiej była możliwość usunięcia tego modułu dla kogoś, kto nie ma zamiaru z niego korzystać.

Kapitula przystala na znacznie wieksze zmiany niz poczatkowo zakladalem...

- biblioteka bedzie relokowalna i to my ustalamy gdzie. przed wystartowaniem biblioteki niezaleznej relokacji mozna bedzie poddac binarke, bufor, wektory init, run

to oznacza, ze jesli chcemy aby nasza gra ladowala sie bezposrednio np. od $200 to bedziemy to mogli zrobic bardzo prosto, chcesz zaladowac w miejsce xB? prosze Cie bardzo, juz mozesz.

mozliwe, ze trzeba bedzie opracowac prawdziwie dobry relokator. centrala juz prowadzi nabor.