1 Ostatnio edytowany przez piotrv (2006-01-18 15:23:43)

TeBe coś kiedyś pisał, że chciałby móc prosto korzystać z całej pamięci w Atari.
W tutorialu cc65 też coś o tym wspomniał.

W związku z tym, że program testowy doszedł mi w cc65 do 14kB i chociaż mam 320kB (RAM-cart) to i tak nie mogę odpalić Numena proponuje zrobić coś takiego:

Sterownik typu EMM386, ładowany w DOS w jakimś autostarcie, maksymalnie niezależny od rodzaju i wersji DOSa, pozwalający na allokację pamięci RAM-carta lub XMS w sposób uniwersalny - niezależnie od posiadanego sprzętu.

Główne funkcje:
- allokacja n banków (wynik: lista - nr banku, adres)
- zwolnienie listy banków (nr banku; nr banku)
- aktywacja / dezaktywacja banku
- informacja o aktywnym nr banku
- możliwość zablokowania przełączenia banku
- informowanie o dostępnej ilości banków (wszystkich / wolnych) i ich rozmiarze
- informowanie o rozpoznanym typie rozszerzenia (może być ciąg znaków + kod)

Allokowane bloki powinny przechowywać informację o tym, że są zaalokowane na trwale lub tymczasowo (np. dla RAM-dysków). Dzięki temu po wyłączeniu kompa RAM-cart nadal miałby poprzydzielaną pamięć - ale tylko dla RAM-dysków lub programów zapisujących coś na stałe.

Kiedyś pisałem sterownik do lepszego E: ale już zapomniałem jak się to robi. Poza tym nie wiem, czy taka informacja była by przydatna w tym projekcie.

Pytania:
- czy coś takiego już istnieje?
- od czego zacząć zgłębianie Atari, żeby coś takiego zrobić (chodzi bardziej o integrację z DOSem, przełączenie banku to chyba banał)

Zenon dystrybuuje kilka DOSów zrobionych specjalnie dla RAM-carta. Czy ktoś wie na czym polegała trudność zrobienia uniwersalnego sterownika do M: ładowanego osobno pod DOSem?
Przecież jest coś takiego jak RAM-CART Handler - TA 10/93, (http://tajemnice.atari8.info/10_93/10_93.html) - więc chyba jest to do zrobienia?

-----
Miłym dodatkiem byłaby obsługa RAMu pod ROMem jako dodatkowego banku.

-----
Odpowiedzi na pytanie: po co?
- żeby móc pisać uniwersalne programy wykrzystujące całą dostępną pamięć
- żeby móc uruchomić RAM-dysk i program wykorzystujący XMS jednocześnie
- żeby nie przerabiać wszystkich po kolei DOSów tylko po to, żeby obsługiwać nowe
  rozszerzenie pamięci

-----
Założenia dodatkowe
- soft powinien móc obsłużyć kilka rozszerzeń na raz
- musi być możliwa współpraca z programami nie korzystającymi z tego
- obsługa do 256 banków

I'm not so bad, once you get to know me.

2

Hmmm. Ale po co coś takiego robić? Oświećcie mnie bo nie kąsam bazenki.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

3

Po to, żeby programy mogły łatwiej korzystać z dodatkowej pamięci nie zamazując ramdysku ani wywalając SDX w kosmos?

KMK
? HEX$(6670358)

4

taki sterownik (standardyzujacy sposob alokacji/automatycznego sprawdzania zajetosci) to marzenie z p. widzenia programistycznego...

sie zastanawialem why to by mialo miec postac handlera - ale rzeczywiscie zastepuje to w jakis sposob odpowiednik syscall z "wiekszych" systemow - calkiem dobre rozwiazanie jesli sie chcemy uniezaleznic od stalych adresow procedur...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

5

Właśnie właśnie. Stałe adresy są fe. Możnaby spróbować coś takiego jak w BIOS - jedno przerwanie (a tutaj pewnie jeden wektor) + x funkcji określonych zawartością rejestrów + parametry w RAM zaadresowane rejestrami lub zawartością stosu.

Przy takim rozwiązaniu potrzebne byłyby na stałe dwa bajty. To chyba nie dużo?

Tak sobie gdybam, bo właśnie tego nie wiem - jak to połączyć z DOSem?

I'm not so bad, once you get to know me.

6

Sterownik CIO pod jakąś niezajętą nazwą (np. "M:" - ale to jest akurat zajęte) bez operacji typu OPEN/CLOSE/GET/PUT/STATUS. Tylko SPECIAL - a tu alloc, dealloc itp. pod odpowiednimi kodami XIO.

KMK
? HEX$(6670358)

7

dokladnie o to mi chodzilo ;)
teraz proponuje zasiasc kiedys na ircu i komitywa zdecydowac o specyfikacji ;)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

8

Nie lubie irca :( Nigdy nie doszedłem jak go uruchomić, nawet wewnątrz UT2004 :D

W takim razie już wiadomo jak to połączyć z DOSem. Będzie trzeba zrobić taki okrojony I/O handler. Trzeba by spisać dokładne API. Spróbuje to zrobić w wolnej chwili (chyba że ktoś mnie ubiegnie).

Oczywiście, że literka musi być nieużywana:
- http://atariki.krap.pl/index.php/Lista_ … C3%B3w_CIO

Na wypadek, gdyby ktoś chciał się tym zająć, kilka linków:

Przykładowe handlery:
- http://tajemnice.atari8.info/10_93/10_9 … ndler.html
- http://www.strotmann.de/twiki/bin/view/ … MemHandler
- http://www.strotmann.de/twiki/bin/view/ … ariHandler
- http://tajemnice.atari8.info/3_92/3_92_handlera.html

Z tego co zrozumiałem, IOCB ma z tym jakiś związek, więc tu jest jakieś wprowadzenie:
- http://atariarchives.planetmirror.com/mmm/iocbs.php

Tu jest coś o bankowaniu w 130XE:
- http://atariarchives.planetmirror.com/m … ndix16.php

A tu o splitowaniu programu w cc65
- http://www.cc65.org/mailarchive/2004-08/4361.html

Tu o procesie RESET i MEMLO:
- http://evilbill.org/Atari/8-Bit/dere/chapt8.html
- http://atariarea.krap.pl/forum/viewtopic.php?pid=38456

Proponuje, aby sterownik miał możliwość przekazywania nieznanych komend do następnego w łańcuchu handlera wybranej literki. Na razie nie wiem jak to zrobić. Inne handlery które można pod to podłączyć to np. handler informujący o konfiguracji sprzętowej (procek, model Atari, wesja OS i wszystko co chcemy uniezależnić od adresów).

Oczywistym następnym etapem po napisaniu takiego bank-handlera będzie implementacja kompatybilnego RAM-dysku. Później możnaby zająć się cc65, żeby był jakiś w tym support.

Pytania:
- czy banki 130XE są zgodne ze wspomnianym "XMS"?
- z tego co wyczytałem, jeśli miałbym XMS to jest szansa tak zaalokować pamięć, żeby Antic nie korzystał z tej samej przestrzeni co 6502. Jak to zrobić?

I'm not so bad, once you get to know me.

9

Bardzo przyjemny byłby taki sterownik do sparty, z prockami podpiętymi pod symbole.

Tymczasem fragment zastosowany w NeoTrackerze 1.4, 1.5 - tu chyba skomentowany na potrzeby NeoPlayera. Chyba jasny i czytelny:

; xms manager v1.1 (neo v>=1.4) ---------------------------------------------

; globals

availableBanks  equ     $0400   1
bankCodeTable   equ     $0401   64
; bank usage Table: a=...
; 7e    - bank used by plug-in code
; 7f    - unavailable bank
; ff    - unused bank
bankUsageTable  equ     $0441   64
unusedBanks     equ     $0481   1

; local variables
temp    equ     $fe

; extended memory initialization
initializeMemory
        mva     availableBanks  unusedBanks
        ldx     #0
        lda     #$ff
initializeMemory_unused
        sta     bankUsageTable,x+
        cpx     availableBanks
        bne     initializeMemory_unused
        lda     #$7f
initializeMemory_unavailable
        cpx     #$40
        beq     initializeMemory_ret
        sta     bankUsageTable,x+
        bne     initializeMemory_unavailable    !
initializeMemory_ret
        rts
        
; extended memory banks allocation
; parameters:   X: number of needed banks
;               A: code to store in usage table
; returns:      C - set if out of memory
;               A: code of first found bank
;               Y: index of first found bank
allocateXmsBanks
        dex:cpx unusedBanks
        scc:rts
        sta     temporaryUsageCode
        ldy:dey availableBanks
allocateXmsBanks_seekLoop
        lda     bankUsageTable,y
        bmi     allocateXmsBanks_found
allocateXmsBanks_next
        dey:bpl allocateXmsBanks_seekLoop       !
allocateXmsBanks_found
        mva     temporaryUsageCode      bankUsageTable,y
        dec     unusedBanks
        dex:bpl allocateXmsBanks_next
        lda     bankCodeTable,y
        rts

; extended memory banks deallocation
; parameters:   A - usage code of deallocating banks
deallocateXmsBanks
        ldx     #0
        tay
deallocateXmsBanks_seekLoop
        cmp     bankUsageTable,x
        beq     deallocateXmsBanks_found
deallocateXmsBanks_next
        inx:cpx availableBanks
        bne     deallocateXmsBanks_seekLoop
deallocateXmsBanks_ret
        rts
deallocateXmsBanks_found
        mva     #$ff    bankUsageTable,x
        inc     unusedBanks
        tya
        jmp     deallocateXmsBanks_next
Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

10

Super, dzięki epi! Właśnie takie kawałki (kodu) szukałem.

I'm not so bad, once you get to know me.

11

piotrv napisał/a:

Na wypadek, gdyby ktoś chciał się tym zająć

Ha, ha, dobry dowcip.

KMK
? HEX$(6670358)

12

Why not? Ja już ledwo zipie, ale jeśli dla nikogo ten temat nie będzie wystarczająco atrakcyjny to na pewno sam się tym zajme. Temat mi chodzi po głowie od czasu mojej reaktywacji w środowisku Atari. Jak widać z kodu epi temat nie jest czymś złożonym. Zresztą chodzi o interfejs do banków, nie o RAM-dysk czy nowy DOS. Piszę tutaj głównie po to żeby zdobyć więcej info i zobaczyć czy kogoś poza mną to jeszcze interesuje.

I'm not so bad, once you get to know me.

13

Dorobienie do tych procek interfejsu pod SDX to rzecz może nawet trywialna.
Tutaj masz tylko miejsce na $40 banków (1MB), bo takie ograniczenie jest w Neo, ale jak chcesz więcej, wystarczy zwiększyć tablice. Do wykrywania banków przełączanych przez Port B najlepsza jest procka Foxa z któregoś SyZyGy (chyba #5). I wykrywa nawet 256 banków.

Swoją drogą przydałby się pod spartą ramdysk z możliwością wyboru używanych banków...

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

14

A ja mam takie gupie pytanie: czy taki alokator/handler/whateva nie wplynie negatywnie na istniejacy soft nie korzystajacy z niego? Skoro ma to trzymac jakies dane w bankach (owe dwa bajty), to jak se jakies demo walnie cos w te dwa bajty to pozniej nie bedzie jakiegos zwiecha (ktos wspominal o przerwaniach)? Osobiscie jakos nie widze zastosowania dla takiego projektu, mysle, ze coraz wiecej osob ma HDD i zapotrzebowanie na ramdyski maleje... Chociaz oczywiscie to moje subiektywne zdanie.

15

Jak se jakieś demo walnie w którekolwiek miejsce (w banku lub poza nim) to żaden handler nie pomoże.

I'm not so bad, once you get to know me.

16

to pewnie jeszcze ochrone pamieci byscie chcieli ;)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

17

po co? skoro chcesz uruchamiac dema/gry - licz sie z ewentualna koniecznoscia restartu kompa
jak uzywasz uzytkow - taka sytuacja nie powinna miec miejsca (choc w oprogramowaniu typu "clasic" pewnie recznie bedziesz musial podac banki - jesli to oprogramowanie kozysta z XMS)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

18 Ostatnio edytowany przez piotrv (2006-01-20 11:09:35)

tebe, właściwie, to chociaż nie spadłem głową na kibel ;) ,
to wczoraj wymyśliłem coś takiego jak protected mode dla Atari :))))))

System moglby sie "schronic" pod ROM lub w specjalnym (np. zerowym) banku.
Wystawilby tylko na zewnatrz procedure obslugi RESET.

Procedura odpalenia programu uzytkownika
- odpalasz system DOS
- "chowasz" go zostawiajac wektory (obsluga RESET, powrot z programu)
- ladujesz program
- blokujesz zmiane bankow (PBCTL, i jak jest to też jego cień)
- uruchamiasz program, ew. z mozliwoscia podpiecia do handlera XMS
- program moze sobie rzezbic po calym RAMie poza przestrzenia ROM,
  takze w zakresie aktywnego banku
- jesli program jest bardzo glodny, to wola o wiecej RAMu w XMS poprzez handler

Czyli nie chronione zostaja wektory + mikro-procki do wskakiwania pod ROM lub
bank zerowy.
 
Wprawdzie to namiastka, ale jakby sie uparl, to jest to jakas mozliwosc...
No i chyba nie ma takiego DOSu, ktorego moznaby ew. pod to spatchować.

Druga mozliwosc to wyrzucenie calego DOSa na czas uruchomienia programu na dysk (lub lepiej: RAM-dysk - taka hibernacja). Ale to już calkiem inna historia...

------
Co do potrzeby istnienia RAM-dysku, to chociaż w DOSie dużo nie robiłem, to wydaje się, że RAM-dysk  jest idealnym miejscem na tworzenie plikow tymczasowych (roboczych) w toolach, ktore przetwarzaja wiecej niz 64kB. To jedno z wielu zastosowan, ktorych pare na swiecie wymyslono dla tego ustrojstwa.

------
dely - w takim razie zostaje logiczny bank "zerowy"

I'm not so bad, once you get to know me.

19

A co jak ktoś wyłączy ROM (99.9% dem).

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

20 Ostatnio edytowany przez drac030 (2006-01-20 11:45:37)

piotrv: nie bardzo rozumiem, o co w tym chodzi. Mógłbyś objaśnić? Gdzie DOS, gdzie wektory? Nie kojarzę.

KMK
? HEX$(6670358)

21 Ostatnio edytowany przez piotrv (2006-01-20 13:11:53)

Po krótce:

Po wyjściu z programu:
DOSowy program z tego co czytałem wczoraj wskakuje do jakiegoś wektora "powrót do DOS". Tam siedzi mikro-procka reaktywująca DOS z banku "zerowego" - bez przesłań, po prostu włącza przestrzeń tego banku i rozładowuje się - jeśli trzeba - do pozostałych rejonów RAM do czasu wywołania nast. programu.

Po crashu ze zwisem:
Po RESET system powinien odzyskać kontrole nad komputerem - dlatego wektor RESET wskazuje na mikro-prockę reaktywującą system w banku "zerowym" - niedostępnym dla programu / dema. Procka włącza bank "zerowy", i odpala co tam system DOS potrzebuje po reaktywacji (np. wyczyszczenie RAMu i przestawienie MEMLO).

Chyba Sparta DOS jest tak duża że się nie mieści cała w RAM, albo mi się zdaje (nie uzywałem jeszcze). Więc może tam już takie podmianki są?

Więc podsumowując, to system DOS/OS byłby chroniony, a nie program blokowany - więc odwrotnie niż normalnie.

To jest tylko taka czysto akademicka dyskusja, bo tak naprawdę to było by z tym trochę roboty, więc mam spore wątpliwości, żeby komuś starczyło pary na przerobienie całego (jakiegokolwiek) DOSa. No może COS-a bym przerobił, ale... kto by to wykorzystywał ? :)

I'm not so bad, once you get to know me.

22

Spartę możesz sobie umieścić:

- używając USE NONE podwyższając MEMLO
- używając USE OSRAM pod ROM
- używając USE BANKED + sterownik ssdxbnk.sys w dowolnym banku XMS

A co jeśli ktoś podepnie pod reset własną prockę? ;)

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

23

dely - no wiadomo, że da się zrobić haka - w końcu ten protected mode nie jest oparty o sprzęt (MMU lub CPU).

I'm not so bad, once you get to know me.

24

1) A co, jeśli program jest rezydentną nakładką na DOS? Wtedy zakończy się natychmiast, a przeładowanie DOS-u z pamięci dodatkowej skasuje nakładkę.

2) Co ze stanem buforów DOS-u i jego wewnętrznych zmiennych? Też chcesz je przywracać do stanu "zamrożonego" w XMS-ie?

KMK
? HEX$(6670358)

25 Ostatnio edytowany przez piotrv (2006-01-20 14:22:25)

Wszystko co potrzebne DOSowi można trzymać w banku "zerowym" bez pakowania/rozpakowywania.
Z tym, że takie rozwiązanie nie będzie umożliwiało korzystanie z programów korzystających z DOSa.
No chyba, że -każde- odwołanie do DOSa będzie go reaktywowało. W sumie wydajnościowo możliwe, chociaż jeśli program będzie chciał coś przesłać z pamięci w obszarze banku do DOSa, to będzie klops (ale znowu - do obejścia).

Co do nakładki - DOS czyści wszystko tylko na RESET. Po powrocie zwykłym trzeba to obsłużyć tak to zwykle się robi w programach DOSowych (chodzi o MEMLO pewnie) - ale nakładka musiałaby wchodzić w bank chroniony.

drac030, nie mów, że chcesz to zrobić ;)

I'm not so bad, once you get to know me.