Skonfigurowałem sobie środowisko IDE (MADAS+Eclipse+Altirra) pod Windowsem i przypominam sobie nieco z programowania.
Ale do rzeczy. Program zaczyna się od $2000, w pierwszej kolejności wyłączam ROM/IRQ i przepinam przerwania na swoje procedury. Blok danych opisujący zestaw znaków zaczyna się od $E000. Po kompilacji i uruchomieniu pod emulatorem program działa poprawnie, ale pod $E000 mam same $00 - dlaczego?
Czy wykonanie:
sei lda #0 sta $d40e lda #$fe sta $d301
ldx <nmi ;nasz nowy adres programu NMI ldy >nmi stx $fffa sty $fffa+1
lda #$c0 sta $d40e
powoduje wyczyszczenie tego obszaru? Czy może mam coś nie tak ustawione w emulatorze/kompilatorze?
pod $e000 jest zestaw znakow jesli rom jest wlaczony, jak wylaczysz rom to jest tam ram. jesli chcesz zeby dane zestawu znakow byly w ram pod rom to musisz je tam skopiowac.
Dzięki za odpowiedź. Ahhhh logiczne! No jasne,że jak definiuje, że mój zestaw ma być od $E000 a tam jest jeszcze ROM to się nie ma prawa tam załadować.
Czyli praktycznie muszę zrobić "loader" który wyłączy ROM i dopiero potem załaduje w odpowiednie obszary moje dane:)
Hmmm... mnie ten problem nieco zaskoczył, wyłączamy ROM aby potem korzystać z jego dobrodziejstw. To może nie wyłączać na razie ROMu skoro przydaje się on nam a wypełnienie pamięci od $2000 do $BFFF nie jest kwestią dni (no chyba że to faktycznie jakiś kopier), ja ostatnią gierkę kodowałem sporo dłużej i nie udało mi się tej pamięci zająć.
tdc - odpowiadając na nurtujące Cię pytanie. Nie wiem jeszcze czy z tego skorzystam. Na razie skompletowałem sobie środowisko pod Windowsem i "odnawiam" wiedzę o programowaniu. Moja ostatnia gra nie potrzebowała aż tyle pamięci, chociaż technikę wyłączania ROMu i wykorzystania z ukrytego RAMu już znałem. Tyle, że w owym czasie miałem już na biurku PCta i zabrałem się za programowaniu właśnie na nim. W skrócie - po prostu odświeżam wiedzę :)
@xxl, zależy z której strony na to patrzeć: wyłączanie ROMu dobrym nawykiem jest, ale korzystanie z wyłączonego zestawu znaków już nie;)
@dan, bardzo dobrze, w sumie ja też przez takie etapy przechodziłem, na początku mojej działalności pecetowej doskonale pamiętałem co w Atari piszczy jednak gdy minęło już kilkanaście lat to sporo zapomniałem i przyznam się że aby luki w pamięci załatać to musiałem w to włożyć sporo wysiłku, ale udało się i warto było.
w obecnej formie przede wszystkim. Znaczne ograniczenie co do obsługiwanej pojemności pliku ATR (obecnie 90/130kB :)), do każdej pojemności osobna wersja xB (wnioskuję to po dziale download i początkowym ustalaniu pojemności dysku) i ewentualne podwersje odpowiedzialne za urządzenia (SIO/nie SIO) i FS. Jak sobie wyobrażasz to w praktyce? - kilkanaście wersji xB? :P Każdy zrobi to, co uważa i nikogo przecież zmuszać nie można. Ja po prostu wolę dobry dos, bo mam tam wszystko co mnie interesuje (i nie tylko), wszystko co potrzebuje działa w sposób szybki, wygodny i w pełni konfigurowalny. Chcę coś, to ładuję sterownik, nie chcę - to tego nie robię. Nie chcę dosa, to mam init pod którym działa praktycznie 99.5% rzeczy. Osobiście nie potrzebuję nic więcej i dlatego dziwię się temu, co mam okazję niekiedy podziwiać ;)- Niestety tym razem padło na xB ... po prostu nie mogę tego do końca zakumać ;)-
z "pojemnoscia dysku" sie nie zgodze, masz wybor gestosci a nie pojemnosci, to dwie rozne sprawy. watek zaczyna rzypominac ten z aa... kazdy mowi o czyms innym ;-)
ok - wyraziłem się co najmniej nieprecyzyjnie, lecz rozróżnianie dodatkowo wersji w stosunku do wielkości sektora powoduje jeszcze większe rozdrobnienie w sensie ilości podwersji ;)- Obecnie jak widzę, to zabawę zaczynamy od sektorów 128 Bajtowych.
... z drugiej zaś strony pojemność też zależy w pewnym stopniu od gęstości ;)- widziałeś dysk pod Atari formatowany na 180kB przy użyciu sektorów o pojemności 128B? ja nie widziałem. ... jeśli już mowa o "mówieniu o czymś innym jak na atariarea" ;)-
musi byc rozroznienie wielkoscia sektora. sa stacje ktore nie czytaja sektorow 256. a xbios z zalozenia ma dzialac na kazdym :p
z pojemnoscia przyzwyczailes sie do tego co "mowi" dos.
ok. przyklad: pisze gre. w jednym pliku np. 64kb mam zapisane plansze. chce zaladowac siodma plansze z pliku. gra ma dzialac na standardzie ale jesli bedzie dodatkowa pamiec ten plik ma wyladowac w ramdysku. gra ma byc odpalona z dyskietki ale jesli ktos ja skopiuje na karta ma dzialac z kardrydza. dzieki xbiosowi robie tylko jedna wersje gry. opisz mi jak to bedzie wygladalo pod dosa :) konkrety.
Nie mogę udzielić odpowiedzi, gdyż mimo wszystko takie założenia są dla mnie bez sensu.
Więc jak, sądzisz że poprzez xBios'a uzyskasz idealną metodę dla nieprzywiązywania wagi do medium, na jakim zapisany jest program?
Wystarczy, że w wersji podstawowej programu / gry / itd nie uwzględnisz faktu w jakim rejonie pamięci operuje cart. Na takiej zasadzie istnieje sporo gier, które np. na SIC!'u nie zadziałają nigdy, może pójdą na MaxFlash'u a zadziałają też z czegokolwiek innego. I tu nawet xB nie pomoże (tak mi się wydaje).
A czy gra sama z siebie nie może sprawdzić sobie, czy istnieje dodatkowa pamięć i zależnie od jej obecności albo doczytywać dane z pliku, albo skopiować dane na ext ram i następnie ciągnąć to stamtąd właśnie?
Zmierzasz chyba do tego, by dana gra / program była(ł) zależny od xBiosa na tyle, by bez niego nie było możliwości uruchomienia i by była dzięki temu jedna podstawowa wersja programu (o czym prawisz) i kilka plików ATR z różnymi xB do uruchomienia w różnym środowisku sprzętowym. Powoduje to raczej niepotrzebne zamieszanie, oraz niestety ograniczenie powodujące jedynie to, że wypuszczając w ten sposób program sam sobie ograniczasz liczbę odbiorców w chwili, w której nie uwzględnisz jakiegoś hardware'u. Na chwilę obecną nie uruchomi tego nikt, kto używa urządzenia na PBI/ECI.
dla Ciebie zalozenia bez sensu dla mnie calkiem realny problem (z xbiosem juz nie) - jescze raz:
pisze gre. w jednym pliku np. 64kb mam zapisane plansze. chce zaladowac siodma plansze z pliku.
powiedz jak to ma dzialac pod dosem :-)
> Więc jak, sądzisz że poprzez xBios'a uzyskasz idealną metodę dla nieprzywiązywania wagi do medium, na jakim zapisany jest program?
calkiem niezla.
> Wystarczy, że w wersji podstawowej programu / gry / itd nie uwzględnisz faktu w jakim rejonie pamięci operuje cart.
nie ma to znaczenia
> Na takiej zasadzie istnieje sporo gier, które np. na SIC!'u nie zadziałają nigdy,
w.mnie problem lezy gdzie indziej. a z ciekawosci daj przyklad gry ktora nie ruszy na SICu. chce cos przetestowac...
> A czy gra sama z siebie nie może sprawdzić sobie, czy istnieje dodatkowa pamięć
moze jesli gra ma uzywac dodatkowej pamieci nie jak ramdysku. a moze dodatkowa pamiec lezy na karcie? nie obslugiwana przez portb? i caly Twoj sposob sie sypie.
> Zmierzasz chyba do tego, by dana gra / program była(ł) zależny od xBiosa
jesli uzywa funkcji xbiosa to chyba jasne ze xbios musi byc obecny podczas operacji IO.
Zadam pomocnicze pytanie. Na jakiej zasadzie demo SillyThings ładując się z jednego pliku ładuje intro, wyświetla je, następnie z tego samego pliku doładowuje resztę danych dema? Ten sam plik z demem działa dokładnie tak samo doładowując dane z carta (SIC!). Nie potrzebuje do tego niczego (nawet xB) i działa na przysłowiowym grzebieniu ;)- Bo działa bez zbędnych zabiegów i spod dosa i spod inita, carta, sio, nie sio itd.
nawet nie musze sprawdzac - inity :-) ale to sie ma nijak do tego o czym pisze. jeden moze sie doladowywac od poczatku do konca ale juz ta metoda sie nie sprawdza jesli chcesz zaladowac najpierw np. 7 level, pozniej 5, pozniej 3, 8,1 ... :-) no kombinuj dalej - jak to zrobic z dosa
Jak? - nie pierdzielić się z możliwością zapisu na carta i grę / program upublicznić w wersji plikowej. Program / gra może zapisać dodatkowy plik z danymi do których dostęp jest dowolny. Minimum kultury programistycznej doprowadzi do tego, że program / gra zadziała na kilku używanych obecnie dosach (II+, MyDOS, SDX). W razie konieczności zrobienia gry na carta - zrobić specjalną wersję programu / gry - i tyle. Zero problemów i każdemu zadziała, oraz nie trzeba chrzanić się z plikiem ATR, tylko kulturalnie wrzucić program / grę do należnego mu katalogu na dysku.
no wlasnie tak chce. plik z gra i plik z danymi. plik z danymi zajmuje 64kb i zapisany jest w nim kilka leveli, jak z uzyciem dosa dostac sie do tych danych - chce zaladowac np faze 7.
ok. note/point - dobry sposob... tylko ze dla takiego rozwiazania trzeba przygotowac dwie kompilacje dla sparty i dla innych dosow, dodatkowo jesli przeniesiesz taki plik na inny nosnik albo wogole przekopiujesz to przestanie dzialac sposob note/point dla atari dosa.
nie trzeba robić dwóch wersji gry / programu dla note / point - wystarczy zrobić uniwersalną prockę, która zadziała na SDX, lub AtariDOS (rzecz prosta do rozpoznania).
Oczywiście, jak wspomniałem takie rozwiązanie w przypadku chęci użycia jakiegoś carta odpada i wówczas trzeba przygotować wersję pod konkretny cart. Są jednak wówczas dwie wersje gry - jedna działa na dosach, druga np. z MaxFlash'a.
... lecz, ostatecznie są to dwie wersje i nie więcej, bo mnogość wersji w przypadku xB może być znacznie większa. Np. 6 wersji, bo:
sio2sd i fat, SIO jako port, pbi/eci jako newdev, sic! cart, maxflash, ... bo ktoś wykopał z kopalni interface MyIDE :)
I teraz szukamy na sieci gry Draconus i mamy do wyboru:
1. draconus.atr (wersja sio2sd fat) 2. draconus.atr (wersja dla SIO) 3. draconus.atr (wersja newdev, np. IDE+ i pliki ATR ładowane z bios) 4. draconus.atr (SIC!) 5. draconus.atr (MaxFlash) 6. draconus.atr (MyIDE)
... nie wspomnę ile radości przysporzyła by mnogość wersji w czasie przygotowania stuffu na compo ;)-
Nie sądzisz, że jeśli powstanie kilkanaście takich programów, to chaos sięgnie zenitu? :)
chcesz dalej brnac ok. jak przygotowac uniwersalna procke dla sdx i atari dos dla note/point. konkrety.
> .. lecz, ostatecznie są to dwie wersje i nie więcej, bo mnogość wersji w przypadku xB może być znacznie większa.
ta liczba w przypadku xbiosa = 1. gra zawsze ma jedna wersje jesli chcesz zmienic urzadzenie zmieniasz biblioteke ale gra zawsze jest ta sama czy to na karta czy z rozszerzeniem pamieci czy bez czy dla FAT czy dla atari dos zawsze jedna wersja gry.
Nie chce mi się brnąć, bo mam inne ciekawsze zajęcia ;) -
Note/Point działa pod SDX tak, że określona jest pozycja w otwartym pliku. Dla AtariDOS jest to określenie w stosunku do sektora. Rozpoznajesz, w jakich warunkach program został uruchomiony. Upubliczniasz program np. na obrazie ATR na którym program współpracuje z DOSII+, operacje note/point przeprowadzasz na sektorach. W programie robisz detekcję obecności SDX - jeśli SDX jest w systemie, to operacje note/point przeprowadzasz w stosunku do otwartego pliku. Jest to szczegółowo opisane w manualu do Sparta DOS X, dział programowanie.
.. no widzisz, przyznajesz że trzeba zmieniać bibliotekę dla xB. Więc użytkownik staje przed sytuacją w której uruchamia grę / program, lecz ten nie działa i nie wiadomo dlaczego ;)-
note/point nie tylko inaczej dziala na roznych dosach. juz mowilem ze wystarczy plik przekopiowac i program przestanie dzialac :-) innymi slowy nie zrobisz niczego uniwersalnego z uzyciem note/point chyba ze ograniczysz sie do jednego wybranego dosa lub zrobisz dyskietke ktorej nie bedzie mozna kopiowac :-)
takich grzeszkow dosiki maja troszke wiecej ;-)
> no widzisz, przyznajesz że trzeba zmieniać bibliotekę
tak, oczywiscie.
> Więc użytkownik staje przed sytuacją w której uruchamia grę / program, lecz ten nie działa i nie wiadomo dlaczego ;)
nie, poniewaz jesli ma biblioteke dla swojego urzadzenia to ma 100% pewnosci ze zadziala.
.. a nie można pod AtariDOS odczytać dane i ztablicować je za każdym razem? Pod SDX ten problem odpada, więc tam (po wykryciu, że program jest uruchomiony pod SDX) wrzucić offset i w ten sposób przesuwać znacznik odczytu w pliku. Da się to zrobić. Po skopiowaniu więc programu zasadniczo nic się nie stanie, a chodzi w tym przypadku o odczyt, więc w przypadku pomyłki pod kontrolą AtariDOS nic z danymi w sektorach się nie stanie.
Czyli jeśli potrzeba do każdego programu bibliotek dla danego urządzenia, to sprowadza się to do zamieszania o którym pisałem :P
Użytkownik zassał program z internetu, program siedzi pod kontrolą xBiosa. Użytkownik za każdym razem musi zweryfikować, jakie biblioteki dołączone są do xB. Zrozumiałem i dalej mnie to nie przekonało.
Dobra, skończmy tą rozmowę, bo każdy ma swoje racje. Pozwoliło mi to bardziej zrozumieć, jak działa xB i chętnie się przyjrzę, jak temat rozwijać się będzie. Być może jest w tym ukryty sens i jakiś pomysł, ten jednak w obecnej postaci nie do końca do mnie przemawia. Ostatecznie - zweryfikuje to zainteresowanie, lub jego brak ze strony użytkowników, oraz ilość zgłaszanych problemów, oraz zapytań.
XXL - pytanie, czy możesz udostępnić źródła xShow celem drobnego moda polegającego na dodaniu możliwości odczytu parametru z linni poleceń i użycie viewera z poziomu np. runext SpartaDOS X?
> a nie można pod AtariDOS odczytać dane i ztablicować je za każdym razem?
sprawdzic jaki mamy filesystem/DOS, ladowac caly plik 64kb zeby stworzyc tablice na podstawie ktorej pozniej ustawiac note/point... to jest jakies kwi pro kwo :D pod dosem to juz mozna nazwac program :D pod xbiosem niezaleznie od filesystemu i urzadzenia robi sie to tak: ldy < pos ldx > pos lda ^ pos jsr xBIOS_POINT
> Czyli jeśli potrzeba do każdego programu bibliotek dla danego urządzenia,
wystarczy miec jedna biblioteke do 100 programow :-)
>Użytkownik za każdym razem musi zweryfikować, jakie biblioteki dołączone są do xB.
nie :-) nie musi a nawet nie powinien jej kopiowac - ma swoja :-)
czyli kolejnym zalozeniem zeby to mialo sens z dosem jest obok napisania specjalnego programu zeby plik zindeksowac jest to ze bedzie ladowane z jednego konkretnego urzadzenia :-) please...
ale pamietasz ze piszemy gre a nie programy, ktore pozwola tej grze pracowac pod kontrola dosa? :D
Wiesz co, kombinujesz jak koń pod górę. Wystarczy napisać grę pod dos i każdy level trzymać w oddzielnym pliku i problem z głowy. Nie trzeba używać wówczas nawet note / point :). Nie ma wówczas żadnych problemów, działa to generalnie wszędzie i praktycznie na wszystkim. Pod warunkiem zachowania podstaw kultury programowania danego sprzętu. Dodatkowo używając dosa, np. SDX masz możliwości i wygodę, której raczej pod xB nie uzyskasz. Tak sądzę przynajmniej ;)-
to super, ale nie kazdy ma sparte, co wiecej - wiekszosc nie... jak zaladuje od $f08 to nie bedzie dzialac pod dosem, bedzie dzialac tylko pod specjalna konfiguracja sparty... ale ja nie chce pisac wersji dla kazdego dosa, chce pisac jedna wersje, chce zeby bylo wygodnie, jakie memlo?
... muszę faktycznie sprawdzić tak z ciekawości który dos będzie miał zbliżone do SDX memlo. Sparta ma bardzo niskie istotnie przez to, że jest na carcie i bankami dołącza się w miarę potrzeb. Dobra, XXL - rób tam swoje, dorób tylko obsługę PBI. Szkoda po prostu, że wypuszczasz program nie licząc się z użytkownikami. HDD to nie diobeł wcielony, więc mogło by to i z tym wynalazkiem działać, bo przecież nie ma problemu? ;)-
Przypomina mi to stary problem amigowców i estekowców - gry całodyskowe, które potem były hackowane i przerabiane na exeki, które można było ładować spod osa/tosa.
Ale do rzeczy. Spodziewam się, że przy architekturze xbiosa możliwe jest stworzenie mostu, który po prostu tłumaczyłby polecenia xbiosa na wywołania dosowe. Rozumiem - xbios siedzi tam, gdzie dos, ale przecież nie musi. Ponadto może istnieć wersja xbiosa kompatybilna z sdx i wtedy po wczytaniu exeka następuje wyłączenie sparty a następnie obsługa urządzenia już przez xbios. Problemem tu jest mnogość hadeków, które sparta obsługuje(?), ale napisz xxl, może to wszystko masz już obcykane.
Nie wydaje mi się, by była możliwa implementacja obsługi formatu sparta dos w xBios. Chodzi o kwestie zajmowanej pamięci celem obsługi FS. Niech sobie to chodzi z "całodysku" (bo to też można załadować w sumie z np. IDE+), ale jeśli jest już ogólnodostępny release, to niechaj działa to nie tylko poprzez SIO, ale też poprzez urządzenia PBI/ECI. Tu chodzi bardziej nie o dos, tylko o to, by program nie musiał "wiedzieć" z czym się komunikuje i by pozostawić dla programu hardcore'owo możliwie jak największą ilość pamięci ram, szczególnie liniowej 64k natywnej atarki i pozostawić możliwość elementarnej komunikacji ze światem zewnętrznym. W całym tym zamieszaniu nie przekonuje mnie tylko jednoczesna uniwersalność bibliotek, bo te też będą zajmować miejsce. Może nie w pamięci, lecz w postaci danych występujących w obrębie pliku *.atr. Lecz nie to jest może problemem, bo zawsze obraz dysku może być odpowiednio większy. Ale, jeśli nie będzie żadnej automatyki do detekcji sprzętu, to wybór biblioteki będzie możliwy po stronie usera (zamieszanie). Jeśli będzie rozbudowany system detekcji, to ucierpi na tym ilość wolnego ramu, lub będzie to zajmowało niepotrzebnie czas. Tak mi się wydaje, albo źle to rozumiem. XXL - poproszę o sprostowanie, jeśli pierdzielę głupoty ;)-
Nadal pytam o xShow, albo napisz po prostu, że nie i tyle. ;)-
@Jhusak - o rozwiązaniu o którym pośrednio wspomniałeś (wyłączenie SDX i poprzez loader uruchomienie pliku niejako spod sdx, lecz bez dosa) myślałem już od dawna. Idealnie nadaje się do tego loader MSDOS, muszę tylko zmotywować autora albo do pacza programu, albo do udostępnienia źródła. Chodzi o to tylko, by loader był w stanie odczytać nazwę ładowanego pliku jako parametr. To umożliwi dopisanie programu do mechanizmu RUNEXT Sparta DOS X. Obecnie mam dla przykładu ponad 40 skojarzeń typów plików do odpowiednich programów. Jest już większość, czyli playery do muzyczek, podgląd większości formatów grafik, podgląd / edycja tekstu, depakery arc, zip, pliki com / exe (opis poniżej), playery do sampli itd.
Chodzi o to, by skorzystać z mechanizmu skojarzeń typu pliku z określoną akcją. Myślałem więc w temacie ładowania binarek o czymś takim:
(co już min. jest) *.com - pliki uruchamiane z włączonymi bibliotekami Sparta DOS X *.exe - pliki uruchamiane z wyłączonymi bibliotekami, rozszerzenie skojarzone w systemie z CAR:X.COM
(co może być, a co prawie już jest) proponowane dla jaj rozszerzenie pliku:
*.ex1 - plik skojarzony z loaderem, który przejmuje kontrolę nad systemem, wyłącza całkowicie SDX i uruchamia plik z ekstremalnie dużą ilością pamięci liniowej 64k i daje pełną dowolność w temacie wyboru banku pamięci rozszerzonej. Jedyna wada, to brak możliwości operacji na plikach. Zalety - Uruchamia się wszystko to, co uruchamia się z "loadera" bez dosa. Funkcjonalność zauważyłem po fakcie, jak spod SDX odpaliłem MSDOS a ten ładował mi wszystko tak, jak by SDX nie było w systemie. Dodatkowe zalety to wygodny i nieograniczony praktycznie dostęp do struktury katalogów, możliwość pracy na partycjach o pojemności 32MB (praktycznie będzie więcej), wygodne użycie i integracja z SDX w sensie RUNEXT.
Pin nie bardzo rozumiem. xbios jest zewnetrzna biblioteka nie jest zintegrowana z ladowanym programem, z zalozenia nie ma detekcji sprzetu i nie ma mozliwosci zeby biblioteka dala info o filesystemie albo sprzecie. udostepnia 61kb ram do bezposredniego ladowania. caly czas dzialasz z plikami a nie z sektorami, kompatybilne z dosem - to nie jest calodysk. mimo tak malego rozmiaru program uzywajacy tej biblioteki moze ladowac i zapisywac pliki na urzadzeniu zewnetrznym - cos wiecej od inicjalizera ;-)
xshow to program prosty jak drut, 90% kodu to biblioteki tebego, ten program mozna napisac w pol godziny... pogadam z Mono - dam mu zrodla niech zadziala.
