Kpisz, czy o drogę pytasz? Modyfikacja (na oko nie więcej niż 40 bajtów kodu) dowolnego DOSa czy loadera umożliwi tę funkcjonalność, tylko jakoś przez lata nie było to nikomu potrzebne.
Wymyśliłeś sobie niepotrzebną potrzebę i teraz udowadniasz jej potrzebę....

Co więcej, jak już pisałem podobna modyfikacja xbiosa, skróci kod o jakieś 100b i przy okazji spowoduje obsługę urządzeń PBI i innych. Tyle że to nie ma sensu (bo ciągnięcie tej idei go nie ma).

Poproszę o obsługę stacji Karin Maxi (jak najbardziej standardowej i obsługiwanej od zawsze przez niemodyfikowane procedury systemu operacyjnego Atari, każdy DOS, loader itp.).

Do atari 8-bit nie ma rozszerzeń!!!
Wszystkie znane mi urządzenia rozbudowujące małe atari zwiększają jego wysokość (seria XL oraz XEGS) lub głębokość (seria XE).

Szerokości nie zwiększa żadne z nich! :)

No proszę, udało się obsłużyć, to co od lat obsługują wszystkie inne loadery i DOSy dogoniłeś w obsłudze SIO system operacyjny Atari sprzed 35 lat, który nie miał problemu z żadną z tych stacji.

Super.

To teraz jeszcze obsługa urządzeń PBI i innych (zgodnych ze standardem oczywiście) i xbios zacznie doganiać DOSy potem obsługa innych formatów dyskietek/dysków twardych (jak najbardziej standardowych).... tak za jakieś 20 lat może da się używać, oczywiście za każdym razem kopiując jeden z 68 plików xbios zgodnych z aktualnie używaną konfiguracją sprzętu, formatem dysku itp.

O widzę jeden download, XXXL... po co ściągasz to co sam uploadowałeś ???

Ja już przestałem, wolę dokarmiać siebie ;P

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