A ja widzę w najstarszej, jaką znalazłem dokumentacji 6502 w miejscach rozkazów niepublikowanych informację, że są one "zarezerwowane do przyszłego wykorzystania". Taki procesor 65816 to po prostu to przyszłe wykorzystanie. Wszystkie rozkazy 6502 mają w nim takie same opcody i takie samo działanie, a w "dziury" (które XXXL traktuje jak rozkazy) zostały wpasowane rozkazy rozszerzające możliwości 6502.
Zgodne z dokumentacją programowanie nie powoduje problemów z wykorzystaniem tych (przewidzianych przez projektantów) rozszerzeń.

Hm... co jest z tym zegarem, że mój post napisany parę minut po 16:00, jest postem napisanym godzinę później i wygląda na to że powinienem był czytać wywód wieczora, a jednak nie miałem szansy go przeczytać, bo go nie było... Nie dziwiłbym się, gdyby nie to że jego post ma dobry czas, a wydawało mi się, że wszystko jest na aa przesunięte o godzinę, więc nie interweniowałem ;)

Poza tym wszystkie te programy zadziałają od razu na dowolnym urządzeniu od standardowej stacji po SIO, przez wszystkie PBI, a w zasadzie nawet z filesystemem nie są związane i już dziś odpalą się z dyskietki w FAT na przykład.

Poza tym XXXL... ja to rozumiem,  że do poparcia głupiej tezy potrzebne są głupie argumenty... ale aż tak głupie... no bez przesady.

Ja za złe uważam tutaj wymyślanie mnemoników do tych rozkazów i implementowanie ich jeszcze (niech by chociaż były włączane jakimś przełącznikiem) jako domyślnie dostępnych w popularnych assemblerach.
Te rozkazy działają tylko dlatego, że zastosowano bardzo uproszczony dekoder rozkazów (z resztą po rozpisaniu sobie w tabeli wszystkich standardowych rozkazów procesora z podziałem na tryby adresowania ładnie wychodzi jak powinny (mniej więcej) działać rozkazy o kodach wynikających z "dziur" w tej tabeli a jednak niektóre działają inaczej, a to już dzieło przypadku.

Nie można traktować przypadku jako pewnika, bo wcześniej czy później to się zemści, tak jak ze skokami do ROMu omijającymi tablicę skoków. Zacznie się potem poprawianie wszystkiego, paczowanie itp.
Nie należy po prostu traktować tych rozkazów tak jak każdych innych, a jak widać co niektórzy uważają że to nie problem.
Tych rozkazów nie ma! Nie ma ich w specyfikacji procesora, nie ma ich w assemblerach (co niestety się zmienia)....

Widzisz, ja to wiem :) , jak by nie było "robię" przy loaderze do gier pod Spartę, który ma najniższe MEMLO (a to tylko dzięki trikom z kompresją mapy pliku w locie - czego nie da się zastosować przy zapisie - i innym wygibasom programistycznym). Zacząłem (i skończę, ale niestety tak się prorobiło że na razie przerwałem) implementować obsługę SIDE do tego loadera i naprawdę cienko z RAMem, trzeba dodatkowo zczytać tablicę partycji, zinterpretować ją stwierdzić o którą partycję chodzi a to dopiero początek, dopiero wiadomo gdzie szukać partycji do tego trzeba oprogramować całą komunikację protokołem IDE.
Da się jakoś upchać ale cudów nie będzie...

A pamiętajmy że potrzeba 4 strony RAM tylko na bufory!!! (2 sektory po 512b). Obecna biblioteka xbios potrzebuje tylko jednej strony, bo działa na filesystemie Atari DOS i na dyskietce.
Czyli w tej sytuacji MEMLO będzie na poziomie minimum $0F00 - oczywiście będzie sporo wyższe bo dodałem tylko bufor, a procedury zajmą swoje. Nie liczyłbym na zejście poniżej $1100, no to już więcej niż ma SDX :)

Nie che mi się, bo jakoś mnie to nie interesuje ;)

Otóż xbios ma 2 podstawowe (a do tego spore) wady.

1. ma własne nie zgodne z niczym innym API, czyli program napisany pod xbiosa, będzie działał tylko z xbiosem, w przeciwieństwie do CIO (oczywiście można powiedzieć, że program napisany pod CIO będzie działał tylko z CIO, ale CIO jest zawsze, nawet jeśli nie załaduje się DOSa udostępnia np magnetofon). Znając życie zaraz dowiemy się że to zaleta xbiosa.

2. I to jest wada, której na razie może nie widać, ale zaraz się zacznie objawiać. Xibios nie oddziela warstwy sprzętu od filesystemu. Czyli biblioteka obsługuje konkretny sprzęt i filesystem na tym sprzęcie. A teraz zagadka, czemu xbios ma tak niskie MEMLO ???

.....

a temu że procedura odczytu sektora przez SIO zmieści się na jednej stronie pamięci (sam napisałem i opublikowałem kiedyś taką maksymalnie krótką prockę, ciekawe czy nie siedzi w xbiosie ;) ), a dodanie zapisu wydłuży ją o kilkadziesiąt bajtów. Obsługa filesystemu Atari DOS też jest prosta, bo to prosty filesystem, do tego xbios nie musi nawet VTOCa obsługiwać, bo nie tworzy nowych plików.
Tak więc puki jest ta jedna... no dwie wersje biblioteki da się względnie to upchać w pamięci. I dlatego nie sądze by kiedykolwiek zawitała obsługa (jak najbardziej standardowej z punktu widzenia Atari) stacji Karin Maxi, SIDE, czy dowolnych new devices. Po prostu mając wyłączony ROM oprogramowanie tego od podstaw zajmie tyle RAMu, że prosty DOS II+ ze swoim MEMLO na poziomie $2000 okaże się zajmować mniej pamięci niż odpowiednia biblioteka xbios.

Oczywiście można zrobić bibliotekę xbios włączającą sobie ROM i komunikować się z new devices przez standardowe procedury Atari OS, ale będzie to przyznanie się przez XXL do błędnego rozumowania, a poza tym Mazemam się na niej nie odpali tak fajnie (bez sensu) jest napisany :P

Punkt 2 jest moooocno naciągany. Tyle samo pracy wymaga napisanie xbiosa dla carta co napisanie prostego handlera działającego przez CIO. Dokładnie te same funkcje i praktycznie taki sam kod. Tyle że jak zrobi się to przez CIO to zadziała na tym carcie od razu wszystko, co kiedykolwiek było napisane zgodnie z zasadami dostępu do plików przez CIO. A w przypadku xbiosa nie.

Pozostaje punkt 1. i z nim się mogę zgodzić ale taki Mazezam nawet takich wymagań nie ma a bez sensu działa TYLKO z xbiosem. I tu zdania nie zmienię. Z tego też powodu dykutuję w wątku o tej nibyplikowej grze.

Co do obsługi Sparty, to już widzę "mały problem", potrzebne są dwa bufory. W przypadku dysku o sektorach 256b to dodatkowa strona pamięci do zajęcia przez xbios i dobijamy do MEMLO SDX, a jak zechcemy dodać sektory 512b.... uuuuu to już mamy w xbiosie wyższe MEMLO niż SDX w trybie BANKED, a funkcjonalność pozostaje mizerna.

A user nie ma żadnego wpływu na to czy z jego (najbardziej standardowo podłączonego) urządzenia program napisany przez tego programistę sie uruchomi. No chyba, że user napisze sobie do swojego urządzenia bibliotekę.

Programista stara się jednak utrudnić życie zwykłym userom (nazywając to oczywiście "ułatwianiem życia"), i zamiast trzymać się rozwiązań, które działają od lat i na dowolnych zgodnych urządzeniach (nawet jeszcze nie zaprojektowanych), stosuje własną protezę, która jest zgodna sama z sobą i z tym co zechce się akurat programiście oprogramować.

Powtórzę się raz jeszcze, te 3 (słownie trzy) odwołania do xbiosa, które są w tym programie można było napisać jako 3 odwołania do CIO i nie byłoby tylu dyskusji, i nie byłoby tylu wersji i gra chodziłaby pod dowolnym DOSem (i nie prawdą jest że HSC, czy ładowanie poziomów to zasługa xbiosa mimo, iż niektórzy tak tutaj piszą).

Oczywiście XXXL odpowie zaraz, że i tak by nie ruszyła bo wyłącza sobie ROM (oczywiście bez sensu, i potrzeby) i ładuje się w obszar DOSa (też bez potrzeby) no i działa tylko dlatego że jest wspaniały, cudowny, funkcjonalny xbios, który omija te ograniczenia (niepotrzebnie dodane do programu).

Wiesz.... w Kazowym katalogu też jest wiele wersji ATRow z jedną wersją gry.
W przypadku tej gry pewne jest, że nie będzie XEXa :) - tak bardzo jest to gra plikowa :P , ale ATRów z różnymi wersjami biblioteki namnoży się sporo.
Może warto od razu zabrać się za opisywanie, który ATR z jakim sprzętem współpracuje, bo ktoś znowu ściagnie sobie plik, który zadziała tylko na emulatorze, albo nie pójdzie na atari 1050 bez przeróbki (bo będzie to wersja DD a do tego tylko pod US) :)

Skoro to plik, to przekopiuj go i odpal na normalnym Atari z klasyczna oryginalną stacją dysków np.... Atari 815.
To jest program całodyskowy udający, że jest plikiem a do tego mocno ograniczony.

Taka prawda.

Mogę poszukać. Edytora nie było. Kiedyś wyciągałem kupę muzyczek z gier i robiłem z tego pliki, które ładowały się do pamięci, odpalały NMI i wracały do DOSa (te pliki mam nawet skopiowane), zero relokowania itp. No i fajnie, można sobie było wczytać, muzyka grała po powrocie do DOSa, tylko oczywiście SIO nie działało. Zrobiłem więc taką wprawkę, czy dałoby się grać muzykę przy działającym SIO pod DOSem. Była tam tablica wartości wpisywanych do rejestrów w każdym kolejnym NMI, czyli było dłuuugie :), ale za to cała obsługa pod NMI, to 4 razy LDA + STA i zwiększenie liczników - no i działało, a że muzykiem nie jestem, to były to przypadkowe dźwięki.
Z resztą pierwszy test na jednym generatorze, to było poprostu LDA RANDOM ; STA ADUF? :) i mamy dźwięk lawy z Boulder Dash.... i SIO działa :)