Ale co za problem pisząc program, który potrzebuje załadować lub zapisać jakiś plik, używać standardowego OPEN (z podaniem nazwy pliku), BGET, BPUT i CLOSE ???
Oprogramowanie tego z poziomu assemblera jest trywialne. Na dyskietce systemowej MAC65 jest nawet zestaw makrodefinicji implementujących wywołanie tych funkcji w sposób identyczny jak w BASICu (jak się komuś uczyć nie chce).
Tak napisany program będzie działał pod każdym atarowskim DOSem, nawet takim, którego jeszcze nie napisano, z każdym dopalaczem, każdym interfejsem (pod warunkiem, że są zgodne z systemem). I będzie działał BEZ DADAWANIA BIBLIOTEK, po prostu po skopiowaniu i uruchomieniu.
Oczywiście jeśli naprawdę brakuje RAMu, a wyłączenie ROMu w czasie ładowania jest konieczne to przyda się inne rozwiązanie, ale w większości przypadków (taki Mazezam np.) nie jest to konieczne, bo program spokojnie odpaliłby się pod dowolnym DOSem, ale autor postanowił że ma być inaczej...

Ostatnio edytowany przez Pecus (2012-10-15 13:10:07)

ale xBios "sam z siebie" wykorzysta dodatkową pamięć - dla mnie jest to ogromna zaleta, nawet w przypadku programów które można napisać "tradycyjnie". Wygoda to kwestia gustu - dla mnie XB jest wygodniejszy. Przecież będzie biblioteka dla Waszych konfiguracji, jeżeli dobrze zrozumiałem? Moim zdaniem warto w to wchodzić na szerszą skalę, nie tylko w przypadku niestandardowych produkcji żyłujących pamięć...

Ostatnio edytowany przez xeen (2012-10-15 13:55:23)

To można też przepisać sobie z ROM do RAM samą tylko obsługę CIO, i używać na wyłączonym ROMie. W moim patchu na MazezaM przepisuję cały ROM do RAM(na łatwizę) i działa. W załączniku małe demko - poprawny wynik to pojawienie się cyferek 0, 1, 2 (0 - kontrolna, 1 - rom przepisany do ram, 2 - instrukcja z bloku od $C000).
Czyli DOSy potrafią ładować pliki binarne wszędzie - czasem tylko trza im trochę pomóc :)

Ostatnio edytowany przez grzybson (2012-10-15 15:53:08)

nie rozwiazujecie problemu zajetej pamieci :-)

niestety tak pieknie to nie jest i nie pod kazdym dosem ;-) - ale to dowod, ze to ograniczenie DOSa a nie pliku binarnego :-)

ok. a jak wykonac "binary load"

juz mamy wszystko zaladowane, pamiec zajeta, od adresu $f000 mam dane do zapisania. i co teraz?

Ostatnio edytowany przez xxl (2012-10-15 16:53:47)

w jakiejs czesci pamiec masz zajeta kodem? kodem wczytanym z dysku? ta czesc traktujesz jako bufor, wczytujesz tam dane, wylaczasz os, kopiujesz pod wskazane miejsce z bufora, wlaczasz os, ponownie wczytujesz nadpisany kod, wylaczasz os. pozamiatane.
towlasnie mialem na mysli piszac "ale przeciez wszystkie te kroki mozna powielac...".

bo domyslam sie ze caly czas masz na mysli nie rozbudowane 65xe?
no i pewnie masz jakas pamiec na ekran? ale wolalbym zabawe z wlaczaniem/wgrywaniem/wylaczeniem/kopiowaniem itd. niz smieci na ekranie (choc wydluza to czas operacji o nadgrywanie spowro nadpisanego jako buforem kodu...).

Ostatnio edytowany przez jellonek (2012-10-15 17:21:47)

A ile jest programów, które potrzebują wgrać 64 kB danych? W szczególności gier?

zrzucic do pliku? tj. caly ram masz wypchany "computed data" ktorych nie masz w pliku? O_o
ps. niby o zrzucaniu do pliku nie wspominalem, ale przelotnie to mialem w myslach, zakladajac ze calosc masz "komputowana z random-randoma". bo jesli dane/kod sa stale, albo komputowane z randoma o znanym/powtarzalnym ziarnie (co jest np. wykorzystane w elite) - to nie widze powodu by takich danych nie wczytywac z dysku... jak jest true-random (np. wykorzystujacy interakcje z userem do ustalenia kolejnych krokow randoma) - wtedy faktycznie mozna zapisywac jakas strone na dysk, by miec strone bufora dla operacji dyskowych...

memlo ztcp >$800, ale jak chcesz konkretne dane to moge zaraz atarke podpiac pod tv...

dopisek: jaka czesc z tych 61kb jest stala, a jaka czesc dogrywana xbiosem przy kolejnych levelach? czy przy jakichkolwiek tam operacjach ktore tego wymagaja? (bo skoro mowimy tym ze nie trzeba czesc "dolnego" ramu wykorzystac jako bufori jest to problem bo nadpisane dane skads trzeba ponownie wziac, to pewnie cos musi byc doczytywane jakichs danych?)

Ostatnio edytowany przez jellonek (2012-10-15 17:33:38)

xxl piszesz teoretycznie. Ja nie neguję że coś takiego może się przydać ale... Czy Mazezam zajmuje całą dostępną pamięć i czy przypadkiem nie zmieściłby się bez kombinowania w pamięci  od $2000 do $C000 i jeszcze sporo by nie zostało?
Wystarczyłoby przed kompilacją ustawić adres startowy na $2000, nie bawić się w utrudniacze typu "a załadujmy coś bezpośrednio do wektorów pod ROM bo to pokaże siłę xbiosa" i zamiast 3 rozkazów JSR do xBiosa dać 3 wywołania CIO.

No po prostu narobić się przy tym trzeba strasznie i nie da się zrobić tego bez ogromnego wysiłku programistycznego - gratuluję.
Dzięki temu otrzymałeś "produkt", który do każdej kombinacji sprzęt-filesystem potrzebuje innej wersji pliku z biblioteką (sam pisałeś że musiałeś podsyłać komuś z ABBUC inną wersję biblioteki, bo nie odpalało się). I zwykły użytkownik, nie może go sobie ot tak za pomocą prostego COPY przekopiować np. na partycje SDX obsługiwaną przez SIDE, czy na dyskietkę z jakimś DOSem jeśli chce odpalać tę grę np. w trybie US (traktuj to jako przykłady różnych konfiguracji sprzętowych, zamiast udowadniać, że w tej konkretnej zadziała), bo do każdej takiej kombinacji potrzebuje inny plik biblioteki.
A jak sobie wymyśli jeszcze inne rozszerzenie, to nawet jeśli będzie ono w 100% zgodne z systemem operacyjnym Atarynki i tak będzie sobie musiał do tej gierki napisać bibliotekę, choć wszystkie inne programy będą działały bez kłopotu.

I to że ABBUC nie miał uwag... swietnie, tyle że oni potraktowali tę grę jako całodyskową i tak ją będą traktować w większości jej użytkownicy.... cała zaleta robienia jej w pliku bierze niestety w łeb.

Ostatnio edytowany przez Pecus (2012-10-15 18:06:59)

te xbiosy nie sa chyba duze rozmiarami, mozna trzymac od biedy ich kilka w katalogu

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.

Ostatnio edytowany przez grzybson (2012-10-15 18:20:39)

ale ja juz na to odpowiedzialme kilka razy :/

> (sam pisałeś że musiałeś podsyłać komuś z ABBUC inną wersję biblioteki, bo nie odpalało się)

mialem blad w bibliotece, Stefana Dorndorfa rzucil okiem i znalazl. blad zostal naprawiony.

> I to że ABBUC nie miał uwag... swietnie, tyle że oni potraktowali tę grę jako całodyskową i tak ją będą traktować w większości jej użytkownicy....

nie prawda. gra znajduje sie na jednej dyskietce wraz z innymi grami

> wlasnie sprawdzilem na real sprzecie, memlo $0e77, sparta dos x z device sparta banked.

to jakas kpina prawda? zeby gra dzialala user musialby miec sparte dos x i dodatkowa pamiec?
dlaczego zmuszasz mnie do kupienia dodatkowego sprzetu w postaci karta i pewnie rozszerzenia pamieci?
xbios ma duzo nizej memlo. jak wyglada pamiec od $000 - $6ff?

> ps. odpowiesz na moje wczesniej zadane pytania?

odpowiedzi padly juz wczesniej (kilka razy)

> W Ram pod Rom-em potrafi - więc gdzie nie da rady?

sprobuj zaladowac bezposrednio w ram od $c000 - $ffff z wylaczeniem rejestrow sprzetowych.

pytam jeszcze raz nie mam rozszerzoonego atari, moge zaladowac dos jakie memlo? tak, zebym mogl robic chociaz binary load, save i load.