Potrzebuję konsultacji :) Projektuje sobie takiego carta. Nie wiem po co (tzn mam pomysł ale teraz nie ważne) i może coś mi z tego wyjdzie. Cart będzie miał 512kB flash i 512kB SRAM (lutowane opcjonalnie). Flash to będzie SST39SF040, z tym że chyba dam TSOP-32 bo się nie zmieszczę z płytką w obudowach cart obecnie dostępnych. Jako RAM planuje AS7C4096A bo na razie to jest dostępne, ale ostatecznie nie przesądzone.
Organizację pamięci chcę zrobić, że: $D5xx steruje bankami Mam bity 76543210 [7] - dokładnie tak jak w przełączanym XEGS, czyli 0-cartON 1-cartOFF [5..0] - dokładnie tak jak w przełączanym XEGS czyli do tego momentu mam identycznie standard z przełączanym XEGS - 512kb. Jeżeli ktoś nie wlutuje SRAMa to nie ma żadnych nowości...
Ale GDY podlutujemy SRAM i [6] -> 1 to podkładany jest SRAM
I teraz NIE WIEM!!! Czy lepiej, żeby w trybie RAM podkładało 16kB (jak w RAMcarcie) czy jednak 8kB ($8000-$9FFF.) to ekstra RAM a górne ($A000-$BFFF) wzięło jak z XEGS czyli z flash.
Moje ATARI 65XE nie ma ECI, ma 64KB i nie będzie lutowane :). Będę próbował się z konwersją programów/gier z 130XE... A może coś własnego "in the future".
Jeżeli mi coś z tego wyjdzie to projekt będzie OPEN. Bez żadnych licencji, z możliwością robienia z tym co się chce. Przełączanie powinien ogarnąć ATF16V8B ale teraz kompiluje testowo na ATF1500A, które jak zwykle teraz nie można kupić :/
Miałbym taką prośbę, żeby "asy" co robiły coś na 130XE podpowiedziały jak z tym ramem dodatkowym jest. Czy blok 8kb to jest ok, czy jednak 16kB to jest obowiązek. Chodzi o to, że docelowo user 64kB wkłada karta z grą i nie dość że gra może mieć do 512kB to jeszcze tyle samo ma ekstra RAM.
Jak dobrze zrozumiałem ideę, to taki cart już jest. Nazywa się CORRINA i gry na nim chodzą. Nie ma obowiązku by blok miał 16kB Wszystko zależy od tego co poeta ma na namyśli, znaczy Ty. Rozumiem że po swojemu daną grę umieścisz w bankach po 8kB pod adresami $A000-$BFFF, natomiast banki 8KB jako RAM "siedzieć" będą pod $8000-$9FFF. Dwa bity rejestru potrzebujesz by to włączało się w przestrzeń ATARI, (D6, D7),pozostałe przełączać będą banki. Ale zwróć uwagę na to, że jeżeli włączysz i RAM i ROM tego modułu jednocześnie, to JEDNOCZEŚNIE przełączać się będą banki i w jednym i drugim, bo są przełączane tym samym rejestrem i tymi samymi bitami. Jeśli można podpowiedzieć to zaprojektuj adresowanie rejestru tak by przypisać mu tylko jeden adres np $D500, a nie dowolny strony $D5xx.
Z drugiej strony - po co tyle ramu. Ram służy do przetwarzania, a rom "ku pamięci". widzę raptem kilka zastosowań, m. in do prekalkulowania softsprajtów. Ale do tego 32 kb ramu spoko wystarczą przy rozsądnym zarządzaniu. Inne to np. olbrzymia plansza gry, tego się nie da przeskoczyć. Ale i tak w takich przypadkach można stosować fraktalne metody (jak np. Amaurote, które gdyby trzymać całą planszę w grze, 1600 bajtów na jeden level, to by się nie zmieściło).
(...)Jak dobrze zrozumiałem ideę, to taki cart już jest. Nazywa się CORRINA i gry na nim chodzą.(...)
Hmm. Czyli wyważam otwarte drzwi. Czemu mnie to nie dziwi :)
Rozumiem ... banki. [quote] TAK :)
[quote]Ale zwróć uwagę na to, że jeżeli włączysz i RAM i ROM tego modułu jednocześnie, to JEDNOCZEŚNIE przełączać się będą banki i w jednym i drugim, bo są przełączane tym samym rejestrem i tymi samymi bitami.
Tak, tylko gdy D6=0 to mam XEGS a wtedy na górnym adresie zawsze siedzi ostatni bank flash. Dolny wzięty będzie odpowiednio... Gdy D6=1 to "wtedy nie wiem" co zrobić z górnym adresem, czy nadal trzymać ostatni bank flash, czy jednak RAM traktować w blokach 16kB. Wtedy ROM się odłączy.
Jeśli można podpowiedzieć to zaprojektuj adresowanie rejestru tak by przypisać mu tylko jeden adres np $D500, a nie dowolny strony $D5xx.
Jak wezmę ATF1500A (którego oczywiście nie można dostać) to mogę stosować dowolne kombinacje $D500 z innymi np. $D501 itp. Ale wyszło mi, że jakby tak $D5XX to wystarczy ATF22V10CQZ, który niby jest dostępny (w cenie podobnej do poprzedniego). Generalnie co do dostępności i cen to jest jakiś dom wariatów, zupełnie nie wiadomo jak coś planować. Na płytce byłyby trzy układy do wlutowania: ROM (czyli flash) RAM (czyli SRAM) i EEPLD. Tak pobocznie: dla ATF1500A Microchip zrobił konwerter POF2JED. POFy najłatwiej robić Quartusem, pisząc co się chce w VERILOG. VERILOG to takie "notatnikowe" pisanie trochę jak w C jaka potrzebna logika i potem "samo się" dalej robi :) Jakby ktoś potrzebował "59-sekundowy" kurs to mogę pomóc...
Z drugiej strony - po co tyle ramu.
Myślałem o Strategi Turowej coś jak Colonizacje/Cywilizacje. Ale faktycznie to chyba będzie mało zastosowań.
Softowo mam na tapecie RAM-CARTa i nim można faktycznie pozamiatać większość problemów i teoretycznie już on jest lekko na wyrost. No a jeszcze AVGCART to już jakiś kosmos. Może ja idę ślepą uliczką, może AVGCART powinien mieć opcję rozszerzenia RAM nie tylko przez ECI ale przez bankowanie? A może już ma tylko nie wiem :/
to chyba nie tak. Cofasz się do lat 90-tych i tego nie ma. A skąd niby masz wiedzieć, że w 2005 albo 2015 ktoś to zrobił? Zwłaszcza jak projekt nie jest OPEN to już w ogóle ginie śmiercią naturalną, bo ani kupić, ani odtworzyć...
Nie.... masz tylko jeden rejestr więc zmieniając bank w ROM, JEDNOCZEŚNIE zmieniasz bank w RAM. Nie będzie tak że u góry będzie zawsze ten sam. Wynika to z tego że bity adresowe ROM i RAM muszą być połączone i są sterowane wyjściami rejestru JEDNOCZEŚNIE by "siekało" na banki. Rozwiązaniem jest drugi rejestr. Mając do dyspozycji wystarczającą ilość bitów pierwszy może niezależnie sterować ROM, a drugi RAM. Drugi rejestr załatwi ci też pomysły o których wspomniałeś, banki będą mogły być 8kB lub 16kB wg życzenia. Przy jednym rejestrze elektronika za bardzo się komplikuje by to osiągnąć. Pomijam tu kwestię oprogramowania bo to póżniej dopasowane musi być do elektroniki.
A powiedz mi jeszcze, czy jest jakiś CART co siedzi tylko na $D500 - $D5FF? A może RAM-CARTa dało by się łatwo przerobić na takie coś?
Tłumaczę o co chodzi. Cały czas drążę temat, żeby te ATRy zamieniać na CARTy. O ile wersja dopasowania do XEGS jakoś mi poszła (może 30% działa) to od RAM-CARTa cały czas się odbijam. W XEGS górny zakres cały czas jest ten sam, więc tam można wepchnąć procedurkę emulowania odczytu sektora. W RAM-CART podmienia się całe 16kB. Więc procedurkę musiałbym mieć w każdym banku. Trochę się wtedy miejsca marnuje. Ale od biedy też by to było. Znowu jak się procurkę da do RAM to zawsze jakaś franca się znajdzie co to nadpisze. A już DOSy to kompletnie zakładają, że pierwsze po BOOT startują. A fajnie by było, żeby w tle jakiś DOS był. Bo te wszystkie CARTy co XEXy ładują to robią to bez DOSa. Więc SAVE już się nie da zrobić.
I na koniec, masa programów chce pracować w adresie górnym i dolnym carta i cały czas trzeba robić gimnastykę z przełączaniem. Jak program poustawia tam jakieś przerwania to robi się beton nie do przejścia. :/
To z RAM-CARTa robi się idealny HD. I to nie jeden. Mało tego, pracujący na pełny gwizdek (nie trzeba czekać na VBLANK bo miga itp). Programowo można by zrobić też tak, że emuluje 1 HD i np dwie stacje, albo więcej stacji z cały czas wsadzonymi dyskami. Takie coś bardzo przypominało by NewDevice ale bez ECI. Czyli dla takich jak ja. Roboczo udało mi się np, zrobić tak, że jak jest odczyt D1 to idzie z CARTa a jak D2 to już SIO zapytuje.
Teraz "gra" która pracuje na dużych tablicach zamiast na RAM, który i tak musi przełączać, pracuje na sektorach, które są równie szybkie.
Zostaje tylko włączenie ATARI. Tu by można było zrobić tak, że po włączeniu RD5 aktywuje obszar górny z rolowanym sektorem 0 (czy czasem coś podobnego już nie jest w RAM-CART?). Czyli od $A000-$BFFF cały czas jest powtarzane 128B. 128 wystarczy na procurkę co w INIT zrobi korektę ROM i odłączy ten obszar. Dalej ATARI poleci jakby nie było żadnego carta. Ale NewDevice pociągnie dalej dane tylko przez okienko strony D5. Kompatybilność poszłaby niesamowicie w górę.
Można zrobić kartridż który operuje na adresach $D500-$D5FF. Tyle tylko że będzie miał pojemność 256 bajtów. I THE END Jak to zrobić opisałem w jednym z SERIOUSów. Jak ma być o większej pojemności to banki 256 bajtowe muszą być przełączane a to wymaga użycia rejestru który to zrobi. Zatem, gdzie go umieścić? Jaki adres mu przypisać? I policz ile musi mieć bitów do sterowania by np. pamięć 8kB podzielić na bloki po 256 bajtów. RAM-CARTA nie da się przerobić by spełnił założenie. Powód. Gdzie umieścić jego rejestr. Chyba że ktoś się uprze ale to bez sensu. Pozostaje idea wskazana przez twórców Atari. Rejestr(y) pod adresem strony $D5xx Pamięć przełączana w blokach po 8kB wspólnie lub niezależnie, lub 16kB jako jeden blok. Reszta w rękach programisty co i jak chce z tym zrobić.
Aż takie skomplikowane to chyba nie jest. Cały dekoder adresów załatwi jedna programowalna kostka. Przykład poniżej dla 4 scalaków 512kB, np flash i SRAM. R/W: $D580 - $D5FF to jest sektor 128bajtów W: $D540 i $D541 to wybór tego sektora
Szyna danych do każdej kostki równolegle. Linie adresowe A0-A6 wprost do pamięci. A7-A18 z kostki programowalnej. 4 wyjścia nCE aktywują pamięci w odpowiednim momencie. Dla SRAM atarowskie RW na wprost do nWE.
Kod logiki w VERILOG dość czytelny, łatwo można modyfikować. To co po prawej na obrazku to zrobił automat. Wiadomo, że ręczne dziobanie takiego czegoś z UCYków to masakra. 56% układu programowalnego wzięło.
Hmmmm. Idziesz okrężną ścieżką. Nie rozumiem po co sprzętowo dzielisz pamięć na fragmenty (sektory) po 128 bajtów. Jak włączysz bank 8kB pamięci w obszar $A000-BFFF to bitami adresowymi A7-A12 dzielisz go sobie na sektory 128 bajtowe. Po co robić to poprzez rejestr, to spowalnia wybór. Chyba najprostszy dekoder i rejestr to układy 74138, 74273. Cały inny podział zrobi procedura.
Bo carty z przełączaniem całych banków już są, więc faktycznie nie ma co otwierać otwartych drzwi. Jednak każde z rozwiązań ma wrodzoną wadę emulowania ATR. A taki CART działający tylko na D5 miałby dużo lepszą kompatybilność przy konwersji plików ATR. Przy zrobieniu konwertera wyszło takie jajo, że wiele programów wczytując się z dyskietki z góry zakłada, że nic nie ma w obszarach $8000-$BFFF. Przełączanie na czas odczytu działa tylko gdy obraz nie "patrzy" na ten zakres i nie ma jakiś procedur obsługi przerwań. Wiele programów miota też przełączaniem OSa i RAMem. Natomiast strony D5 nie ruszają, bo ona jest typowo hardwarowa. Nawet OS przy NewDevice zakłada, że właśnie przez D5 będzie gadał. Co prawda chce jeszcze ECI, ale to można oszukać.
Z tego co zauważyłem, to łatwiej jest zrobić konwersje z carta do XEX i ATR potem, niż w drugą stronę. W najbardziej zaawansowanym AVGCART jak już nic nie pomaga z ATRem to trzeba kabelkiem SIO się wspomóc.
Układ programowalny zawsze będzie jeden. Przy standardowych 74xxx jakakolwiek zmiana oznacza robienie od nowa płytki i projektu. Może się okazać, że musi być dekoder adresu, jakieś bramki do logiki no i rejestry zatrzaskujące. To chyba jednak lepiej, żeby był jeden układ, który robi wszystko a pozostałe miejsce w pudełku carta przeznaczyć na kości pamięci.
Generalnie komputerki bez ECI mają przekichane. Kombinuję, czy może jednak coś jeszcze można wyciągnąć z konfiguracji, czy jednak już klapa. A wydaje mi się, że taki ROM/RAM cart miałby jakąś wartość dodaną. Co prawda RAM dzielić na sektory to tak średnio. Ale ROM jak najbardziej by się przydał.
Chyba zaskoczyłem o co ci chodzi. Dwa adresy strony $D5xx przeznaczasz jako adres na rejestr sprzętowy, z kolei 128 bajtów jako bank/sektor który jest podstawiany. No, próbuj.
To jeszcze ostatnia rzecz. Twój instruktarz na temat "Projektowania cartów" znam niemal na pamięć. :)
Napisałeś: "F/2 - podstawowy sygnał zegarowy wyznaczający takt pracy procesora i pozostałych układów Atari. Zbocze opadające jest zboczem aktywnym dla operacji zapis/odczyt ustabilizowanych danych na szynie danych. W nietypowych zastosowaniach zboczem aktywnym jest zbocze narastające."
Jak zbocze OPADA to ATARI zatrzaskuje stany wcześniej ustalone? Rozumiem, że wtedy układ pośredniczący powinien na zboczu NARASTAJĄCYM przygotować wszystko, żeby przy opadającym ATARI miało wszystko stabilne?
Tak literatura podaje z której się uczyłem. Analiza różnych rozwiązań kartów to potwierdza. Niekoniecznie na zboczu narastającym. Ogólnie powinno być ustabilizowane przed opadającym zboczem.
ha, coś takiegośmy zaprojektowali do operation blood, ale tylko do ROM. O ile pamiętam $d500, $d501 wybór sektora (STA), po chwili cała strona $d5 stawała się tym sektorem. Sprzęd zaprojektował kolega z technikum telekomunikacyjnego, chyba Mietek (?). Wszystko na 74xxx. to miało mieć 128KiB na epromach. programator i kasowarka epromów pożyczona od TOMSów. Wychodziło za drogo, Mirage nie chciało.
Jeszcze mi takie coś wyszło. Patrząc na opis: ->link<-
Wychodzi na to, że jakby tak zrobić płytkę co ma: - ATF1500A (programowalny CPLD) - SST39SF040 (512kB-ROM) - opcjonalnie: albo drugi SST39SF040 (512kB-ROM) albo AS6C1008 (128kB-RAM) albo NIC - ewentualnie jakieś kondensatory przeciwzakłóceniowe
gdzie: - magistrala D[8:0] leci wprost z ATARI do: CPLD, ROM i opcjonalnego ROM/RAM - magistrala A[6:0] leci wprost z ATARI do: ROM i opcjonalnego ROM/RAM - magistrala A[12:7] przelatuje przez CPLD i może być modyfikowana przez niego dla: ROM i opcjonalnego ROM/RAM - sygnały F2, RW, nCCTL, nS4, nS5 lecą do CPLD - sygnały RD4 i RD5 z CPLD wracają do ATARI - wyjście ADDR[18] jest współdzielone z WE# opcjonalnej pamięci RAM (bo brakuje pinów na CPLDku)
To w zależności od wsadu dla CPLD można by zrobić carty w standardzie: - wszystkie do 16kB - raczej wszystkie do 64kB - XEGS do 1MB - S-XEGS do 1MB - Atarimax do 1MB - Megacart do 1MB - SIC! bez zapisu
Wsady byłby w VERILOG OpenSource więc nawet można by sobie wymyślać nowe standardy... A płytka i scalaki cały czas te same. No i w tym wszystkim przemyciłbym sektorowy ROM-RAM cart :) z tym, że RAM to max 128kB bo faktycznie po grzyba więcej (no i brakuje mi "druta" dla WE#).
Ten projekt (kształtu) płytki w wątku "Atari custom WB/XEGS PCB" to ma jakieś blokady patentowe/znaki towarowe czy inne noble? Czy można na nim bazować?
