Myślałem, że "coś więcej" to chodzi o kod ;)

Select przełącza pomiędzy dwoma trybami pracy: "SIO" i "OS". W skrócie, to jeżeli program działa w trybie "OS" to odpali z twardziela i odpali też w trybie "SIO". Jeśli jednak program działa w trybie "SIO" a np. zapisuje coś bezpośrednio do ram pod rom to w trybie "OS" nie zadziała. Tak jakoś to wygląda z czego mi się kojarzy.

Po naciśnięciu SELECT i tak się nie załaduje to, co zostało kiepsko zakodowane ;)

XXL - po prostu wydaje mi się, iż programy pisane pod xBios mogłyby w zasadzie zadziałać w każdych warunkach. To nie jest wada tego rozwiązania, to by była zaleta. Zmuszanie koderów do lenistwa niczemu nie służy.

Bo byś się posrał jak byś za każdym razem czekał ze swoim SIO na załadowanie 40kB danych :P

Bo na pytania odpowiadasz wybiórczo :P

Nie nudzę, tylko grzecznie piszę co na ten temat sądzę. Miker, z drugiej strony nikt nie każe Ci tego czytać :)

i teraz ... ojojojoj....

Oto ograniczenia wg XXL:

http://www.atari.org.pl/forum/viewtopic ... 14#p167114

Bo jeśli autor programu będzie myślał tak, jak autor xBiosa to sukces mamy gwarantowany :P

Załadują się tylko z xBios, bo są do niego przywiązane. To samo można zrobić z HDD i z czego wiem to jest znacznie więcej czasu na takie ficzery choćby i dlatego, że pokey nie zajmuje się obsługą transmisji w sensie portu SIO.

Bzdurnym założeniem moim zdaniem było umożliwienie dostępu do opcji innej, niż po naciśnięciu /select/ ;)

Kończy? - tu bym obstawiał opcję /może jest w połowie/ ;) ... no i zależnie od sposobu działania, będzie to albo nieużyteczna ciekawostka, albo użyteczne gui.

Bo ten "normalny" user nie wie, że można się nie męczyć a Atari to nie ZX-Spectrum :D

Są, bo TBXL nie działa do końca poprawnie na modyfikowanym o szybkie FP osie, a szkoda - bo jeśli korzysta z procedur systemowych to mógłby niektóre obliczenia przeprowadzić znacznie szybciej:

Tu jest opis FP i FastCHIP:

http://atariki.krap.pl/index.php/Pakiet_matematyczny

Takich spraw nie wytłumaczę autorowi /xBios - biblioteka IO dla gier które lubią przestrzeń/, ponieważ nie jestem koderem. "ograniczenie OS" to ulubione określenie XXL'a, wiec pozwoliłem je sobie tu przytoczyć ;)

Przepraszam, że kotleta odgrzałem.

Czyli jak rozumiem, to z całą pewnością nie ma opcji zpaczowania tego FP, lub TBXL by mogło to razem współpracować? Bo jak by nie ten problem, to wrzucił bym to do Atarki.

Z racji na chwilę wolnego czasu popełniłem mały (duży - ale o tym dalej) programik. Co robi :)

... w zasadzie nic. Odpalamy Sparta Commander, ustawiamy kursor na pliku z fontami (*.FNT) return - no i mamy podgląd fonta. Po naciśnięciu klawisza następuje powrót do SC.

Jest tylko jeden problem, że po wyjściu z programu do SC wszystko działa do czasu naciśnięcia resetu. Następuje wówczas mniej, lub bardziej spektakularny krasz. W trybie VBXE trafiło nawet w karte na tyle skutecznie, że koniecznością stało się wyłączenie Atarki i ponowne włączenie ;)- taki grubszy reset :D.

A ten mały programik jest dlatego niemały, że powstał w wyniku eksperymentów w TBXL z linią poleceń sdx. Działa oczywiście poprzez runext, lub poprzez podanie parametru z linii poleceń.

Draco - podeślę w tym tygodniu źródło tego problemu, jak będziesz miał chwilkę to zobacz co zchrzaniłem.