Oto co napisano w tajemnicach atari nr 8/91 w cyklu "Jak powstaja DOSy"
Tak powinien zachowywac sie dobrze napisany DOS w teorii.

Istnieją dwa wektory, które należy właściwie ustawić z punktu widzenia obsługi RESETu. Są to: DOSVEC (słowo 10 czyli $a) oraz DOSINI (słowo 12 czyli $c). Po naciśnięciu klawisza RESET system operacyjny wykona skok do procedury znajdującej się pod adresem zapisanym w DOSINI. Powinny się w niej znajdować instrukcje uaktualniające MEMLO, HATABS oraz zamykające wszystkie lokalne pliki (RESET zamyka wszystkie bloki kontroli wejścia/wyjścia, więc nie ma możliwości zamknięcia plików na dyskietce). Wektor DOSVEC natomiast zawiera globalny adres powrotu do DOS-u, przykładowo wydanie w Basicu polecenia DOS spowoduje praktycznie skok przez wektor DOSVEC. Pod adresem wskazywanym przez słowo 10 powinny przede wszystkim znajdować się instrukcje kasujące flagi przerwania i trybu dziesiętnego (CLI oraz CLD), inicjujące stos (LDX #$ff; TXS),zamykające wszystkie pliki, uaktualniające tablicę HATABS (jeśli np. napisaliśmy bardzo ważny program w Basicu, a z bliżej nieokreślonego powodu tablica została zniszczona, to ta]de rozwiązanie może umożliwić nagranie stworzonego programu).

Dlatego też nie używam toporów typu DOS II+/D :) - Lzd; pytanie - gdzie Sparta X trzyma memlo ?? - sorry nie kodze normalnie, winc tylko pytam - nie bić prosze  :twisted:

Dziekuje za informacje Lizard i Mikey.

Po tych wyjasnieniach, a w szczegolnosci po uwagach na temat odmiennosci dzialania Sparty, chcialbym blizej zapytac, jak ten system radzi sobie z prostymi programami uzytkowymi, na przyklad, ktore laduja sie zwykle od adresu $2000 i zupelnie nie przejmuja sie zagospodarowaniem strony zerowej powyzej $80.
Slyszalem, ze programy pod Sparte sa relokowalne, stad wzmianowane programy rezydentne, domyslam sie, bardzo czesto gniezdza sie w pamieci komputera. Przypuszczam, ze jesli memlo jest za wysokie, to program sie nie wczyta, co oznacza, jesli memlo nie bardzo mozna w programie zmienic (np. program juz krazy w obiegu), ze i tak trzeba bedzie zrezygnowac z programow rezydentnych w systemie, a przynajmniej z wiekszosci z nich (i ich wiekszej liczby jednoczesnie).
Stad chyba decydujac sie na niski adres poczatkowy programu, nie bardzo nalezy sie przejmowac koniecznoscia zachowania przyjaznych warunkow dla innych programow - rezydentnych. Takie moje przypuszczenia i ocena, nie wiem, czy mozna sie z tym zgodzic.

Innym problemem dla takiego rozbudowanego i przyjaznego programom rezydentnym systemu jak Sparta, jest chyba pamiec dodatkowa w bankach. Jesli program zaklada ich uzywanie, powiedzmy z mozliwoscia ich swobodnego wyboru, to czy Sparta jest w tej mierze sie w stanie "dostroic".

Inna watpliwosc, czy Sparta umozliwia bezproblemowe wykorzystanie pamieci pod romem (zdaje sie, ze tak, jesli jest odpowiednio skonfigurowana) i czy nie jest dla niej problemem przejmowanie, chocby na czas dzialania programu, wektorow przerwan (pewnie nalezaloby sie "doczepiac" do nich, ale czy jest to wogole dopuszczalne przy zalozeniu, ze programy rezydentne odpadaja), oraz czy mozna wylaczajac rom wpisac w lokacje $fffa-$ffff wlasciwe dla programu adresy. Nalezy moze zrobic kopie zawartosci tych adresow, a przed oddaniem systemowi sterowania, odtworzyc ich zawartosc?

Jeszcze jedno pytanie. Wracajac do tematu postawionego w temacie watku, do jakiego dosu z tych dwoch, o ktorych byla tu juz mowa, bardziej podobny jest Mydos, wedlug tylko tego kryterium?

Oczywiście. To jest chyba jedyny cywilizowany sposób korzystania z wektora przerwania, niezależnie od tego, czy "wpinasz" się z własną procedurą w łańcuch dotychczas zainstalowanych procedur, czy zastępujesz wszystko własną procedurą.

Według którego kryterium, bo się zgubiłem  ;) MyDOS ma MEMLO w okolicach $2000 (nie wiem dokładnie, ale raczej nie wyżej), nie ma w nim czegoś takiego jak relokowalne binaria, nie jest ulokowany w dodatkowej pamięci ...

Generalie przestrzeń dla programów została przyjęta właśnie od adresu $2000. Nazwałbym to już tradycją. ;)

SDX również nie przejmuje się zbytnio "starszą" połówką strony 0.

Wszystkie programy będące nakładkami są relokowalne i umieszczają się, bądź są umieszczane pod adresem wskazywanym przez MemLo. MemLo po takiej operacji podnoszone jest o odpowiednią wartość (musi to zrobić Twoja nakładka :!: ).

Tak jak poprzednicy napisali. Pod SDX w trybie Banked raczej nie zdaża się, by nakładki (wszystkie razem) zajmowały pamięć powyżej $2000.

Program się wczyta, ale jeśli nadpisze np. procedurę jakiegoś przerwania, to... sam sobie dopisz scenariusz :)

No niestety, trzeba będzie rezygnować. Wskaźnika MemLo lepiej samemu nie ruszać (nie ma potrzeby), chyba, że program ma być nakładką, wtedy należy ten wskaźnik ustawić ponad nią. Nakładki pisane specjalnie dla SDX nie muszą tego robić, wystarczy, że zmienią flagę Install na różą od zera (polecam DEC INSTALL ;) ), a system już sam zadba o zmianę wskaźnika.

Nie można się z tym zgodzić. Lepiej podnieść trochę adres ładowania własnego programu niż narażać się systemowi i użytkownikowi. Big Brother is watchig you. Jak się nie będziesz przejmować, to wszyscy się na Ciebie obrażą. :P

Sparta sama z siebie nie może przeskoczyć z banku do banku. Pin podał receptę na to. Jest jeszcze jeden problem z dodatkową pamięcią pod SDX. Ten DOS bardzo nie lubi, gdy program sam zmienia banki. Zwis grozi, gdy SDX pracuje w trybie Banked i: ˇ ładowany program zmienia bank ładowanym blokiem:

    .or $D301
    .by bank
    .or $4000
; kod lub dane

ˇ wywoływana jest operacja I/O urządzenia "Dn:" lub urządzeń Sparty (DSK, CON, CAR, itp.) po ręcznej zmianie banku

Gdy pracuje w trybie None lub Banked, to tak.

Chodzi Ci o przerwania sprzętowe ($FFFA-$FFFF)? Możesz je dowolnie wykorzystywać, ale na koniec przywróć je do stanu początkowego. SpartaDOS wstawia tam wektory procedur podmieniających RAM na ROM i wywołyjących właściwą procedurę rozpoznania źródła przerwania. Nie wszystkie programy korzystające z RAM-u pod ROM-em i zmieniające te wektory przywracają je i później są problemy (z powieszeniem kompa włącznie).

Dobrze kombinujesz. ;) Jest to reguła we wszystkich systemach niezależnie od komputera i systemu. Program zmieiający wektory przerwań musi je przywrócić najpóźniej przy kończeniu pracy. Wyjątkiem są programy rezydentne. Ale nawet onne muszą mieć mechanizmy sprzątania po sobie na wypadek usuwania ich z pamięci (może ktoś napisze kiedyś podsystem zarządzania pamięcią w Atari).

MyDOS ma najwięcej wspólnego z DOS-em 2.5. Jeśli chodzi o przerwania, to należy z nimi ostrożnie jak pod Spartą (i gdziekolwiek indziej), jeśli chodzi o dodatkową pamięć, to można zaszaleć jak pod DOS-em II+/D, najwyżej skopiesz sobie (i innym) ramdysk. 8)

[ Dodano: 22.04.2005 15:49:42 ]

Większość scenowych produkcji, albo nie ma opcji wyjścia, albo wychodzi przez reset (JMP $E474). Za takie wychodzenie z programu powinni wieszać na miejscu. Wynika to z lenistwa koderów, którym nie chce się napisać prostej procedury zapamiętywania ustawień i przywracania ich na koniec. :?

Załóż po prostu, że przywracasz stan wszystkich zmiennych systemowych, w jakich twój program grzebie - chyba, że celem jego działania ma być zmiana ich wartości.

Lizard pewnie miał na myśli to, co zilustrował przykładem: SDX nie lubi, kiedy  plik binarny zawiera sekwencję powodującą, że loader wstawia jakąś wartość bezpośrednio do PORTB, bo następuje wtedy natychmiastowe przełączenie banku pamięci i kod DOS-u po prostu znika z przestrzeni adresowej.

Natomiast jak już program się załaduje, może sobie przełączać banki pamięci jak chce, byleby spełnił 2 warunki:

1) nie uszkodził kodu DOS-u, jeśli ten siedzi w którymś z banków (jak to poznać - zob. dokumentacja do SDX)

2) przywrócił przy wyjściu taką wartość PORTB, jaką zastał.

Zawsze mi się wydawało, że to zalezy od rozszerzenia pamięci. To znaczy, są takie rozszerzenia (np. 256k TOMS), których SDX nie rozpoznaje w całości, widzi np. tylko 192k. Przełączenie na bank, który Sparta "widzi", nie powoduje złych skutków, natomiast przełączenie na jakikolwiek z pozostałych powoduje zwis przy próbie odwołania się do urządzenia "D:".

Tu nie chodzi o banki, których fizycznie nie ma, tylko o takie, które są, ale SpartaDOS X o tym nie wie. Dlatego wykrywanie sprytną procką nie ma tu wiele do rzeczy, tu trzeba DOS-owi (a nie sobie) udowodnić, że te banki istnieją  ;)

Już jest od dawna. :) Draco powinien to gdzieś mieć. Jak nie on, to Pinek.

Pozatym, zmiana banku agłówkiem programu jest proszeniem się o kłopoty. Nie lepiej załadować fragment pliku do pamięci podstawowej, przełączyć pamięć i wtedy przenieść dane? Ładnie, zgrabnie i elegancko. Dodatkowo możemy łatwo kontrolować banki bez ryzyka, że spróbujemy włączyć bank, którego nie ma (tym razem fizycznie).

Mnie się zawsze Sparta wiesza, gdy próbuję ładować program zmieniający banki metodą podaną przez Lewisa. Niewykluczone, że przyczyną jest moje rozszerzenie - 320 kB CompyShop. To rozszerzenie widziane jest przez SDX w połowie (8 banków zamiast 16-tu).

Program, ktory zaklada w swoim dzialaniu, juz po zaladowaniu do pamieci i uruchomieniu pod Sparta w trybie Banked, doczytywanie danych do dodatkowych bankow pamieci, spowoduje zwis kompa, bo procedury odpowiedzialne za odczyt z urzadzenia zewnetrznego siedzia takze w ktoryms z bankow?

Jak technicznie moze to wygladac, skoro PORTB jest rejestem tylko do zapisu? Gdzie znalezc informacje na temat "aktywnego" banku?

Zapytam wprost, nawet takich zmiennych jak DMACTL, SDLST?

Oddzielna procedura GR.0 istnieje? Domyslalem sie, ze moze cos w romie takiego jest, ale nie natrafilem na zadne wzmianki na jej temat.
Pewnie ustawia tez przy okazji dlisty zmienne DMACTL, SDLST i pare innych zwiazanych z wygladem ekranu?
Czy Draco miales tylko na mysli wewnetrzna dla programu procke realizujaca podobne zadanie?

Draco, wielkie dzieki!

Dokladnie tego potrzebowalem. Gdyby nie ta podpowiedz, to pewnie myslalbym nad wlasna procka przywracajaca ekran do stanu wyjsciowego z wstawianiem dlisty wlacznie. Roznica potezna.

Tak tylko na marginesie zapytam, czy bajt $9b musi na pewno byc po "E:", przy otwieraniu ekranu? Wyprobowalem, ze i bez tego bajtu na koncu nazwy pliku otwieranego do odczytu (dajmy na to: "D1:PROG.OBJ"), mozna procedure CIO wywolywac z sukcesem.