To nie SI, tylko GR.0. :P

Znak końca moża pominąć, gdy urządzenie nie obsługuje nazw plików (E:, K:, S:, P:) lub, gdy po nazwie można zorientować się, gdzie jej koniec (np. fname.ext - rozszerzenie 3-znakowe). Należy tylko zwrócić uwagę, by zaraz za nazwą nie było znaku ">" (MyDOS i SpartaDOS) lub "" (tylko SpartaDOS X). Inaczej sterownik "D:" uzna naszą nazwę za nazwę katalogu, a śmiecie za nią za nazwę naszego pliku. Tak więc jeśli nie chcemy mieć popularnych w Windowsach błędów przepełnieia bufora :mrgreen: , to lepiej kończyć nazwę bezpiecznym $9B lub chociaż wartością 0.

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?

Precyzyjna i pelna odpowiedz, dziekuje.

Przydatnosc procedury jest oczywiscie duza. Musze jednak wyjasnic, ze planowalem rozwiazac problem okreslania dostepnych uzytkownikowi bankow w sposob zdecydowanie bardziej prymitywny.
Otoz myslalem nad zrzuceniem odpowiedzialnosci na wyznaczenie bankow niedostepnych dla programu, na uzytkownika, poprzez odpowiednie przygotowanie pliku konfiguracyjnego, doczytywanego tuz po uruchomieni programu. Wczesniej tylko typowa procedura rozpoznajaca wszystkie dostepne banki pamieci dodatkowej tworzylaby ich tablice, z ktorej to eliminowane bylyby banki obecne wlasnie w pliku konfiguracyjnym.
Moze nie jest to rozwiazanie optymalne dla uzytkownikow Sparty, ale sadze z analizy odpowiedzi, ze do zaakceptowania.

W tablicy t_ nie odnajduje pozycji, gdzie wskazane bylyby banki zajmowane przez Ramdysk. Moze jest to zapisane w innym miejscu, a moze jest to rozwiazane w ten sposob, ze banki zajmowane sa "od tylu" tablicy bankow, a wiec nie mozna swobodnie dobierac bankow dla Ramdysku.

Przed powrotem do Sparty, nalezy rozumiem przywrocic tym samym zawartosc banku podstawowego (z tablicy t_, $FF zwykle). Inna zawartosc banku podstawowego moze zaistniec w jakich okolicznosciach i czy wowczas istotnie bank $FF bedzie do dyspozycji uzytkownika?

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?)

W MyDosie mozliwe jest wczytanie programu nie "wchodzac" do podkalogow (np. D1:MSX:BRULL.COM). D: w tym czasie moze wskazywac na zupelnie inna sciezke, niz ta, spod ktorej wczytany zostal program.
Zapoznawalem sie dzis troche z dokumentacja SpartaDOS X i wynika z niej, ze takze mozliwe jest wczytanie programu ze sciezki roznej od biezacej.
Mozna ewentualnie przyjac, ze nalezy tak ustawic sciezke, aby wskazywala na miejsce, w ktorym znajduje sie plik konfiguracyjny programu. Tylko, ze bedzie to mala niedogodnosc dla uzytkownika.

SpartaDOS X ma mechanizm zwany szlakiem poszukiwań. Jest to zmienna środowiskowa PATH, w której zapisane są katalogi, w jakich szukany jest otwierany plik (nie koniecznie wykonywalny). Polecenie OPEN #1,4+32,0,"D:twojplik.dat" spowoduje przeszukanie wszystkich katalogów zawartych w zmiennej PATH (od pierwszego do ostatniego), a na końcu katalogu bierzącego i otwarcie podanego pliku z katalogu, w którym został znaleziony jako pierwszy.

Np.
PATH=c:dos;b:programy;e:gry
Plik twojplik.dat znajduje się w katalogach: b:programy, e:gry i w katalogu bieżącym, czyli tym, w którym zajdowałeś się w momencie uruchomienia programu (np. a:moje).
Wykonanie powyższego OPEN spowoduje otwarcie pliku twojplik.dat z katalogu b:programy.

Oczywiście nie musi to być wcale ten plik, o który Ci chodziło, bo program, który go otwiera był uruchomiony przez polecenie np. c:dostoolstwojplik. Aby sprawdzić pod SpartaDOS X (tylko ta wersja!) z jakiego katalogu został uruchomiony plik należy wykonać poniższy kod:

; Przepisanie urządzenia, ścieżki i nazwy uruchomionego programu
; pod adres wskazany przez rejestry AX

auxptr =   $15
device =   $0761
name   =   $0762
path   =   $07A0

g.path sta auxptr
       stx auxptr+1
       ldy #0
       lda #'D
       sta (auxptr),y
       iny
       lda device       ; urządzenie z jakiego został uruchomiony program
       ora #$30         ; przerabiamy na jego nr ;)
       sta (auxptr),y
       iny
       lda #':
       sta (auxptr),y   ; mamy już Dn:

       iny              ; teraz przepisujemy ścieżkę
       lda path-3,y
       sta (auxptr),y
       bne *-6
       cpy #3           ; jeśli program uruchomiony z bieżącego katalogu,
       beq ?skp         ; to brak ścieżki
       lda path-4,y     ; jeśli z wykorzystaniem szlaku poszukiwań,
       jsr ckspec       ; to brak '' lub '>' na końcu ścieżki
       beq ?skp
       lda #'>
       sta (auxptr),y

?skp   ldx #-1          ; przepisujemy nazwę
?cn    inx
       cpx #8
       bcs ?id
       jsr ?cc          ; przenosimy znak nazwy
       bne ?cn

?id    lda #'.          ; kropka rozdzielająca nazwę od rozszerzenia
       sta (auxptr),y
       iny

       ldx #8
?ce    inx
       cpx #12
       bcs ?in
       jsr ?cc
       bne ?ce

?in    lda #0
       sta (auxptr),y
       rts

?cc    lda name,x
       sta (auxptr),y
       iny
       cmp #$20         ; sprawdzamy, czy spacja (koniec nazwy)
       rts

ckspec cmp #'<
       beq *+8
       cmp #'>
       beq *+4
       cmp #'
       rts

Jak widać procedura nie robi nic szczególnego. Przepisuje tylko urządzenie, ścieżkę i nazwę pliku w formie strawnej dla OPEN. Wskaźnik auxptr może być umieszczony pod dowolnym adresem na stronie 0 ($15 jest dobrą lokalizacją nie kolidującą, ani z systemem, ani z ew. inymi zmiennymi pragramu).

Powyższa procedura jest lekką modyfikacją procki umieszczonej w Config Selectorze. Tam jest nieco krótsza, gdyż korzysta z paru procedur Sparty, który tu nie można użyć ze względu na ich "ruchomy" charakter ze względu na wersję.

O wiele łatwiej jest ustalić ścieżkę pod MyDOS-em, czy dyskową wersją SpartaDOS-u. Tak jak marok dobrze kombiuje, można skorzystać z adresu bufora kanału 0 CIO.

[ Dodano: 03.05.2005 00:23:15 ]
Lewis, QA jak i wszystkie "inteligentne" programy próbujące zgadnąć skąd zostały wczytane wykładają się pod SpartaDOS-em i MyDOS-em. To dlatego, że odczytują tylko numer urządzenia z DUNIT ($0301) i wstawiają go pomiędzy "D" a ":". ;) Pod MyDOS-em "Dn:" oznacza katalog główny dysku n, a pod Spartą katalog bieżący tego dysku.

Jeśli pod Spartą jesteś w katalogu D3:ZRODLA, w zmiennej PATH masz wstawiony katalog z QA, powiedzmy Twój D2:PROG, a katalogiem bieżącym dla dysku D2: będzie akurat D2:GNIOT, to QA będzie szukał pliku QA.SET w katalogu bieżącym dysku D2:, czyli D2:GNIOT.

Po MyDOS-em (drzewo katalogów takie samo jak w powyższym przykładzie ze Spartą), QA zawsze będzie szukało QA.SET w katalogu głównym dysku D2: i nie pomogą tu kombinacje z "CHDIR".

Tak, ale napisałeś to jako przypuszczenie, a ja przejrzyście naświetliłem temat. ;)

Z QA problem rozwiążałem kategorycznie - nie używam. :D Do Panthera z koleji naisałem krótki "skrypt" odpalany zamiast programu:

cd b:applspanther
x b:applspanther

Katalog bieżący zawsze jest sprawdzany na końcu. Chyba, że się go dołączy gdzieś w środku lub na początku PATH. (W przeciwieństwie do takiego za przeproszeniem MS-DOS-a, gdzie katalog bieżący sprawdzany jest przed PATH.)

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?

Dokladnie i w celu wygodnego pisania najlepiej wlasnie tego uzywac, bo zadowala i Sparte i MyDosa. Innych DOSow z obsluga podkatalogow brak (jak narazie ;) ).

No wlasnie, nawet nie wiedzialem, ze ma to podkatalogi... Bo nie uzywalem... ;)

..i tu ciekawostka. Graphisc Op. System v2.0 poprawnie widzi podkatalogi dosa XE, lecz z formatem Sparta coś już nie bardzo. Pomimo, że istnieje jakiś enigmatyczny ster dla SDX... diamond.sdx(!) - w gnatach wygląda jak plik dla X'a.

A wydawało się, że wyjście do dosa - to taka prosta rzecz :)