Super robota. Mam nadzieje, ze zostanie ona uwzgledniona w opracowywanej wersji SDX.
Wniosek stad taki, ze dostep do tablicy T_ jest jednak koniecznoscia w programach uzytkowych, a nie zakladanie okreslonej konstrukcji tej tablicy.

Zdaje sie jest miejsce na 16 wpisow (rowne maksymalnej liczba grup bankow). Przy zastrzezeniu, ze wpisy sie nie powtorza, nie ma obawy, ze sie wysypie.

[ Dodano: Czw Maj 19, 2005 2:00 pm ]
Problem dojscia do tablicy T_ i przetworzenia grup bankow na wartosci poszczegolnych bankow jest juz rozwiazany. Skorzystalem z podpowiedzi Truba w zlokalizowaniu danych tablicy, reszte rozwiazaly podpowiedzi Lizarda (lacznie z podanym kodem).
Obecnie probuje dodac wywolanie GR.0, ale niestety nie udaje sie to z jakis powodow. Proba wywolania konczy sie powrotem z komunikatem bledu $81.
Pierwsze skojarzenie mam takie, ze moze otwieram juz otwarty kanal (zerowy) i powinienem albo go sprobowac zamknac (pamietam, ze czytalem w TA, ze jest on zawsze otwarty i ze chyba nie mozna go zamknac), albo wywolac GR.0 z innego niz zerowy kanal (co tez nie bardzo wydaje mi sie dzialaniem poprawnym, skoro E: jest przydzielony wlasnie do kanalu 0). Co wiec robic, o ile wlasciwie interpretuje blad systemu?

Ponownie ladna procedurka Lizarda, za ktora naleza sie brawa.

Rozumiem, ze jext_on i jext_off maja stale miejsce w Sparcie niezaleznie od jej wersji, co jest bardzo wazne w odniesieniu do zmiennej wartosci adresu tablicy o jaka nam chodzi. Cenne spostrzezenie.
Wewnatrz tych spartowych procedur, podejrzewam, ze dostep do adresu, odpowiednio do wersji, $906 lub $908 (T_+4), odbywa sie za pomoca adresacji bezposredniej (indeksowej Y najpewniej), bo inaczej adres tej tablicy znajdowalby sie gdzies na stronie zerowej i mozna byloby to wykorzystac.
Jext_on ustawia bank xxxx00xx (dot. watrosci >=4; zgaszone bity, to wniosek jeszcze z pierwszej procki Lizarda) z grupy bankow rozpoznanych przez Sparte i wkazanych w tablicy na wejsciu przez akumulator. Rej. X pozostawia bez zmian.
Jest_off wylacza bank aktywny (i przelacza go pewnie na bank podstawowy) oraz pokazuje na wyjsciu w rej. A indeks z tablicy odpowiadajacy bankowi wylaczonemu.

W procedurze Lizarda, liczba zapalonych bitow akumulatora na wyjsciu okresla wielkosc dostepnej pamieci. Oprocz tego ta czesc procedury mowi nam, ze bity ROM i Basica oba sa zapalone w wartosciach bankow w T_+8 (maski), co mnie tez interesowalo.

Jesli sie pogubilem we wnioskach, to przepraszam. Smiale teorie, nie zawsze sa trafne. ;)

[ Dodano: Pią Maj 06, 2005 3:09 pm ]
Odnosnie wektra DOSINI. Moja watpliwosc wziela sie ze zwyklej niewiedzy na temat znaczenia klawisza RESET w komputerze wogole. Bo sadzielem, ze ma on prowadzic w dosie do powrotu do systemu, a jest czyms wiecej, co powinna sugerowac juz sama nazwa, inicjacja systemu, czyli przywroceniem pierwotnych ustawien (MEMLO dla przykladu).

Lizard, jesli sie zgodzisz, to chetnie zastosuje w programie Twoja procedure na rozpoznawanie sciezki, z ktorej zostal wczytany program pod SDX. Drobne dopasowanie jej do potrzeb programu bedzie wymagac jedynie podmiany tej czesci, ktora odpowiada za wpis nazwy pliku.
Z drugiej strony plik konfiguracyjny potrzebny jest mi tylko po to, aby ustalic zabronione z dostepnych bankow pamieci, a pod SDX mozna byloby z powodzeniem sie bez tego obyc, o czym pisales. Niemniej tej przewagi SDX nad innymi dosami raczej nie bede wykorzystywal, chociaz przyjrze sie mozliwosciom wplecenia odpowiednich poprawek w kodzie programu i jeszcze sie nad tym glebiej zastanowie (musialyby istniec rownolegle dwa sposoby korzystania z bankow w programie).
Starsze wersje Sparty (3.x) chyba nie bedzie mozna uzywac z programem korzystajacym z RAMu pod ROMem, a wiec separatory katalogow charakterystyczne dla tego tylko dosu mozna odrzucic.

Poza tym mialbym jeszcze takie pytania:
Sa jeszcze, poza MyDosem i Sparta, dosy umozliwiajace tworzenie katalogow na dysku?
Pod MyDosem uzywa sie separatora ":" dla oddzielenia katalogu i tylko ten znak jest w uzyciu?

Mysle wiec, ze program powinien przypominac o tym, czy plik konfiguracyjny zostal odnaleziony i doczytany (ewentualnie tez informowal, jakie z bankow zostaly wylaczone z uzywania). Mam nadzieje, ze banki zajmowane przez ramdysk uzytkownik bedzie w stanie w jakis sposob sam ustalic (nie mam wiedzy, czy to zawsze mozliwe). Zamierzam dolaczyc do programu tak skonstruowany plik konfiguracyjny, ktory wylaczy z uzywania wszystkie mozliwe banki dodatkowej pamieci (poniewaz program wcale ich do pracy nie bedzie potrzebowal). Poza tym rzecz jasna dokladny opis budowy takiego pliku, aby latwo bylo go samemu sporzadzic. To oczywiscie nie jest rozwiazanie optymalne dla uzytkownikow Sparty, ale nie chcialbym ograniczac mozliwosc uzywania programu jedynie do srodowiska tego DOSu.
Niestety wybor takiego rozwiazania rodzi jeszcze jeden problem dosc powazny. Mianowicie okreslenie sciezki z jakiej zostal wczytany program, poniewaz slusznym zalozeniem wydaje sie szukanie pliku pomocniczego do programu w tym samym miejscu, co sam program.
Chyba znalazlem sposob na rozwiazanie tego problemu, poprzez posluzenie sie adresem bufora nazwy wprowadzonej poprzez E: (kanal 0 IOCB). Nie mam jeszcze opracowanej procedury analizujacej wprowadzona nazwe i wyodrebniajacej sciezke prowadzaca do pliku (trzeba uwzglednic mozliwosc uzycia roznych separatorow dla oznaczenia podkatalogow), ale sadze, ze jest to rozwiazanie dobre.
Wymusza to tylko koniecznosc uruchomienia programu w dosie, poprzez E:, a nie jakims menadzerem plikow.

Mozna jednak chyba zalozyc, ze na 99,9% jest to na pewno bank $FF (niezaleznie czy to Sparta, czy inny DOS)?

Chcialbym jeszcze z ciekawosci zapytac, w jakim porzadku Sparta umieszcza w obszarze tablicy T_ "masek przelaczajacych banki", rozpoznane kombinacje aktywujace przelaczanie bankow pamieci. Chodzi mi o to, czy kody grup bankow (po 4) uszeregowane sa wg. swoich wartosci np. od najstarszego do najmlodszego w tej tablicy, czy nie ma takiego porzadku? (A co z bitami OS i Basica, czy sa ustawione czy zgaszone w tych maskach przelaczajacych banki?)

Po niekrotkiej przerwie, chcialbym jednak wrocic do tematu. Mam wciaz powazne watpliwosci jak sobie poradzic z obsluga dodatkowych bankow, a nie bardzo potrafie znalezc rekomendowana przez Draco dokunentacje do SpartaDOS na sieci (powinna byc tu: http://my.en.com/~russg/, ale maja przegladarka mi tam nic nie wyswietla).

Pojmuje problem z uzywaniem dodatkowych bankow pamieci w ten sposob, ze Sparta nie rozpoznaje wszystkich dostepnych uzytkownikowi bankow, przez co proba dostania sie do nich poprzez "reczne" przelaczanie i probe doczytania do nich danych z urzadzenia zewnetrznego powoduje zwis kompa. Dochodzi do tego problem umiejetnego pomijania w programie tych bankow, ktore zajete sa przez Sparte.

W takiej sytuacji, czy program dzialajacy wg. ponizszego scenariusza ma szanse dzialac pod Sparta w trybie banked?:

1. Zapamietanie aktualnie aktywnego pod Sparta banku.
2. Wybor banku wolnego i widzianego przez Sparte.
3. Wczytanie z urzadzenia zewn. danych bezposrednio do wybranego jak wyzej banku.

Przy powrocie do Sparty przywrocenie, wraz z innymi ustawieniami, poprzedniej zawartosci $d301.

Dodatkowo chcialbym dopytac, czy bank podstawowy jest zawsze pozostawiany wolnym do wykorzystania, czy nalezy zalozyc, ze Sparta moze tam cos waznego przechowywac?

Jeszcze pytanie odnosnie otwarcia E:. Zawartosc ICAX1 i 2 pewnie okresla tryb otwarcia ekranu, czy moglym zapytac jakie konkretnie znaczenie przypisane jest tym zmiennym?

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?

Sedno problemu postawionego w tym watku. Ja niestety nie bardzo wiem, ktore z ustawien nalezy przywracac, a ktore spokojnie mozna pozostawic gestii DOS'u. Mysle wiec, ze nie zawsze tylko lenistwo decydowalo o takim stylu pisania programow.

W takiej sytuacji, czy programy, ktore same przelaczaja banki w trakcie swojego dzialania, moga byc uruchamiane pod Sparta? Domyslam sie, ze w ktoryms z innych trybow pracy niz Banked, ale wowczas, czy pamiec pod ROM'em moze pozostawac wolna i czy rownoczesnie memlo bez nakladek w systemie nie przekroczy granicy $2000? Obawiam sie, ze nie, a wiec czy jest jakas dobra metoda korzystania z dodatkowych bankow pamieci dla programow dzialajacych pod Sparta?
A moze to zastrzezenie, ktore tu cytuje, nie dotyczy sytuacji "przejecia" przerwan przez dzialajacy program. Wowczas wystarczyloby tylko unikac bankow zajmowanych przez Sparte, a wskazanych programowi np. w  jego pliku konfiguracyjnym.

powyzej zamiast slowa memlo powinno byc adres ladowania programu, stad sens powyzszego zostal zle odczytany, za co przepraszam...

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?

Nie wiem, czy program zapisuje dane fontow wraz z naglowkiem okreslajacym miejsce ulokowania w pamieci i czy wartosc tego adresu mozna swobodnie okreslic. Jesli nie, to nalezaloby taki naglowek stworzyc, ew. skorygowac do wartosci umozliwiajacej rezydowanie w pamieci QA (szesc bajtow na poczatku pliku).
QA po wczytaniu sie, relokuje sie w dol pamieci, wedlug zawartosci memlo. Dlatego nalezaloby najpierw wczytac QA, wyjsc do dosu i dopiero teraz wykonac instrukcja typu LOA wczytanie fontow w odpowiednio dobrany obszar pamieci, po czym wrocic do QA instrukcja RUN dosa.
Adres fontow musi byc podzielny przez $400. Najlepiej zapewnic mu bezpieczenstwo umieszczajac go wysoko w pamieci i obnizajac w opcjach QA granice mozliwej do wykorzystania przez siebie pamieci. Chyba opcja nazywa sie MEMHI.
Drugi sposob. Zanim wczyta sie QA, wczytac fonty w pierwszy wolny obszar pamieci x*$400 - x*$400+$3ff, powyzej adresu wskazywanego przez memlo i podniesc memlo ponad dane fontow (x+1)*$400.

Draco, a moze daloby sie zrobic jakis w miare prosty konwerter z postaci generowanej przez Dissasembler na taka, ktora bylaby do przyjecia?
Nie musi to byc nawet na Atari.
Niestety z bledami w dissasemblacji kodu niewiele mozna zrobic poza recznym poprawianiem, co takze odnosi sie do drugiego disasemblera, ktorego, z powodu wlasnie stwierdzonego przeze mnie braku na sieci, postanowilem dodac w zalaczniku. (Kiedys sciagnelem go z istniejacej jeszcze wtedy strony Holmsa).

Draco masz oczywiscie racje, co do problemu. To prawda rowniez, ze stawiam sie w sytuacji czlowieka, o ktorym napisales, zabierajac sie za cos na czym sie slabo znam (programowanie na atari, w szczegolnosci korzystanie z systemu).

Argumentacja jaka przytoczyles na temat potrzeby uzywania wlasciwej drogi odczytu directory jest bardzo istotna i dobrze, ze przedstawiles to tak szczegolowo.
Natomiast wyjasnie dlaczego zalezalo mi na zastosowaniu wlasnie takiej metody odczytu directory (ta procedura powyzej to tylko przyklad, docelowo jej postac ma miec inna forme - uwzgledniajaca chocby reakcje na blad).
Przede wszystkim zalezalo mi na oszczednosci miejsca na bufor dla directory (w przypadku tej motody wystarczy strona pamieci i kazdorazowe odczytywanie wskazanego sektora directory).
Zastosowanie do programu, ktory z zaloznia wspolpracowac mial z gora 63 plikami (moze to dziwne, ale pewne ograniczenia przyjalem juz w programie - zastosowane bufory dla danych). Istotny stal sie tez dostep do niektorych innych bajtow wpisu w directory poza sama nazwa pliku, celem obliczenia, moze dosc problematyczny pomysl, "sum kontrolnych", tak aby miec pewna kontrole nad zmianami w directory dysku.

W przykladzie, ktory podalem, wystarczy tylko zamienic wektor z $e459 na $e453 - dzieki TeBe za podpowiedz.

Rzeczywiscie, bardzo fajnie pomyslane. Gratuluje inwencji Laoo. Dziekuje Draco za objasnienie!

Dla mnie 65816 pozostawal do wczoraj zagadnieniem slabo rozumianym, dzis dzieki temu tematowi, wydaje mi sie, ze jest troche lepiej. Byla to wiec dobra okazja do przyjrzenia sie blizej temu prockowi, co moze kiedys mi sie tez przyda.