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 … 47 48 49 50 51 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
AtariDOS FS nie moze pracowac z takimi parametrami, wiec musisz poruszac sie poza FS
xBios daje taka mozliwosc, standardowy modul I/O xB (xSIOV) moze przeprowadzic komunikacje z urzadzeniami, ktorych bufor sektora ma dowolna wielkosci (w praktyce nie wiecej jak 50 KB - to jest parametr konfiguracyjny)
no wiec spokojnie, Atari da rade :-)
Odpowiedz w 100% mnie satysfakcjonuje. :)
wiec musisz poruszac sie poza FS
lub pod Sparta FS. Tam bez problemu obsługiwane są sektory 512, czy też klastry złożone z większej ilości takich sektorów. Dodatkowo obsługa nie jest związana ze sprzętem, więc dowolny hardware obsługujący takie rozwiązanie zadziała.
to prawda AtariDOS FS lub SpartaDOS FS sa tu tyle samo - nic nie warte - nie obsluguja 'sektorow' dynamicznej wielkosci.
zreszta ... za komunikacje ze sprzetem odpowiedzialna jest zupelnie inna warstwa, obsluga filesystemu nie ma tu nic do rzeczy :-)
niezly trolling Pin :D
Jakby Arsantica ładowała się w US to też by była muzyczka podczas ładowania?
standard US przewiduje szeroki wachlarz mozliwych predkosci... prawidlowa odpowiedz - na niektorych urzadzeniach tak a na innych nie. dlatego jesli programista wlaczy US w xB to musi znac ograniczenia jakie moga sie pojawic przy niektorych urzadzeniach.
dostepny jest testowy xB v4 jesli ktos chce sie pobawic przedpremierowo to zapraszam.
nowa zatwierdzona funkcja:
xBIOS_SET_BUFFER_SIZE equ xBIOS+$48
A możesz z przykładami o tych ograniczeniach?
Myślę że wszyscy dwaj użytkownicy xbios z niecierpliwoscią czekaja na nowe funkcje :)
> A możesz z przykładami o tych ograniczeniach?
ograniczenia czasowe. przykladowo jesli chcesz zaprogramowac jakis efekt ktory bedzie wyswietlany podczas ladowania i do tego wymusisz koniecznosc uzycia urzdzenia SIO to przy standardowej predkosci masz sporo czasu - nawet co dwie linie obrazu mozesz wlaczyc DLI (jesli uzyjesz systemowej procedyry musisz liczc sie z tym, ze czasem NMI sie 'zgubi') jesli uzyjesz wewnetrznych procek xB to przerwania beda stabilne. teraz, chcesz dodatkowo wlaczyc US - zmienna podpowiada Ci ze urzadzenie moze dzialac z szybkoscia 126674 bitow na sekunde ... przy 1,7 mhz cpu niestety jesli wlaczysz DLI to pojawia sie bledy transmisji.
a jeśli DLI nie będzie używać STA WSYNC ? to też będą błędy transmisji?
I jak DLI zrobi CLI ?
wydaje mi sie, ze przy transmisji 126kbit czyli bajt jest zglaszany na szynie co ok. 140 cykli jakiekolwiek DLI moze byc problemem
Dokonalo sie... calkowite zaskoczenie, konsternacja, degeneroscena w szoku. pojawil sie nowy xBIOS 4
zachowane dotychczasowe funkcje oraz nowosci:
1. dotychczasowy problem atarowcow - pod zadnym systemem (bez wymiany ROM) nie mozliwe bylo ladowanie zadnych plikow .xex oraz tych z obrazow .atr, ktore ladowaly dane pod ROM - rozwiazany, teraz juz nie musisz wymieniac ROM aby korzystac z Bluetooth, nowy xB umozliwia ladowanie .xex (i .atr) wprost z urzadzen mobilnych. oczywicie programy korzystajace z funkcji xB maja dostep do danych na urzadzeniu poprzez Bluetooth.
2. calkowicie nowy modul I/O, dynamiczna dlugosc bufora, nowe mozliwosci komunikacji protokolem UDP, obsluga nowych (niezdefinowanych komend).
3. funkcja zmiany gestosci do obslugi AtariDOS FS i pochodnych,
4. nowa funkcjonalnosc menu - zmiana urzadzen - shift + 1-F
5. BOOT dla uzytkownikow Bluetooth (must have na kazdym telefonie :D)
ile zajmuje? tak, caly czas 1 kilobajt
uwazaj! dyskutujac, uzywajac albo nawet tylko myslac o nowym xB mozesz zostac automatycznie posadzony przez administracje o prowadzenie krucjaty... wlasciwie nie wiadomo przeciwko czemu lub komu; badz czujny.
Sorki, ale od jakiegoś czasu nie śledziłem postępów xB. Mógłbyś wyjaśnić bardziej łopatologicznie punkt 1?
Bo z tego co wiem, to jedynym urządzeniem wykorzystującym Bluetooth jest SIO2BT. Widziałem je na ostatnich Głuchołazach i rozmawiałem z autorem. Z tego co zrozumiałem, zmiana systemu aby korzystać z tego urządzenia, nie była konieczna, aby ładować pliki pod ROM, tylko wynikała z faktu, że BT ma zbyt luźne timingi jak na ostre wymagania Atari.
Jeśli więc mówimy o współpracy z tym urządzeniem, to nawet jeśli xB umożliwia załadowanie XEX'a przez BT na standardowym systemie, to jak najpierw załadować xB? :)
bardzo dobre pytanie.
-bez zmodyfikowanego OS nie da sie zaladowac .xex
-pliki w .atr mozna pod warunkiem ze zabootujesz ze specjalnie przygotowanego .atr oraz ladowany plik nie bedzie zapisywal pod rom (to przy ataridos)
-ze sparta x wogole sie nie da (trzeba zmodyfikowac OS)
atari po BT zaladuje tylko jeden sektor - pozniej sie wywala. cala sztuczka polega na tym, aby odpowiednio ten jeden sektor przygotowac. odpowiedz na Twoje pytanie jest w pukcie 5. jest boot ktory laduje xB
Następne demo uruchomi się wyłącznie ze SIo2BT ;)
I po co to trolollo?
Sugestia do XXL: czy można dołożyć obsługę TOS FS....gdy do tego na Rapidusie zrobi się emulację 68000 to wtedy...olalla jaka przyszłość sie rysuje...
Ostatnio edytowany przez BartoszP (2014-12-20 09:48:21)
Bo z tego co wiem, to jedynym urządzeniem wykorzystującym Bluetooth jest SIO2BT.
Zgadza sie.
Z tego co zrozumiałem, zmiana systemu aby korzystać z tego urządzenia, nie była konieczna, aby ładować pliki pod ROM, tylko wynikała z faktu, że BT ma zbyt luźne timingi jak na ostre wymagania Atari.
Zgadza sie.
Jesli masz Ultimate 1MB lub jakikolwiek "OS Switch" i uzywasz zmodyfikowanego OS-a, to wszystko (ATR, XEX) dziala bez problemow (i nowy xBios nie jest konieczny).
Jesli masz ATARI z oryginalnym OS i chcialbys uzywac SIO2BT, potrzebny jest loader, ktory laduje gry uzywajac zmodyfikowanych procedur SIO.
Taki loader (ATR z jednym sektorem danych) jest w paczce z plikami projektu SIO2BT:
https://drive.google.com/file/d/0B3-191 … FBsRW1iRUE
Loader:
- kopiuje OS ROM do RAMu
- modyfikuje procedure SIO
- laduje gre z dysku D2
A jak zaladowac loader? Calkiem normalnie (uzywajac oryginalnych procedur SIO).
To co napisal xxl, ze z oryginalnym OS "atari po BT zaladuje tylko jeden sektor - pozniej sie wywala" nie do konca sie zgadza. Ze wzgledu na niedotrzymany timing, ATARI wysyla wielokrotnie kazdy rozkaz SIO (taki jest "error handling" procedur SIO - nie udalo sie, to jeszcze raz). Kiedy przychodzi odpowiedz ze smartfona, ATARI moze wlasnie jej oczekiwac (wtedy komunikacja sie udaje) lub moze wlasnie ponownie wysylac rozkaz SIO (w tym przypadku odpowiedz ze smartfona jest ignorowana). Jak sie nie uda, to jest powtorzenie i w koncu sie udaje.
Mozna wiec odczytac w ten sposob nawet cala gre, jesli ktos jest cierpliwy. Jeden z uzytkownikow SIO2BT, ktory nie przeczytal instrukcji, zglosil sie do mnie z problemem, ze bardzo dlugo laduja mu sie gry. Okazalo sie, ze mial oryginalny OS i nie uzywal loader-a. Pomimo to ladowal z oryginalnym OS-em gry. Trwalo to (ze wzgledu na problemy z komunikacja) dwa razy dluzej, ale udawalo sie.
Im wiec krotszy loader, tym lepiej. Mi udalo sie prosty loader zmiescic w jednym sektorze danych (zeby otrzymac jeden sektor danych, ATARI musi wyslac az 2 rozkazy (GetStatus i GetSector) i otrzymac 2 odpowiedzi).
Problem z moim loaderem jest taki, ze daje sie nim zaladowac okolo 70% gier (XEX, ATR).
Ale jesli gra np. wykorzystuje pamiec RAM pod OS-em, to nie da rady.
Tutaj pojawia sie nowy xBios.
ATR z loaderem podpinamy pod D1 (zamiast mojego 1-sektorowego loadera).
Gry (XEX lub ATR zawierajacy XEX-y) podpinamy np. pod D2 i gotowe.
Jeśli więc mówimy o współpracy z tym urządzeniem, to nawet jeśli xB umożliwia załadowanie XEX'a przez BT na standardowym systemie, to jak najpierw załadować xB? :)
ATARI uzywajac standardowych procedur SIO laduje pierwszy sektor ATR z xBios-em i uruchamia zaladowany kod.
Ten rowniez kopiuje ROM do RAMu i modyfikuje procedure OS, ale robi to tylko po to, zeby sprawnie zaladowac samego xBios-a.
xBios posiada wlasne procedury SIO (dzialajace rowniez z SIO2BT) i pozwala na ladowanie gier, ktorych nie dalo sie zaladowac moim malym loaderem.
Podsumowujac: Pojawila sie nowa (lepsza) mozliwosc ladowania gier przez Bluetooth dla ATARI z oryginalnym OS :)
Ostatnio edytowany przez Montezuma (2014-12-20 10:12:00)
Sugestia do XXL: czy można dołożyć obsługę TOS FS....gdy do tego na Rapidusie zrobi się emulację 68000 to wtedy...olalla jaka przyszłość sie rysuje...
68000. Hm.
To nie byłoby prościej i taniej, jakby zwolennicy rapidusa przesiedli się od razu na Amigę 500?
Eee to znaczy na Atari 1650XLD?
@BartoszP, nie, xBIOS jest biblioteka I/O dla malego atari; nie wspieram rozwiazan ktore wymagaja deformowania sprzetu.
Ale wyobraź sobie ten lans na możliwość bezpośredniego kopiowania danych dysk XL/XE <-> dysk ST. Tylko przekładamy dysk albo kartę CF pomiedzy sprzętami i.... voila. Rapidus i ewentualna emulacja nie ma tu nic do rzeczy.
Ostatnio edytowany przez BartoszP (2014-12-20 15:09:00)
ze sparta x wogole sie nie da (trzeba zmodyfikowac OS)
SDX mieści się w cartridge więc można by rozważyć implementację odpowiedniej zmiany (drac030 lub trub musieliby się wypowiedzieć) i wtedy nie trzeba byłoby ładować loadera skądkolwiek a komunikacja szła by bezproblemowo. To jest zaleta DOSa umieszczonego w ROMie :)
Edit: A właśnie - co to jest możliwość komunikacji protokołem UDP? Myślimy o sieciowym UDP?
Ostatnio edytowany przez mono (2014-12-20 16:45:59)
Ale wyobraź sobie ten lans na możliwość bezpośredniego kopiowania danych dysk XL/XE <-> dysk ST
Da się bez problemu, na razie jednak w jedną stronę (jeszcze ;) ).
Strony Poprzednia 1 … 47 48 49 50 51 … 71 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.213 sekund, wykonano 7 zapytań ]