1,126

za naglowkiem mamy:

.byte    c'XAUTORUN   '

.byte   >xBIOS
.byte   >SECTOR_BUFFER
.word   INITAD
.word   RUNAD

.word   AOSV
.word   xSIOV

.byte   nag_PORTB
.byte   nag_NMIEN
.byte   nag_IRQEN

nazwe pliku autostart i glowne parametry. dla relokacji adres biblioteki, bufor, wektory init i run, nastepnie jest adres procedur I/O pierwsza to systemowa, druga xBiosowa.

a pozniej wartosci zapisane na czas relokacji, mozna dowolnie skonfigurowac xB pod swoj projekt. nic nie stoi na przeszkodzie, aby umiescic xB w pamieci pod rom lub w np. w MapRAM.

dojdzie prawdopodobnie jeszcze jedna zmiana. bufor sektora bedzie najprawdopodobniej wyrownywany do konca strony a nie jej poczatku - taka nowa wytyczna...

obecnie xB w stosunku do ostatniej wersji skrocil sie o 250 bajtow (ciagle jednak brakuje zalaczonego relokatora)

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

1,127

dokonalo sie.

z relokatorem binariow calosc jest krotsza tylko o 16 bajtow. zrobilo sie tez miejsce na jakas nowa funkcje. zyczenia?

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

1,128

projekt będzie miał do osiągnięcia jakiś cel czy to niekończąca się opowieść ?

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

1,129

mysle, ze cel zostal osiagniety przy wersji ktora teraz bede publikowal.

doprowadzam do stanu w ktorym kazdy bedzie mogl bez mojej ingerencji skonfigurowac xB pod swoj projekt, lacznie z relokacja czy usunieciem z binarki "menu" czy usunieciem sterownika systemowego dla maksymalnego skrocenia biblioteki.

bede tez musial dodac to, czego na poczatku dodawac nie chcialem czyli dwie funkcje:
PUT_SECTOR
GET_SECTOR

opublikuje tez pelna liste zmiennych, co zostalo dodane, wyjasnienie bajtow konfiguracyjnych.

mysle, ze ustosunkowalem sie juz do wszystkich uwag.

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

1,130

nareszcie, oddaj Xbios-a i zajmij się czymś nowym

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

1,131

SimCity... ech, rozmarzyłem się... :P

Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

Terry Pratchett - Równoumagicznienie

1,132 Ostatnio edytowany przez xxl (2014-04-10 23:20:14)

wersja testowa.

zmiany:
- jesli urzadzenie obsluguje US to zmienna xHSPEED przechowuje HSIndex w przeciwnym wypadku $ff (poprzednio $00)
- bufor sektora wyrownywany do konca strony (poprzednio poczatku strony)
zmiany dotyczace standardowych ustawien:
- xB uruchamia sie z systemowym modulem I/O, domyslnym jest modul xSIOV (xBiosowy).

nowosci:
- nowa funkcja xBIOS_READ_SECTOR (i alias do xBIOS_PUT_SECTOR)
- naglowek konfiguracyjny:
- mozliwosc zmiany nazwy pliku do automatycznego uruchomienia
- mozliwosc zmiany adresu biblioteki
- mozliwosc zmiany adresu bufora
- mozliwosc zmiany adresow wektorow INIT i RUN
- mozliwosc wskazania modulu I/O
- mozliwosc nadania wartosci PORTB,NMIEN,IRQEN podczas ladowania pierwszego pliku
- relokator binariow,
- mozliwosc podzielenia/usuniecia z biblioteki "MENU" i sterownika systemowego


wersja testowa ma nastepujacy naglowek:

.byte    c'XAUTORUN   '  ; nazwa pliku automatycznego startu
.byte   >$0800     ; adres biblioteki xB - dowolny adres
.byte   >$0700     ; adres bufora - dowolny
.word   INITAD  ; zmiana adresu inicjacji
.word   RUNAD   ; zmiana adresu uruchomienia
.word   AOSV    ; adres sterownika OS
.word   AOSV_RELOC ; procedura relokacji zmiennych dla sterownika systemowego (xBUFFERH,xDAUX2,xDAUX1)
.word   xSIOV   ; informacyjnie adres sterownika xB
.byte   $ff     ; PORTB nie bierze pod uwage BASICA
.byte   $40     ; NMIEN
.byte   $c0     ; IRQEN

co oznacza ze bez problemu mozemy umiescic bilioteke i bufor pod rom juz w momencie uruchomienia. na starcie biblioteka kompilowana jest pod $2000 po czym przed ladowaniem pliku jest relokowana na wskazane przez usera miejsce,

Post's attachments

beta3.atr 90.02 kb, liczba pobrań: 3 (od 2014-04-11) 

Tylko zalogowani mogą pobierać załączniki.
http://atari.pl/hsc/ad.php?i=1.

1,133

kilka poprawek (w konfiguracji)

http://atari.pl/beta3.atr

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

1,134

myslalem, ze dosc...

jak pobrac pelny wpis w katalogu ze statusem, iloscia zajetych sektorow przez plik itd?

w petli pobierac kolejne wpisy funkcja xBIOS_LIST_DIR

ale jak pobrac jeden szukany?

nowa funkcja:


ldy <fname
ldx >fname
jsr xBIOS_FIND

standardowo C=1 wpis nieznaleziony

w rejestrze X index do wpisu z nazwa, statusem i cala reszta.
 
mialo nie byc takiej funkcji... i moze jej nie bedzie, poki co testowo.

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

1,135

ta sama osoba.
- doprecyzowane xBIOS_LIST_DIR, teraz w rejestrze A oddawany jest bajt statusowy wpisu w katalogu dysku.
przykladowo jesli chcemy wiedziec czy funkcja oddala nazwe pliku czy katalogu wykonujemy and #$10 (0 = plik)
- zmienna przechowujaca wielkosc sektora (srednio potrzebne wedlug mnie)
- doprecyzwane xBIOS_FIND, mozna indeksowac pliki na nosniku bez funkcji xBIOS_OPEN_FILE - nie trzeba "otwierac" pliku (dziala wielokrotnie szybciej)

po co:

mozemy na raz "otworzyc" wszystkie interesujace nas pliki na dysku, pliki te moga znajdowac sie w roznych katalogach.
dostep do takiego zindeksowanego pliku jest natychmiastowy, nie trzeba zmieniac katalogu (w razie potrzeby) i otwierac plkiku - co wiazaloby sie z przeszukaniem katalogu.

owszem, caly czas 1KB.


http://atari.pl/beta3.atr

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

1,136 Ostatnio edytowany przez xxl (2014-05-05 09:13:04)

powrocil temat ograniczen plikow binarnych.

spotkal sie ktos z plikiem binarnym, w ktorym adres poczatku danych jest wiekszy od adresu konca danych?

czy jakikolwiek dos moze tworzyc takie pliki binarne i czy moglby je teoretycznie zaladowac?

----

sprawdzalem

MyDOS
- tworzy takie pliki prawidlowo, tworzy rowniez pliki binarne z adresem ladowania $FFFF
- nie laduje stworzonych przez siebie plikow binarnych. w zaleznosci od adresu ladowania bledy: 130 i 180
DOS 2.0D
- tworzy prawidlowo rowniez z adresem ladowania $FFFF
- laduje prawidlowo z wylaczeniem tego gdzie adresem ladowania bylo $FFFF
DOS 2.5
- nie tworzy
- laduje prawidlowo z wylaczeniem plikow z adresem ladownaia $FFFF

kilka innych ktore sprawadzalem nie tworza i nie laduja takich plikow, niektore przy probie ladowania zawieszaja komputer.

PC-narzady nie rozpoznaja takich plikow jako "pliki binarne"

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

1,137

szkoda, ze tak pozno dolaczyl ze swoimi uwagami...

nowa zmienna xSEGMENT ktora przechowuje ilosc danych do przetworzenia w segmencie.

funkcja xBIOS_GET_FILE_OFFSET oddaje polozenie wpliku uwzgledniajace naglowki itd. natomiast xSEGMENT zlicza same dane w obecnym segmencie pliku (bez naglowka), swietny sposob na tworzenie np. licznikow ladowania

dodatkowo obsluga plikow binarnych w ktorych adres ladowania jest wyzszy od adresu konca danych

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

1,138

przyklad uzycia xSEGMENT i xBIOS_GET_FILE_OFFSET oraz naglowka konfiguracyjnego.

przyklad pokazuje relokacje xB np. pod ROM i ladowanie z memlo $0200

przykladowy plik wyglada tak:

                org     DMACTL
                .byte   $00
                org     NMIV
                .word   MyNMI
                org     DLISTL
                .word   DisplayList
                org     CHBASE
                .byte   >Fonts

        org $0200
               
    :$7000    .byte $ff


http://www.youtube.com/watch?v=dNOsrXpOrL0

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

1,139

padlo pytanie o indeksowanie plikow i danych w pliku w xBiosie.
 
indeksowac mozemy pliki na dysku. mozemy na raz "otworzyc" wszystkie interesujace nas pliki. pozytek jest taki, ze "otwarcie pliku zindeksowanego" nie wiaze sie z przeszukiwaniem katalogu, plik otwierany jest natychmiast bez wzgledu na to w jakim katalogu sie znajduje.. mozemy to zrobic za pomoca funkcji xBIOS_OPEN_FILE i przechowac uchwyt do pliku ze zmiennych xDAUX2 (xBIOS+$3fd), xDAUX1 (xBIOS+$3fe). w dowolnym momncie mozemy otworzyc ten plik funkcja xBIOS_OPEN_DEFAULT_FILE zapisujac uchwyt do zmiennej xFILE xBIOS+$3ee. funkcje OPEN_FILE mozna zastapic xBIOS_FIND_FILE i pobrac uchwyt bezposrednio z bufora (oszczedzi czasu)

indeksowanie danych w pliku. gdy mamy polaczone dane w jeden duzy plik i chcemy miec do nich natychmiastowy dostep mozemy zrobic tak: otwieramy plik, przesuwamy sie do interesujacego nas punktu gdzie rozpoczynaja sie dane (to nie musi byc poczatek bloku w pliku binarnym) po czym pobieramy uchwyt ze zmiennych xDAUX2 i xDAUX1 oraz offset ze zmiennej xBUFFERO.  jesli w ktoryms momencie dzialania programu chcemy miec dostep do tych danych wykonujemy xBIOS_OPEN_DEFAULT_FILE i zapisujemy ofset do xBUFFERO. ta operacja jest natychmiastowa - nie ma przeszukiwania katalogu albo odczytu pliku od poczatku. mozna z takich indeksowanych punktow w pliku wykonywac takze Binary_load uwzgledniajac naglowki pliku binarnego... gdyby ktos chcial :-)
 
generalnie indeksowanie plikow lub danych w pliku wiaze sie z jednorazowym odczytaniem calego pliku, pozniej dostep do dowolnego miejsca w pliku jest natychmiastowy (zapis 3 bajtow uchwytu), pozniej juz nie ma operacji otwierania pliku lub przeszukiwania katalogu.
indeksowanie w xB jest odporne na relokacje bufora, biblioteki czy zmiane gestosci dyskietki...

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

1,140 Ostatnio edytowany przez xxl (2014-05-20 21:22:56)

wobec wrogiej propagandy dotyczacej nowej wersji xBios Komitet Standaryzacji poprosil dzial R&D o przedstawienie oficjalnego stanowiska.

szpetna plotka numer 1: xB spowalnia transmisje.

Odpowiedz: standardowo przy wykorzystaniu biblioteki xB ograniczeniem szybkosci I/O sa mozliwosci samego urzadzenia. standardowo xB dziala na wszystkich urzadzeniach widzianych przez system operacyjny z szybkoscia na ktora system operacyjny pozwala. prawda jest, ze programista dzieki bibliotece moze dedytkowac swoj produkt konkretnej rodzinie urzadzen, ma rowniez mozliwosc blokowania dzialenie swojego programu przy probie wspolpracy z wybranymi urzadzeniami.


klamstwo numer 2: pod xB nie mozna otworzyc jednoczesnie kilku plikow.

Odpowiedz: nie ma ograniczen w ilosci otwartych jednoczesnie plikow pod xB, jedyna granica jest pamiec komputera. trzeba pamietac ze przykladowo 30 jednoczesnie otwartych plikow w trybie fast moze zabrac 8kb ramu, w trybie slow 200 jednoczesnie otwartych plikow zabierze 1kb


bzdura 3: xB nie moze korzystac z pamieci RAM pod ROM bez buforowania.

Odpowiedz: w pamiecia RAM pod ROM moze znajdowac sie zarowno biblioteka (wbudowany relokator) jak i bufor I/O takze relokowalny, transfer danych mozna rowniez przeprowadzic bez udzialu bufora I/O.


forumowy celebryta: xB jest zle napisany.

stanowisko komisji: taki z niego koder jak z koziej dupy traba.


---
dokumentacja sie tworzy, na zyczenie funkja SET_PARAMS zostala rozdzielona na dwie: xBIOS_SET_RUNAD i xBIOS_SET_INIAD, dodatkowo uscislone zostalo jednoczesne otwieranie wielu plikow.

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

1,141

xxl napisał/a:

taki z niego koder jak z koziej dupy traba.

Czyli jest szkotem i gra na dupach... dudach :P

Sikor umarł...

1,142 Ostatnio edytowany przez Pecus (2014-05-21 09:21:03)

Pecus napisał/a:

Po prostu w efekcie końcowym albo powstanie kolejny DOS obsługujący w zależności od wersji różny 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 (wg Ciebie) znosi niektóre ograniczenia DOSa ale (wg mnie) nakłada na programistę inne ograniczenia, których nie ma DOS.

Zacytowałem sam siebie z pierwszej strony :) - tam się sprzeciwiałeś, a jesteś coraz bliżej DOSa niezgodnego na poziomie API ze wszystkimi innymi istniejącymi na Atari DOSami, działającego tylko na konkretnych konfiguracjach sprzętowych i filesystemie (w zależności od biblioteki) i wcale nie tak małego jak był na początku (vide otwarcie wielu plików na raz).
Może jeszcze nie na 46 stronie, ale koło 80 przyznasz mi rację :P

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

1,143

> jesteś coraz bliżej DOSa

xB roznie byl nazywany, ale DOSem nigdy nie bedzie. zalozenia na ktorych budowane byly DOSy na atari uwazam za bledne. biblioteka pokazuje ze zupelnie inne podejscie do operacji na plikach moze byc skuteczne, szybsze, krotsze i bezproblemowe.


> działającego tylko na konkretnych konfiguracjach sprzętowych

plotka. xB w standarowej konfiguracji dziala na kazdej konfiguracji sprzetowej. programista ma pelna kontrole nad obslugiwanymi urzadzeniami - jesli program uzywajacy biblioteki nie dziala na konkretnym sprzecie to znaczy ze programista sobie tego nie zyczyl.


> w zależności od biblioteki

plotka. jest tylko jedna wersja biblioteki. programista ma kontrole nad wielkoscia pliku biblioteki i jej umiejscowieniem w pamieci. dodatkowo dostepne sa tez przykladowe sterowniki dla roznego rodzaju kartow... gdyby ktos chcial karta ze swoja gra :-)


> i wcale nie tak małego jak był na początku

plotka. w zalozeniach biblioteka zajmowala 1KB, na poczatku przy 5 funkcjach zajmowala 1KB, dzis przy 25 podstawowych funkcjach nadal zajmuje 1KB


> vide otwarcie wielu plików na raz

kilka osob wplywa na ksztal biblioteki, indeksowanie danych czy otwarcie wielu plikow na raz stalo sie potrzebne i zostalo udostepnione, bez ograniczen - tu rowniez widac przewage biblioteki nad DOS.


> Może jeszcze nie na 46 stronie, ale koło 80 przyznasz mi rację

mozeliwe, ale nie w tej kwestii.

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

1,144

kolejne nieosiagalne pod DOS slodkosci:

przyklad obrazuje jak moze wygladac dostep do danych poindeksowanych (jedna z metod). dane z level 1,2,3 znajduja sie w jednym pliku, dane z level 4, 5, 6 znajduja sie w osobnych plikach.

na co warto zwrocic uwage to:
a/ brak operacji otwarcia pliku przy dostepie do danych,
b/ dane traktowane jak osobny plik (np. mozna wykonac binary load, offset zachowuje sie jakby to byl osobny plik itd.)

demonstrowana metoda i tak jest najwolniejsza z mozliwych :-) do indeksowania zamiast open mozna uzyc find, zamiast jednego bufora mozna pod xB przydzielic ich... nieograniczona ilosc dla kazdego pliku/danych swoj wlasny ;-)

Post's attachments

test.atr 90.02 kb, liczba pobrań: 6 (od 2014-06-02) 

Tylko zalogowani mogą pobierać załączniki.
http://atari.pl/hsc/ad.php?i=1.

1,145 Ostatnio edytowany przez mono (2014-06-02 20:03:11)

Fajne, fajne.
1. Jak zorganizowane są pliki na dyskietce? Czy żeby poprawnie działało xBIOS_GET_FILE_OFFSET/xBIOS_SET_FILE_OFFSET plik powinien być zapisany w kolejnych sektorach czy też może być rozsiany po całym dysku (korzystasz z linków na końcu sektorów czy nie)?
2. Co robi zmiana katalogu bieżącego xBIOS_CHANGE_DIR? I pochodne - jak otwierasz plik? Czy przeszukujesz kolejne wpisy (64 lub 128 pozycji katalogu (jak wiadomo katalog w ATARIDOS zajmuje zawsze 8 kolejnych sektorów) i czytasz kolejne sektory katalogu)?
3. Na czym polega indeksowanie plików? Czy po prostu wyszukujesz odpowiedni plik w katalogu i ja (jako programista) mogę sobie wtedy zachować jego pozycję dzięki czemu mogę w dowolnej chwili czytać dowolny sektor i resztę pliku (i korzystać z xBIOS_SET_FILE_OFFSET)?
4. Jak wygląda zmiana xBIOS_SET_FILE_OFFSET np. z $1000 na $0 - czy potrzebujesz odczytać z katalogu gdzie jest początek pliku i przeliczyć pozycję (lub przelecieć się po sektorach i przeczytać wszystkie linki aż do chwili kiedy znajdziesz odpowiedni sektor pliku)?
Fajny pomysł z tym indeksowaniem - zaciekawiło mnie jak to działa i jakie założenia przy budowie dyskietki z .atr poczyniłeś.

Edit: A uchwyty! Przepraszam - uciekło mi trochę postów w wątku i przypadkiem zobaczyłem. Ale nadal ciekawi mnie zmiana offsetów i zakładana organizacja pliku na dysku.

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

1,146

1. rodzina ataridos/mydos/bibodos/topdos itd. sektory pliku moga byc rozsiane po nosniku, korzystam z linkow w sektorze,

2. xBIOS_CHANGE_DIR pozwala na zmiane katalogu biezacego (oraz zainicjowanie wskaznika biezacej pozycji w katalogu), podobne - xBIOS_OPEN_CURRENT_DIR, xBIOS_OPEN_DEFAULT_DIR. katalog biezacy jest jasny natomiast katalog domyslny to ten z ktorego uruchomiony zostal Twoj program. Twoj program ma dostep tylko do katalogu domyslnego i jego podkatalogow. xBIOS_LIST_DIR pobiera kolejny wpis w katalogu. otwarcie pliku - kilka metod... najprostsza xBIOS_OPEN_FILE (z przeszukaniem katalog obecnego).

3. indeksowanie. jeden z przykladow z plikiem: otwieram plik i przechowuje do niego uchwyt (2 bajty z xDAUX1/2, mozna tez trzeci z xBUFFERO jesli dane sa tylko czescia pliku, mozemy tez przydzielic plikowi osobny bufor) teraz jesli kiedykolwiek bedziemy chcieli dostac sie do danych z tego pliku zapisujemy uchyt do zmiennej xFILE i wykonujemy xBIOS_OPEN_DEFAULT_FILE (od teraz ta czesc pliku traktowana jest jak osobny plik).

4. jesli zmieniamy offset z wiekszej na mniejsza nie trzeba odczytywac katalogu, nalezy wykonac xBIOS_OPEN_DEFAULT_FILE - plik zaladowany przez xB automatycznie staje sie pierwszym zindeksowanym plikiem. jesli uzywamy xBIOS_SET_FILE_OFFSET to xB "przeleci sie po sektorach" pliku az znajdzie odpowiednia pozycje - dlatego powstalo indeksowanie :-)

5. nie ma zadnych zmian w organizacji plikow na dysku. na dysku moga znajdowac sie pliki zakladane roznymi dosami (rozne linkowanie) czy 64/128 plikow.

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

1,147 Ostatnio edytowany przez xxl (2014-06-06 08:26:09)

urozmaicenie 1:
przyklad jak odtwarzac muzyke podczas ladowania:

xBIOS                           equ $0800
xIRQEN                          equ xBIOS+$3e8
xBIOS_SET_DEFAULT_DEVICE        equ xBIOS+$2A
DLP_PLAYER_ZPG_VARS             equ $e0
DLP_PLAYER_ADDRESS              equ $78d4       ; do 7c80
DLP_ADDRESS                     equ $7000
;AUDCTL_SUPPORT                 equ 1
;XBIOS_AUDCTL_SUPPORT           equ 1
DLP_INIT                        equ DLP_PLAYER_ADDRESS+$80
DLP_PLAY                        equ DLP_PLAYER_ADDRESS+$83

                icl 'atarihw.ah'

                opt h-                  ; bez identyfikatora FFFF   (*1)
                org [a(start,start+(stop-start)-1)],$0c00
start
                sei
                lda #0
                sta nmien
                sta irqen
                sta dmactl
                sta xIRQEN
                lda #$fe
                sta portb                       ; ROM OFF (*2)
                jmp xBIOS_SET_DEFAULT_DEVICE
stop
                opt h+
                ini start

                org $7000
                ins 'dciomusic.dat'

                org $0000               ; prosto na strone zero (*3)

IONMI           sta zpa
                stx zpx
                sty zpy
                jsr DLP_PLAY
                lda #0
zpa     equ *-1                
                ldx #0
zpx     equ *-1                
                ldy #0
zpy     equ *-1                
                rti

playmusic
                lda <IONMI
                sta $fffa
                lda >IONMI
                sta $fffb
                jsr DLP_INIT
                lda #$40
                sta nmien
                rts
                ini playmusic

                org $c000       ; do RAMU pod ROM (*4)
      :$1000    .byte $ff

                org $d800       ; (*4)             
      :$2700    .byte $ff

koniec          lda random
                sta colbak
                jmp koniec

                run koniec

ciekawostki:
*1 - plik nie ma identyfikatora pliku binarnego dzieki temu tylko xB bedzie mogl to zaladowac, dos wyswietli blad.
*2 - ladowanie programu z wylaczonym ROMem
*3 - ladowanie programu bezposrednio na strone zerowa
*4 - ladowanie bezposrednio do ramu pod rom

Post's attachments

test.atr 90.02 kb, liczba pobrań: 2 (od 2014-06-06) 

Tylko zalogowani mogą pobierać załączniki.
http://atari.pl/hsc/ad.php?i=1.

1,148 Ostatnio edytowany przez mono (2014-06-06 09:02:26)

xxl napisał/a:

*1 - plik nie ma identyfikatora pliku binarnego dzieki temu tylko xB bedzie mogl to zaladowac, dos wyswietli blad.

A może w ogóle zrobiłbyś dla plików xBIOSowych osobny nagłówek identyfikujący. Dzięki temu można by łatwo je identyfikować i ładować, albo i nie.
O ile wiem obecnie zajęte są:
$FFFF (ATARI)
$FFFE (Sparta)
$FFFD (Sparta)
$FFFC (Sparta)
$FFFB (Sparta)
$FFFA (Sparta)
$FFF0 (ACX)
$DDFF (BasicXE)
$FBFB (AlfAssembler)
Może coś w rodzaju $4278 :)?

Edit: Czy DOSy (i user) identyfikują sobie tylko po rozszerzeniu (powiedzmy .XB)?

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

1,149

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

zastanawiam sie komu by sie chcialo sprawdzac pliki po identyfikatorze w pierwszym naglowku i na tej podstawie decydowac :D wychodzi mi ze nikomu. jesli usuniesz identyfikator to otrzymasz efekt o ktorym piszesz - tylko xB bedzie mogl to zaladowac.

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

1,150

Komu? Odpowiedź jest przecież oczywista - loader w SpartaDOS X :)

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