Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

RAMCART - programowanie

Od 51 do 100 z 168

- 1:
  
  CommentAuthorgienekp
- CommentTime3 May 2023
A da się tak uruchomić z wiersza poleceń atari800, żeby ruszył XEX z wsadzonym CAR w trybie RW?

Chce sprawdzić czy XEX wypełni mi RAMCARTa :)
- base.xex.7z
- 2: CommentAuthormono
- CommentTime3 May 2023 zmieniony
Nie. Nie ma parametrów dla RAMCART-a.
Ale opcje R/W, A, B, C, D, 1/2, 2/4 nie resetują cartridge'a - możesz je zmienić w każdej chwili z menu cartridge'a bez obawy, że komputer Ci się zresetuje.

Edit: Zresztą musisz brać pod uwagę, że tam są fizyczne przyciski i mogą być ustawione przeróżnie (szczególnie finezyjny jest 2x128K/256K z przyciskami P1 i P2). Czyli niestety program musi prosić użytkownika żeby łaskawie przełączył przyciski tak, jak sobie tego życzysz.

Edit 2: Ale konfiguracja przycisków za pomocą parametrów leci na listę TODO :) Dobry pomysł.
- 3:
  
  CommentAuthorgienekp
- CommentTime3 May 2023
OK, to co zrobiłem leci na GitHuba.
->link<-

ATR musi być 256 sektorowy. Najlepiej robić na bazie tego "base.atr". Konwerter robi wersję 8MB. Pod emulatorem działa.
- 4: CommentAuthorPawex (RTG)
- CommentTime3 May 2023 zmieniony
Ponieważ jeszcze nie do końca ogarniam temat więc zapytam:
Czy program diagnostyczny ACID800 (.atr) da się przekonwertować na Ram-Carta?
Pisałem do autora (phaeron) czy jest wersja na cartridge ale nie dostałem odpowiedzi.
- 5:
  
  CommentAuthorgienekp
- CommentTime3 May 2023 zmieniony
Niestety ale ACID800 robi całą masę nietypowych trików, żeby przetestować "to i owo". Automatyczna konwersja się nie uda. Taki program powinien autor zbudować od początku jako cartridge i to najlepiej diagnostyczny.

Edit.
Automat nie, ale ręcznie jak się pomoże to poleci. Sprawdź załącznik.
- Acid800.car
- 6: CommentAuthorPawex (RTG)
- CommentTime3 May 2023 zmieniony
Ok, dzięki. Tak myślałem.
Co do konwertera car-->xex to rozumiem, że muszę sobie skompilować pod linuksem te źródła z githuba poleceniem: ./go.sh?
- 7:
  
  CommentAuthorgienekp
- CommentTime3 May 2023
Tak, bo ja mam akurat macos, ktoś tam windowsa, a ktoś inny linuxa. Więc nie kompiluję, bo pewnie jeszcze się wiele w tym zmieni. Ale to co już jest to działa.
- 8: CommentAuthorZenon
- CommentTime3 May 2023 zmieniony
Jak działa to: moim życzeniem było od zawsze, by oprogramowanie "widziało" pamięć RAMCARTA, jako jeden ciąg, bez podziału na moduły po 128kB.
Bity D0, D1, rejestru $D500 zachowują swoje funkcje jak teraz, natomiast bity D2-D7 rejestru $D500, oraz odnośne bity rejestru $D501 adresują banki 16kB od nr. 00... wzwyż, jako jeden ciąg, po kolei.
Przełączniki całkowicie są ignorowane, usunięte, nie ma ich. Wybór banku wyłącznie programowo.
Najbardziej pojemny moduł to 32MB. Na początku program pyta jaki moduł?
Jak pojemna pamięć.... 64kB, 128kB, 1MB, 2MB, 4MB, 8MB, 16MB, 32MB.
według udzielonej odpowiedzi zapamiętuje najwyższy numer banku i...
No właśnie co... np, ładuje pliki po kolei jak gdyby pamięć RAMCARTA była dyskietką, tylko pojemniejszą. Potem, tak jak czyni to DOS, można by odczytać katalog, wybrać plik do załadowania, etc. etc... pomysłów wiele. A brak przełączników i zamieszania z nimi związanego ułatwia oprogramowanie. Jedynym hamulcem jest określona pojemność pamięci. Ale to bez znaczenia, bo np, moduł 8MB, zadeklarowany jako 2MB, będzie zachowywał się jak rzeczywisty moduł 2MB, "olewając" pozostałe 6MB.
GIENEKP.... da radę coś takiego zrobić, dla mnie?
Gdy poprosiłem Jagera robił co chciałem. Teraz prośba do ciebie ;)
- 9:
  
  CommentAuthorgaltron
- CommentTime3 May 2023
Witam, w końcu coś ruszyło w sprawie RAM CART-a ;) Widzę że już sporo osób próbuje coś zrobić aby była widoczna cała zawartość RAM CART-a powyżej 256KB. Dla mnie to rewelacja ! Może się uda komuś ogarnąć temat obsługi całej pamięci RAM CART-a. Można by było korzystać z całej pamięci. Byłby to przełom na wielką skalę ;) Dziękuję wszystkim którzy biorą w tym projekcie udział, ja niestety w kwestii programowania nie pomogę ;)
- 10:
  
  CommentAuthorgienekp
- CommentTime4 May 2023 zmieniony
No prace ruszyły bo @mono zrobił emulację. To jest naprawdę WIELKA robota! Bez tego to pisanie czegokolwiek to masakra. Bo inaczej jest kiedy buduje się własny sprzęt i pisze soft do niego, a inaczej jak już coś jest (ponad 20-lat temu :) ) i trzeba dokombinować kod. Ale teraz to w zasadzie można wymyślać wszystkie fikołki. :)

Ja poszedłem na początek metodą z innych swoich toolsów, czyli ATR2cośtam. Wziąłem ATR2MAX zmieniłem sposób bankowania i poszło od kopa. Tzn, zawiesiłem się na kolejności bitów ale to detal. W sumie to jest cart jak to cart. Dlatego ta metoda, bo ja jestem z epoki magnetofonów i kompletnie DOSów nie znam. I nawet nie wiem jak układają się sektory w standardzie np. MYDOS. Więc klonuje ATR-a a tam wszystko ładnie już jest poukładane. A jak zrobić toolsa, że wsadzam pustego RAMCARTa i puszczam polecenie, żeby mi to jakoś ogarnął to nie wiem. A klon to klon. To umie każdy :)

Ja mam fizycznie RAMCART-8MB więc od niego zacząłem. Natomiast, bazowego ATR przygotowałem w wielkości dla carta 4MB, bo taki zadziała i na 8 i na 16 i na 32. I to jest obraz CIĄGŁY (!). Żadne tam podziały itp. Po prostu jak JEDEN "dysk twardy 4MB".

Obawiam się, że 8MB to jest maksimum dla DOSów, nawet nie jestem pewien czy te 4MB dla DOS II+/D to nie za dużo (Nawet PC nie miało takich dyskietek :) ). Bo przy tej wielkości pokazuje śmieci w wielkości, ale działa (ale nie wiem czy na całym obszarze). Dobrze by było jakby ktoś zwykłe ATRy sprawdził jakie mogą być największe dla tego DOSa.

Nowego DOSa nikt nie będzie robił, a SDX nie wejdzie. Natomiast jest prosta furtka. Że carty 8/16/32 będą mieć więcej virtualnych dysków. Czyli np. 8MB ma wsadzone opcjonalnie do 2 dyskietek. Bo port $D501 (bit432) to taki wybór dyskietki. Ponieważ ja się podkładam pod ROM, to nie ma problemu żeby "wsadź 3-dyskietkę (3 bank 4MB) do D5:". I DOS zamiast zapytywać po SIO poleci do carta jakby nigdy nic. Nawet nie będzie wiedział, że mu ktoś jakieś podmianki robi. Największy cart 32MB to 8 dyskietek (D1-D8 i szafa gra). Jeszcze nie wiem, jak zrobić komendę DOS co pobiera parametr typu "POLECENIE D5 B3". I chciałbym ją zrobić dla czystej ciekawości w "C". Nikt (?) nie pisze w C na ATARI, a przy ramcarcie aż tak bardzo o te pojemności to się nie musimy martwić ;)

Nie ma na razie zapisu. Bo dla żadnego carta nie umiałem tego zrobić. No ale dla ramcarta to zapis to jest "STA". No to jak jest procedura LDA A - STA B to wystarczy zamienić A z B i po kłopocie.

Ostatnia sprawa. Jak przejść z wirtualnego CAR na real. zrobiłem RAMCART2XEX. Ten XEX to wypełniacz RAMCARTA, ale taki byczy XEX zabija ładowarki. Trzeba go jakoś podzielić na kilka części.

Jedynie czego nie ogarniam to tych przycisków. U mnie jest tylko RW i już mam kłopot :). Mam pomysł jak to wykryć, bo to nie może być żadna komenda DOS, to musi być szybka procedurka. Bo to wszystko musi być szybkie, inaczej po co nam RAMCART. Proceudrkę można umieścić w dolnym banku i tam ładnie wykryć czy się zapisujemy czy nie :)

Tak w ogóle to nie dało by się tego przycisku RW wywalić? Podłączyć nie wiem, np. $D501-bit7? Carty bezprzyciskowe i tak używają D501.

Przy okazji zapytania o ACID800 wyszedł taki pomysł. Bardzo często procedurki umieszcza się na $0100 tam gdzie stos. Jak to jest procedurka na chwilę to spoko. Ale jak ma cały czas siedzieć to lepiej pod stosem. Jak cart wstaje i jest INIT to stos jest pusty. Można naPcHAć pha i stos się przesunie i mamy lukę.
A wejście do RAMCARTa czy to RO czy RW to tylko:
```
lda VCOUNT
cmp #$52
bne DOLDA		
lda #$02 ; bez znaczenia czy RO czy RW bo wchodzimy do $8000
sta $D500
jmp $8000
```
No jest jeszcze trochę roboty, ale wszystko jest Open więc można zobaczyć i... podpowiedzieć.
- 11:
  
  CommentAuthorgaltron
- CommentTime4 May 2023
#gienekp - żebym to ja drobny skłądacz RAM CART-a kumał co napisałeś to było by fajnie ;) Dla mnie to czarna magia ;) Dobrze że są tacy wspaniali ludzie którzy zajęli się programowaniem a nie składaniem i mogą teraz coś zrobić dla potomnych ... ;)SUPER ! Dziękuję Wam wszystkim za pomoc w rozwiązaniu tego problemu. Gdy rozmawiałem z MONO to otrzymałem informację że SDX poradziłby sobie z obsługą całej pamięci RAM CART-a i jednym z rozwiązań jest wykorzystanie początkowych adresów RAM CART-a gdzie można ulokować SDX i po starcie Atari SDX sam by się ładował do pamięci i przy okazji mógłby mieć już obsługę RAM CARTA.
- 12:
  
  CommentAuthorgienekp
- CommentTime4 May 2023 zmieniony
SDX ma inne bankowanie i bez grzebania w nim raczej się nie da. Wiem, bo mój pierwszy cart źle zaprojektowałem (pomyliłem zatrzaskiwanie "na adresach" z "na danych") i kombinowałem jakby tu zmienić te bankowania.
Może jakby poprosić autora o małą modyfikację? To wtedy RAMCART byłby prawdziwym twardym dyskiem.
Pod SDX też można napisać procedurkę dostępu i walnąć normalnie na żywca FAT16 i się nie pitolić. Co nie byłoby takie złe przy tej pojemności.

Ja myślę, że jak już jest emulacja to autor SDX miałby dużo łatwiej. Ten SDX jest mocno konfigurowalny ->link<-
Ja dokładałem i kasowałem pliki. Może jakby takiego "najchudszego" zrobić. To może by to wstało?

RAMCART ma sprytnie włączane osobno banki. Więc na czas SDX-owania pstrykany byłby bank górny. Ale już przy odczycie FATa to można mu na chwilkę dopiąć drugi bank. Nawet jakby robić taki trik, że poza SDXem przerzuca się sektor z banku dolnego do górnego, żeby ten sobie mógł ładnie poczytać. Minimalnie dłuższy czas dostępu ale by to grało. W końcu na HD też głowica lata na różne dystanse i jest różny czas odczytu.
- 13:
  
  CommentAuthorjhusak
- CommentTime4 May 2023 zmieniony
gienekp:
Można naPcHAć pha i stos się przesunie i mamy lukę.

A jest takie coś jak TSX/TXS

gienekp:
Ostatnia sprawa. Jak przejść z wirtualnego CAR na real. zrobiłem RAMCART2XEX. Ten XEX to wypełniacz RAMCARTA, ale taki byczy XEX zabija ładowarki. Trzeba go jakoś podzielić na kilka części.

Zabija/nie zabija. Użyj kompresji np. zx7. Nawet tam błąd poprawiłem (zapisywał za dużo zer na końcu) Proste jak konstrukcja cepa, dekompresor zajmuje nieco ponad 100 bajtów i jest pieruńsko szybki (bo po prostu przepisuje dane :)

->link<-

A dekompresor jest na stronie xxl.atari.pl
- 14:
  
  CommentAuthorgienekp
- CommentTime4 May 2023 zmieniony
jhusak:
A jest takie coś jak TSX/TXS

... ano faktycznie jest :)
W sumie to nigdy tego nie używałem, ale przydatne, można suwać się stosem w te i nazad :)

Ciekawe czy kasetowy "wykrzyknik" dałby radę takiego XEX wepchać. Nie wiem ile by trwało ładowanie takiego 8MB w normalu, ale na noc by zostawił i nad ranem by było :)
- 15: CommentAuthormono
- CommentTime4 May 2023
Pół godziny to 100KB - potrzebowałbyś taśmę o długości 40 godzin :)
- 16:
  
  CommentAuthorjhusak
- CommentTime4 May 2023
A jakby użyć zx7 - to 20+-10.
- 17: CommentAuthorZenon
- CommentTime4 May 2023
Swego czasu ramcarta 1MB ładowałem posługując się plikiem typu BAT. Wstawione komunikaty informowały tylko... kolejna dyskietka do stacji. I załadowało się. Oczywiście wcześniej dyskietki były przygotowane, tzn, nagrałem na nie co się dało do pełna, jako pliki tekstowe, bo było najłatwiej.
- 18:
  
  CommentAuthorgienekp
- CommentTime4 May 2023
40 godzin to już kasety z CIA lub KGB :)
Bez kompresji nie da rady.

Patrze na zx7, ale on chyba nie kompresuje XEXa i potem go odpala. Muszę sam podzielić na bloki i potem każdy odpalać dekompresją?
- 19:
  
  CommentAuthorjhusak
- CommentTime5 May 2023 zmieniony
Tak, to jest narzędzie blok - blok. Do strumieniowej dekompresji jest inny algorytm kompresji (zx0,zx1, zx5), wtedy da się zrobić to, czego potrzebujesz.

Tylko, że one dłużej kompresują.
- 20:
  
  CommentAuthorgienekp
- CommentTime5 May 2023 zmieniony
Poszedł upgrade na GitHuba. Okazuje się, że co prawda dla starych RAMCARTów używany był DOS II+/D. Niestety ale kompletnie nie radzi sobie z większymi pojemnościami. Nie wiem, ale gdzieś powyżej sektora 1000 głupieje. Szkoda bo to fajny DOS.

Ponieważ format MyDOS w zasadzie obsługuje dobrze tylko MyDOS 4.53/4 to nie było za bardzo wyjścia. Ten dos jest jakiś masakryczny. Wczytuje się do połowy, po czym robi połowę zimnego startu, kasuje stos. Trzeba go było lekko zhakować, żeby w ogóle ruszył z RAMCARTa. Ale udało się.

Samo zrobienie 4MB ATR też nie takie proste. Bo nie ma czym tego wypełnić. Bo większe gry nie ruszą z dosem. Więc trzeba było takimi małymi pyrdkami jakoś zapełnić do testów. Plik base.atr to taki bazowy jaki poszedł do konwersji.

ATR2RAMCART wyprodukuje base.car. I to pod emulatorem ładnie działa. Na razie w trybie do odczytu ale już można sobie składankę gier czy programów zrobić.

Wgrywaczkę zrobiłem tak, że ramcart2xex produkuje takiego XEX co wypełni nam ramcarta. Tu też była pułapka bo włączony ramcart w trybie RW jest po bocie niewidoczny. Włączenie banków budzi idiotyczną procedurę OSa w VBLANKU która skacze do nieskończonej pętli czekającej na sprzętowy reset. ATARI zakładało, że można carty wkładać w czasie pracy. Dlatego ramcart2xex musi dodać procedurkę "lda TRIG3 + sta GINTLK", żeby to oszukać. Dzięki temu włączenie carta na RD4 i RD5 nie skiluje nam systemu. Ostatecznie ramcart2xex wyprodukuje nam base.xex.

Takiego base.xex wpakowałem do "ciut większego" ATR też sformatowanym w MyDOSie. W przykładzie fillerup.atr. No i odpaliłem w emulatorze ale z podłączonym tym razem pustym cartem 8MB.

No i wszystko... działa :)

Jest prośba, żeby posiadacze SIO2SD (lub innych obsługiwaczy ATR) i fizycznych ramcartów 4MB/16MB/32MB puścili "fillerup.atr" i zobaczyli czy zadziała już tip-top na realnym sprzęcie. 8MB ja sprawdzę u siebie.

Po całej sekwencji mamy RAMCARTa który odpowiada dokładnie naszemu początkowemu plikowi ATR.

EDIT
Pod emulatorem pamiętać o tych przełącznikach.
- 21:
  
  CommentAuthorgienekp
- CommentTime6 May 2023
Real RAM-CART v1.0 8MB: PASS

Puściłem przez SIO2SD bez TURBO, żeby za bardzo nie filozofować. 40minut i 28 sekund trwało wypełnienie 4MB :)
Warto było bo wszystko działa. D1 to RAMCART pozostałe Dx normalnie działają.

Aż baterię w RAMCARcie wymieniłem na nową, z emocji. Bo skoro i tak go czyściłem to była okazja.

Procedura jest dość oczywista:
- kopiujemy "fillerup.atr" na kartę SD dla SIO2SD
- ustawiamy w SIO2SD ten obraz w gotowości na D1
- wyłączamy atari
- wsadzamy RAMCART z wciśniętym RW
- włączamy ATARI - wczyta się MYDOS
- klawisz "L" i plik "FILLERUP.COM"
- ekran zrobi się cały ciemno czerwony i zacznie się ładować
- czekamy 40 minut (bez turbo) - w między czasie ATARI zacznie kolory zmieniać ;)
- gdy pojawi nam się okno DOSu tzn, że wszystko OK
- wyłączamy przycisk RW i wyłączamy ATARI
Po włączeniu wystartuje RAMCART z MyDOSem.

Ponieważ na ten moment działa co miało działać to puszczam Release z kompilacjami dla MacOS (oba procki) i Windows.
->link<-
- 22:
  
  CommentAuthorjhusak
- CommentTime6 May 2023
A czy nie ma takiej opcji, żeby ten dos, co jest na ramcarcie, na czas zapisu przełączał go w tryb RW a potem od razu w RO? To by zminimalizowało możliwość zepsucia pierwszego banku. Ale piszę to bez znajomości tego urządzenia, więc pytanie może być bez sensu np.
- 23:
  
  CommentAuthorgienekp
- CommentTime6 May 2023 zmieniony
No właśnie RW jest tylko z przycisku. Jakby RW było programowalne to by się tylko włączało na moment.
W tej chwili jest tak, że bank 0 startuje. Bank 1 jest na razie nie używany. Bank 2 i 3 to tablica sektorów, żeby szybko odnaleźć dany sektor. Od Banku 4 lecą dane. W każdym banku zabieram 1024 na końcu na procedury IO. Dzięki temu przełączenie banku nie podcina procedur. Docelowo można to uprościć. Mając 16kB bankowanie nie trzeba takich fikołków jak np. w MAXFLASH.

Docelowo Bank 1 ma trzymać kopię banku 0, który to jest wysokiego ryzyka. Bo jak chcemy zapis to niestety ale kart trzeba będzie podczas użytkowania trzymać na RW. I wyobrażam sobie to tak, że gdzieś poza RAMCARTem będzie prosta komenda ratunkowa "zrób kopię Bank-1 do Bank-0". I to będzie jedyna sytuacja kiedy Bank-1 będzie włączony.

Jest dużo pomysłów. Bo to faktycznie zapiernicza, ten RAMCART.
Ale dla mnie sukces jest połowiczny, bo MyDOS nie potrafi odpalić wielu gier :)
Tak w ogóle moje zdanie jest takie, że te DOSy atarowskie to do bani są. Dobrze, że w epoce miałem tylko magnetofon :P

Dlatego raczej teraz prace pójdą w zwykłe narzędzia nieDOSOWe.
"sformatuj ramcart"
"dodaj XEX do ramcarta"
"skasuj XEX z ramcarta"
A po starcie zwykłe menu gdzie wybieramy, która gra idzie do uruchomienia.
- 24: CommentAuthorZenon
- CommentTime6 May 2023
Nie da się, bo to sprzętowo jest przełączane. Gdyby coś wpisać do rejestru to po włączeniu zasilania jest resetowany i na jego wyjściu pojawia się zero.
Bramka NOT neguje ten stan a przełączni poda na linię RD5 zero, lub jedynkę w zależności jaki tryb jest wybrany, zapis czy odczyt. Dodatkowy warunek jest taki że pusty, nowy ramcart, źle zaprogramowany.... zawsze uruchomiony musi być w trybie zapis, potem można wybrać dowolny tryb.
- 25:
  
  CommentAuthorjhusak
- CommentTime6 May 2023
ok, rozumiem, czyli trzeba nauczyć sie takiego stylu pracy, że kart jest zawsze w trybie read only, a jak trzeba coś zapisać, to się przełącza, zapisuje i znowu przełącza.
- 26: CommentAuthorZenon
- CommentTime6 May 2023
Tak, jak zapisany i nie musi bootować to stan przełącznika może być w trybie zapis. Ale... moduł nie ma zabezpieczenia pamięci przed przypadkowym nadpisaniem w czasie włączenia zasilania. Dlatego dobrym zwyczajem jest wyłączać go i włączać w trybie odczyt. Aby bezpiecznie przełączyć, w zestawie jest procedurka SW.COM i powinno się pod jej kontrolą przełączeń dokonywać.
Jeżeli przełącznik jest w trybie odczyt, to drugą sekcją przełącznika linia WE SRAM (zapis do pamięci), jest podciągnięta opornikiem to Vcc co blokuje przypadkowy wpis, nadpisanie.
Ja konfigurowałem moduł tak.
Włączenie w trybie zapis, formatowanie, kopiowanie plików do niego + kopiowany DOS obsługujący RAMCARTA w formie plikowej, ten z zestawu, albo ten co Jager przysposobił, obowiązkowo procedurka SW.COM, nadanie swoich nazw programom, zainicjowanie modułu, pod kontrolą przełączenie w tryb odczyt i moduł po ponownym włączeniu botował. Zazwyczaj i MENU wybierałem by załadowało DOSa z modułu, i jak była potrzeba to przełączałem moduł w tryb Zapis, pod kontrolą SW.COM.
W zestawie jest też DOS obsługujący pliki typu BAT, więc odpowiednio przygotowany BAT, sam ładował co trzeba i komunikatami prosił o wykonanie poleceń związanych z używanymi programami. Fajnie to działało z drugim rejestrem $D501 który symulował użycie bitów D6, D7 rejestru $D500 które to bity w modułach 128kB i DOUBLE RAMCART nie są używane. Ta uwaga dotyczy modelu 1MB który przed laty opracowałem i opisałem w SERIUSIE.
- 27: CommentAuthormono
- CommentTime6 May 2023
@Zenon: Czyli $D500 używa bitów 0,1,2,3,4,5 jak RAMCART 128 (bity 6 i 7 nieużywane), a w $D501 następuje wybór modułu 128K?
Jeśli tak, to taki wariant RAMCART-a nie jest w emulacji obsługiwany. Musiałem to przeoczyć w SERIOUS-ach.
Wariant 1M jest obsługiwany tylko w nowej postaci od Galtrona czyli sterowany tylko rejestrem $D500 (czy mamy przyciski ABC czy bity 2,6,7 zależy od opcji "jumpers").
- 28: CommentAuthorZenon
- CommentTime6 May 2023 zmieniony
Tak, jak piszesz.
Zrobiłem model 1MB, tylko że jak pisał mi Jager w DOSie który przystosował do obsługi RAMCARTA nie ma już miejsca. To znaczy, pousuwał co się dało by w to miejsce wprowadzić zmiany, tablice, etc...etc... (jakoś tak ) i nie da się już niczego upchać a nie chce "pogrubiać" DOSa. Ale ja już miałem zaprojektowany z zrobiony moduł 1MB właśnie z drugim rejestrem. Bo 1MB powinien też pracować na oryginalnym oprogramowaniu, a tam bity D6, D7 chyba przy wyborze banków zawsze ustawiane były na 11. No i nie wybierałyby kolejnych banków. Dlatego drugi rejestr $D501 wybiera moduły jak dobrze pamiętam chyba 4X256kB, natomiast bity rejestru $D500 wybierają bank.
Aby to działało Jager napisał procedurę która to obsługiwała. Pracowała w tle. Jej zadanie było tylko takie, że klawiszami klawiatury chyba 1-4 wybierało się dany fragment RAMCARTA, a wybór decydował że następował wpis do rejestru $D501. Takich modeli wykonałem chyba trzy czy cztery.
Opisane też w SERIOUSIE. W tej chwili piszę z pamięci i być może do opisu wkradły się jakieś nieścisłości.
Kiedy tworzyłem schemat 1MB dla Galtrona ustaliliśmy że moduł obsługiwany będzie bitami rejestru $D500 i nie ma co zawracać sobie głowy drugim rejestrem. Tym bardziej że modułów 1MB z dwoma rejestrami rozeszło się niewiele, a komplikować to będzie dalsze rozszerzanie pamięci RAMCARTA.
A przełączniki są tylko po to, i tu się powtarzam, by działało na oprogramowaniu dla modelu 128ZkB. Kto biegły na płytce może dokonać niewielkich zmian, usunąć przełączniki i mieć model całkowicie programowo obsługiwany. No właśnie.... to trzeba napisać, a zrobić to musi fachowiec ;)
- 29:
  
  CommentAuthorgienekp
- CommentTime6 May 2023 zmieniony
Mam dwa pytania:

1. Jeśli to nie jest tajemnica handlowa :) to których typów cartów jest najwięcej wśród ludzi. I chodzi mi o te bez przycisków. Dla mniejszych pojemności jest soft więc po co wyważać otwarte drzwi. Bardziej chodzi mi o te 4/8/16/32

2. Skoro cart jest podtrzymywany bateryjnie, to dlaczego istnieje zagrożenie, że zostawiony w trybie RW może złapać śmieci? Co jest w zasadzie podtrzymywane bateryjnie, tylko pamięć, a może i rejestr D501 lub D500?
- 30: CommentAuthorZenon
- CommentTime6 May 2023
Ile jest nabywców RAMCARTA?
Wersji sprzed lat, oryginał.... pytać Avalon, reklamowali sprzedawali.
Te które ja robiłem dla ludzików jakieś 15-20 szt. W większości DOUBLE RAMCARTY. Było kilka w wersji z przełącznikami 1MB.
Natomiast wersje powyżej 1MB.... hmmmm robiłem schemat ile poszło w świat pytać Galtrona.

Bateryjnie podtrzymywana jest tylko pamięć, rejestr bierze za dużo prądu, tak mała bateryjka starczy na.... tydzień z hakiem.
Dlaczego może nadpisywać? To nie jest reguła że zawsze to się stanie. Wejście zapisu pamięci SRAM (WE), nie może wisieć w powietrzu bo działa jak antena,
Może być dołączone do innych układów ale, wyczytałem w literaturze że to wejście powinno być sterowane przez specjalizowane układy dedykowane do tego by wymusić odpowiednie aktywowanie go. W momencie włączenia zasilania powstawać mogą i powstają różne dziwne zakłócenia. A Ramcart, jego pamięć raz i drugi załapie to i.... koniec zabawy. Z doświadczenia używania Ramcarta wiem że tak się dzieje, instrukcja oryginału jak pamiętam też coś na temat podawała by nie załączać komputera gdy moduł jest w trybie zapis. Niby nie powinno się nic dziać, ale się dzieje. W większości przypadków, gdy porównywałem zawartość pamięci z wprogramowanym wsadem, gdzie przekłamało, zazwyczaj był to jeden bajt, zamiast prawidłowego wpisu pojawiało się 00 lub FF....
Jak napisałem, to nie jest reguła że się nadpisze.... to przypadek jeden na... hmm... optyliard:)
Pamięci EEPROM mają ten problem rozwiązany, by ją otworzyć do zapisu trzeba podać odpowiednie kody do rejestru.
- 31:
  
  CommentAuthorPeri Noid
- CommentTime6 May 2023
Ja mam wersję 1MB i byłbym szczęśliwy gdybym mógł wgrać w poszczególne sloty obrazy zwykłych cartów, tak "na chama" - na przykład w tej chwili chciałbym sparwdzić różne wersje wsadów diagnostycznych SALT.
- 32:
  
  CommentAuthorgienekp
- CommentTime6 May 2023
1. Pytam w odniesieniu do obecnych DOSów, które to nie radzą sobie z większymi pojemnościami. Jeżeli użytkowników 32MB nie ma za dużo to można przyjąć za standard MyDOS i jego 16MB jako max. Będzie o tyle łatwiej, że ramcarty będą formatowane w trybie MyDOS, czyli jakiś znany standard.

2. Ale te nogi pamięci wszystkie wiszą jako "antenki"? Nie dało się jakiegoś WE ściągnąć rezystorem w jeden stan i sterować mocniejszym tranzystorem?

Ale spoko, mam pomysł. Bo wciśnięcie w czasie pracy przycisku RW powoduje zmianę na RD5 i o to się czepia OS ATARI. A ponieważ do obsługi podmieniany jest ROM to w jego kopii w RAM można wywalić to czepianie się OSa. I sama procedura detekcji R/W robi się bardzo prosta. Wystarczy, że będzie siedzieć w banku 0 dolnym i przełączy bank0 górny i od razu będzie wiadomo gdzie jesteśmy. A to będzie oznaczać, że przyciskiem RW będzie można pstrykać w czasie pracy bez żadnych konsekwencji...
- 33: CommentAuthorZenon
- CommentTime6 May 2023 zmieniony
Nieraz już pisałem że programiści mają pole do popisu. Jak dany pomysł działa, to jest dobry.
Np. Ramcart 32MB ma w sobie cztery pamięci 16MB. Ich piny WE są z sobą zwarte i sterowane jednocześnie bramką. Co i kiedy do której pamięci trafi, o tym decyduje generowany przez dekoder sygnał CS.
Sygnał do WE, w trybie zapis pobierany jest z wyjścia bramki, w trybie odczyt ten pin podciągnięty jest opornikiem do Vcc poprzez przełącznik zapis/odczyt.
Punkt3, czytaj to samo co na początku. Wyznaję zasadę, jak działa to dobre. Każdy pomysł wart przetestowania. Sam z Ramcartem walczyłem bo mi nie chciało zaskoczyć. Wymyśliłem taki dziwny dekoder, który tak na dobrą sprawę nic nie robi i w ogóle nie jest potrzebny. Sterowanie mogło być super proste, ale nie działało, do dziś nie wiem dlaczego... kombinowałem, aż wymyśliłem i zadziałało i tak zostało. To rozwiązanie stosowałem przed laty, bo moduły późniejsze nie mają już tego dziwnego dekodera, a działają.
Jeżeli chcesz, to prześlę ci schemat ramcarta 128kB, zobaczysz jak to zrobione. Podaj meila.
Jeszcze taka uwaga. Wczesne Ramcarty robiłem tak by rejestr sprzętowy był do zapisu i odczytu. Można było w dowolnej chwili zrobić odczyt i odcyfrować jaki bank jest aktualnie wybrany i w jakiej pozycji jest przełącznik zapis/odczyt. Oryginał był tylko do zapisu.
- 34: CommentAuthormono
- CommentTime6 May 2023 zmieniony
Oryginał czyli 64K?

Jeśli idzie o przełącznik RW - ustawienie RAMCART-a w trybie do zapisu i wykonanie zimnego startu (E477) powoduje, że OS testując ilość dostępnej pamięci i obecność cartridge-a będzie zapisywał RAM $0200-$BFFF. Zakłada, że cartridge ma ROM :) Więc sam OS zniszczy w tym przypadku zawartość banku 0 carta i (na szczęście) nie będzie z niego startował bo go nie wykryje. Ale to chyba już ktoś opisywał tutaj.

Edit: Nie pamiętam za to, jaki test jest robiony przy zwykłym resecie (gorący start), ale chyba tylko PUPBTx, TRIG3+GINTLK, CARTCK+odczyt carta, ale za to otworzy się edytor i w $BC20-$BFFF wszystko się zamaże.
- 35:
  
  CommentAuthorgienekp
- CommentTime6 May 2023 zmieniony
Kłopot jest jakby w kolejności powstawania. Zwykle to jest tak, że najpierw robi się sprzęt a potem pisze soft do niego. No ale tu mamy troszkę inną sytuację bo soft który umie czytać duże pojemności jak SpartaDOS X powstał przed RAM-CARTem 32MB. Jasne, że można napisać nowego SDX ale jest to zdecydowanie trudniej niż zaprojektować nowego ramcarta. Dlatego te 32MB w jednym ciągu to raczej nic obecnego nie ogarnie (mam na myśli DOSy). Można zrobić jakąś "wgrywaczkę" do gier, ale to inny temat.
Zupełnie inaczej się sprawa ma dla 16MB bo np. MyDOS da radę. Podejrzewam, że wszystkie ramcarty do 1MB to DOS II+/D bez problemu obsłuży. Czyli jest dużo łatwiej.
No więc to, że te duże pojemności są zgodne w dół to wcale nie pomaga.

Przełącznik RW ma trzy pułapki. No bo user powinien sobie go naciskać kiedy chce. Czyli jak naciśnie, zrobi się negacja na D0 to VBLANK będzie chciał się zblokować w oczekiwaniu na RESET i tam w tym miejscu trzeba zrobić myk, że my odłączamy bank 0. Jak będziemy cały czas utrzymywać carta odpiętego i dołączać tylko na czas odczytu/zapisu sektora, to ewentualny reset (czyli druga pułapka) staje się nie groźna.

Natomiast trzecia pułapka jest taka, że nie da się programowo zabezpieczyć przed głupim userem, który będzie chciał na siłę zepsuć dane pstrykając resetem i przyciskiem. No bo nawet programowo odłączymy carta, wskoczy basic, user da polecenie BYE wciśnie RW i zrobi RESET i bank startowy poleci w kosmos.
I na tą okoliczność widzę tylko zewnętrzną procedurę ratunkową odpalaną z dysku która skopiuje bank 1 do banku 0. Dlatego pisałem o tym, że bank 1 przygotowany jest na backup.
- 36: CommentAuthorZenon
- CommentTime6 May 2023
Oryginał czyli moduł 64KB lub 128kB bo w tej materii niczym się nie różnią,
I w jednym i drugim jako rejestr stosowany był 74174, sześć przerzutników typu D. Tylko do zapisu.
Ja myślę że jest tak. Tryb zapis, więc RD4 i RD5=00. MMU nie przełączy na pamięć ramcarta, tym samym system nic do niego nie wpisze i nie testuje jego pamięci. Jest całkowicie odłączona. Zawsze, gdy jest tryb zapis RD5=0. Włączamy komputer. Teraz można przełączyć przełącznikiem na odczyt ale całość wisi, lub z poziomu Basica ustawić bit D0 w rejestrze $D500, też to zawiśnie, pomijam inne niuanse.
Tryb odczyt, nadal RD4=0 a RD5=1, system rozpoznaje że jest kartridź i go uruchamia, nadal nie ma dostępu do całej pamięci banku0 Ramcarta, dopiero uruchomiona procedura z ramcarta może ale nie musi ustawić bit D1 w rejestrze i dolne 8kB banku0 jest dla systemu dostępne. Ekran się skaszani bo zatraci się pamięć atari gdzie jest DL, dlatego musi być mądrze napisana...
Wynika z tego że banki można mieć jako 8kB lub 16kB. W tym pierwszym przypadku traci się połowę pamięci ramcarta, jest niedostępna.
Ramcartem można się pobawić używając tylko 8kB banków jako $8000-$9FFF z poziomu Basica.
POKE 54528,2
włączony bank0, ekran się skaszani, reset w Atari i jest ok, jest obraz. System przełączył pamięć, jednocześnie do pamięci ramcarta wpisał DisplayList
POKE 54528,6
Włączony bank1
to samo jak wyżej, ale... ponownie
POKE54528,2
I mamy pierwszy ekran z... wpisanym POKE 54528,6
- 37: CommentAuthorZenon
- CommentTime6 May 2023
Ale się zrobiło ciekawie.
Pamięć ramcarta to pamięć ciągła, Atari widzi ją zawsze jako banki i zawsze tak samo adresuje. Banki 16kB jako $8000-$BFFF, więc tu problemu nie ma.
Jakimś sposobem obsłużyć trzeba rejestr który przełącza banki, a po przełączeniu, zapisu do kolejnego banku dokona ta sama procedura, też problemu nie ma.
Copier.... ustawia bank0, kopiuje.... ustawia bank1 kopiuje pod te same adresy... itd itp aż 32MB się zapełni.
Co innego wgrywać pliki bo zapamiętać trzeba (w tablicy?) co gdzie się znajduje, plików może być dużo więc tablica też duża.... na dyskietce wydzielone jest do tego sporo sektorów.
To takie moje przemyślenia, niestety.... za wysokie progi
- 38:
  
  CommentAuthorgienekp
- CommentTime6 May 2023 zmieniony
Rozbijamy wszystko na czynniki pierwsze co do bitu, bo to pozwala określić warunki brzegowe możliwości tego co jest :)

Bankowanie ramcarta jest idealne jako rozszerzenie pamięci RAM. Co prawda programy nie za bardzo chcą tego używać a powinny bo to lepsze niż wszystko.

Kompletnie zmienia się sytuacja jak chcemy zrobić ramcarta jako dysk (jak HDD). I tutaj mamy przeciwko sobie zarówno OS jak i DOSy. Bo DOSy widzą nie bank ale sektor. Numer sektora jest 16-bit, a że większość sektorów ma 256 bajtów to nie ma wyjścia 256*256*256. Numer sektora 24-bitowy to już inna bajka. ATARI już ma problemy z 16-bitami więc 24 to jeszcze większy kłopot.

Nie ma znaczenia to, że można łatwo wypełnić 32MB. Bo tym programikiem co zrobiłem "ramcart2xex" bez problemu wypełni się i 32MB dowolnymi danymi. To już działa. Tylko, że DOS ma to w nosie i tak daleko nie sięga. Trzeba by napisać nowy DOS :)

OS nie chce, żeby mu wpinać i wypinać carta, a jeszcze jak jest zapisywalny to chce go czyścić. DOSy znowu chcą mieć całą pamięć ATARI i najlepiej jakby nic nie bankować. SDX, który naturalnie działa z carta, nie dopuszcza, że coś innego będzie po swojemu bankować.

A programiści z ATARI założyli, że cała obsługa NowychUrządzeń będzie szła przez $D8XX. I w tej koncepcji w ogóle nie ma bankowania. Czyli jeszcze inaczej.

Wygląda na to, że HDD tylko na złączu carta powinien wszystko robić wyłącznie stroną $D5xx. Ale takiego numeru już prostą logiką na TTLkach nie da rady obskoczyć. Trzeba kontroler, wymianę danych itd. I robi nam się normalny HDD.

Dlatego szukamy złotego środka. Co się da i co jest akceptowalne. ;)
- 39:
  
  CommentAuthorjhusak
- CommentTime7 May 2023 zmieniony
Czy ja niezbyt dobrze rozumiem, ale chyba jednak dobrze, że jak te pamięci wymagają pewnej sekwencji do zapisu, to trzeba na starcie ZABLOKOWAĆ takie przebiegi odpowiednim układem podczas startu. Czyli błąd projektowy. Szczerze mówiąc dla mnie jest to główny powód, dlaczego jeszcze nie mam tego kartridża.

@zenon - startowy sektor jes zapamiętywany we wpisie z nazwą pliku, podobnie, jak ilość sektorów i status pliku (począwszy od sektora 361/$169)

Pliki w formacie MyDos Double Density począwszy od podanego sektora przebiegają po liście sektorów, gdzie na końcu każdy sektor ma link do następnego, z wyjątkiem ostatniego sektora w pliku (16 bitów). Poza tym jest też zajętość sektora (8 bitów) Czyli sektor ma 253 bajty danych i 3 administracyjne. A sama zajętość leży w liście FAT, sektory poprzedzające sektor 361 będący pierwszym sektorem katalogu, czyli $169 - w zależności od ilości sektorów nośnika. może być ich kilka, bo jeden sektor 256 bajtów niesie info o ca 2000 sektorów.
- 40: CommentAuthorZenon
- CommentTime7 May 2023
Błąd nie błąd....
A po co dyskietka ma z boku otworek który po zapisie należy zakleić?
Ile razy przypadkowo nie zaklejając go wykasowałeś co na niej?
Przecież z niezaklejonym otworem dyskietka prawidłowo odczytuje, zapisuje etc... to po co zaklejać.
takim otworkiem dla ramcarta, ogólnie, dla pamięci SRAM jest to że "wachlując" zasilaniem, nie powinien być w tym czasie w trybie zapis.
Zapewne względy finansowe zadecydowały że projektując układ wybrany został prosty sposób zabezpieczenia przed mogącymi pojawiać się przekłamaniami a nie strzelista konstrukcja.
A samo atari, jego pamięć robi co chce i ustawia komórki jak chce. Po włączeniu zasilania system traci czas i pyrczy by doprowadzić wszystko do porządku. A samo wymuzdrzanie, i radzenie sobie z problemem by jedna kość była innego rodzaju i tak nie usuwa go całkowicie. To błąd w projekcie? Tak już jest, sądzę że każdemu się przytrafiło że włączył Atarynkę i nie działa, ponownie włączył i działa. Z Ramcartem jest podobnie, tyle że tu bardziej może to wkurzyć człowieka.
Nie to żebym pod niebiosa wychwalał ten moduł, ma swoje zalety i wady, i też uważam że dobrze byłoby gdyby w 100% był tylko z zaletami. Dlatego w instrukcji twórcy napisali... (parafrazuję), nagraj na niego grę, zainicjuj i używaj jak zwykłego kardridża.

Tak, to wiem jak sektory są powiązane, na nagranym ramcarcie jest podobnie, tak też mają stacje dysków sektory w EPROM poukładane i po starcie EPROM symuluje dyskietkę i ładują się z niej programy, procedury.
I wiem że nie jest to tak prosto oprogramować bo numer sektora przeliczany musi być na adres w pamięci.
Dlatego jestem pełen podziwu dla ludzików którzy się za to biorą i posuwają do przodu. A moje przemyślenia.... może pomogą, może nie.
- 41:
  
  CommentAuthorjhusak
- CommentTime7 May 2023
@Zenon - wiem, że mocno rozwinąłeś ten projekt i rozumiem, że masz do niego sentyment.

Ja bym zaakceptował, jeśli można włączyć i wyłączyć zapis jak na dyskietce. Ale tu widzę, że jeszcze trzeba uruchamiać jakiś program do tego, a to powoduje decyzję: fajny cart ale ja nie mam takiej dyscypliny i zaraz sobie go uwarzę (zawartość) - co go dla mnie dyskwalifikuje, bo ja bym go używał właśnie jako stacji dysków.

Więc może warto pomyśleć, jak dorobić ten zabezpieczacz przed zapisem przez pierwsze kilka sekund, może będzie to płyteczka "wlutuj se i będziesz zadowolony" i sprawa rozwiązana nawet dla użytkowników dotychczasowych kartridży.
- 42: CommentAuthorZenon
- CommentTime7 May 2023
To znaczy, sposób użytkowania i obsługi wymyślili projektanci. Taka ich koncepcja. Ja tylko rozbudowałem do większych pojemności, po drodze dodając bajery w postaci DoubleRamcarta, odczytu rejestru, zamiany lini RD4, RD5, przystosowania do współpracy ze Spartą i takie tam...
Sentyment mam bo na tym poznawałem niuanse Atari. Gdyby pamięci EEPROM, przy zapisie były tak szybkie jak przy odczycie.... problem prawie rozwiązany.
Może się mylę, ale przełączanie musi odbywać się pod kontrolą procedury. Atari nie pozwala bezkarnie przełączać sygnału RD5 kiedy się chce. Przełączanie równoznaczne jest z włożeniem, wyjęciem kartridża z gniazda gdy Atari włączone. NIE WOLNO.
- 43:
  
  CommentAuthorjhusak
- CommentTime7 May 2023
Może nie rozumiem, ale co ma rd5 do przełącznika rw?
- 44: CommentAuthormono
- CommentTime7 May 2023
Jak przełączasz RW to negowane jest znaczenie bitu 0 w $D500.
- 45: CommentAuthorZenon
- CommentTime7 May 2023
To jest powiązane.
Przełącznik w pozycji zapis i włączamy komputer
Rejestr, bit D0=0 przez przełącznik RW przechodzi na RD5=0
Druga sekcja przełącznika łączy WE pamięci ramcarta z bramką generującą impuls zapisu. Można pamięć zapisać ale jest to niemożliwe bo RD4, RD5=00 i pamięć jest odłączona sygnałem CS bo MMU nie generuje sygnałów S4, S5.
Można teraz ustawić D0, D1=11, więc wpisujemy, MMU przełączy na pamięć ramcarta i można go zapisać. To tak w skrócie bez wnikania w inne niuanse.
Gdy przełączymy teraz przełącznik w tryb odczyt, wtedy D0=1 (bo został ustawiony) ale o stanie RD5 decyduje teraz wyjście bramki NOT I RD5=0 RD4 nadal=1.
To przełączenie powinno się odbywać pod kontrolą procedury, bo przełączenie w dowolnej chwili skutkuje.... THE END.
Coś podobnego robi system gdy podmieniamy wektory przerwań, trzeba grzecznie poczekać na koniec synchronizacji pionowej i wtedy jest sukces. Nawet w systemie jest do tego przygotowana procedura. Dla Ramcarta trzeba podobną uruchomić z zewnątrz.
Oczywiście możemy programowo wymusić stan odczyt. Przełącznik nadal w pozycji zapis. Wpis do rejestru D1, D0=01 przez przełącznik ustawi RD5=1, MMU przełączy na pamięć ramcarta. A że przełącznik jest w trybie zapis więc do pamięci ramcarta można zapisywać.
- 46:
  
  CommentAuthorgienekp
- CommentTime7 May 2023 zmieniony
Taka myśl. Bo w sumie wyłaniają się trzy zastosowania ramcarta:
- jako rozszerzenie ram - nie mam zastrzeżeń
- jako dyskietka - sekwencja włączenia przycisku R/W akceptowalna
- jako dysk twardy - nie akceptowalne - trzeba wymyślić jakiś trik, żeby nie było tych "procedur". Dysk twardy zawsze musi być w trybie R/W.

Ponieważ przełącznik R/W neguje znaczenie Bit 0. To jak kart był wyłączony (RD5=0) to wciśnięcie R/W spowoduje, że RD5 dostanie 1.

Ale to się prosto omija (są dwie metody tę z CRITIC = $42 nie opisuję) . Jeżeli już mamy skopiowany ROM do RAM (a tak musimy zrobić, żeby zabotować z ramcarta jak z dysku) to według Zientary:
```
;SYStem Vertical
;BLank interrupt
       *= $C0DF
WAIT   JMP WAIT
       (...)
PHASE2 LDA TRIG3
       CMP GINTLK 
       BNE WAIT
```
wystarczy CMP GINTLK podmienić na CMP TRIG3 i RD5 nam nie straszne. Gorzej że podmienia się bank gdzie akurat często siedzi DL i obraz.
Ale jakby JMP WAIT zamienić na JMP TRIK i dać pod TRIK procedurę co zaneguje Bit-0 $D500 to problem znika. User może pstrykać RW i NIC mu się nie zawiesi. Najwyżej na czas niepełnej ramki mignie mu obraz. Oczywiście wszystko się pieprzy jak jakiś program PORTBem przywraca ROM. A programy robią to nagminnie, nie mówiąc już, że MyDOS to robi :/

Odporność na reset ciepły ja uzyskałem podmianą DOSINI na
```
jsr RESTRAM
        jmp $07E0 ; MyDOS  4.53/4	
RESTRAM lda PORTB
        and #$FE
        sta PORTB
        rts
```
Dlatego jest tak na około, bo zawsze siedzi w RAM procedurka, że jak nam program namiesza w PORTB to RUN 0133

I tyle można programowo zabezpieczyć. Reszta to hardware.

Zenon:
Oczywiście możemy programowo wymusić stan odczyt. Przełącznik nadal w pozycji zapis. Wpis do rejestru D1, D0=01 przez przełącznik ustawi RD5=1, MMU przełączy na pamięć ramcarta. A że przełącznik jest w trybie zapis więc do pamięci ramcarta można zapisywać.

hmm, nie kumam
- 47: CommentAuthorZenon
- CommentTime7 May 2023 zmieniony
Powyżej nie wspomniałem o niuansach.
Ale to proste
Tryb zapis
D0=0 RD5=0
D0=1 RD5=1
Tryb odczyt
D0=0 RD5=1
D0=1 RD5=0
a że wpis do rejestru nie jest blokowany więc niezależnie od położenia przełącznika można programowo dowolnie ustawić stan bitu D0 rejestru a RD5 zachowuje się jak wyżej.
Ale stan linii WE pamięci zachowuje się w/g położenia przełącznika a nie rejestru i nie można tego zmienić programowo.
Więc pomimo że wymuszony został tryb odczyt, do pamięci można wpisywać.
- 48:
  
  CommentAuthorjhusak
- CommentTime7 May 2023
HA - ależ to rozwiązuje problem! Przynajmniej tak mi się wydaje.

Bo z tego, co zrozumiałem, to tryb read służy do emulacji kartridża i startuje z banku 0, a tryb RW domyślnie nie włącza banku, zachowuje się, jakby kartridża nie było, co pozwala na kontrolowane zapisywanie do niego, nie?
- 49:
  
  CommentAuthorgienekp
- CommentTime7 May 2023
No właśnie hardwarowo pamięci i tak działają pod dyktando przycisku, więc programowo nic się nie da zrobić :/

Właśnie zdałem sobie sprawę, że tryb "dysk twardy" nie jest możliwy. Jeżeli aktualnie wykonuje się kod z banku górnego to wciśnięcie przycisku RW zawsze go zabije. I nie druga faza VBLANK ale najnormalniej program poleci na manowce i dodatkowo może namieszać w danych randomowo.

Pozostaje praca dyskietkowa i przełączanie pod nadzorem jakiegoś programu. Więc podejście, z którym się próbowałem, żeby mieć jak największy obraz ciągły jest bez sensu. Bo skoro i tak już będą wirtualne dyskietki to niech $D501 wybiera numer dyskietki a $D500 niech będzie tą daną dyskietką. Pojemność i tak będzie niemała bo prawie 1MB.
- 50: CommentAuthormono
- CommentTime7 May 2023 zmieniony
Można przepisać kod górnej połówki banku 0 do RAM żeby się przed tym zabezpieczyć.

Edit: A przed zwisem w VBLKD można się zabezpieczyć robiąc na VBLKI
```
sta WSYNC
sta WSYNC
lda TRIG3
sta GINTLK
```
Edit 2: Można by się zastanowić też nad konsekwencjami jednorazowego wykonania:
```
lda #%00000100
sta PMCNTL
```
przy inicjalizacji carta, co spowodowałoby zatrzaśnięcie stanu TRIG3, więc przyciskanie RW jakkolwiek odłączałoby obszar pamięci, ale nie wieszałoby systemu.

Od 51 do 100 z 168