Tak. Domyślny jest bank 0, zapis pod $d500+0..7f - ustawia bank 0..7f, >=d580 wyłącza kartridż i dostępny jest ram zamiast tego. Nie ma sensu cytać z d5xx, nie jest to zaimplementowane w hardware, odczyt powinien dać ff (rezystory podciągające).
Przy czym JatariCart ma 1 lub 2 chipy prom/eprom/eeprom/flash. W związku z tym możliwa jest konfiguracja taka, że dostęp do pierwszego chipu (i boot banku) ogarniają adresy d500-d53f, a do drugiego chipu d540-d57f. Jeśli chip jest mniejszy, niż 4Mb (512 kB), banki się zawiną w zależności od wielkości chipa, ale zawsze chip startuje od d500 lub od d540 (bit 6 wybiera chip 1 albo 2)
W przypadku jednego chipa, po wybraniu banku nieistniejącego chipa, cały bank powininien być wypełniony ff (rezystory podciągające)
@gienekp, jeszcze jakbyś dał źródłowe atr-y do tych car-ów co żeś wygenerował, to mógłbym coś potestować, bo jak na razie nie mogę trafić na działającego, z wyjątkiem tych, co są robione z xexów i Biednego Psa Antoniego.
Widzę, że używasz jedynej sensownej platformy sprzętowej :D
Po dodaniu opcji -c ruszył i Rycerz, i Klątwa, i Beer Belly Burt Brew Biz (swoją drogą ktoś był nieźle naćpany wymyślając taką nazwę), Vicky, ale tylko intro, ale Raid Over Moscow nie i Beach Head też nie. Na oryginalnym typie kartridża.
Jest bardzo dobrze. Podejrzewam małe poprawki konieczne do uruchomienia pozostałych gier.
J(atari)Cart jest OpenCource czy obstawiony patentami?
Bo jakby był Open to byłaby to dla mnie idealna platforma do dalszej zabawy. Przygotowuje sobie różne takie zabawki, tylko z cartami to jest tak, że albo twórcy zamknęli temat, albo gdzieś to przepadło albo nie chcą dać/sprzedać itd. A widzę, że J(atari)Cart ma bardzo przyjazne i logiczne bankowanie. Siedzi na $A000-$BFFF co się dużo łatwiej ogarnia niż np. $8000-$BFFF. Przełącza się adresami, czyli oba zbocza PHI2 można wykorzystać, CZYLI GAL20-tka wystarcza (bez zatrzasków) do zrobienia całego carta ReadOnly.
Czy jakiś emulator J(atari)Carta emuluje? Jeżeli nie to kogo przekupić żeby w Atari 800 emu było?
Planuję zrobić: - "sklejaczkę" XEX ale na wszystkie systemy a nie tylko windows. Loader już mam więc z górki - zapis... i będę miał już wszystko do RAMcarta, po prostu po bandzie zrobi się plik ATR np. 4MB i potem tylko program klonujący do RAMCARTa, ale jak będzie zapis to i J(atari)Cart by śmigał, czyli ATRy w carcie można by zapisywać. - powiesić atr2car tylko na D1 (lub innym numerku w opcji) - pierwsze testy pozytywne - zrobić urządzenie G: i natywnie czytać/zapisywać na G:. No bo np. jak na pierwszym banku wkleję basica to SAVE "G:FAJNE.BAS" i szafa gra. Na razie mam już obsługę G: (nawet relokowalną) zostaje tylko powklejać funkcje.
Wszystko OpenSource, żeby przekonać ludzi do cartów. No ale muszę mieć standard też Open.
Jatari Cart, to jest przecież kartridż zgodny z Maxflash. A Maxflash jest obsługiwany w emulatorach. Zapis na takim kartridżu nie jest też żadną tajemnicą, ani nie jest wiedzą, której jeszcze nie zgłębiono. Na kartridżach zgodnych ze standardem Atarimax-Maxflash wyprodukowane są fizyczne wersje gier FloB i Tensor Trzaskowskiego. Obie gry mają wbudowany zapis ustawień i osiągnięć/rekordów na kartridżu i obie te gry mają udostępnione publicznie źródła. Tensor jest zrobiony w assemblerze przez mgr_inz_rafala, a FloB w MadPascalu, do którego Bocianu zrobił szereg bibliotek (blibs) napisanych w assemblerze do obsługi kartridża Maxflash. Wszystko jest gotowe i działające, a źródła można znaleźć na stronach autorów i korzystać do woli. Dodatkowo xxl zrobił taką wersję swojego xbiosa czy tam xdosa, już nie pamiętam, która pozwalała plik atr wrzucić na kartridż zgodny ze standardem Maxflash. W ten sposób kiedyś testowaliśmy Prince of Persia na takim kartridżu i działało. Tylko tu nie wiem czy xxl upubliczniał gdzieś kod, czy trzyma go w tajemnicy.
wersji (kodów dla plików CAR) dla 256kB i 512kB NIE MA, a SXEGS i SIC mają, to mnie zmyliło, bo wcześniej męczyłem 512kB, ale w sumie można się tym nie przejmować bo standard 42 to ogarnia.
Czyli dobrze by było, żebym w konwerterze dał opcję czy się chce plik CAR czy może BIN (dla programatora). BIN wyjdzie o wielkości wlutowanej pamięci (LUB DWA BINY), CAR zawsze z kodem 42 1MB dopełniony np. FFami.
Na Githubie znalazłem ->link<- a tam w tytule bije "J(atari)Cart256(kB) J(atari)Cart1024(kB)".
W każdym razie przy okazji na bazie szablonu Mq do obudów Sikora zrobiłem: ->link<-
pod pamięć 128/256/512kB w trybie readonly. Płytka jest tak zaprojektowana, że w zależności od wsadu do ATF22V10C można mieć albo 41 albo 42 albo ten "plus". Plus to do eksperymentu z SDX, że pierwsze 128kB to jest wersja beta a drugie 128kB to stabilna. Ponieważ przełączenie tych wersji jest pod innym adresem to powinno mi to zadziałać. Tak czy siak wsadem do GALa zawsze mogę wrócić do normalnego maxflasha (41 lub 42).
Płytki będę miał lada dzień, zamawiałem inny projekt do firmy to te podłożyłem, doszły jakieś kupony i 50 płytek pozłacanych wyszło w cenie zwykłych, więc jak ktoś będzie chciał do zabawy to mogę to przekazać. Wiadomo, licencja na to jak w szablonie Mq, można robić z tym co się chce, nie ma to dla mnie żadnego znaczenia.
Jeszcze jest taka kwestia, że typ 42(8Mbit) to jest kartridż, który domyślnie startuje z banku 127. To jest swego rodzaju pomyłka producenta tego kartridża, i tak było w pierwszych wersjach produkcji. Później to poprawili i kolejne edycje kartridża startowały już z banku 0 - tak jak powinny. No i tak jest do dziś. Ale w emulatorze zostało że nr 42 to jest kartridż startujący z banku 127. W altirra są dwa maxflash'e 8mbit i jeden z nich nazywa się old, a drugi new. Ten old ma numerek 42, a ten new nie ma wcale numerka, więc nie idzie zrobić pliku car z nagłówkiem, żeby taki kartridż startował automatycznie w odpowiednim typie. Ale jak się zrobi obraz kartridża bez nagłówka i odpali w emulatorze, to emulator pyta co to za kartridż i wybieramy właśnie new, wtedy startuje z banku 0. To jest o tyle istotne, że jest jeszcze też możliwość zrobienia maxflasha 4Mbit, który ma jedną kość pamięci zamiast dwóch. Taki kartridż nie ma wtedy oczywiście banku 127, bo ma tylko 64 banki i startuje normalnie z banku 0 jak ten new 8Mbit. Oryginalne oprogramowanie Maxflash Cartridge Studio generuje pliki atr do programowania kartridży z poziomu Atari, i ten atr potrafi rozpoznać kartridż 1Mbit, 4Mbit, 8Mbit i zaprogramować. Kartridż 4Mbit działa identycznie jak 8Mbit, tylko ma ucięte połowę banków. Na takim "połowicznym" kartridżu jest wydany FloB i Tensor. Tak że jeśli chcesz zrobić kartridż zgodny 100% z Maxflash, ale na jednej kości, to jak najbardziej możesz iść tą drogą.
właśnie kieruję się w stronę 4Mbit, bo to jest jedna kostka 512kB i takie jakby optimum rozsądku, logiki i kosztów. W takim razie będę robił BINy bo to aktywuje czujność "operatora" i opcją CAR pod emulator do testów (ze startem 127)
...a że adresy można łapać na zboczu narastającym zegara to by mi dało ekstra 2 piny w ATF22V10C czyli mógłbym wejść na level wyżej i zrobić zapis. Taki cart miałby tylko dwie kostki:
Oryginalny Maxflash ma kości AM29F040. Różnica jest taka, że jest inny rozmiar sektora w tych kościach niż w SST39SF040. Z elektronicznego punktu widzenia i dla nowego softu, to lepiej jest w tych SST, bo jest mniejszy sektor, więc można mniejsze porcje danych kasować i zapisywać. Ale z punktu widzenia zgodności, to kość SST39SF040 nie jest zgodna z tym standardem w zakresie zapisu. Oczywiście odczyt zadziała identycznie, kasowanie i zapis całej kości też, ale już sektorowe podejście będzie inne. Czyli np. nie zadziała obraz kartridża FloB i Tensor, które zapisują większe sektory. Oryginalne oprogramowanie od Maxflasha też nie zadziała w ogóle, bo ono0 z kolei rozpoznaje sobie jaka kość siedzi w kartridżu i działa tylko na kościach AMD. To trochę słabe, bo jest cały szereg kości innych producentów ze zgodnością 100%, ale soft od maxflasha nie widzi takich kartridży z innymi kościami. Co ciekawe, jak się wsadzi kart z kością AMD, to program wykrywa sobie Maxflash i wtedy na włączonym kompie można podmienić kartridż na taki z inną kością i normalnie się zaprogramuje. Zapis w grach FloB i Tensor działa poprawnie na dowolnej kości zgodnej z AM29F040.
I druga sprawa: jest problem z dostaniem scalaków z logiką, które chcesz zastosować. Mam to samo z moimi kartridżami, ja tam stosuję xilinx XC9536XL i obecnie nie da się ich kupić. To trochę do dupy, bo chciałem wydawać kolejne gry...
Tak, będę jednak szedł w stronę SST39SF040. Najwyżej będę miał więcej do oprogramowania. No i tak jak piszesz, mniejszy sektor jest przyjaźniejszy, zwłaszcza jak się trzeba podpiąć do krwiobiegu gry z przed 30 lat. Wtedy zawsze brakuje pamięci na bufory.
W ogóle to raczej powolutku będę robił wszystkie narzędzia od zera. Wieloplatformowe i otwarte. Oczywiście bazując na tym co jest no i wiadomo nie wchodząc w kolizje komercyjne. Zrobi się konsolowo, potestuje i potem GUI i wilk syty i owca cała.
Z dostępnością jest jakaś masakra, no ręce opadają. Zaczęły znikać GALe 16-tki to myślę, można obskoczyć 22-jką. Zamówiłem sobie kilkanaście sztuk, poprojektowałem płytki... Jeszcze płytki nie doszły a tu kurde układów brak. Jakieś szczątkowe ilości na SMD i kicha. Kończą się GALe, CPLDeków brak, a FPGA tańsze latają po rynku z ceną 100x większą (!). Czyli co, kartka papieru i cofamy się do bramek i przerzutników? Może tak trzeba, jakby nie patrzeć J(atari)Cart taki jest.
Jedyny plusik to, że emulator ATARI800 z jądrem 5 ma: | 75 | 800/XL/XE | 1024 | Atarimax 1 MB Flash cartridge (new)
O, to fajnie że uwzględnili ten nowszy maxflash pod osobnym numerkiem 75, nie wiedziałem tego.
Co do dostępności elektroniki, to wszystko po kolei znika z rynku, bo wyprzedają się zapasy, a fabryki nie dostają surowców do produkcji. Wiem to z pierwszej ręki od Mousera, bo dzwoniłem do nich i uciąłem sobie pogawędkę. Jakieś 2 miesiące temu pytałem ich czy jak układy nie są dostępne, ale jest podana data dostawy, to można je kupować i będą - powiedzieli, że tak, więc zamówiłem w Mouserze xilinxy, bo podawali, że 22 lipca będą. Dziś dostałem info od Mousera, że zmieniły się daty i poinformują mnie o nowych terminach. Przy tych zamówionych przeze mnie xilinxach nie ma na stronie w ogóle podanej daty dostawy, a przy innych jak jest jakaś data, to wszystko 2023, czyli tak jak by nie było. Co ciekawe, pomimo braku tych xilinxów zmienili ich ceny - podnieśli o 100%-150%. To samo ze wszystkimi atmegami, attiny itd. Myślę, że to, że zwykłe układy TTL są jeszcze dostępne, wynika z tego że jest więcej producentów tych układów, więc świat dysponuje większymi zapasami magazynowymi, a też układy te nie są już tak powszechnie wykorzystywane, więc jeszcze leżą.
No wszędzie pojawia się ten przeklęty 23-rok. Niedobrze, bo poważne projekty w firmie zaczynają się kłaść. Ja akurat siedziałem na alterze (teraz intel). Najgorsze bo nie wiadomo jak projektować, żeby za miesiąc nie było klapy.
Z tego co obserwuje to wciąż ESP32 jest OK no i te stare 74xx zwłaszcza na SMD. Ciekawe, czy ktoś robił jakieś projekty dla ATARI z ESP32? Czy np. ESP zdążyłby ze swoimi IO zareagować na to co się dzieje na pinach carta.
Mq Twój szablon płytki do obudowy Sikora daje dość sporo miejsca na elementy a to znacznie podnosi możliwości upychania 74XX więc na razie przegrani nie będziemy. Trzeba tylko wrócić do starej szkoły (jak z całym ATARI :) ).
No nic, mamy kod 75, TTLy jeszcze są więc całe moce trza skierować w stronę J(atari)Cart z zapisem. Wieczorkiem coś postukam i zobaczę czy AVGCart kod 75 "już umie".
Rok 2023 gdzie się pojawia, to znaczy, że tak na prawdę nie jest to konkretny termin, tylko coś tam musieli wpisać. Surowce nie są dostarczane do fabryk, więc nie produkują, a daty dla tych niedostępnych komponentów z tego co widzę podaje się jako dziś+czas realizacji zamówień z fabryki, a ten wynosi zwykle 52 tygodnie (tak podają oficjalnie). Ktoś to tam tak wpisuje i tak sobie wisi, żeby pewnie na stronach nie raziło, że wszystko jest niedostępne.
Przeciętny człowiek nie rozumie, że trwa wojna światowa, bo ta kojarzy mu się ze szczelaniem z karabinu a nie np. z blokadą surowców. Tymczasem elektroniki nie ma i nie wiadomo czy będzie, ja obstawiam, że jeszcze długo nie. Ów przeciętny człowiek zauważy co się dzieje dopiero jak zniknie jedzenie z półek w markecie, bo rolnik nie wyjedzie traktorem na pole, bo mu elektronika padnie w traktorze i nie będzie czym jej naprawić. Może wcześniej padną np. chłodziarki w markecie, to też na jedno wychodzi. To że my nie mamy scalaka do kartridża Atari, to się wydaje ciekawą przygodą z poszukiwaniem jak temat obejść. Tymczasem tych samych scalaków brakuje firmom produkującym praktycznie wszystko co nas otacza na świecie, bo w każdej branży i każdej technologii, we wszelkich liniach produkcyjnych itp. elektronika jest dziś nieodzowna. Atari się nie popsuje, a jak się popsuje, to można łatwo naprawić. Ale każda nowsza elektronika (współczesna) od kilkunastu lat jest produkowana w technologiach "zielonych", które sprawiają, że elektronika działa kilka lat i koniec, więc słabo to widzę. Ale to tak nawiasem, sorry za offtopic.
@jhusak: czy ten opublikowany przez Ciebie na githubie schemat Jatari starszy w wersji v5 (256k), to jest przetestowany i działało tam wszystko bez problemu? Pytam, bo chcę sobie zaprojektować maxflasha do swoich potrzeb wydawniczych "po swojemu" (być może z uproszczeniami zmniejszającymi np. ilość banków pod moje konkretne gry). Rozchodzi się o to, że jeśli u Ciebie czasy propagacji na poszczególnych sygnałach są dobrze ustawione tymi wszystkimi bramkami szeregowo łączonymi, to bym się o to oparł częściowo i nie potrzebował bym tego testować ponownie i wyważać otwartych drzwi. Z tego co widziałem, to tam sterowanie zapisem/odczytem masz zrobione w standardowy sposób z sygnałów RW i PHI2, zatrzaskiwanie też standardowo, jedynie zastanawiam się nad tą częścią sterującą /CE (tam te bramki szeregowo i diody).
@Mq To "dla własnych potrzeb" to będzie otwarte czy zamknięte?
@All Czy ktoś kiedykolwiek robił taki trik, żeby programować flasha TYLKO XEXem (bez kodu 6502). XEX to w zasadzie takie POKE w blokach. Skoro J(atari)Cart można zapisywać, to po co budować jakieś ekstra narzędzia jak można zrobić taki prosty generator XEXa (flash2xex) co najpierw robi serie poleceń kasujących a potem serie poleceń programujących. Wtedy wkładało by się polutowanego ale nie zaprogramowanego J(atari)Carta uruchamiało xexa na czymkolwiek, nawet z magnetofonu (trza tylko wykrzyknik dograć) :) i blok po bloku mielić.
Tak robię (no, prawie) :) Generuję xexy z loaderem, wrzucam na SIO2SD i programuję. Jest funkcja weryfikacji z nadpisywaniem i tylko weryfikacji.
Tam są zależności czasowe, które trzeba ogarnąć, każdy zapis bajtu jest obudowany protokołem zapisu, więc taki xex, jeśli by działał, byłby bardzo długi, a po wywołaniu erase należy trochę odczekać, czyli trzeba by robić 5*50*312 zapisów do wsync np aby mieć pauzę 5 sekund. Bez żadnej kontroli, nie wiadomo, co się nagra.
Tak, przetestowane, Ridiculous Reality, Kolony, Adam Is Me, Deszczownik, Cosmic Hero i pewnie jeszcze coś :)
A te diody to bramka OR, tańsze niż kolejny scalak. Na wersji 1MB są dwie takie, na 256kB jedna i tylko w wersji read only.
Nie ma sensu "robić pod potrzeby", lepiej "uniwersalnie", jak jest. W zależności od tego, jaki flash 5V przylutujesz, będzie działać. No i prom też, ale ten trzeba zewnętrznie zaprogramować.
Jedno mnie zastanawia, po włączeniu kart niezaprogramowany zgłosi się na RD5 jedynką no i atari poleci w maliny. Z drugiej strony OS ma dwa rejestry TRIG3 i GINTLK. Jeżeli się różnią to przy VBLanku zrobiony będzie reset, a całość oznacza, że zmieniono carta. To co atari przewidywało przekładanie cartów w czasie pracy? To jest to hotplug?
No bo jeżeli w czasie pracy można wsadzić carta, to należałoby puścić w pętli:
lda TRIG3 sta GINTLK
Potem wsadzić kompletnie nie zaprogramowany cart, potwierdzić klawiszem, zaprogramować i zrobić reset. Nie mając żadnego programatora, możnaby sobie carty robić.
Pusty kart nie startuje, tak jakby go nie było. Natomiast jeśli jest zaprogramowany, to ja wykorzystuję reset bug lub to, że on się przełącza i bywa, że się wyłączy, jak przychodzi reset. Trzecia opcja to rozgałęziałka Toriego na 4 kartridże, które można przełączać i włączać i wyłączać.
Nie kumam ORa z diod. Przecież nS5 nie powinno się pojawiać gdy RD5 jest 0. Więc dlaczego nie połączyć na wprost nS5 do nCE pamięci?
Nie gra mi też logika dla nWE i nOE. Jeżeli dobrze zdekodowałem to: nWE=0 tylko gdy nRW=0 (to OK) i PHI2=1 (przecież dane są nie gotowe?) nOW=0 nRW=1 i PHI2=1 Patrzę pod kątem pamięci SST39SF040
@gienekp - esp32 jest całkiem szybkie. trochę dziwny procek, wywodzący się bardziej z MIPSa, niż czegoś innego, ale szybki i są dwa. carta powinien uciągnąć bez problemu, tylko trzeba buforki 5-3.3V postawić.
@gienekp: nie myślałem o tym w kategoriach otwarte/zamknięte. Jak robiłem kartridż na xilinx, to publikowałem wersję read only, którą zrobiłem na początku. R/W już nie opublikowałem, bo nad readonly pracowałem kilka miesięcy (w tym czekanie na kilka kolejnych poprawianych wersji pcb), po czym zobaczyłem komercyjnie wydaną grę na kartridżu zrobionym z tego projektu. Takie rzeczy irytują. Pewnie z podobnych powodów Kuba opublikował tą starszą wersję jatari, a ostatecznej już nie.
Myślę, że to jest dobre rozwiązanie, że się publikuje projekty działające, ale wymagające własnej inwencji do dokończenia pod własne potrzeby i ulepszenia dla zyskania pełniejszej funkcjonalności. To zaspokaja zarówno oczekiwania dzielenia się wiedzą i udostępniania projektów innym twórcom, jak i pozostawia trochę do zrobienia samodzielnie we własnym zakresie, żeby każdy kto chce mógł z tego skorzystać tak jak chce, ale żeby odciąć cwaniaczków, którzy się na tym nie znają, ale biorą i produkują dla zysku kosztem pracy innych osób, bo widzą w tym łatwe pieniądze dla siebie bez nakładu pracy.
Jednocześnie @gienekp: jeśli chcesz, to np. Tobie udostępnię cokolwiek mam, bo widzę, że wkładasz sam też masę pracy i dzielisz się wiedzą z innymi. Wyślij mi maila (mój mail jest w profilu), to dam Ci moje źródła z xilinxa, może Ci się przydadzą do porównań.
Tak widzę temat publikowania i dzielenia się efektami swojej pracy, poświęconego czasu i pieniędzy.
A w temacie merytorycznym: ja wiem o co chodzi z bramkami uproszczonymi na diodach, ale właśnie pytałem Kubę o to, czy to jest sprawdzone dobrze pod kątem tego, że widać, że tam ta część schematu z tym podwójnie zanegowanym sygnałem do /CE, to jest robiona celowo żeby sygnały poprzesuwać na propagacjach i odpowiednio poustawiać. Wiem, że w Atari dotyczy to często sytuacji gdzie dla zapisu i odczytu trzeba trochę inaczej przesunąć/wydłużyć sygnały. Dlatego pytanie czy to działa dobrze zarówno dla odczytu i zapisu. @gienek możesz mieć rację ze swoimi równaniami, ale może się właśnie okazać, że timingi nie będą dobrze pasowały. Nie wiem, tylko sugeruję i dopytuję Kubę jak to analizował:-)
Mq - w punkt. Rzeczywiście, chciałem trochę odrobić koszty projektu. W sumie się zwróciło chyba.
Posiłkowałem się samouczkiem "Projektowanie Cartów" by Zenon. Aż taki mundry to ja nie jestem, ale z tymi propagacjami to "mam to gdzieś w pamięci", jak projektuję. W sumie, jak się stosuje HCT czy TTL, to te propagacje są wystarczająco długie, żeby wszystko się poustalało. Pamiętam, że analizowałem układ pod względem sygnałów nieustalonych przy przełączaniu.
I jeszcze - podwójne zanegowanie to efekt optymalizacji części, można wywalić układ 7400, wlutować 3 rezystory i tę diodę i masz read only.
Mq w 100% się zgadzam. Granica pomiędzy Open i Komercja powinna być wyraźna i każdy powinien mieć swoją i nic nikomu do tego. Z Kubą już mam kontakt i wszystko gra.
Właśnie te timingi mnie trochę odstraszają. Zwłaszcza przy zapisie gdzie trzeba ze zboczem Write dla flasha odpowiednio się wyrobić :/ Bo tam na narastającym flash zapamiętuje adres a na opadającym dane. A dane przecież ATARI ma gotowe na opadającym. Toż to się musi zejść w czasie.
W ogóle to sobie zrobiłem płytkę co wyciąga port carta na goldpiny. Bo tak normalnie to tragicznie się oscyloskopem lata po tym złączu. ->link<-
Płytka już wylądowała, pewnie za tydzień będę miał to sobie zobaczę jak wyglądają przebiegi luzem a jak obciążone różnymi bramkami i przerzutnikami.
I jeszcze jedno, na schemacie JatariCarta sygnał do zatrzaskiwania przerzutników nie uwzględnia RW, rozumiem, że bank PRZEŁĄCZY "LDA" jak i "STA" w sensie jakikolwiek odczyt lub zapis z $D5xx?
Maxflash przełącza banki na "dotknięcie" adresu. Czyli nie ważne czy LDA czy STA się robi i nie ważne jakie dane tam lecą. Ważny jest adres tylko i pojawienie się z tym związanego CCTL (czyli adres z zakresu piątej strony).
Znalazłem taki pliczek tekstowy u siebie na kompie, w którym zapisałem ważne informacje o działaniu kartridża. Wklejam zawartość mojego pliku. Część po angielsku przeklejona z forum atariage jeśli dobrze pamiętam, tam chodziło o uniknięcie zwisów przy włączaniu i wyłączaniu kartridża. I przykład przerzucania danych z pamięci kartridża do RAM pod kartridżem.
AtariMax -działanie
128 banków po 8k pod adresem A000-BFFF
Zapis pod adresy D500-D57F - aktywacja banku Zapis pod adres D580 - wyłączenie kartridża
Any bank switching operation will complete within a single instruction. So this will work fine:
lda $d500 ; turn cart on lda $a000 ; get a byte sta $d501 ; bank 1 ldx $a000 ; stx $d580 ; cart off sta $a000 ; save in ram under cart stx $a001 ; save in ram under cart sta $d500 ; cart back on
If you have the XL/XE OS enabled, remember there is a software cartridge interlock in the OS VBI routine that checks to see if a cart has been pulled out suddenly or suddenly inserted.
So if the OS VBI routine is installed and running every 1/60th second, you will have to disable interrupts before turning the cartridge on or off, and update the interlock register to reflect its new state before turning the VBI back on. This is not required to switch banks, only to turn from off to on, or on to off.
There is code in every flash cart module source file that shows how to do this safely and quickly. If you are going to rid yourself of the OS anyway for your game, you wont have to worry about the interlock anyway.
Żeby cart się nie zawiesił przy przerwaniu trzeba zrobić trik: lda TRIG3 sta GINTLK
Zientara "Podstawowe procedury systemu operacyjnego" strona 16. TRIG3 jest jakoś ustawiany sprzętowo, nie odkryłem jeszcze jak. Jeżeli GINTLK jest inne niż TRIG3 to jest to info, że włożono lub wyjęto carta (Zientara str.44). To jest ten HotPlug dla mnie zaskakujący.
Ja po kopiowaniu i mieszaniu bankami zawsze kopiuję Trig3 do GINTLK. Ale można się naciąć. Bo raz wyliczałem tak, żeby kopiowanie było na wygaszeniu pionowym. I pech chciał, że akurat łapało VBLK jak nie zdążyłem skopiować TRIGa 3 i kaplica. W najnowszej wersji kopiuję tak, żeby być przed VBLK :)
Dodam jeszcze, że przy zmianie banku, jeżeli wcześniej kartridż był włączony i nie odłączamy go, to nie ma problemu. Można go zmieniać "na żywca" i nic się nie wydarzy złego. Problem z wykryciem wyjęcia/włożenia kartridża w przypadku Maxflasha występuje tylko podczas całkowitego wyłączania kartridża i jego włączania (czyli przy wyborze banku na odłączonym kartridżu).
Tak niestety jak kopiujemy sektor z carta do RAM to włączamy cart, pobieramy bajt, wyłączamy cart i zapisujemy bajt. Pstrykamy tym co chwilę.
Wciąż nie gra mi logika sterująca R/W dla SST39SF040. Upierając się przy jednym typie bramek. To jeżeli wybór banku jest za dotknięciem to potrzeba 9 NAND, a jeżeli byłby taki wybór tylko przy W to 8 NORów (robi się wspólna cześć wykrywająca zbocze góra-dół przy Write). Sporo jest NOTów więc w praktyce to chyba lepiej dać scalak z sześcioma.
No najlepiej to by było GALem ogarnąć... którego nie ma dostępnego :/
Nie analizuję tego co narysowałeś, ale jedna ważna uwaga: jak się coś takiego projektuje w GAL-u, czy tam w jakimś nowszym CPLD/FPGA, to wystarczy zająć się logiką, zakładając, że dajemy coś na wyjście i mielimy wszystko w "czarnej skrzynce" dostając odpowiednie wyjście. Jest tak dlatego, że obojętnie co sobie tam w środku skonstruujemy, to czas propagacji od wejścia do wyjścia jest zawsze taki sam i nie musimy się nim za mocno przejmować. Przy konstruowaniu takiego układu za pomocą bramek z TTL-ek, musimy brać pod uwagę, że każda bramka ma swój czas propagacji i jak ustawiamy je szeregowo, to dłuższą drogą sygnał idzie dłużej, przez co jest opóźniony względem bezpośredniego sygnału albo innego sygnału, który np. przechodzi przez pojedynczą bramkę. Cała sztuka więc polega na tym, żeby tak poukładać bramki, żeby sygnały następowały w odpowiedniej kolejności logicznej po przejściu każdego miejsca w układzie. Tak że np. ja, żebym mógł cokolwiek w tym temacie powiedzieć, to najpierw musiał bym się dokształcić z tych sygnałów występujących na szynach Atari, żeby wiedzieć co tam po kolei jak przychodzić powinno. Jak sobie projektowałem zawartość xilinxa, to w ogóle się tym nie musiałem przejmować.
A co do kopiowania zawartości kartridża do pamięci: rozumiem że masz na myśli kopiowanie w to samo miejsce (czyli na przykład cały bank 8kB z A000 kartridża do A000 RAM). Nie trzeba co każdy bajt wachlować przerwaniami. Wystarczy wyłączyć przerwania, albo całkiem OS, wtedy normalnie można włączać/wyłączać kartridż i kopiować sobie zawartość, a dopiero po skopiowaniu całości włączyć z powrotem przerwania (czy tam cały OS).
gienekp aleś to skomplikował.... Dlaczego nie użyjesz 74LS138 i 74LS00, załatwi sprawę. W razie potrzeby użyj szybszych scalaków. Rozumiem że bit7 steruje RD5 poprzez rejestr. Narysowałeś że poprzez bramkę, nie mogę zaskoczyć dlaczego tak.
Pisze się, sprawdza a i tak przemyci się bubel. RD5=0 kart nieaktywny, RD5=1 kart włączony. Włączony, czyli można zaadresować pamięć na kartridżu i wykonywać operacje zapis/odczyt. Proste kartridże sygnał RD5 połączony mają z Vcc i taki kart jest zawsze włączony.
Na opublikowanym schemacie jatari v5, sygnał RD5 jest pobierany z rejestru i negowany, a wcześniej w nim zatrzaskiwany sygnałem CCTL z bitu 7 adresu. A więc chyba poprawnie, bo adres z bitem 7 ustawionym na 1 powinien odłączyć kartridż. W rejestrze jest wtedy zatrzaśnięte 1, a więc idzie przez negację do RD5 jako 0, co odłącza kartridż.
Tak, to ma sens. Ok, co się wpisze do rejestru to bez znaczenia, ważne że to co się z niego pobierze po "obróbce" przyjmie wartość "0" by kart odłączyć. Ramcart tak ma, że zero lub jedynka odłącza go w zależności od położenia przełącznika zapis/odczyt.
Mq ja to rozumiem. Też mam GALa i wpisuję logikę i wszystko jest OK. Kompilator załatwia to automatem. Na płytce mam pamięć gal i jeden kondensator. I szafa gra. Natomiast cofam się do "średniowiecza", na wypadek co będzie jak na rynku braknie xilinxów/alter/intelów/laticów i innych microchipów. Zostaną nam stare UCY-ki :) Trzeba i na taką okoliczność być przygotowanym. Kuba w swoim projekcie ma 3 scalaki i np. diody bo inaczej musiałby użyć 4 scalaki. Pytanie jaka jest minimalna liczba scalaków, żeby ogarnąć jeden 512kB w trybie odczytu i zapisu?
Mam przebiegi połapane oscyloskopem na łączu. To tak sobie to wygląda, bo jeśli chodzi o cart w trybie readonly to praktycznie robi się to na "drutach". Gorzej jak ma być zapis bo np. pamięć flash adres łapie na zboczu opadającym CE# lub WE# w zależności co będzie ostatnie. Jeżeli CE# spinamy na wprost z S5 a tak jest najbardziej logicznie to WE będzie decydować o czasówce. Pamięć flash dane do zapisu zatrzaskuje na zboczu narastającym CE# lub WE# w zależności co będzie szybciej. S5 atari trzyma dość długo (czyli CE#). A poprawne dane na łączu są dość krótko i pewne są tylko przy opadającym PHI2. Więc WE# MUSI się z tym zboczem zgadzać. Inaczej to będzie szukanie hazardu.
TTLki są tutaj wystarczająco szybkie w stosunku do atari więc kłopotu nie ma. Gorzej, że atari ma jakby lekko w fazie przesunięty zegar względem ustawiania adresów i danych.
Kopiowanie danych carta który emuluje ATR podpięte jest pod funkcję OSa, no bo musimy maksymalnie długo udawać, że mamy stację, a ta zakłada, że mamy dwa wskaźniki SKĄD i DOKĄD. Ponieważ nie wiemy czy "dokąd" nie będzie w RAM pod cartem, to niestety procedura kopiująca musi wykonać włączenie i wyłączenie dla bajta. To jest jedyna skuteczna metoda gdy program/gra zajmuje nam całą pamięć i mamy 0 bajtów na jakichkolwiek bufor. Nie można wtedy wyłączyć przerwań bo może akurat ktoś gra muzyczką w czasie wczytywania. Nie da się wyłączyć obrazu bo będzie miganie podczas ładowania. Generalnie z procedurą trzeba się tak wcisnąć, żeby nie ruszyć przerwań, zająć 0 bajtów w RAM i wyrobić się na styk przed VBLK. Oczywiście z zapisem ten numer nie przejdzie. Musi być taki bufor jak sektor flasha.
@Zenon Dobrze, że jesteś :)
bit7 to 7 bit rejestru, który trzyma $D5XX. Rejestr wstaje na 0 a RD5 musi mieć 1 po włączeniu. Nie ma rady musi być negacja. Bez znaczenia czy NOTem czy NORem czy NANDem. Coś tam trzeba dać.
rejestr np.74574 dla wartości $D5XX zatrzaskuje na narastającym, a że adres jest gotowy również na narastającym to należy przepuścić PHI2 tylko gdy CTTL=0 i ewentualnie RW=0 (tego maxflash nie chce bo cokolwiek na $D5XX go rusza).
nS5 "drutem" do nCE - tutaj mam dylemat (pod względem WR# flasha) czy nie trzeba coś się opóźnić. Trzeba oscyloskopem sprawdzić. Dla readonly działa drut.
nOE idzie w negacji do RW, tak przynajmniej chce dokumentacja flash
zrobienie nWE to jest wyzwanie. Powinno być w negacji do PHI2 tylko gdy S5=0 i RW=0.
No więc podsumowując, jak nam braknie GALi to według mnie potrzeba woreczek 74574 i dwa woreczki 7402, generalnie dwa produkty. No opcjonalnie można jeszcze konfiguracja po jednym 74574 7400 i 7404. Ale jakby nie patrzeć to 3 produkty, czyli rośnie mam prawdopodobieństwo, że któregoś braknie i klapa :)
Natomiast nie kumam tego 74LS138(dekoder 3 na 8) i 74LS00(NAND)... Co mi to da?
@gienekp: jak szukasz żeby było jak najmniej produktów potrzebnych, to może by się dało wszystko na samych diodach z uproszczonych bramek zbudować:-) Jeden produkt tylko potrzebny:-) Woreczek jakichś szybkich diod schotky'ego i już:-)
Co do LS138, to nie korzystasz z opracowań Zenona? Tu masz w opisach konstrukcji kartridży różnych kilka przykładów wykorzystania LS138: ->link<-
I jeszcze z tymi sygnałami, oscyloskopem i hazardami. Niestety jest tak, że co rewizja płyty, to sygnały inne. Więcej: co egzemplarz Atari to sygnały inne. A jak jeszcze ludzie porozszerzali sprzęty, to już timingi są tak porozwalane, że szkoda gadać, każdy sprzęt ma inaczej, a działa wszystko na styk zwykle. Wpięcie kartridża też nie pomaga sygnałom. A jednak jakoś te Maxflashe działają, więc widać się musi dać jakoś. Dlatego pisałem, że trzeba jakoś układać bramki, żeby "wyregulować" czasami propagacji odpowiednie wyrównanie sygnałów. Ja nie umiem, więc wziąłem szybkiego xilinxa i się nie przejmowałem, a wszystko śmiga elegancko. Pewnie siądę do tych TTL-ek, ale teraz nie mam czasu, może za kilka tygodni jak się będzie na horyzoncie zbliżała jakaś gra do wydania:-)
W sumie to ciekawe byłoby dać na bramkach nor: podwójna dioda w sot23 i mosfet w sot23 x 3 oraz 5 * mosfet jako negator. Problematyczne mogą być stany zabronione. Ale 6502 na tranzystorach jeden gostek zrobił.
Wy się nie śmiejcie :) Bo jeszcze będziemy bramki z tranzystorów robić :) Więc "woreczek" diod to ja bym jednak już zamówił :)
Bo z tej wygody to myśmy pozapominali, jak ten świat kiedyś był robiony, a warto tą wiedzę odświeżać.
Triki 74138 to widziałem, tylko że nadal nie zmniejsza to liczby "produktów" poniżej poziomu Kuby i raczej by się przydało jakby trzeba było kilka kości 512kB obsłużyć. Jak jest jedna, to zostaje logika AND i NOT. Z tym, że każdy układ logiczny można zrobić mając NAND lub NOR. Zamiana NAND na NOR jest odwracalna ale ostateczna liczba zależy od realizowanej funkcji. Idąc w jeden "produkt" rośnie nam poplątanie :)
A i każdy układ logiczny można zrobić za pomocą pamięci :) No a już kompletnie każdy logiczno-sekwencyjny da się zrobić przy pomocy pamięci i przerzutników. W końcu tak działają FPGA.
... i to też oznacza, że procesor można zrobić za pomocą pamięci i przerzutników :)
