Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen
Oki. Zrozumiałem. Wciskam Option, żeby wyłączyć Basic, wczytuje się xB i znów wciskam Option, żeby pominąć ładowanie pliku domyślnego. Coś dużo tego wciskania :P
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 … 46 47 48 49 50 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Oki. Zrozumiałem. Wciskam Option, żeby wyłączyć Basic, wczytuje się xB i znów wciskam Option, żeby pominąć ładowanie pliku domyślnego. Coś dużo tego wciskania :P
dlatego dobrze jest zadbac o to zeby nasza gra sama przygotowala sobie srodowisko np. wlaczyla lub wylaczyla BASIC.
rozwinieciem tej idei jest sam xB, Twoja gra moze dodatkowo wylaczyc/ustawic przerwania, wylaczyc ROM, wskazac modul komunikacji ktory Ci najbardziej odpowiada, relokowac wektory init/run czy bufor itd. xB jest elastyczny :-)
zmienna xDEVICE ujawniona!
xDEVICE equ xBIOS+$3e7 ( http://xxl.atari.pl/?p=1076 )
przyklad dzialania w nowym SlightSID Playerze ( http://xxl.atari.pl/?page_id=708 )
opcjonalne "menu" xBiosa (wyglad w zalaczniku) zostanie zastapione przez opcjonalny interfejs okienkowy.
mozna zglaszac mockupy. kto zaprojektuje interfejs ktory zostanie uzyty automatycznie zyska pozycje na tajnej liscie zasluzonych dla projektu xB :)
informacje na temat okienkowego interfejsu mozna znalezc tu: http://atarionline.pl/forum/comments.ph … e=1#Item_0
gdzie mozna zglaszac uwagi dotyczace komponentow (biblioteka okienkowa sie tworzy - mozna wplywac)
jak pisac wlasne moduly I/O do xB ?
przyklad ponizej to sterownik ramdysku. dzieki modulowej budowie xB mozna np. wymienic domyslny modul I/O np. na taki:
RAMV stx RAMCMD
lda xDAUX1
asl @
tay
lda xDAUX2
rol @
tax
cpx #volume+1
bcs _eret
tya
sec
ror @
lsr @
pha
lda #$00
ror @
pha
lda portb
sta preserve
and #%11000011
ora banks,x
sta portb
lda xBUFFERH
pha
lda #$80
pha
lda #$00
RAMCMD equ *-1
and #%10
beq @+
lda #%11
@ ldy #2
@ tax
pla
sta RAMSRC,x
pla
sta RAMSRC+1,x
txa
eor #%11
dey
bne @-
@ lda $ffff,y
RAMSRC equ *-2
sta $ffff,y
iny
bpl @-
lda #$ff
preserve equ *-1
sta portb
clc
_eret rts
volume equ $04
banks .byte %00000000
.byte %00000100
.byte %00001000
.byte %00001100
mozna obslugiwac ramdysk zakladany dosem, z katalogami itd.
ciekawy pomysl to stworzenie gry w pliku binarnym, ktory kolejnymi naglowkami zaladuje dane do pamieci dodatkowej (np. skompresowana zawartosc ramdysku stworzona np. MyDOSem) po czym wykona xBIOS_SET_DEVICE wskazujac RAMDysk jako urzadzenie domyslne. mamy wolna pamiec, ramdysk z plikami i xB do obslugi plikow w ramdysku :-)
... xB bedzie krotszy.
Jak przy naprawie magnetofonu. Za każdym razem zostaje trochę śrubek :) Jak to się dzieje xxl? Moje programy z każdymi nowymi funkcjami są zawsze coraz to dłuższe - u Ciebie odwrotnie :) Też bym tak chciał. Podziel się cholera tajemnicą.
Ten przykład z ramdyskiem jeśli dobrze zrozumiałem pozwala na dodanie nowego nośnika na poziomie podstawowym (dostęp do sektorów). Czy z fsami można zrobić to samo równie przyjemnie (wiesz o co mi chodzi :P) ?
podziele sie ale to nie jest tajemnica:
- trzymanie sie kurczowo zastanych standardow czesto hamuje rozwoj pewnych nowych idei i prowadzi do wydluzania kodu - chociazby ostatni przyklad z interfejsem Bluetooth do atari,
- wiele rzeczy mozna zrobic inaczej - krocej/szybciej - ale bez zmiany sposobu myslenia wykonanie tego jest niemozliwe
tak, modul fs tez mozna zmienic - bardzo wdzieczna czesc xB podczas optymalizacji. przykladowy (gdzies 50 stron wczesniej) modul obslugi FATa zajmowal okolo strony pamieci, AtariDOS zajmuje ponad dwie strony.
Dziękuję.
modul obslugi FATa zajmowal okolo strony pamieci
Wydaje mi się, że piszesz o obsłudze fata przez SIO2SD, nie jest to więc obsługa fata przez xBios na tej zasadzie, na której xB obsługuje Atari DOS.
xB obsłuży fata na fdd, side, lub ide+, czy czymkolwiek takim?
tak, SIO2SD wyprzedza wymienione urzadzenia na tym polu. udostepnia emulace stacji dyskow (urzadzenie $31 SIO) ale oprocz tego udostepnia takze nowe urzadzenie, ktore w lancuchu SIO zglasza sie jako $72... mozna by powiedziec nowa era urzadzenia SIO plug'n play :-)
Nowe urzadzenie obsluguje FAT a dostep do / zarzadzanie plikami na tym filesystemie z poziomu Atari zapewniony jest dzieki nowym rozkazom na protokole SIO.
wszystko co trzeba zrobic aby atari mialo dostep do plikow i katalogow na filesystemie FAT to ...w standardowy sposob obslugiwac nowe urzadzenie SIO :D
no wiec xB do obslugi FAT na nowoczesnym urzadzeniu SIO spozywa jakies 0.5% zasobow atari, ciekawe ile zasobow atari konsumuje sterownik FAT dla urzadzen ktore wymieniles.
ciekawe ile zasobow atari konsumuje sterownik FAT dla urzadzen ktore wymieniles.
z pewnością dużo i jest dość pamięciożerny. W optymalnej konfiguracji fakt faktem MemLo wyskakuje pod niecałe $2000. Różnica jest tylko taka, że sterownik ten obsługuje FAT'a na dowolnym urządzeniu podłączonym do Atari a co jest najlepsze - umożliwia wygodny i skrajnie szybki transfer danych z PC na HDD Atari. Możesz np. w kilka minut przewalić wszystkie gry z sieci na HDD.
Jest to jednak w sumie mimo wszystko ciekawe, bo fajnie by było mieć taki sterownik pod Spartę. Dzięki za pomysł! ;)
[OT]
kur... znowu zbiorowisko kolesi...
dlaczego to nie jest nigdzie udokumentowane?
co to kur... za polityka,
między nami powskimi kumplami...
"a mnie się to nie widzi..." że zacytuję poetę...
[/OT]
tzn - o co Ci chodzi, bo osobiście nie bardzo rozumiem? ;)
> z pewnością dużo i jest dość pamięciożerny. W optymalnej konfiguracji fakt faktem MemLo wyskakuje pod niecałe $2000
no wlasnie :-)
> Różnica jest tylko taka, że sterownik ten obsługuje FAT'a na dowolnym urządzeniu podłączonym do Atari
chcesz powiedziec, ze bedziesz uzywal filesystemu FAT na np. stacji 1050 ? a probowales? :D
czy Ty sie slyszysz? tym usprawiedliwiasz pamieciozernosc swojego dosa ? :D
> a co jest najlepsze - umożliwia wygodny i skrajnie szybki transfer danych z PC na HDD Atari. Możesz np. w kilka minut przewalić wszystkie gry z sieci na HDD.
zanim zabootujesz swojego dosa to ja przewale wszystkie gry z sieci na karte. przepraszam, nie wiedzialem ze ktos moze miec taki problem jak userzy dosa.
no ale tu jano widac ze pamieciozerny sterownik dla dosa byl potrzebny aby rozwiazywac nieistniejace problemy :)
> Dzięki za pomysł!
ten "pomysl" funkcjonuje juz na atari pewnie z 10 lat. dobrze, moze w koncu zainteresuja Cie prawdziwie nowoczesne rozwiazania :-)
jesteś złośliwy chyba do granic swoich możliwości ;)- jeśli tak chcesz rozmawiać, to proszę bardzo.
1. używałem fata nawet na FDD. Kopiowałem dane wprost z Atari STe używając Sparta DOS X, Karin maxi i dyskietki 3,5". Ciekawe, co na to Twój sztandarowy produkt, bo najprawdopodobniej z wysiłku zrobił by kupę ;)
2. Nie rozumiesz "problemu" transferu danych na dysk twardy, problem obecnie nie istnieje a twoja ograniczona percepcja rzeczywistości odrzuca możliwość użytkowania nowoczesnych rozwiązań ;) ... no i brniesz i rozwijasz od kilku lat projekt, gdzie z racji na spore zainteresowanie produktem sam odpisujesz na swoje własne posty o nowinkach, które jak widzę cieszą się sporym zainteresowaniem. Chyba wyłącznie z racji na okresowo występujący flejm ;)
3. Ten pomysł to uzupełnienie mało istotnej luki i służy wyłącznie temu, by się rozwijać a nie uwsteczniać, bo coś przy czym wokół tak wiele szumu robisz najczęściej rozwiązuje się na etapie zwykłego sterownika pod DOS, który siedzi w jakimś toolkicie i każdy może tego użyć i nie ma czego tutaj przeżywać. Po prostu jest częścią większej całości i działa nie stanowiąc jednej z ważniejszych cech dla której ktoś zdecydował się na użytkowanie takiego rozwiązania ;) Ukierunkowanie wprost i wyłącznie na FAT'a poprzez xBios to strzał w kolano i nikomu niepotrzebny gadżet. Działa wyłącznie na SIO2SD. Nie każdy ma sio2sd. Ja na szczęście mam ;)
nie wiem dlaczego traktujesz to jako zlosliwosc.
pytalem czy uzywales fata na atarowych flopkach a Ty mi wyjezdzasz, ze uzywales fata na urzadzeniu podlaczonym do atari poprzez interfejs newDevice (KarinMaxi) ... czujesz roznice ? ;-) ile razy to zrobiles? raz? odpowiedz sobie dlaczego. nie podpowiem bo uznasz to za zlosliwosc.
powtarzam, placisz cennymi zasobami za cos czego nigdy nie uzyjesz i to nie z racji tego ze mozesz nie miec takiego urzadzenia ale dlatego, ze byloby to skrajnie uciazliwe. promujesz niefunkcjonalne rozwiazania...
reszty punktow nie rozumiem.
ten trzeci punkt... nie wiem, usilujesz mi powiedziec, ze na jednym nosniku uzywasz roznych filesystemow i dlatego musisz miec jakas kobyle z roznymi sterownikami? chyba zle rozumiem bo to jakas bzdura, sa interfejsy ktore to zalatwiaja i nie potrzeba do tego 1/3 pamieci atari.
Ostatnio edytowany przez xxl (2014-10-20 08:54:42)
dostepna jest aktualizacja xB:
- prawidlowo dziala z SIO2BT (Bluetooth) - np. podczas I/O po BT moze grac muzyka
- poprawione dzialanie na niestandardowych ustawieniach - na niektorych urzadzeniach nie rozpoznawal gestosci w przypadku relokacji biblioteki albo zmiany ustawienia przerwan - teraz dziala prawidlowo,
ta wersja xB przeszla testy na najwiekszej ilosci roznych urzadzen jak do tej pory.
otrzymalem zgloszenie od osoby ktora warto wysluchac, miala bardzo mocne argumenty. w nowej wersji xB znajdziemy:
- funkcja do zmiany formatu (dla modulu FS)
- zmienna wielkosc bloku danych (dla modulu SIO)
- pojawi sie nowa zmienna; zmieni sie schemat zapisu (na prostszy)
- zwiekszy sie tez mozliwosc indywidualizacji xB (wazna zmiana)
dostalem solidna pomoc przy optymalizacji, na dzien dzisiejszy jest juz wykonane 3/4 modyfikacji
Mógłbym prosić o szczegóły?
szczegolow 1 i 2 nie chce podawac bo nie bede zdradzal szczegolow cudzego projektu, xB zyska spora nowa funkcjonalnosc.
zmiany w procedrach I/O dotyczace zapisu - jesli czytamy i zapisujemy do pliku to aktualizowane beda tylko te 'sektory' w ktorych wykonywany byl zapis. nawet gdy mamy otwartych jednoczesnie kilka plikow i z jednego przenosimy sie na koniec drugiego (poindeksowane) to dane nie zostana utracone.
natomiast indywidualizacja, obecnie podczas uruchamiania xB komenda Status i HiSpeedIndex realizowane sa procedura systemu operacyjnego, w przyszlosci bedzie to poprzez modul zdefiniowany przez usera.
caly czas zbieram informacje o ciekawych pomyslach ktore mozna zaimplementowac w xB.
CZyli xB będzie obsługiwał sektory 512B ?
Like it ,)
A jest szansa na dłuższe bloki niż 512?
A łazi mi po głowie pewien projekt od dłuższego czasu.
Narazie dojrzewa.
A taka funkcjonalność załatwiła by sprawę po stronie Atari :)
Strony Poprzednia 1 … 46 47 48 49 50 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.234 sekund, wykonano 10 zapytań ]