Eeeee tam ze Streetem przesadzacie. Do emulacji WiFi jest zbędne, a cała reszta w Streecie jest.
No i z dwiema dobrymi grami w sklepie nówka 449zł.
Wiem bo kupiłem i potrzeby posiadania WiFi nie zauważam.

Devil inside....
A imię jego czterdzieści i cztery :)

E tam zaraz atak. Po prostu uściślić chciałem ;).

Bo w przypadku Jet Boot Jack Twój problem rozwiązuje sama gra, uruchamia się resetem, a potem zmienia wektory. A Final Legacy "cytowałem z pamięci" i nie wiem w czym dokładnie był tam problem.

Nie pamiętam teraz tytułu (poza tym, że nakombinowałem się z loaderem, żeby ta gra się łądowała), ale nic Ci to nie pomoże, prześledź sobie w ROM procedurę resetu i tyle.
Jeśli program ustawi komórki:

$033D, $033E, $033F (zwane magicznymi ;) )
$0244 - znacznik zimnego startu
i wektory
$02,$03 lub $0C,$0D  w połączeniu z odpowiednim stanem $09

NIC nie zrobisz i koniec. Ale powinieneś to wiedzieć i mieć tego świadomość (a wygląda na to że wiesz ale nie masz świadomości :) - bo w to, że nie wiesz ja nie uwierzę).

Oczywiście, ale wiadomo jakie magiczne komórki są sprawdzane (i jakie powinny mieć wartości), znam przynajmniej kilka gier, które na starcie odtwarzają 3 magiczne bajty a potem ustawiają wektory warm startu. Najczęściej są to dumpy z Cartów.

Co więcej znam przynajmniej jedną grę (także dump z carta), która na starcie SPRAWDZA te magiczne bajty i jeśli są zmienione - nie startuje a właściwie startuje źle i po chwili się wywala.

I wtedy może sobie XXL pomazać.... ops pomarzyć oczywiście ;P

Powiedzmy sobie szczerze. XXL chce stworzyć mocno ograniczonego DOSa i jednocześnie nie nazywać go DOSem (no i w sumie racja, bo to raczej DOSik). Oczywiście znosi on kilka ograniczeń, ale jednocześnie (w stosunku do innych DOSów) nakłada ich dużo więcej.

A TOMS nie ma przypadkiem domyślnie włączonego buforowania, bo to ono powoduje przekłamanie wyników.

obie atarki bym wzial jesli aktualne jeszcze... bo mi moja padla.
ale nie bardzo mam cos ma wymiane... poza biletami NBP

Skrót myślowy zrobiłem. Większość loaderów załaduje dane pod adres $ffff (np. blok dwubajtowy pod adres $fffe) , ale żaden nie załaduje bloku którego adresem startowym jest $ffff.

A to fakt... zwracam honor i idę na zakupy po 16GB RAM do grzyba (zupełnie serio :) ).

Jesli nie mozna xBiosa umieszczac w innych obszarach to zyskalismy raptem 2 i pol strony RAM w stosunku do SDX w trybie BANKED ... co za OGROMNY zysk :P

mono: wiekszosc (jak nie wszystkie) loaderow potraktuje 6 kolejnych $ff jako 3 naglowki i bedzie oczekiwało adresu startowego po nich.

Bardzo dobry przykład tebe.
A co jeśli pod adresem $700 jest akurat xBios ???
Czy on nie zajmuje miejsca?, czy się sam relokuje szukając wolnego miejsca w pamięci?? Nie - on zajmuje - mało ale jednak, w związku z tym jeśli chcę ten kawałek pamięci użyć muszę mieć KOLEJNĄ WERSJE bibliotek, skompilowaną pod inny adres.
Czyli poza wersjami dla różnego sprzętu, powstawać będą wersję dla różnych programów - oczywiście każda z tych "podwersji" będzie musiała mieć wersje dla różnych konfiguracji sprzętowych....

Czy nie lepiej jednak trzymać się zasad przy pisaniu programów??

(tak wiem SIDy to wyjątkowa sytuacja, ale dlaczego do tej wyjątkowej sytuacji dorabiać ideologię uniwersalności rozwiązania)