1 Ostatnio edytowany przez qbahusak (2012-05-02 15:28:04)

No właśnie; jest jakiś opis tego ustrojstwa, rejestry, jak działa, itp - taki opis jak jest dla SIC!CART?
Wujek gogol milczy na ten temat.

No dobra, jeśli jest, to chciałbym sobie o tym poczytać.

Pomożecie?

2

maxflash 8mbit (1mbit ma po prostu mniej tych aktywnych rejestrow)

RD4<='0';
WR0<=NOT (PHI2 AND RW);
WR1<=NOT (PHI2 AND RW);

AB<=BA(5 downto 0);
ROM<=S5 OR BA(6);
CS0<=S5 OR NOT BA(6);
RD5<=NOT BA(7);

CLK<=NOT (NOT CCTL AND PHI2);
RD<=NOT (PHI2 AND RW);

Bank_Address:    process (clk,A_bus)
    begin
        if    rising_edge(clk)    then
            BA<=A_Bus(7 downto 0);
        end if;
    end process;
przechodze na tumiwisizm

3

Może nie wyglądam ale nie kapuję jeszcze tego galowego zapisu... :)

Z tego, co tu widzę, to wynika, że rejestr d5xx wygląda tak:
bity 0-5 to numer banku (64 banki po 8 kb? to razem 512 kB, a nie 1 MB)
bit 6: ROM? gdzie idzie ten sygnał?
bit 7 oznacza włączenie banku w przestrzeni a000-bfff(0) i wyłączenie (1)

Proszę o sprostowanie :)

4

pewnie dlatego, ze to malo galowy zapis ;)

tak czy owak to nie, nie ma jednego rejestru
szyna danych i jej zawartosc nie maja zadnego znaczenia
cart reaguje na kazdy dostep do rejonu d5xx przelaczajac banki
i tak d500-d57f przelaczaja banki (fizycznie to sa 2 kostki po 512kb)
dostep do d580-d5ff wylacza cart

przechodze na tumiwisizm

5 Ostatnio edytowany przez qbahusak (2012-05-04 21:41:18)

ROM<=S5 OR BA(6);
CS0<=S5 OR NOT BA(6);

Rozumiem, że powyższy ROM, to kostka 1, a CS0 to kostka 2.

Skąd inąd to fajny kartridż, można wrzucić do niego flash 512 kB i sram 512 kB lub mniejszy i hulajdusza!

No i Action powinien się uruchomić bez problemu :)

Aha, i jeszcze jest problem z wykryciem zmian kartridża - trzeba to w OS wyłączyć, aby można było sobie bankować na wesoło, bo inaczej reset po zmianie banku :/

edit: to powyżej dotyczy tylko i wyłącznie procedury resetu, nie przerwania vblk - więc problemu nie ma :)

6 Ostatnio edytowany przez Krótki (2012-05-04 07:56:23)

... albo zapewnić, żeby w każdym banku zawartość $BFF0..$BFFF była taka sama (suma kontrolna kartridża jest (błędnie) wyliczana na podstawie $BFF0-$C0EF).

Jak sobe teraz myślę, że kartridże OSS i XEGS w zakresie $B000..$BFFF miały zawsze tan sam bank, to podejrzewam, że zaprojektowali je w ten sposób również z tego powodu.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

7

kuba: ten kod ktory wkleilem wlasnie taki jest, tj rom to flash, ale cs0 to wlasnie czip selekt kostki sram (watek "w odpowiedzi na corine")
bankowac sobie mozna na wesolo bez zmian w os, os jedyne co sprawdza, to stan lini rd5 (trig3) podczas vblanka, a konkretnie czy wartosc trig3 i trig3s jest taka sama, wiec bankowanie tu nic nie psuje
jedynie przy wylaczeniu cartridga trzeba to robic z sensem (patrz np atariki)

nie wiem kiedy jest liczona suma o ktorej piszecie wprost lub w domniemaniu, ale nie jest ona sprawdzana podczas normalnej pracy systemu
bank w oss (4kb) czy xegs super cart (8k) byl sobie jaki byl raczej z innego powodu

przechodze na tumiwisizm

8 Ostatnio edytowany przez qbahusak (2012-05-04 21:42:37)

Suma o której piszemy jest liczona podczas procedury RESET i jeśli jest gorący start i stwierdzi, że suma kontrolna się różni, to robi się z niego zimny start.

A z bankowanymi kartami oss to często się wciskało reset i zimny start był nie na miejscu - więc bank b000-bfff jest zawsze ten sam, a zmieniają się A000-Afff.

A z tym TRIG3 = RD5 to wystarczy CRITIC ustawić i już nie będzie sprawdzał.

9 Ostatnio edytowany przez qbahusak (2012-05-10 08:28:38)

Czyli suma sumarum, po co są aż 2 gale na maxflashu? (odp: dla wygody i zabezpieczenia)

Żeby zrobić ten cart od podstaw na dyskretnych elementach, wystarczy zatrzask 8bit i kilka bramek na odczyt/zapis?

Wg mnie chyba najwygodniej byłoby zrobić 1 zatrzask linii adresowych i gal 16v8 na logikę.