1,151

xxl napisał/a:

niema czegos takiego jak pliki xbiosowe. to sa zwykle pliki binarne. nawet nie musisz korzystac z funkcji xB...

Owszem jest, bo można napisać nawet nieświadomie binarkę tak, że odpali tylko z xBios. Wystarczy ulokować ją bez większego sensu a np. od $0800 choćby i było to 1kB kodu i używało kilku kilo gdzieś tam ;)

Pytanie tylko po co tak robić?

Tylko po to by ograniczyć środowisko uruchamiania programu.

Kontakt: pin@usdk.pl

1,152

> Owszem jest, bo można napisać nawet nieświadomie binarkę

nieswiadomie binarki pisza tylko konsumenci DOSa...
chcesz powiedziec, ze wszystkie pliki z ktorymi nie rodzi sobie Twoj DOS automatycznie staja sie plikami xbiosowymi?

to wina Tuska!


@mono: nic nie trzeba robic przeciez, ten DOS, jak i inne DOSy, zachowa sie podobnie - rozlozy rece.

http://atari.pl/hsc/ad.php?i=1.

1,153 Ostatnio edytowany przez mono (2014-06-07 14:14:49)

No wiesz. Zafundowanie użytkownikowi zwisu komputera nie jest takie fajne, a jak posługujesz się zwykłym nagłówkiem ATARI DOS, to trzeba rozbudowywać loader, żeby przypadkiem się zabezpieczyć np. przed ładowaniem w obszar nie przeznaczony dla usera (co robi np ATARI DOS 2.5). Kiedy masz sygnaturę wtedy wszystko jest jasne i proste - rozpoznajemy i uruchamiamy (jak umiemy), lub nie (jak nie umiemy). Masz tam zresztą swoje metody do zmiany adresów INI/RUN i oidp kiedyś mogły też być inne nagłówki bloków (ale może źle pamiętam). I parę innych fajnych możliwości, których nie dają znane DOSy.

Edit:

xxl napisał/a:

nic nie trzeba robic przeciez, ten DOS, jak i inne DOSy, zachowa sie podobnie - rozlozy rece

No owszem owszem, ale niech to zrobi w sposób cywilizowany a nie przez zwis.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

1,154

> Zafundowanie użytkownikowi zwisu komputera nie jest takie fajne ...

no ale piszesz co powinien robic DOS. zaladuj sobie przykladowo jakims DOSem gry fileowe... zwis. czy ktos przejmowal sie ograniczeniami dosa? ja mam sie przejmowac ;-)

> Kiedy masz sygnaturę wtedy wszystko jest jasne i proste - rozpoznajemy i uruchamiamy (jak umiemy), lub nie (jak nie umiemy).

no wlasnie, usuwajac $FFFF z pierwszego naglowka pliku (jak zademonstrowalem) nie zaladujesz DOSem bo dos nie umie i szafa gra.

> No owszem owszem, ale niech to zrobi w sposób cywilizowany a nie przez zwis.

bez identyfikatora FFFF, DOS wyswietli komunikat bledu, nie przejdzie do ladowania.

http://atari.pl/hsc/ad.php?i=1.

1,155

Ależ przejdzie. Wystarczy, że na początku pliku znajdą się rozkazy:

isb $??FF,x ;$FFFF
inc $??FF,x ;$FFFE
dcp $??FF,x ;$FFFD
dcp $??FF ;$FFFC
lax $??FF,y ;$FFFB
lax $??FF ;$FFFA
aso $??FF ;$FFF0
isb $??DD,x ;$DDFF
lax $??FB,y ;$FBFB

Choć to prawie same niepubliczne, to zawsze chętny do oszukania DOSa wyprowadzi go w maliny.
Sam mógłbyś (podejrzewam, że z przewrotną przyjemnością :D) tak zacząć pierwszy blok programu, żeby DOS poszedł się kochać - choćby tym INCem. Stąd właśnie moja propozycja o zdefiniowanie nagłówka. Mniej mi chodzi o to żeby DOS zadziałał poprawnie, ale żeby użytkownik nie musiał restartować komputera przy próbie uruchomienia programu, którego w danym środowisku nie będzie mógł poprawnie odpalić. Mając identyfikator nawet głupi DOS może załadować Twojego xBIOSa i zrobić to, czego żąda od niego user.
Jeśli się nie da, to trudno - zawsze pozostanie rozszerzenie pliku.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

1,156

Po głębszym zastanowieniu jednak przyznaję Ci rację - wystarczy analizować czy nie próbujesz ulokować bloku w niedozwolonym miejscu i się zbuntować. W mocy jednak pozostaje argument o ładowaniu xBIOSa przez DOS celem odpalenia programu.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

1,157

> Ależ przejdzie. Wystarczy, że na początku pliku znajdą się rozkazy:

nie przejdzie. kazdy blok pliku binarnego ma naglowek. w naglowku jest poczatek ladowania i koniec ladowani, przed pierwszym naglowkiem jest identyfikator. dos nie zaladuje pliku bez identyfikatora przed pierwszym naglowkiem. jakiekolwiek rozkazy na poczatku bloku nie maja tu zadnego znaczenia.

a rozmnazanie identyfikatorow to bardzo zly pomysl... temat rzeka :-)

http://atari.pl/hsc/ad.php?i=1.

1,158

aktualizacja informacji o xB na http://xxl.atari.pl/?p=1076

oraz aktualizacja nazw funkcji zgodnie z sugestiami...

xBIOS_OPEN_DEFAULT_DIR
xBIOS_OPEN_CURRENT_DIR
xBIOS_OPEN_DIR
xBIOS_GET_ENTRY
xBIOS_RENAME_ENTRY
xBIOS_FIND_ENTRY
xBIOS_OPEN_DEFAULT_FILE
xBIOS_LOAD_FILE
xBIOS_OPEN_FILE
xBIOS_LOAD_BINARY_FILE
xBIOS_SET_LENGTH
xBIOS_SET_FILE_OFFSET
xBIOS_LOAD_DATA
xBIOS_WRITE_DATA
xBIOS_GET_BYTE
xBIOS_PUT_BYTE
xBIOS_READ_SECTOR
xBIOS_FLUSH_BUFFER
xBIOS_SET_INIAD
xBIOS_SET_RUNAD
xBIOS_SET_DEFAULT_DEVICE
xBIOS_SET_DEVICE
xBIOS_RELOCATE_BUFFER

dodatkowo ID urzadzenia z ktorego xB zostal uruchomiony jest teraz przechowywany w zmiennej dostepnej dla programisty.

http://atari.pl/hsc/ad.php?i=1.

1,159

no i jest.

http://atari.pl/xb3test.atr

komu nie dziala?

http://atari.pl/hsc/ad.php?i=1.

1,160

kilka przykladow:

http://atariage.com/forums/topic/227057-xbios-tutorial/

http://atari.pl/hsc/ad.php?i=1.

1,161

co sie stanie jesli interesujace nas programy wykorzystujace xB przekopiujemy do ramdysku i stamtad uruchomimy xB?


a to sie stanie:

http://youtu.be/L2SHG_4PeyI

http://atari.pl/hsc/ad.php?i=1.

1,162

pytanie tylko, jaki to sens ma ;)

najbardziej not user friendly player do sidów, całkiem na miarę XiX wieku ;)

Kontakt: pin@usdk.pl

1,163

SID PLAYER? hejtuj w odpowiednim watku.

sprawa dotyczy xBios i jego kolejnych mozliwosci :-) chyba Grzybson chcial miec mozliwosc odpalania produkcji wykorzystujacych xB z ramdysku. przechowuje program w jakims pamieciozernym filesystemie, na czas zabawy przekopiowuje pliki do ramdyku i odpala xBiosa - tak to sobie wykombinowal.

oczywiscie w wersji xB v3 programista zawsze ma mozliwosc zablokowania takich kombinacji :)

http://atari.pl/hsc/ad.php?i=1.

1,164 Ostatnio edytowany przez mono (2014-07-14 10:52:14)

A xB nie mógłby samodzielnie przenosić plików do ramdysku kiedy się wybierze taką opcję z loadera? Główny program użytkownika mógłby wtedy korzystać już tylko z docelowego sterownika (dla ramdysku).

Edit: Choć w sumie mógłby to robić program użytkownika, bo zawsze wtedy może pokazać coś fajnego na ekranie i zagrać muzykę.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

1,165

idea jest taka, zeby xB uruchomic w gotowym srodowisku. programista moze miec kaprys i przykladowo taki Pin bedzie mial wrazenie ze jakas gra dziala mu z jego dosa gdy w rzeczywistosci bedzie to xB ;)

poza tym inny programista zarzyczyl sobie mozliwosc definiowania wielkosci ramdysku lezacego w bankach o wybranych numerach.

porozmawiam z Wiedzacymi, zoptymalizuje i zrodlo zostanie udostepnione podobnie jak zrodlo AOSV.

http://atari.pl/hsc/ad.php?i=1.

1,166

xxl napisał/a:

i przykladowo taki Pin bedzie mial wrazenie ze jakas gra dziala mu z jego dosa gdy w rzeczywistosci bedzie to xB ;)


to by mi nie przeszkadzało powiedzmy ;) - niech się tylko uruchomi jakkolwiek już.

Kontakt: pin@usdk.pl

1,167

wkrotce bedzie aktualizacja. dwie sprawy:
- jest cos w relokatorze co moze sprawiac klopot zaawansowanym userom, warto to poprawic
- kod zostal skrocony w dwoch obszarach: zezwolenie na uruchamianie xB z urzadzen ktore nie odpowiadaja np. na STATUS oraz xB bedzie wstepnie skonfigurowany juz w momencie uruchomienia.

zaoszczedzonego miejsca bedzie tyle, ze moznaby wbudowac obsluge ramdysku. pytanie: trzymac sie obecnej wielkosci i dodac nowa funkcjonalnosc czy lepiej skrocic plik bo i tak obsluge ramdysku mozna dodac odpowiednim wpisem w naglowku i dodaniem bloku obslugi ramdysku. po co wyreczac progrmiste, jak bedzie chcial ramdysk to sobie doda sam (zrodlo bedzie dostepne).

http://atari.pl/hsc/ad.php?i=1.

1,168

xxl napisał/a:

pytanie: trzymac sie obecnej wielkosci i dodac nowa funkcjonalnosc czy lepiej skrocic plik bo i tak obsluge ramdysku mozna dodac odpowiednim wpisem w naglowku i dodaniem bloku obslugi ramdysku

Sugeruję drugie rozwiązanie. Nie ma sensu płacić za coś, czego się nie wykorzystuje.

1,169

ten ramdysk, to finalnie wykryje dostępne banki, czy bazuje na tym, że coś jest i jest to 130XE?

Kontakt: pin@usdk.pl

1,170

zdefiniuj "dostepne banki"

http://atari.pl/hsc/ad.php?i=1.

1,171

xB po aktualizacji do sciagniecia:

http://xxl.atari.pl/?p=1076

http://atari.pl/hsc/ad.php?i=1.

1,172

Mam pytanie. Na stronie z xBiosem jest taka informacja: "Jeśli podczas uruchomienia biblioteki przytrzymamy klawisz OPTION, ładowanie pliku domyślnego zostanie pominięte".
Czy to oznacza, że mając w Atari QMEG-a plik domyślny standardowo nie zostanie odczytany i żeby go odczytać to trzeba naciskać Option? QMEG odwraca działanie klawisza Option przy odłączaniu Basica. Czy ma to znaczenie przy pracy z xB?

1,173

Jeśli podczas uruchomienia biblioteki przytrzymamy klawisz OPTION to niezaleznie od tego czy mamy QMEGa ładowanie pliku domyślnego zostanie pominięte.
Plik domyslny standardowo jest zawsze uruchaminy, jesli go nie ma lub jesli trzymamy OPTION przy starcie xB to uruchomione zostanie MENU.

http://atari.pl/hsc/ad.php?i=1.

1,174

No dobrze, ale mając Qmega trzymanie Option spowoduje włączenie Basica. Co jeśli nie chcemy Basica?
I odwrotnie - nie mając Qmega - trzymanie Option wyłączy Basic. Co jeśli akurat chcemy mieć Basic?
Sorki za głupie pytania, ale jakoś tak mi to do głowy przyszło :)

1,175

AtariOS oraz QMEG wlaczaja/wylaczaja BASIC podczas "zimnego startu". xB nie siedzi w ROM, trzeba go zaladowac, sprawdza OPTION po zaladowaniu.

przykladowo:
jesli nie chcesz BASICA i masz AtariOS to wlaczasz komputer z wcisnietym klawiszem OPTION...

http://atari.pl/hsc/ad.php?i=1.