no i jest :) nowy xB - jak ktos chce do testow to zapraszam.

z grubszych zmian:

- zmienna dlugosc bufora,
- zmienna dlugosc katalogu

z mniejszych:
- predefiniowany czas oczekiwania dla FujiNet sciagajaca sektory z netu (user juz nie musi tego robic sam)

@xxl: Czy ten czas oczekiwania to inny parametr niż to, co było potrzebne dla SIO2BT (timeout po wysłaniu komendy)? Na ile go ustawiasz dla FujiNet?

Jeśli dobrze pamiętam to w procedurze SIO są dwa liczniki DRETRY i CRETRY. Jeden jest ustawiany na dwa powtórzenia, drugi na 15. Ile retry i jakie dajesz u siebie dla FN (chyba, że masz retry inaczej zaimplementowane)? Timeout na odpowiedź po komendzie jest 2 ramki, natomiast typowy dla komendy R/P to jest 7 ramek - to by nam dawało 15*7=105 ramek czyli mniej więcej 2 sekundy. Do minuty jeszcze daleko...
Konkludując - ciekawi mnie jakie wartości timeoutów i retry ustawiasz u siebie do poprawnej komunikacji z FN. Bo inaczej będę musiał to sam badać :)

xB oddaje statusy (zaleznie of funkcji) w C, rejestrach i reg.statusu.

obecnie przy EOF znacznik C=1 co okazuje sie byc klopotliwe poniewaz:

     jsr     xBIOS_OPEN_DEFAULT_FILE

     ldy     <dest
     ldx     >dest
     jsr     xBIOS_LOAD_DATA

C=1

ale jak ustalimy ilość danych, nawet na dlugosc pliku to EOF nie zostanie osiagniety:

     jsr     xBIOS_OPEN_DEFAULT_FILE

     ldy     <data_len
     ldx     >data_len
     jsr     xBIOS_SET_LENGTH

     ldy     <dest
     ldx     >dest
     jsr     xBIOS_LOAD_DATA

C=0

obydwa przypadki zaladuja tyle samo danych ale w drugim przypadku nie osiagamy EOF.

prawdopodobnie, kolejna wersja xB zglosi EOF poprzez C=0

sa jakies przeciwskazania ktorych jeszcze nie widze?

kolejna zgloszona modyfikacja: jesli wyedytuje sie config w naglowku xB to ten już nie bedzie probowal zaladowac pliku konfiguracyjnego po uruchomieniu.

pieknie, 8bit-Unity dla Atari zaczyna uzywac skompresowanych binarek baj default. drugi po LiteDOS ktory uzywa formatu cex :D

http://8bit-unity.com/?wpdmpro=8bit-gob … 2020-05-18

Potrzebuję, aby XIOS był przechowywany skompresowany w pamięci ROM kartridża z grą. Inflate do pamięci, gdy wymagany jest dostęp do dysku. Używam Inflate/Deflate, ponieważ miał on, w czasie gdy go tworzyłem, dobry współczynnik kompresji. Pojawia się monit o to, który slot pliku ma być użyty, jak 0 do 9. Zapisuje się do pliku jak GAMSAV0 do GAMSAV9. Można go później ponownie załadować.
Mam dużą grę typu Adventure, którą złożyłem dla Atari 8-bit. Obecnie pracuję z systemem operacyjnym i zapisuję dane gry bezpośrednio do sektorów dysku, ale nie chcę mieć do czynienia z idiotami, którzy ignorują ostrzeżenia i umieszczają w systemie dysk z innymi plikami i kasują je. Są też wichrzyciele, którzy zrobią coś takiego celowo, aby twierdzić, że kartridż z grą jest wadliwy, próbowali dostać go za darmo lub żeby dostać darmową kopię od autora. Jeden z nich lubi zamieszczać obelgi na temat XXL w mediach społecznościowych i na forum AtariAge. Na razie powiem tylko, że nie lubię wchodzić na forum AtariAge, bo to toksyczne środowisko.
U mnie program ładuje się do pamięci przy 2800$ i zapisuje na dysk blok 2K, który ma wszystkie informacje o postępie gry.

I need XIOS to load into RAM at $2800 from cartridge. It will be loaded with a deflate routine.  I use Inflate / Deflate because it had a good compression ratio at the time I created it. The game will program will ask which file slot to use, like 0 to 9. Saves to a file like GAMSAV0 to GAMSAV9. You can reload it later.
I have a big adventure game that I made for an Atari 8-bit. Currently, I'm working with the operating system and saving game data directly to disk sectors, but I don't want to deal with idiots who ignore warnings and put other files on the system and delete them. The program saves a 2K block from RAM to the disk, which has all the data for progress of the game. Variables, and what has happened so far.

jesli planujesz produkcję tylko dla CAR to moim zdaniem nie ma potrzeby uzywania xB. sa rozwiazania zapewniajace zapis danych na CAR bez potrzeby angazowania filesystemu.

przykladem moze byc: https://github.com/jhusak/jataricart

jesli jednak chcialbys uzyc xB to w przypadku zapisu na car potrzebowalbys odpowiedniego przygotowania takiego car... to moze byc klopotliwe, rozwiazanie nr.1 jest prostsze

OK. I remember what I was trying to do a few years ago. I needed the XBIOS source code so, I can add my piece of code to prompt the user for the file name. The program will save or load the game files from there using XBIOS. I can assemble the routine call it when the player wants to save their game progress.

The program currently uses a function that directly writes to disk sectors with no file names. The users will just format a separate diskette with nothing else on it, just for the game files. I have concerns that someone will accidentally put in a disk with other important files on it

OK. I remember what I was trying to do a few years ago. I needed the XBIOS source code so, I can add my piece of code to prompt the user for the file name. The program will save or load the game files from there using XBIOS. I can assemble the routine call it when the player wants to save their game progress.

The program currently uses a function that directly writes to disk sectors with no file names. The users will just format a separate diskette with nothing else on it, just for the game files. I have concerns that someone will accidentally put in a disk with other important files on it.

[Edit] I am attaching the current disk save/load system that accesses sectors directly.

Rozumiem.
Zawsze stronę D5XX mogę zrobić tak, że na początku dam sobie tablicę skoków. I w każdym "minibanku" te skoki będą identyczne. Więc przełączanie tych minibanków po D5XX nie wpłynie na powroty itp.

Bardzo ciekawy ten xBIOS :)