Komenda xBIOS_WRITE_FILE nie przyjmuje parametru określającego długości pliku do zapisu. Ta informacja musi gdzieś istnieć, aby komenda funkcjonowała prawidłowo. Skąd, kiedy i w jaki sposób jest ona pobierana?

Bardziej intuicyjne byłoby założenie, że CLOSE jest wymagany za każdym razem, gdy korzystamy z PUT/GET. Ma to również sens w każdym przypadku korzystania z komend xBIOS_LOAD_FILE, xBIOS_WRITE_FILE, nawet gdy implementacja CLOSE dla tych przypadków jest pusta. Taki sposób korzystania z biblioteki jest łatwiej sobie utrwalić. CLOSE jest komplementarne dla OPEN. Komenda xBIOS_RUN_FILE jest tutaj wyjątkiem, gdyż automatycznie otwiera i zamyka plik, a komenda LOAD_DIR nie operuje na pliku.

Długość jest znana - tzn. kto ją zna?

To może zamiast CLOSE nazwij to FLUSH.

Chodzi mi o to, aby jawnie wyspecyfikować w dokumentacji, że protokół korzystania z operacji READ/WRITE jest następujący: OPEN, READ/WRITE, CLOSE. Każdy inny sposób może spowodować niezdefiniowane zachowanie. Jako użytkownik biblioteki nie chciałbym pewnego dnia zostać zaskoczony faktem, że dotychczasowy protokół korzystania jest błędny z racji zmiany implementacji CLOSE. Specyfikując go jednoznacznie unikamy na przyszłość takich problemów.

Czy nie lepiej byłoby zamienić obecną parę komend WRITE_FILE/PUT_BYTE na jedną, bardziej ogólną WRITE_FILE, gdzie podawalibyśmy ilość bajtów do zapisu? Użytkownik biblioteki zna maksymalny rozmiar danych do przetransferowania, więc nie byłoby z tym problemów. Skracamy w ten sposób listę komend kosztem rozbudowania interfejsu nowej komendy. Dla mnie taki interfejs byłby bardziej intuicyjny. Zapis do pliku tym sposobem byłby także bardziej wydajny.

Ta sama uwaga dotyczy komendy READ_FILE.

EDIT:
Możnaby wprowadzić komendę SET_LENGTH (X,Y - długość pliku) dla operacji READ/WRITE. Byłaby to opcjonalna komenda wykonywana po otwarciu pliku. Jeśli nie zostanie wywołana - odczytywany/zapisywany jest cały plik. W przeciwnym przypadku operujemy na ilości danych przekazanych w komendzie SET_LENGTH. Od strony implementacyjnej nie jest to problemem, wystarczy jedna flaga oraz słowo opisujące długość. Pętla realizująca odczyt bajtów, którą powyżej umieściłeś, stałaby się szczegółem implementacyjnym. Tym sposobem odczyt/zapis określonej ilości bajtów byłby prostszy. Oczywiście wydłuża się w ten sposób implementacja biblioteki, ale być może zostało ci jeszcze trochę bajtów.

Sekwencja komend SET_LENGTH (X,Y), SET_LENGTH (X) załatwiłaby sprawę.

Alternatywa:

ldy #<file_name
ldx #>file_name                
lda #EMode.CHUNK // ew. clc
jsr xBIOS_OPEN_FILE

ldy #<$ffffff
ldx #>$ffffff
lda #^$ffffff
jsr xBIOS_SET_LENGTH

ldy #<adres
ldx #>adres
jsr xBIOS_WRITE

jsr xBIOS_CLOSE_FILE

vs

ldy #<file_name
ldx #>file_name
lda #EMode.STREAM // ew. sec
jsr xBIOS_OPEN_FILE

lda #value
jsr xBIOS_WRITE

jsr xBIOS_CLOSE_FILE

Czy planujesz, aby lokalizacja skąd/gdzie pobierane/zapisywane są dane, mogła być wyrażana przez liczbę większą od 16'stu bitów?

dodane:

xBIOS_SET_LENGTH        equ xBIOS+$1e

przyklad uzycia:

                ldy <file_name
                ldx >file_name                
                jsr xBIOS_OPEN_FILE

                ldy #$80             ; len = $380
                ldx #$03
                jsr xBIOS_SET_LENGTH

                ldy <load_dest
                ldx >load_dest                
                jsr xBIOS_LOAD_FILE

czyli $380 bajtow zostanie zaladowanych z pliku. jesli plik jest krotszy niz (w tym przypadku $380) lub nie podamy dlugosci zostanie zaladowany caly plik.

pierwszy post wyedytowany

> XBIOS jest już w 16/32bitowych Atarkach, więc proponuję zmianę, tak żeby się komuś nie pomyliło

ta nazwa funkcjonuje nie tylko na st ale na malym atari chyba nie?

Tę bolączkę usuwa dowolny DOS, wystarczy trzymać się zasad, nie trzymasz się tych zasad widocznie.

Mylisz ZASADY poprawnego tworzenia plików binarnych z ograniczeniami. W związku z tym Twoje produkcje nie trzymające się tych zasad będą działały tylko pod Twoim inicjalizerem - chora idea.

Jaki to "pozytek" że program będzie musiał mieć wersje pod:
- SIO + standardowa prędkość
- SIO + turbo (tyle wersji ile turb)
- SIDE
- MyIDE
a do tego wszystkie te wersje w odmianie AtariDOS, SpartaDOS, a może jakiś inny wymyślisz.....

Jednym zdaniem.
"Wymyślasz" coś co zostało już dawno wymyślone, oprogramowane i ustandaryzowane jako DOS, tylko po to by nie trzymać się standardów tworzenia plików binarnych i zasad współpracy programów z pamięciami zewnętrznymi.

To oczywiście moja prywatna opinia, ale się z nią zgadzam :) !!!

DOSy są różne, obsługują różne filesystemy (mogę dzięki temy wybrać sobie HDD pod SDX i trzymać tam grę, która jest zgoadna z zasadami), jeśli ta gra prawidłowo używa OPEN, READ, PUT, WRITE, i CLOSE to MUSI działać pod KAŻDYM DOSem - pomijając zajętość pamięci oczywiście.

Bo de facto gra z włączoną tą biblioteką będzie grą całodyskową zapisaną pod konkretnym filesystemem i działającą z konkretnym rozwiązaniem sprzętowym (w zależności od biblioteki oczywiście).
To nie łatwiej pisać po sektorach?

Z zasady nie ładujemy pliku w miejsce rejestrów systemowych, kulturalny programista nie ładuje bajtu 0 do zegara systemowego prosto z pliku, kultularny programista robi na początku programu kawałek kodu inicjujący rejestr zegara tym zerem. Jest to czytelne i jako takie prawidłowe. Zasady są jasne:
- nie ładujemy nic w obszar rejestrów systemowych, stosu itp.
- zakładamy, że to co jest pod MEMLO jest "święte", więc staramy się ładować kod jak najwyżej.
- nie wyłączamy ROMu w czasie ładowania.

A jak jako programista tej gry chciałbym otworzyć dwa pliki jednocześnie?
Po prostu w efekcie końcowym albo powstanie kolejny DOS obsługujący w zależności od wersji rózny sprzęt i filesystemy - a nie będzie to już takie maleństwo. ... Albo zostanie to w postaci tego kadłubka, którym jest obecnie, który (eg Ciebie) znosi niektóre ograniczenia DOSa ale (wg mnie) nakłada na programistę inne ograniczenia, których nie ma DOS.
Może zakup w końcu 130XE i wtedy SDX załatwi Twoje problemy w większości... a przy okazji obsłuży od razu wszystkie filesystemy i użądzenia, bez posiłkowania się różnymi wersjami bibliotek.

Aaaa.... i zostaw $FFFA-$FFFF w spokoju !!!! :)

xxl, ale nie SET_LENGHT, tylko SET_LENGTH, dobrze?

Pecus, a nie szkoda ci czasu?
ale piszcie chlopaki, piszcie - ubaw po pachy ;)

O.K. Nie doczytałem o ładowaniu, czyli, trzeba będzie mieć DOSa, do tego xBiosa i grę .... dla każdej gry podfolder, albo dyskietka, albo ciagła zmiana nazw na xAutorun. A nie prościej pominąć jedno ogniwo i napisać grę tak by umiała działać z DOSem???

A co do wykropkowania, to zacytowałeś moje zdanie, w którym wymieniłem listę komend, bez tych komend :P - a je wykropkowałeś. Bez urazy, ale patrz na to co sam piszesz.

A to ulubiony adres kolegi ;P

P.-S. Chłopaki nie bierzcie tego do siebie... lubię drażnić czasem :P  Co nie zmienia faktu, że uważam to co napisałem - nie dopasowujmy systemu do gry, ale grę do systemu.