Nie mówmy o rzeczach, których jeszcze NIE MA, pomówmy o tym co JEST TU i TERAZ. A na chwilę obecną xBios JEST TYLKO dla AtariFS w SD/ED, więc uruchamialność plików binarnych binarnych zależnych od xBios jest ograniczona tylko do tych gęstości i filesystemów.

Tak w ogóle ta wizja rozlicznych wersji xBios dla każdej konfiguracji bardzo mi trąci marzeniem o "szklanych domach"...

EDIT:

W wątku o MazezaM powołujesz się na wyniki ankiety w tym topicu... Z góry zaznaczam, że nie pamiętam jak kiedyś zagłosowałem, ale teraz ta ankieta wydaje mi się tendencyjna - są opcje za xBios, opcja "nie mam Atari", ale nie dałeś opcji dla miłośników DOSów. Ciekawe jak w takiej konfiguracji wyglądałyby wyniki...

No pewnie, że nie załaduje. Przecież te dosy i loadery wykorzystują procedury cio, które są w rom, więc jak im je odłączysz, to nie załadują i się wykrzaczą. A że XBios z nich nie korzysta, to załaduje. Chyba, że zrobić sztuczkę, o której już wspominałem - przepisać rom do ram, wtedy możesz ładować i spod DOSa na $e477.

SapEmu nie zabangla prosto z XEX loader-a, bo musi doczytać później odczytać pliczkiz sapami, do czego potrzebny jest dos.

SapEmu ze strony epi'ego - http://epi.atari8.info/sapemu.php

Właśnie- SIO. Wokół tego cała dyskusja się m.in. kręci. Co ze standardowymi urządzeniami NEWDEVICE obsługiwanymi przez standardowy ROM Atari? Nie ma xBios dla NewDevice, trzeba sobie napisać. Natomiast standardowe procedury obsługi CIO są tak napisane, że im to lotto, czy urządzenie jest SIO czy NEW DEVICE - jednakowo obsługują oba.

Nikt nie mówi (a przynajmniej ja), że xBios to zdecydowane zuoooo. Gdy pamięci na styk, a my uparcie chcemy aby programik ruszył na stock 64kB - ok, uzycie xBios jest do przełknięcia, można uznać za uzasadnione. Ale do gier typu MazezaM gdzie zajętość pamięci jest mała? Tam były tylko trzy skoki do xBios (zmiana wektorów load i init, jeden open file, jedno load data). IMO Najważniejsze to zachować równowagę.

PS: No i przyznam, że czekam na wersje Cartridge'owe.

W kwestii Binary Load - co z komendą nr 40 cio instalowaną (chyba) przez DOSa 2.5, przez Spartę na 100%, nie wiem jak inne. Nie testowałem, ale np. w takim TurboBasicu XL komendy BLOAD i BRUN jakoś są zrobione, nie?

Pewnie czegoś nie rozumiem (jak zwykle). W Ram pod Rom-em potrafi - więc gdzie nie da rady?

Sprawdzałem na SDX 4.45, SDLoad, DOS II+/D, MyDOS4.50T (te 3 na real hardware, OS - Qmeg), DOS 2.5 z CP (na emu, AtariOS) - każdy z nich bez problemu załadował program testowy i uruchomił kod z segmentu z $c000.

Powiedziało się A to trzeba powiedzieć i B. Więc wsparcie dla HSC będzie. Tyle, że HSC jeszcze oficjalnie MazezaM nie wspiera - jak robić reverse engineering, jeśli się ie ma co reversować :)

Szybkie wyszukiwanie i wygląda na to, że w MazezaM są tylko trzy odwołania do xBios - jedno do xBIOS_SET_VECTORS, o którym mówiłem, jedno xBIOS_OPEN_FILE i xBIOS_LOAD_DATA. Na pierwszy rzut oka nie ma zapisu. Rąbka tajemnicy pewnie uchyliłby pliczek MAZEZAM.PCH, trza tylko poczekać na release....

Co do samej gry - to jasne że się podoba! Takie gierki logincze zawsze wciągają. No i ten motyw na beepera. Poza tym gdyby się nie podobała, to nie zadawałbym sobie trudu, aby ją łatać, prawda ? ;)

@Pin
MapRAM potrzebny jest tylko do STARYCH gier połatanych do współpracy z HSC. Nowe gry nie potrzebują go (EDIT: Mapramu dla jasności). Dely choćby zapowiadał, że AGFFYO będzie wspierać HSC (ale bez xBios ;) )

EDIT:

Aaaa - gra chyba wykorzystuje hiscore i tokensy, tak? Brak tokenów będę musiał ścierpieć. Ale dalsze skoki do procedur xBios wypadałoby znaleźć i zaNOPować chociaż.

Nie będzie. "Formatować" w pełnym tego słowa znaczeniu to można tylko nośniki magnetyczne.

Secon - o ile dobrze zrozumiałem to w FDISKu SIDE możesz normalnie montować ATRy (ktoś potwierdzi?) ATRa z QA znajdziesz bez problemu.