O obsłudze rozszerzonej pamięci


      Witajcie polscy koderzy! Spróbujcie używać rozszerzonej pamięci w poniżej opisany sposób... (kierowane szczególnie do koderów dem VENT i JOURNEY)!

Heaven/TQA

Oddaję klawiaturę Tamasowi Bene z HARD software...

      "...Wszystko zależy od tego, co nazywamy "standardem". Moje rozszerzenie pamięci jest zgodne z 130XE (bez przełączania ANTICa), więc wszystkie programy pisane dla XE, powinny także uruchomić się na moim Atari. W rzeczywistości jest to rozszerzenie 192 kB, tak więc cała pamięć to 256KB.

      Problemem jest, że koderzy dem (i inne ludziki) używają komórki $d301 w niestandardowy sposób. Chodzi o to, że oni zmieniają bity w $d301, które działają odmiennie na różnych rozszerzeniach lub nawet przechowują oni wartości w $d301 inne niż $fc-$ff, zamiast tylko maskowania tamtych bitów, które mają być zmienione (na szczęście Atari OS został napisany znacznie bardziej ostrożnie, oni nawet używają maskowania bitów do ustawiania wartości takich jak $ff. Inaczej nawet OS mógłby nie działać z maszynami z dodatkową pamięcią.).

Na przykład, znalazłem następujące instrukcje w demie "Journey", w kilku miejscach:

      lda #$b3
      sta $d301

To ma trochę odmienne znaczenie na poszczególnych rozszerzeniach, ale nie mam pomysłu, co to powinno robić. Dla mnie, to po prostu włącza OS i wyłącza BASIC. Przy okazji, moje 192KB rozszerzenie działa następująco:

bity 0, 1 i 7 działają jak w normalnym Atari (włączanie OS/Basic/Selftest)
bit 4 włącza/wyłącza rozszerzenie, tak jak w 130 XE. Tutaj jest tablica dla bitów 2, 3, 5, 6:

bit 6
bit 5
bit 3
bit 2
działanie
0
0
0
0
mapuje podstawową pamięć $0000-$3fff na $4000-$7fff
0
0
0
1
mapuje podstawową pamięć $4000-$7fff na $4000-$7fff
0
0
1
0
mapuje podstawową pamięć $8000-$bfff na $4000-$7fff
0
0
1
1
mapuje podstawową pammięć $c000-$ffff na $4000-$7fff
0
1
0
0
rozszerzony bank #01 na $4000-$7fff
0
1
0
1
rozszerzony bank #02 na $4000-$7fff
0
1
1
0
rozszerzony bank #03 na $4000-$7fff
0
1
1
1
rozszerzony bank #04 na $4000-$7fff
1
0
0
0
rozszerzony bank #05 na $4000-$7fff
1
0
0
1
rozszerzony bank #06 na $4000-$7fff
1
0
1
0
rozszerzony bank #07 na $4000-$7fff
1
0
1
1
rozszerzony bank #08 na $4000-$7fff
1
1
0
0
rozszerzony bank #09 na $4000-$7fff
1
1
0
1
rozszerzony bank #10 na $4000-$7fff
1
1
1
0
rozszerzony bank #11 na $4000-$7fff
1
1
1
1
rozszerzony bank #12 na $4000-$7fff

To rozszerzenie jest dość standardowe, zostało opublikowane w niemieckim Atari Magazin kilka lat temu. To także wymaga najprostszego hardware'u, jaki znam, więc jest także najtańsze. Jestem pewien, że dużo ludzi wbudowało to z tych powodów.

Od tłumacza: powyższe rozszerzenie w pełni odpowiada standardowi Newell'a (a co za tym idzie, także jest zgodne z rozszerzeniem 256 kB firmy TOMS). Większość programów używając rozszerzonej pamięci wykonuje pewien rodzaj sprawdzania pamięci (przynajmniej te dobrze napisane ;-)). Lecz one zwykle źle działają na moim rozszerzeniu, ponieważ wykrywają dodatkowe banki w pierwszych 4 przypadkach (bit5=bit6=0) nawet jeśli w tych przypadkach główna pamięć jest mapowana (przełączana) na obszar przełączania banków $4000-$7fff. Dziwię się, czemu one nie robią sprawdzania w tym przypadku. To byłoby proste - po prostu potraktować cztery 16 kB "banki" głównej (podstawowej) pamięci w ten sam sposób jak rozszerzone banki i sprawdzić czy zapisanie do któregokolwiek powoduje jakąś zmianę w jakimś innym banku. Sprawdzanie mogłoby wyglądać podobnie jak to:

  1. Ustaw wszystkie możliwe wartości bitów 2, 3, 5, 6 i przechowaj odmienne liczby dla każdego z nich od $4000 (liczby 1-16).
  2. Przechowaj liczby 17-20 w adresach $0000, $4000, $8000 i $c000 w głównej pamięci.
  3. Ustaw wszystkie możliwe wartości w bitach 2, 3, 5, 6 ponownie i sprawdź czy wartość przechowana pod $4000 w każdym banku jest tam ciągle, lub czy jest nadpisana. Jeśli nadpisana z różną wartością, wtedy nie jest to prawdziwy, oddzielny bank, więc usuwasz go z listy dostępnych banków.
      To jest tak proste. Nawet prościejszą metodą byłoby pozwolić skonfigurować użytkownikowi liczbę banków pamięci i rzeczywiste wartości $d301, które on chce użyć. Np. ramdysk w DOSach takich jak Turbo DOS i MyDOS pracuje w ten sposób. Innym przykładem jest wspaniała gra "The Brundles" z KE-Soft.

TAMAS/Hard Soft

Od tłumacza: Standard opisanany przez Tamasa (zgodny z polskim TOMSem) do sterowania bankami dodatkowej pamięci używa bitów 2, 3, 5 i 6 w PORTB ($d301). Nie jest to najlepsze rozwiązanie, delikatnie pisząc, ale bardzo popularne (też je mam, więc chyba należy się z tym liczyć... i pisać programy działające na tym standardzie). Oto jak jeden z najlepszych scenowych koderów pisze o rozszerzeniu TOMS:

"Jeśli ktoś ma 256 kB (TOMS), to niektóre programy nie będą działać (np. Envision, Video Blitter, Wormhole z Halle Pro.'94). Wyobraź sobie, że ładujesz obrazek do dodatkowego banku ($4000-$7fff), a program umieszcza od adresu $4000 w normalnej pamięci. W wypadku rozszerzenia pamięci TOMS, procesor i Antic nie mogą mieć dostępu do innych obszarów pamięci oddzielnie, tylko: jeżeli 6502 korzysta ze zwykłej pamięci, to Antic też, a jeśli 6502 korzysta z dodatkowej, to Antic również i dlatego np. demo "Video Blitter" się 'kisi'."

      W standardzie Compy Shop 320 kB zostało to rozwiązane lepiej, gdyż tam są używane bity 2,3,6 i 7. Czyli zamiast bitu 5 (bit określający dostęp Antica do pamięci) jest tu bit 7 (tzw. bit Self-Testu), w ogóle zazwyczaj nie używany i idealny do sterowania bankami. Jednakże, biorąc pod uwagę ilość compów ze standardem TOMS, nie dziwi fakt, że w demo-compo jest zakaz wystawiania dem, używających 'niestandardowego' (tak jak w Compy) dostępu do Antica... Nie jest to jednak duży problem, bo dobrze napisane programy powinny ruszyć na obydwóch typach rozszerzenia (np. Asskicker, Ultra, Disk-Copy). Po prostu w bardzo złym guście jest pisanie tylko pod własne rozszerzenie pamięci.

Tłumaczenie i dodatkowe objaśnienia
Dracon/TAQUART