Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
atari.area forum » Fabryka - 8bit » xBios - biblioteka IO dla gier ktore lubia przestrzen
Strony Poprzednia 1 2 3 4 5 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
No to akurat jest chyba proste :) Sygnatura jest wymagana w pierwszym bloku pliku - jeśli jej nie ma DOS raportuje error 152 (not binary format). Kolejne bloki MOGĄ jej nie mieć. Ale MOGĄ mieć więc nie ma problemu.
Problem z adresem $FFFF wynika z tego, że segment do załadowania od tej lokalizacji można wyrazić w pliku binarnym na dwa sposoby. Pierwszy posiada nagłówek $FF FF, a za nim adres poczatkowy i końcowy. Drugi nie posiada tego nagłówka. Każdy kolejny (poza pierwszym) segment może być wyrażony na jeden z tych dwóch sposobów. Loader po napotkaniu sekwencji $FF FF musi potraktować ją jako początek nagłówka, a nie adres początkowy. Problem pojawia się w momencie, gdy rzeczywisty segment nie posiada tego nagłówka, czyli zaczyna się od adresu początkowego, którym może być właśnie $FFFF. Nie rozróżnimy tych dwóch sytuacji. Skutkiem tego rozsypie się cały proces ładowania programu - a w konsekwencji może to doprowadzić do nadpisywania pamięci w nieprzewidziany sposób. Rozwiązaniem byłoby przyjęcie założenia, że nie możemy nic załadować od adresu $FFFF, bądź też, że ładowanie od adresu $FFFF zawsze poprzedzone jest nagłówkiem $FF FF. Nic mi nie wiadomo o istnieniu takich założeń.
Komplikujesz. Jeśli sygnatura jest opcjonalna to oznacza, że może istnieć plik, w którym każdy blok ma sygnaturę. Jeśli $FF$FF oznacza sygnaturę bloku po której następuje adres początku i adres końca, to blok z adresem początku $FFFF ale bez sygnatury jest po prostu błędnie wygenerowany.
Edit: Nic mi natomiat nie wiadomo o tym, że sygnatura ma występować tylko w pierwszym bloku, a w następnym jej nie ma. Nawet w Atariki pisze, że w pierwszym jest obowiązkowa, a w kolejnych opcjonalna.
Plik taki ma strukturę blokową, tzn. składa się z jednego, bądź więcej bloków, czy też segmentów, przy czym pierwszy z nich musi zaczynać się sygnaturą w postaci słowa $FFFF. Pozostałe bloki mogą zawierać tę sygnaturę, ale nie jest to warunek konieczny - wszystkie natomiast muszą zawierać nagłówek.
Edit 2: usystematyzowanie pojęć
no wlasnie jesli chcemy ladowac od $ffff to musi byc poprzedzony sygnaturka i nie ma problemu ale skad wiadomo ze sygnaturka jest opcjonalna?
---
sprawdzilem MADS nie generuje sygnaturki przed blokiem ladowanym pod $ffff
Nic mi natomiat nie wiadomo o tym, że sygnatura ma występować tylko w pierwszym bloku, a w następnym jej nie ma. Nawet w Atariki pisze, że w pierwszym jest obowiązkowa, a w kolejnych opcjonalna.
Jeśli odnosisz się do mojej wypowiedzi, to z niej nie wynikało, że sygnatura ($FF FF) może występować tylko w pierwszym segmencie - wręcz przeciwnie. Pisałem o tym, że istnieją dwa różne sposoby wyrażania segmentu poza pierwszym segmentem. W pierwszym segmencie sygnatura jest obowiązkowa, w pozostałych opcjonalna.
sprawdzilem MADS nie generuje sygnaturki przed blokiem ladowanym pod $ffff
To Mads ma problem.
EDIT: @mono. Skoro odnosisz się do artykułu z Atariki, to w nim nie ma nic napisane o tym, że bloki ładowane od adresu $FFFF muszą być poprzedzone sygnaturą. To jedynie Nasze założenie powodujące, że taki plik zostałby prawidłowo załadowany.
Jeśli odnosisz się do mojej wypowiedzi, to z niej nie wynikało, że sygnatura ($FF FF) może występować tylko w pierwszym segmencie - wręcz przeciwnie.
Nie odnoszę się - przypadkowe podobieństwo niezamierzone :)
To jedynie Nasze założenie powodujące, że taki plik zostałby prawidłowo załadowany.
Racja.
male pytanie - po kiego w ogole ta akademicka dyskusja na temat ladowania czegokolwiek pod adres $ffff ? jesli ma to pokazac wyzszosc xbiosa nad czymkolwiek innym - troche w zla strone offtopic sie zrobil ;)
lekki offtop byc moze da odpowiedz skad wiadomo ze kolejne bloki w pliku binarnym nie musza miec sygnaturki w naglowku.
czy dos jest w stanie stworzyc taki plik? chyba nie, dos stworzy/polaczyc pliki binarne tak ze zawsze bedzie sygnaturka wiec skad pomysl ze nie musi byc sygnaturki? moze ktos podejrzal loadera w dosie i zauwazyl ze wynika to z jego uproszczonej budowy i mozliwy jest taki myk. ciekawe tez czy ktorys ze starszych kompilatorow gdy atari jeszcze zylo nie generuje sygnaturki w naglowku np Assembler Editor, MAC/65 lub Kyan Pascal ... ?
nagłówek $FFFF jest tylko na początku pliku, aby można było stwierdzić czy to jest plik wykonywalny AtariDOS, kolejne bloki nie muszą ich posiadać ponieważ UWAGA !!! pliki AtariDOS-a nie dysponują innymi blokami niż $FF $FF
SDX posiada bloki inne niż $FF $FF i dla plików SDX są generowane nagłówki
jeśli XXL uważasz że zapisywanie nadmiarowej informacji jest niezbędna będziesz musiał spędzić mnóstwo czasu nad poprawianiem tysięcy plików wygenerowanych od początku historii Atari-DOS
jeśli ktoś łączył pliki Atari-DOS przy pomocy jakiegoś APPEND-era to faktycznie nadmiarowe $FF $FF mogą się pojawić, dlatego loader plików DOS-a powinien uwzględniać taką sytuację
ktoś tu chce odkryć Amerykę po raz miliard sześćsetny ?
> nagłówek $FFFF jest tylko na początku pliku, aby można było stwierdzić czy to jest plik wykonywalny AtariDOS
e tam. raczej zeby stwierdzic czy jest to plik binarny dosa. moze zawierac same dane.
> jeśli XXL uważasz że zapisywanie nadmiarowej informacji jest niezbędna
jest niezbedna (zeby stworzyc prawidlowy plik binarny dosa) jesli naglowek wskazuje $ffff jako load adres
Z faktu, że plik będzie się zaczynał od sekwencji $FF FF nie możesz wyciągnąć wniosku, że to plik binarny dosa. Może to również być zwykły plik z danymi.
ogólnie sprawa sprowadza się do tego jedynego przypadku kiedy loader pomyli się, bo zinterpretuje adres nowego bloku $FFFF jako nagłówek bloku, przez co pominie dwa bajty
org $2000
nop
org $FFFF
clc
FF FF 00 20 00 20 EA FF FF FF FF 18żaden inny adres oprócz $FFFF nie spowoduje tego zamieszania
p.s.
QA, Xasm zapiszą w/w przykład tak samo
no ale kto normalny chcialby ladowac blok danych od adresu $ffff?
te dywagacje serio prowadza do jakiegos konkretnego celu?
> sprawdzilem MADS nie generuje sygnaturki przed blokiem ladowanym pod $ffff
odszczekuje. MADS generuje sygnature $ffff przed blokiem ladowanym pod $ffff czyli wszystko gra
---
no jak to? :-) po kilku kilobajtach tekstu doszlismy do wniosku (mam nadzieje - hi Pecus) ze prawidlowo zbudowany plik binarny moze zawierac w naglowku adres ladowania pod rom :D
Ale nikt nie mówił, że nie może. W większości loaderów pod $ffff nic się nie załaduje.
Przeanalizowałem kiedyś kilka i wszystkie działały tak:
- pobierz 2 bajty z pliku
- jeśli oba to $ff skok na początek
- jeśli nie potraktuj je jako adres początkowy bloku
- pobierz 2 bajty i potraktuj je jako adres końcowy
- wczytaj blok
- skocz na początek
czyli pod $ffff nic się nie da wczytać
> W większości loaderów pod $ffff nic się nie załaduje.
no to wiekszosc loaderow ma problem, oczywiscie pod xBiosem bez problemu sie zaladuje.
> Przeanalizowałem kiedyś kilka i wszystkie działały tak:
> ...
> czyli pod $ffff nic się nie da wczytać
zeby dojsc do takiego wniosku trzebaby przeanalizowac nie ten algorytm tylko w jaki sposob jest porownywany adres ladowania z adresem konca czyli musisz zaglebic sie w podpunkty:
- wczytaj blok
- skocz na początek
receptura na to zeby te "inne" loadery tez mogly ladowac pod $ffff jest np. taka:
ldy load_adr_lo
lda load_adr_hi
cpy end_adr_lo
sbc end_adr_hi
bcc ladujemy_dalej_URAAaa wniosek: pod $ffff (uwaga odkrycie - to do spamerow) mozna zaladowac jeden bajt :-)
Raczej:
ldy end_adr_lo
lda end_adr_hi
cpy load_adr_lo
sbc load_adr_hi
bcs ladujemy_dalej_URAAaaSkrót myślowy zrobiłem. Większość loaderów załaduje dane pod adres $ffff (np. blok dwubajtowy pod adres $fffe) , ale żaden nie załaduje bloku którego adresem startowym jest $ffff.
> ale żaden nie załaduje bloku którego adresem startowym jest $ffff
xBios moze zaladowac 1 bajt gdy adresem startowym jest $FFFF
NOTE/POINT dodane, POINT moze sie przydac NOTE jak ktos lubi (nie kosztowalo miejsca w pamieci wiec dodalem)
POINT ustawia wskaznik czytania z pliku na bajt ktorego adres jest w rejestrze A,X,Y
NOTE czyta wskaznik, oddaje adres w A,X,Y
przyklad uzycia:
ldy <file_name
ldx >file_name
jsr xBIOS_OPEN_FILE
ldy #$80
ldx #$03
lda #0
jsr xBIOS_POINT
jsr xBIOS_GET_BYTEw akumulatorze znajdzie sie bajt o indeksie $000380 od poczatku pliku.
umknielo mi wczesniej a to moze miec dla niektorych znaczenie:
xBIOS_OPEN_FILE - otwiera plik do odczytu/zapisu (wymiany) mozna jednoczesnie czytac i pisac do/z pliku.
xBIOS_SET_LENGTH - jesli uzywamy to wystarczy raz ustawic, nie trzeba inicjowac po kazdym READ/WRITE
W pierwszym poscie dodana biblioteka dla stacji pojedynczej gestosci - dyskietki SD wielkosc sektora 128b
a tu testowo (run_file) xBIOS dla SIO2SD i filesystemu FAT
szybkosc transmisji 68k, biblioteka moze uruchamiac dowolny program zapisany na karcie SD pod nazwa xautorun. prosze pamietac ze biblioteka ma dostep tylko do katalogu z ktorego zostala uruchomiona :-)
Hmm, muszę to sobie potestować :)
No zaraz, ale żeby uruchomić xbios to trzeba go najpierw wczytać, czyli skorzystać z loadera zawartego w sio2sd, tak? Jaka jest przewaga xbios nad loaderem z sio2sd? Sorki, nie zgłębiałem całego wątku i pewnie stąd moje głupie pytanie.
pytanie nie jest glupie. odpowiem krotko (pelna odpowiedz jest tu: http://xxl.atari.pl/?page_id=718 ) xBios pozwala uruchomionej grze czytac i zapisywac dane/ uruchamiac inne programy itp. zaden inicjalizer tego nie umozliwia. jesli gra bedzie korzystac z funkcji xBios bedzie mogla czytac/zapisywac dane na dowolne urzadzenie dla ktorego jest xBios w tym wypadku na karcie SD w FAT. sprobuj zapisac lub wczytac cos pod dosem w FAT ;-) nie bez znaczenia jest tez ile pamieci udostepnia xBios...
obsluguje fat, czy vfat, czy moze fat32?
pewnie zmieniajac procedure obslugi odczyt/zapis sektora mozna od reki uzyc side miast sio2sd...
xBios wykorzystuje cechy urzadzenia - w tym przypadku: FAT12, FAT16 i FAT32, dlugosc nazwy do 39 znakow wielkosc pojedynczego pliku do 16MB
Strony Poprzednia 1 2 3 4 5 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » xBios - biblioteka IO dla gier ktore lubia przestrzen
Wygenerowano w 0.056 sekund, wykonano 40 zapytań