@jhusak Windows to jest masakryczny system, on nie jest kompatybilny sam ze sobą. Tylko "#include <stdio.h>" i to w ograniczonym zakresie. Nawet "printf" jest niebezpieczny, bo te formatowania działają inaczej na 32-bit i 64-bit. Tu trzeba pisać jak w starym Borlandzie. Typy tylko char i int. Funkcje ogólnie znane i tak trzeba jeszcze raz napisać wprost. Kod wygląda przedziwnie, ale łyknie go każdy kompilator.
Patrzyłem na te gry z kompresją. Jedna rzecz mnie zastanawia. Skoro plik dosowy składa się z bloków ładujących i po każdym bloku może wystąpić sekwencja INIT($02E2), to jak ma wrócić kod kończony RTS jak kompresor wyczyścił stos?
Ja rozumiem, że całodyskowy ATR to robi co chce. Ale XEX jakieś zasady powinien trzymać.
@gienekp Oczywiście że xex powinien trzymać zasady. Jedną z zasad jest utrzymywanie płynności czytania z medium, nie zakłócenie tego w żaden sposób. Np. TurboBasic xl doczytuje własnymi procedurami resztę pliku wykorzystując otwarty kanał IO, co powoduje że nie da się go wczytać bez dosa, a dokładniej podsystemu wejścia wyjścia. Natomiast nie rozumiem wątpliwości co do kompresji. Jeśli został wczytany cały plik, to może robić co chce. Natomiast w trakcie wczytywania nie powinien robić żadnych operacji używając stosu, czy strony siódmej, czy zerowej. Rozumiem problem starych kompresorów, które z racji tego że muszą obsłużyć jak najwięcej plików, muszą chować się po kątach, jednak wpływa to na późniejszą ich obróbkę loaderami.
Tu wydaje mi się, że problem jest typu: ładuje run, potem init, i po inicie ma już run władowany, a twoje podejście ten run przesuwa na koniec pliku, i jeszcze trzeba go doczytać. Sprawdzę. ---- edit --- a nie, dodajesz run tylko, gdy go nie było.
A ja tak z głupia Frant... Bez żadnego trybu, że zacytuję klasyka. Jedna z moich rozrywek od czasu do czasu polega na wzięciu XEX-a i zapisaniu go na kasecie z dodany loaderem (czasami wykrzyknik, czasami loader Turgena). Czy taki wasz fikuśny XEX z kompresją z magnetofonu się wczyta? :-D
Kasetowy loader "Wykrzyknik" mamy rozpracowany co do bajtu. Inna sprawa, że tam jest bug. Ale nie wczytają się wszystkie gry skompresowane. Dawno temu robiłem xex2cas i wtedy nawet nie wiedziałem dlaczego tak jest. Tak przy okazji niedawno kolega @mono zrobił loader kasetowy co ma 128bajtów(!). Jeden rekord i od kopa bez przerwy idzie xex.
W menu4car jest analizator xex i mały naprawiacz. Jest wiele xexów sknoconych. Przykład na AOL "RivierRaid". Pytanie czy nie trzeba takiego xexa przeanalizować zanim się go wklei do CAR i poprawić ile się da lub przygotować loader na taki przypadek. W MaxflashStudio można zmienić adres loadera, ale weź tu teraz wytłumacz użytkownikowi jak ten adres dobierać.
@bartgo ATR2JAC idzie inną drogą. Natomiast w przyszłości menu4car wsadzi ATR do menu. Czyli menu4car jest jakby poziom wyżej a atr2jac będzie jedną z podfunkcji.
No ale bariera jest, żeby to zrobić elegancko z automatu. Te standardy trzymane są tak sobie. :/
Kuba, nie wiem skąd się bierze ta ucieczka przed 7mą stroną?
Po co pakujesz loader od $780, zostawiasz sobie $80b na jakiś bufor? (bo tylko wtedy ma to sens).
Wszystkie loadery/DOSy uruchamiające standardowe pliki binarne siedzą w pamięci od $700 i jedynie starają się zajmować jak najmniej.
Żaden plik binarny zgodny ze standardem nie będzie na pewno pisał nic od $0700 do miejsca które już musi naprawdę koniecznie zająć ze względu na swoją objętość. (wyjątkiem bywają oczywiście produkcje XXLa :P ).
Naturalnym dla dowolnego loadera miejscem jego umieszczenia jest 7ma strona i to od jej początku. Loader bardzo kulturalny ustawia jeszcze MEMLO na swój koniec :) . Loader idealny nie "dotyka" żadnej komórki na stronie zerowej czy gdzieś indziej a swoje zmienne/liczniki trzyma wewnątrz siebie na 7mej stronie, realizując je (niestety) jako kod samomodyfikowalny.
Jeśli coś się na załaduje tak napisanym loaderem (pod warunkiem oczywiście, że cała reszta procedur ładujących i uruchamiających kolejne bloki jest O.K. :) ), to nie jest wina loadera tylko tego czegoś.
Nie ma ucieczki, gdzie to napisałem? Mam bufor cykliczny i mogę go w sumie umieścić przed loaderem, bo na razie jest za od $800; ale dlatego tam jest, bo jest opcją. Bufor cykliczny musi być na granicy stron pamięci. I głupio było by mieć 700-770, dziura, 800-8ff.
Ale mimo napisania wszystkiego idealnie, znalazły się chyba ze 2 gry, które się nie odpalały... i była to ich wina! :P Wystarczyło minimalnie poprawić ich sposób ładowania i już.
A pamiętasz że plik binarny może nie mieć bloku RUN i wtedy uruchamia się od .... i tu są dwie wersje :) (a spotkałem się i z trzecią, ale najmniej sensowną, choć najłatwiejszą do zaprogramowania w loaderze). I, jeśli dobrze pamiętam, to z tego powodu wspomniane wyżej 2 gry się nie odpalały.
Te dwie najpopularniejsze opcje to: - adres pierwszego ładowanego bloku (tak jest w większości loaderów więc i w Micro Sparta DOS) - adres bloku, który został załadowany najniżej w pamięci (i tak chciały się - z tego co pamiętam - uruchamiać te gry, z którymi był problem, wystarczyło dodać blok RUN z prawidłowym adresem na końcu).
A trzecia (najłatwiejsza do ogarnięcia) to ostatni ładowany blok.
Program NameCopy z tajemnic atari w ogóle nie ma RUN ale za to ma tylko INIT. Co w praktyce oznacza, że ten INIT jest jak RUN. No ale jednak INIT.
@Pecus Któraś gra (nie pamiętam która) wczytuje się od $0700. Ale wydaje mi się, że to była przeróbka z pliku BOOT na XEX. Po prostu ktoś zrobił grę kasetową co ładowała się od razu Start+Option i szła od $0700.
Faktycznie pasowałoby gdzieś tę wiedzę o tych loaderach zebrać. Bo podejrzewam, że nie jeden już przechodził i będzie przechodził przez tę plątaninę kombinacji.
Ale to nie jest jakaś wielka wiedza niezmierzona. Każdy kto robił jakiekolwiek pliki xex i próbował je potem odpalać jakimkolwiek loaderem, szybko nauczył się, że najbezpieczniej jest robić wszystkie gry/programy od $2000, wtedy prawie wszystkimi loaderami i większością dosów da się to wczytywać, odpalać i śmiga. Jak zaczyna nam być ciasno w pamięci, to schodzimy coraz niżej z tych $2000 i wtedy już robimy selekcję jaki dos i/lub loader to udźwignie. Jak nie potrzebujemy dos-a, to możemy zjeżdżać w dół trochę śmielej. A loadery i dos-y wszystkie lecą od $700 standardowo, więc to właściwie jest już cała potrzebna wiedza na ten temat:-) Jak robimy coś specyficznego, to możemy sobie zafundować własny loader, wtedy też najlepiej go pisać od $700, bo przyda nam się być może uniwersalnie do wielu innych rzeczy. A dlaczego akurat od $700? Bo tak jest napisane w mapie pamięci, że od $700 do $1FFF jest to pamięć przeznaczona z założenia na DOS, a od $2000 zaczyna się wolna pamięć dla programów.
No jak się robi własny XEX to ok. Gorzej jak trzeba obsłużyć "cudzy". :)
Mam pomysł, jak znaleźć idealne miejsce. Ściągnę całe archiwum AOL, rozpakuję, a potem "skrypt" zmieli wszystkie XEXy i zrobi statystykę, ile razy dana komórka pamięci została inicjowana blokiem z XEX :)
i będzie wiadomo gdzie jest najrzadziej używany zakres
RUNa nie wykonuje się od razu jak się taki blok załaduje, tylko jak się skończy plik :) Przeciwnie niż INIT, który odpalić trzeba bezpośrednio po jego załadowaniu.
Tak się zastanawiam czy nie powinno istnieć osobne narzędzie "XEX2XEX", które by posprawdzało xexa na wszystkie strony. Czy ma po kolei INITy, czy ewentualnie uzupełnić poprawnie o RUNa. No i z "automatu" zaproponować adres loadera. Czyli cała wiedza o wszystkich kruczkach xexa.
Po takim zmieleniu loader szedłby już jak po sznurku.
Nie wiesz, co jest po pierwszym inicie, albo po kolejnym. Jest sobie np. Screen przed grą i wszystko resetuje. Niestety, to tylko narzędzie z grubsza. Poza tym taki złośliwy xex może być uzależniony od kolejności ładowanych bloków, initów etc. Więc to wycinanie ffff-ów wewnątrz pomiędzy blokami to może być spoko (bo loader w ogólności po napotkaniu start = ffff powinien jeszcze raz załadować start i iść dalej), ale reszta... raczej nie.
Mam taki pomysł, żeby przemielić wszystkie gry homesofta na kartridże. Mam opanowane już szybkie testowanie wczytywania (niestety ręczne) ale grę można przetestować w jakąś sekundę.
@gienekp: trochę nie rozumiem pomysłu robienia loaderów pod xexy konkretne. Tzn. rozumiem jak ktoś z jakiegoś konkretnego powodu musi zrobić jakiś dziwny xex i wtedy robi sobie do tego jednego xex-a odpowiedni specjalistyczny loader, chociaż nie przychodzi mi taka sytuacja przykładowa do głowy na potwierdzenie że może istnieć taka potrzeba dziwna:-)
Generalnie jak xex jest zrobiony poprawnie, to loader poprawny go załaduje. Loader powinien być poprawny, a nie dopasowany do niepoprawnych xexów. Tak myślę. W przeciwnym razie, to zaczyna mi przypominać sytuację, jak byśmy we wlewie paliwa w samochodzie z dieslem instalowali specjalny system rurek, zaworów i czujników, które sprawdzą czy czasem użytkownik nie leje benzyny do diesla, czy tam odwrotnie i wtedy odpowiednio wykona myślenie za użytkownika.
Od zawsze była sytuacja taka, że jak jakiś xex nie działa, to się szuka innej jego wersji, która jest poprawiona, a jak nie ma to trzeba xexa poprawić niepoprawnego, a nie loader żeby działał na tyle niepoprawnie żeby wczytał niepoprawnego xexa:-)
Takie moje luźne przemyślenia filozoficzno-egzystencjalne:-)
Bardziej mi chodzi o to, że po samych blokach w XEX automat może podać, które adresy są zabronione. Bo że uruchomiony kod w INIT może wysadzić wszystko to inna sprawa.
Natomiast taki tools byłby przydatny też dla innych narzędzi. MaxflashStudio ma wybierany adres loadera, ale nigdy nie wiadomo co wybrać.
Inne GUI zanim składałoby do kupy carta, przejechałoby każdego xexa i możliwie maksymalnie przygotowało go do wczytywania. Inaczej loader to będzie coraz więcej "ifów" na wypadek tego czy tamtego.
@Mq Dokładnie o to samo mi chodzi. :) Loader powinien być prosty i dokładnie ogarniać standard. Natomiast zepsuty XEX powinien naprawić jakiś inny "wcześniejszy" tools. Jedynie co loader może zrobić to zmienić adres potrzebnego zakresu RAM. I to też mogłby zrobić jakiś analizator proponujący adres bezpieczny.
Ciekawostka, kilka gier homesofta doczytuje pliki, np: Barbarian, Karateka, Goonies, Winter Olympiad, Gauntlet. Ciekawe, czy ma na swoich dyskietkach mini-dosa. Może coś a/la xbios?
Ciekawa sprawa z tymi grami. Może ktoś wie, czy plik XEX dla DOSu tak samo ma się zachować dla kasety? Chodzi o doczytywanie. W DOSie troszkę łatwiej, no z magnetofonem to trzeba i silnik wyłączyć i poczekać, a przewijanie już manualne jest. Chyba że XEX dla kasety to lekko na siłę został dostosowany. Są gdzieś jakieś archiwa, kto w ogóle wymyślił ten format?
Bo generalnie menu4car ma dwie warstwy. Jedna PCtowa, gdzie można jakoś przygotować wcześniej dane, ewentualnie coś naprawić w spitolonym xex. W części drugie ATARowej to już loader musi dać sobie radę z tym co mu podano.
Tak w zasadzie to nawet nie potrzeba do carta XEXa wsadzać, ale dowolną strukturę blokową. Zastanawiam się, czy jakby w danym banku carta, była procedura dla danych w tym banku. To jeżeli kopiowanie nie szło by w adres A000-BFFF to nie potrzeba w ogóle RAM zabierać.
Xex jest niezależny od systemu, każdy dos może mieć inny format pliku binarnego. Np. Sparta DOS X. A natywny jest boot i jest podobny do formatu binarki c64, ale jednak bardziej rozbudowany.
Na Atari na magnetofonie właśnie z powodu doczytywania zapis ma długie przerwy, np. w basicu list „c:”. Ale w przypadku gier to marnotrawstwo, więc są krótkie i martw się człowieku. Lekarstwem jest analiza pliku i przy zapisie po napotkaniu bloku init danie po nim długiej przerwy. Po inicie silnik jest wyłączany i włączany z powrotem po powrocie. I wszystko działa :) Atari był chyba jedynym komputerem domowym, przynajmniej mi znanym, który pozwalał przetwarzać dane w locie przy użyciu magnetofonu. Commodore I Spectrum ładowały tylko binarne bloki pod miejsce w pamięci i koniec.
Czyli tak jak pisałem... :) Choć koniec 6tej strony mniej "oblegany", no ale to dlatego, że wiele programów ładuje sobie pomocnicze procki na 6tą stronę (jest pik na wykresie :) ) nie wypełniając jej w całości.
Coś jest z tymi danymi nie tak, bo zbyt wiele XEXów ładuje się wg nich na 7mą stronę. Czy aby na pewno przeanalizowałeś tylko prawidłowe pliki binarne DOSa? Bo wiesz, baza bazą, nazwy plików można nadać dowolne, a zawartość.... różnie bywa.
A co do XEXa i jego budowy/formatu.. Faktycznie jest ona niezależna od systemu operacyjnego (ROM), ale mamy tylko jeden format pliku binarnego DOS w Atari. i oczywiście rozszerzenie tego formatu używane przez SpartaDOS - ale to dalej rozszerzenie jednego formatu. Oczywiście mogły powstać osobne formaty dla różnych DOSów, ale na szczęście nie powstały :)
Wszelkie "wariacje" wprowadzające nazwy programu itp. w dalszym ciągu trzymają się tego standardu: ->link<-
Po rozpakowaniu archiwum pod linuxem dałem polecenie find dla XEXów. Tak powstała mi lista. Następnie napisałem programik co wczytywał daną pozycję z listy, sprawdzał nagłówek czy jest FFFF. Jeżeli tak to uznawałem, że to jednak plik XEX. Następnie w danym pliku XEX, program odczytywał po kolei bloki tak jak to robi loader. I np. jak był np. zakres $0600 - $0620, to te pozycje w tablicy dostawały PLUS 1. I tak powstawał histogram.
Czyli to co jest to są bloku plików XEX. Jeżeli jakiś program po INIT dodatkowo coś mieszał wykonując kod to już tego nie ma.
Ciekawe wnioski: - programiści lubili zaczynać od pewnych adresów a kończyli wiadomo różnie, stąd kształt piłokształtny - tylko jakieś 50% XEXów ma RUN, czyli startują INITem - średnio wypada dwa INITy na XEXa - loader na 7 stronie nie da więcej niż 90% "sprawności" - lubiany jest początkowy zakres pamięci stosu, końcówka rzadko
Dla mnie jeden wniosek jest jasny, przy bardzo krótkim kodzie w RAM najlepiej schować się pod koniec stosu.
Edit: Dodałem plik "files.txt", który był listą plików do analizy.
Wyciągnąłbyś jeszcze listę tych (ponad 400) pozycji, które ładują się na początek 7mej strony.
To bardzo ciekawe, że tak dużo XEXów ładuje się tam gdzie nie powinno (plik binarny DOSu z definicji nie powinien ruszać obszaru DOS, bo podcina gałąź, ktora go ładuje :) ). Taki program nie da się załadować spod DOSa, ani żadnym znanym loaderem (Micro DOS - pierwszy loader jaki w życiu widziałem :) , CHAOS LOADER, SDLOAD, Micro SParta DOS, Speed Initializer, COS, "wykrzyknik", itp.).
No też o tym pomyślałem i dałem na printfa. Wylosujcie jakąś pozycję i sprawdźcie niezależnie. Bo może ja mam jakiś babol.
Albo może jest tak, że wczytuje się pierwszy blok, a potem jest INIT i dalsze dane nie mają nic wspólnego z blokiem dos? I te adresy to jakiś random danych.
Edit. Sprawdzam kolejną pozycję i znowu czeski wyrób. Oni mieli jakiegoś swojego DOSa?
Edit2. To nie są jakieś Basicowe patenty? Że był program golas w Basic. On jest wtedy robiony od $0700. I ktoś dorobił sprytny loader? Bo pasowałby nam taki loader dla BAS :)
Ale to program pisany na kolanie :) Swoją drogą kiedyś czekaliśmy na wczytanie jednego XEXa kilka minut, a tu analiza wszystkich bloków wszystkich gier niecałe 4 sekundy :)
Skoro brałeś wszystkie bloki z wszystkich xexów, to może być tak, że pod te $700 przykładowo w większości tych programów ładują się jakieś dalsze bloki, a nie pierwszy, przy czym w pierwszym bloku może być jakiś własny loader, np. mniejszy, albo bardziej specjalizowany, albo po prostu przeniesiony w jakiś zupełnie inny obszar pamięci, bo tak komuś było wygodnie. Wyobrażam sobie przykładowo taką sytuację, że pierwszy blok ładuje własny loader który ma wbudowany np. jakiś dekompresor i dalsze bloki ładuje sobie np. z dekompresją w locie, a początkowy pierwszy blok musi załadować dowolnym standardowym dosem lub loaderem. Wydaje mi się, że z tego typu względów warto by było analizować tylko pierwszy blok gdzie się ładuje... chociaż nie, bo może też być sytuacja, że kolejny blok ktoś ładuje z dupy pod $700... Eeee, no to nie wiem, ale rzuciłem sobie kawałek przemyślenia z mojej głowy:-)
No właśnie to nie takie proste. Trzeba przyjąć uproszczenia, nie ma (poza uruchomieniem i śledzeniem programu, a i to nie daje żadnej gwarancji) rozwiązania, co poda w 100%, że z tym loaderem "ten kod działa" a "ten nie działa"
Uwaga na pliki kopiowane programem NCOPY, bo dokładają na początku programu blok z nazwą programu ->link<- i to trochę psuje ideę uruchamiania programu przez skok do pierwszego bloku.
Dzięki za uwagi - ponieważ ten nagłówen jest przez NCOPY maszynowo dodawany, można to wywalać w preprocesingu.
Właśnie testuję narzędzie, co robi z dyskietek Homesofta flashery JCart/MaxFlash. Nie działa szybko, bo kompresuje, ale działa :) W wyniku powstaje z 50 kartridży, co daje średnio niecałe 10 dyskietek na kartridż (zapis plikami z tych dyskietek). Pliki zapisywane na kartridż są po kolei dyskietkami w kolejności umieszczenia.
@Mq: Taki loader zaszyty w pliku binarnym nie ma szansy zadziałania w sposób jaki opisujesz. Jego uruchomienie będzie wymagało przeczytania pliku on nowa (bo tylko loader, który rozpoczął ładowanie tego pliku "wie" który bajt jest następny do pobrania i gdzie znajduje się bufor itp. )
Jeśli mógłby w ogóle zaistnieć (loader we wnętrzu pliku binarnego), to musiałby ponownie zacząć ładować ten plik, więc musiałby znać jego nazwę (upraszczam trochę :) ), tak więc nie można byłoby zmieniać nazwy pliku. Dodatkowo musiałby umieć obsłużyć konkretny nośnik fizyczny - więc taki plik nie odpalałby się z innego formatu dysku, czy też po skopiowaniu na kasetę itp.
Takie rozwiązanie zrównałbym z programem całodyskowym, bo tego typu plik byłby przywiązany skutecznie do nośnika, co całkowicie mija się z ideą standardowego pliku binarnego.
I takim rozwiązaniom po prostu jestem przeciwny, więc tego typu plik, jeśli by istniał, wylądował by od razu w śmietniku. (pozdrowienia dla XXLa :) ).
To właśnie miałem na myśli pisząc "to nie takie proste" :) Trochę tak działa TurboBasicXL, że się sam sobie loaderem robi. I nie wczyta się z kartridża, chyba, że tam minidos będzie.
To prawda. Zamiast to zrobić po ludzku to Ostrowski zrobił jakiś chory mechanizm zakładający że otwarty jest #1 i się do niego odwołuje z inita. Tylko po to, żeby załadować kawałek siebie pod ROM. Można by to wreszcie raz na zawsze przerobić.
Może tak być, że ktoś robił pod emulatorem i w ogóle nie sprawdził na żywym Atari. Współcześnie ludzie nieraz się bawią w programowanie, a nie mają w ogóle prawdziwego sprzętu. Np tak pisze gry i programy na Atari niejaki zbyti:-) Tzn. nie twierdzę, że on robi takie błędy, chyba raczej nie, ale on faktycznie Atari w ogóle nie posiada:-) Ja tak w tym roku też przypadkowo zrobiłem na Grawitacji pisząc Laskę Opata:-) Pomyliłem się i wrzuciłem od $700 blok z muzyką. Potem o tym zapomniałem, pisałem cały czas pod emulatorem, więc wszystko działało elegancko. Problem wyszedł w momencie jak już gotowe prace były testowane na sprzęcie prezentacyjnym i nie szło niczym mojej gry załadować. Rzutem na taśmę szybko przerabiałem. Wersja ostateczna Laski Opata ładuje się od $2000, bo już zrobiłem prawilnie, a gra jest małą, więc nie ma tam szarpania się z pamięcią. W każdym razie piszę to, żeby wskazać że mogą się takie przypadki zdarzać przypadkowo:-)
Co do mojej koncepcji wcześniejszej z loaderem samosięloadującym:-), to pisałem szybki pomysł z czapki, dzięki Pecuś za naprostowanie:-)
