Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Fabryka - 8bit » xBios - biblioteka IO dla gier ktore lubia przestrzen
Strony Poprzednia 1 … 36 37 38 39 40 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
no dobrze, to mam pytania odnosnie US:
1. stacja moze odebrac komende w turbo a dane w normalu? lub odwrotnie, komenda normal, dane turbo.
2. czy jakakolwiek stacja po komendzie w normalu moze "poprosic" o dane w turbo?
3. czy przelaczenie stacji na turbo nastepuje po odpowiedzi na HighSpeedIndex czy odpowiedz ma znaczenie tylko informacyjna.
4. na ktorej predkosci stacja nasluchuje: US czy normal - chodzi o to z ktora predkoscia wysylka komendy na 100% bedzie musiala byc powtarzana.
1. nie, wszystko leci w takiej predkosci jaka sie wynegocjowalo. Chyba ze masz na mysli sytuacje gdy komputer po nadaniu komendy przelaczy sie na inna predkosc, wtedy jest to mozliwe bo tak wlasnie dziala rozpoznawanie predkosci w US.
2. jakakolwiek US nie ma takiej mozliwosci bo nie ma zadnych 'komend' które miały by to sygnalizować .
3. informacyjne, stacja nie powinna sie przlaczyc, tylko zaserwowac HSIndex w predkosci w jakiej akurat sie znajduje. to komputer powinien zaczac nadawac w odpytanej predkosci i dopiero stacja metoda prob i bledow przelacza sie na turbo.
4. na takiej w jakim trybie akurat sie znajduje. po wlaczeniu z racji kompatybilnosci z twoim ulubionym stock OS jest to normal.
ps: wiekszosc osob ktore mogly by ci pomoc jeszcze bardziej skutecznie zniecheciles swego czasu:) (trub, pecus) wiec tyle ode mnie w tym temacie rowniez, mam nadzieje ze dobrze to spisalem z pamieci.
2. a czy w jakimkolwiek systemie turbo po wyslaniu rozkazu (dowolnego) stacja zamiast ACK ("A") moze odpowiedziec np. "H" - tym samym dac sygnal ze moze pracowac w hispeed ?
3. dotyczy jednego urzadzenia - stacja ma zdefiniowane dwie predkosci std i turbo czy moze pracowac w kilku szybkosciach turbo?
Ad.3. Tygrys: std, Synchromesh 38k, US 52k, Turbo/Top 68k, ale to chyba nie o to Ci chodziło.
XFD601/602, o których zapomniałem mają też te tryby, tylko nie wiem którą prędkość Synchromesha, bo tego w Atariki nie ma (pewnie 38k). Ale prędkość US 68k/80k jest wybierana na sztywno, a nie dynamicznie jak rozumiem.
Nie wiem jakie zestawy mają dokładnie TOMS Multi i 710/720.
Do tego nie wiem jak działają Speedy 1050 i IS Plate. Czy różne prędkości US są możliwe?
Tu faktycznie jakiś większy spec by się przydał.
Ale jak Acid napisał przy okazji najnowszego firmware do SIO2SD nikt nie wie dokładnie teraz jak działały te wszystkie rozszerzenia.
Zapytaj na AtariAge też, może np. sup8dct albo Hias odpowiedzą coś więcej.
A tak w ogóle, to kod Hi Speed w AtariSIO Hiasa Ci nie wystarczy do zaadoptowania do xBiosa?
Chociaż jak uzyskamy odpowiedzi na powyższe pytania to będziemy wszyscy mądrzejsi.
sama obsluga turbo Hiasa zajmuje prawie tyle co caly xbios. tak czy owak lektura jest bardzo pouczajaca. jesli ktos ma wymieniony rom na ten Hiasa to w menu xbios klawiszem select moze wybrac procedury turbo Hiasa...
ja nie mam ambicji obslugiwac wszystkie mozliwe rodzaje systemow turbo, moge dodac system UltraSpeed i to tylko dlatego ze nie zwiekszy to wielkosci biblioteki no i jest najlepszy ;-). widze ze wystarczy pobrac HSIndex i nie dawac mozliwosci recznego wyboru szybkosci.
Lemiel, dolozylec cegielke.
SimDrive Simiusa potrafi obsługiwać 3 rodzaje turbo i nie jest to jakiś strasznie wielki kawał kodu.
Oczywiście to kod robiący z Atari stację dysków.
dodanie kolejnego turbo nie jest problemem, pewnie z 10 bajtow wiecej ;-) co o tym mysle napisalem tu: http://www.atari.org.pl/forum/viewtopic … 18#p176118 :D szkoda na to miejsca. US w xB to bedzie wlasciwie tylko bajer, niby wiecej mozliwosci niz przy zwyklym US ale i tak caly czas ograniczona uzytecznosc z powodu obciazenia cpu transmisja...
do naszych laboratoriow przekazalismy uwagi uzytkownikow. dwadziesci trzy minuty pozniej otrzymalismy projekt hojnego w nowe funkcje xBIOS 2.0, oczywiscie przy nieograniczonym budzecie naszych programistow mozna byc pewnym ze biblioteka bedzie zajmowala dokladnie tyle samo: 1kb
nowe funkcje menu dostepne userowi (programista nie bedzie mial wplywu na te ustawienia):
- mozliwosc wlaczenia UltraSpeed,
- standardowo AtariDOS umozliwia zapis 64 plikow w jednym katalogu, mozliwosc zezwolenie na obsluge katalogu z 128 wpisami (niektore DOSy obsuguja)
zmiany/rozszerzenia zmiennych dla programistow:
- udostepnienie zmiennej xBUFFERH (starszy bajt adresu bufora)
dla ekspertow, jesli zaistnieje potrzeba tworzenia niestandardowych formatow, zabezpieczen, kopiowania lub tworzenia plikow
- udostepnienie zmiennych xAUDCTL, xIRQEN, xSECTORL, xSECTORH
zmiany/rozszerzenia funkcji dla programistow:
- w katalogu plik i podkatalog moga miec te same nazwy
- dodanie funkcji:
xBIOS_RENAME_DIR
xBIOS_OPEN_DIR
xBIOS_LIST_DIR
xBIOS_HOME_DIR
xBIOS_OPEN_HOME_FILE
- oddzielenie funkcji xBIOS_DEFAULT_DEVICE od xBIOS_SET_DEVICE
- modyfikacja dzialania funkcji xBIOS_CHANGE_DIR
- zastapienie funkcji zmiany parametrow trzema nowymi:
xBIOS_RELOC_BUFFER
xBIOS_RELOC_RUNAD
xBIOS_RELOC_INITAD
nie jestem przekonany czy mozliwosc nadawania tych samych nazw dla plikowow i katalogow jest dobra...
jesli ktos ma uwagi co do nazw zmiennych lub funkcji to slucham.
- standardowo AtariDOS umozliwia zapis 64 plikow w jednym katalogu, mozliwosc zezwolenie na obsluge katalogu z 128 wpisami (niektore DOSy obsuguja)
Czy mógłbym prosić o informacje, które? I ewentualnie przykładowe atry (celem rozszerzenia atari8fs o obsługę)...
np. BiboDOS. DOSy pod dane katalogu uzywaja 128 bajtow z sektora, jesli sektor ma 256 bajtow to polowa jest pusta.
8 sektorow na katalog w sektorze 8 wpisow (1 wpis 16 bajtow) = 64 pliki
wiec jesli mamy sektor 256 to mozna miec 8 x 16 = 128 plikow w jednym katalogu. w BiboDOS o ile dobrze pamietam trzeba formatowac dyskietke w "gestosci" Q.
xBIOS_OPEN_DIR
Czy to jest nowa nazwa dla f. zmieniającej katalog? Jeśli tak, to jest ona nietrafna. W powszechnej konwencji nazywamy taką akcję zmianą bieżącego katalogu, ustawieniem katalogu.
xBIOS_HOME_DIR
Złamana konwencja nazewnicza. Dotychczas wszystkie posiadały takową: xBIOS_[czasownik]_[podmiot]. Proponuję powrót do intuicyjnej formy: xBIOS_SET_HOME_DIR / xBIOS_SET_DEFAULT_DIR.
nie jestem przekonany czy mozliwosc nadawania tych samych nazw dla plikowow i katalogow jest dobra...
Jeśli jakiś DOS udostępnia taką f. to ma to sens. W takiej sytuacji kluczem identyfikującym element systemu plików byłaby para nazwa + typ.
xBIOS_OPEN_DIR sluzy do wskazania katalogu na ktorym ma dzialac funkcje dotyczaca katalogu np. xBIOS_LIST_DIR. do zmiany katalogu sluzy funkcja xBIOS_CHANGE_DIR.
xBIOS_HOME_DIR - ta funkcja nie sluzy do ustawiania katalogu domyslnego tylko do powrotu do katalogu domyslnego. katalog domyslny to ten z ktorego zostal uruchomiony program - nie koniecznie katalog glowny dysku. program uruchomiony xbiosem ma dostep tylko do swojego katalogu (home) i do podkatalogow w tym katalogu - wyzej nie wyjdzie.
no wlasnie nazwa + typ moze identyfikowac z czym mamy do czynienia ale dosy chyba tego nie robia :/ nie wiem czy rozszerzac mozliwosci czy zachowac ograniczenia dosow.
xBIOS_HOME_DIR - ta funkcja nie sluzy do ustawiania katalogu domyslnego tylko do powrotu do katalogu domyslnego.
Zatem xBIOS_CHANGE_DIR_TO_DEFAULT.
no wlasnie nazwa + typ moze identyfikowac z czym mamy do czynienia ale dosy chyba tego nie robia :/ nie wiem czy rozszerzac mozliwosci czy zachowac ograniczenia dosow.
Jeśli nie ma takich potrzeb, to nie warto tego realizować. Wygląda to na nadprodukcję, dodatkowo mającą niekorzystny wpływ na interfejs biblioteki.
no dobrze, sprawdzane beda tylko nazwy, bez typow, tak jak w dos. rename bedzie dzialac tez dla katalogow. zmienilem nazwy:
xBIOS_OPEN_DIR
xBIOS_LIST_DIR
xBIOS_CHANGE_DIR
xBIOS_CHANGE_DIR_TO_DEFAULT
xBIOS_RENAME
xBIOS_LOAD_FILE
xBIOS_OPEN_FILE
xBIOS_OPEN_DEFAULT_FILE
xBIOS_LOAD_DATA
xBIOS_WRITE_DATA
xBIOS_GET_BYTE
xBIOS_PUT_BYTE
xBIOS_SET_LENGTH
xBIOS_FLUSH_BUFFER
xBIOS_LOAD_BINARY_FILE
xBIOS_GET_FILE_OFFSET
xBIOS_SET_FILE_OFFSET
xBIOS_RELOCATE_BUFFER
xBIOS_SET_PARAMS
xBIOS_SET_DEVICE
xBIOS_SET_DEFAULT_DEVICE
ktoras jest jeszcze niejasna/bledna?
xBIOS_RENAME
Skąd wynikła potrzeba na istnienie takiej funkcji? Do tej pory wydawało się, że intencją biblioteki jest ograniczony zakres zmian, czego wyrazem było udostępnienie f. do zapisu istniejącego już pliku. Teraz okazuje się, że istnieje zapotrzebowanie na zmiany również na poziomie struktury systemu plików. Dlaczego?
xBIOS_DEFAULT_DEVICE
Proponuję konsekwentnie xBIOS_SET_DEFAULT_DEVICE.
nazwa podmieniona.
odnosnie rename. tak, wolne "sloty" beda mogly byc nazywane (kazdy to osobny plik) przez gracza. co do zmian nazwy kataogow, np. mozliwosc umieszczenia tabeli wynikow jako spisu podkatalogu. podczas przegladania dysku zwyklaym dosem po DIR pojawi sie tabela wynikow ;-)
odnosnie rename. tak, wolne "sloty" beda mogly byc nazywane (kazdy to osobny plik) przez gracza.
Technicznie rzecz biorąc nadawanie nazw slotom nie wymaga zmiany nazwy pliku. Można zmienić zawartość pliku, jakiś jego fragment odpowiedzialny za "metadane", powiedzmy pierwszych N-bajtów.
co do zmian nazwy kataogow, np. mozliwosc umieszczenia tabeli wynikow jako spisu podkatalogu. podczas przegladania dysku zwyklaym dosem po DIR pojawi sie tabela wynikow ;-)
Czy to jest aż tak istotne, aby łamać pierwotne założenia? Można sobie wyobrazić plugin do filesystemu, który odczyta stosowne metadane z nazw plików/katalogów.
pierwotne zalozenia: minimalny rozmiar biblioteki i maksymalnie uproszczony interfejs... to jest zachowane, a dodatkowa funkcja zmiany nazwy plikow i katalogow... chyba lepiej ze sie zmiescila i jest niz mialo by jej nie byc?
tak, mozna by bylo zrobic: slot1, slot2, slot3, slot4 a w tych plikach odpowiednie zapisy. tez dobry sposob.
ktoras jest jeszcze niejasna/bledna?
Proponuję konsekwentne wyrównanie pozostałych nazw:
xBIOS_BINARY_LOAD -> xBIOS_LOAD_BINARY / xBIOS_LOAD_BINARY_FILE
xBIOS_NOTE -> xBIOS_GET_FILE_OFFSET
xBIOS_POINT ->xBIOS_SET_FILE_OFFSET
mozliwosc zezwolenie na obsluge katalogu z 128 wpisami (niektore DOSy obsuguja)
W jakiej kolejności są przydzielane te dodatkowe wpisy? Po zajęciu standardowych 64, czy kolejno (już po 8 zajętych wpisach) ?
Proszę o uzupełnienie http://atariki.krap.pl/index.php?title=Format_BiboDOS :)
ok. nazwy zmienilem, wrocila funkcja xBIOS_SET_PARAMS do ustawiania nowych adresow dla wektorow runad i initad natomiast funkcje do relokacji bufora wydzielilem
@Fox: po kolei. jedyna potrzebna modyfikacja to zmiana rozkazu "bpl" na "bcc"...
---
ktoras wersja turbo dosa tez ma katalog wielkosci 128 wpisow
Chyba niejedyna. DOSy chyba działają tak, że jak napotkają zero w pierwszym bajcie wpisu w katalogu, nie czytają następnych sektorów katalogu. Tutaj możemy mieć sytuację, że zwykły DOS nagrał nam np. 10 plików i jeśli napotykając zero w drugiej połówce pierwszego sektora katalogu zakończymy odczyt katalogu, to nie dotrzemy do pozostałych 2 plików.
tak to prawda, trzeba to przewidziec - w taki razie:
- jesli napotka na zero na pozycji 9 wpisu czyta kolejny sektor katalogu
- jesli napotka na zero konczy odczyt
Dokładniej to zrobiłbym tak, że zero w pierwszej połówce kończy katalog - w drugiej połówce nie. To załatwi przypadek, że nagrywamy najpierw standardowym DOSem, a potem dogrywamy BiboDOSem.
heh, niezly pomysl :-)
w taki razie trzeba dodac cos w rodzaju:
txa
bpl koniec_katalogu
bmi sprawdz_nastepny_sektor_katalogu
Strony Poprzednia 1 … 36 37 38 39 40 … 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.050 sekund, wykonano 32 zapytań