atarionline.pl MaxPlus - Forum Atarum

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.

    • 1:
       
      CommentAuthorgienekp
    • CommentTime4 Sep 2022 zmieniony
     
    MaxFlash 128/+/512

    Zachciało mi się potestować DOSy. No ale że ten, o którym tak wszyscy piszą czyli SpartaDOS wymaga carta no to nie pozostało nic innego jak zrobić sobie takie cudo. Ponieważ, sam projekt rozpocząłem jakieś 4 miesiąc temu i nic nie wskazywało na to, że braknie GALi więc idąc na łatwiznę, stwierdziłem, że na płytce musi być minimum elementów. Pamięć musi być, a że cart będzie ReadOnly to i tak programator będzie potrzebny, więc wezmę największego GALa czyli ATF22V10C, przewlekane, jakiś kondensator przeciwzakłóceniowy i gotowe.

    Teoria teorią, wyszły mi 4 projekty (potem opiszę pozostałe). W każdym razie skoro jest jeden większy GAL to i nóżek programowalnych więcej. Więc można by coś więcej dodać.
    I tak powstał projekt MaxFlash128kBplus. Dlaczego PLUS to zaraz...

    Wszystko co potrzeba do zrozumienia co jest w GALach jest na GiHubie:
    ->link<-

    Projekt płytki jest banalny. Lecą same druty od ATARI do pamięci i GALa. Jeden kondensator, ale bez niego na moim starym zasilaczu działa. W zasadzie niema co tam śmiecić.
    Pamięci obsługiwane to: SST39SF010A, SST39SF020A, SST39SF040 (te miałem i te testowałem).

    Płytka została zrobiona na bazie szablonu kolegi Mariusza "Mq" za co należy mu bardzo podziękować! PCB pasuje do obudów Sikora.
    Projekt płytki udostępniłem eksperymentalnie na PCBWay. ->link<-
    Nie wiem jak to wyjdzie w praktyce to szarowanie z PCBWaya ale jest okazja przetestować. :)

    SpartaDOS dla MaxFlasha128kB zajmuje 128kB :) Pomyślałem, skoro mam niewykorzystane linie w GALu to pociągnę resztę Adresów i zrobię taki trik. Dla pamięci 256kB do pierwszej 128-ki wstawię SpartaDOS oficjalnego a do drugiej 128kB wstawię sobie Betę. SpartaDOS nic nie będzie wiedział, że jest jakieś inne 128kB a przełączanie tych... no nazwałem to stronami (a to dlatego, że poboczny pomysł z atr2car sugerował, że można by udawać obracanie dyskietki...inna bajka). SprataDOS pstryka $D500+x i wyłącza $D510. Jak mu klepnę POKE $D521,1 ($D52X - nr stron) to podmieni mu się całe 128kB. Robię reset i wstaje SpartaDOS beta który nic nie wie, że była jakaś inna rzeczywistość. Więc pstrykając $D500+x nadal wszystko działa.

    No a, że w praktyce pociągnięte są A7,A6,A5,A4 no to i MaxFlash(new) z pamięcią 512kB też zadziała. I tak w zasadzie jedną płytką można obskoczyć 3 standardy. W zależności co wgramy do GALa taki mamy standard.

    Wsady do GALi niewiele się różnią.

    MaxFlash128kB - Tutaj A0-A3 bankuje A5-A7 pilnuje zakresu $D5xx
    /* ****************** LOGIC *********************** */
    nPHI2 = ( !PHI2 );

    nRW = ( !RW );
    CCTL = ( !nCCTL );
    nA4 = ( !A4 );
    A = ( !A5 ) & ( !A6 ) & ( !A7 );

    nCE = ( nS5 # nRW );
    trig = ( A & CCTL);
    ntrig = !trig;

    RD5.D = !( ( trig & A4 ) # ( ( !trig ) & ( !RD5 ) ) );
    RD5.ar = 'b'0;
    RD5.sp = 'b'0;
    RD5.OE = 'b'1;

    A13.D = ( ( trig & A0 ) # ( ( !trig ) & A13 ) );
    A14.D = ( ( trig & A1 ) # ( ( !trig ) & A14 ) );
    A15.D = ( ( trig & A2 ) # ( ( !trig ) & A15 ) );
    A16.D = ( ( trig & A3 ) # ( ( !trig ) & A16 ) );
    A17.D = 'b'0;
    A18.D = 'b'0;


    MaxFlash 128kBplus - jak powyżej ale jest wybór strony, żeby zachować zgodność w dół. Za to można np. 4 SpartaDOSy wgrać.
    * ****************** LOGIC *********************** */
    nPHI2 = ( !PHI2 );

    nRW = ( !RW );
    CCTL = ( !nCCTL );
    nA4 = ( !A4 );
    A = ( !A5 ) & ( !A6 ) & ( !A7 );
    B = ( A5 ) & ( !A6 ) & ( !A7 );

    nCE = ( nS5 # nRW );
    trig = ( A & CCTL); /* & nRW );*/
    ntrig = !trig;
    mode = ( B & CCTL); /* & nRW );*/

    nmode = !mode;

    RD5.D = !( ( trig & A4 ) # ( ( !trig ) & ( !RD5 ) ) );
    RD5.ar = 'b'0;
    RD5.sp = 'b'0;
    RD5.OE = 'b'1;

    A13.D = ( ( trig & A0 ) # ( ( !trig ) & A13 ) );
    A14.D = ( ( trig & A1 ) # ( ( !trig ) & A14 ) );
    A15.D = ( ( trig & A2 ) # ( ( !trig ) & A15 ) );
    A16.D = ( ( trig & A3 ) # ( ( !trig ) & A16 ) );
    A17.D = ( ( mode & A0 ) # ( ( !mode ) & A17 ) );
    A18.D = ( ( mode & A1 ) # ( ( !mode ) & A18 ) );


    MaxFlash1MB(new) a w zasadzie JACART512kB ReadOnly - tu latamy po całym zakresie ALE bez A6.
    /* ****************** LOGIC *********************** */
    nPHI2 = ( !PHI2 );

    nRW = ( !RW );
    CCTL = ( !nCCTL );
    nA7 = ( !A7 );
    A = ( !A6 ) & ( !A7 );

    nCE = ( nS5 # nRW );
    trig = ( A & CCTL);
    ntrig = !trig;

    RD5.D = !( ( trig & A7 ) # ( ( !trig ) & ( !RD5 ) ) );
    RD5.ar = 'b'0;
    RD5.sp = 'b'0;
    RD5.OE = 'b'1;

    A13.D = ( ( trig & A0 ) # ( ( !trig ) & A13 ) );
    A14.D = ( ( trig & A1 ) # ( ( !trig ) & A14 ) );
    A15.D = ( ( trig & A2 ) # ( ( !trig ) & A15 ) );
    A16.D = ( ( trig & A3 ) # ( ( !trig ) & A16 ) );
    A17.D = ( ( trig & A4 ) # ( ( !trig ) & A17 ) );
    A18.D = ( ( trig & A5 ) # ( ( !trig ) & A18 ) );


    Uwagi:
    - atr2max i atr2jac z pobocznego wątku jest z tym zgodny
    - o wersję z zapisem to pytać jhusak i mq, oni mają swoje rozwiązania sprawdzone
    - GALi przewlekanych nie ma, ale są TSSOPY i można się ratować ->link<-
    - z tym projektem można robić co się chce. Kopiować, zmieniać, handlować...
    - jak dokończę pozostałe projekty to chętnym mogę wysłać płytki PCB. Zamawiałem to przy okazji innych projektów, a chińczyk zawsze coś tam więcej doprodukuje. Bez transportu, bez VATu itd
    • 2:
       
      CommentAuthorMq
    • CommentTime4 Sep 2022
     
    Bardzo fajny projekt. Gratuluję ukończenia:-)
    • 3:
       
      CommentAuthorpancio
    • CommentTime4 Sep 2022 zmieniony
     
    Super to wygląda.. jeszcze muszę się zagłębić w sczegóły ale juz mi się baaaardzo podoba :-) No i reflektowałbym ja jakies jedno PCB do testów
    • 4:
       
      CommentAuthorgienekp
    • CommentTime4 Sep 2022 zmieniony
     
    Tak będą PCB dla testerów, nie ma problemu.

    Wracając do tematu, to tak edukacyjnie, wyjaśnienia może wymagać jeden trik. Z moich obserwacji zwykle carty atari wymagają sterowania, gdzie COŚ jest zatrzaskiwane pod jakimś warunkiem i to zatrzaśnięte jeszcze jest korygowane (jakieś NOTy czy coś podobnego). Czyli jest zatrzask wyzwalany logiką i wyjście też pasowałoby potraktować logiką.

    Tymczasem GALe są budowane na jedno kopyto, gdzie jest logika i zatrzask na wyjściu.

    Ponieważ jedynie co można zrobić to zabrać sygnał z pinu wyjściowego i wpuścić do logiki, to robiąc trik z zatrzaskiwaniem na KAŻDYM zboczu PHI2 sygnału albo starego (starej wartości) albo nowego (nowej wartości) można jakby wybrnąć z tej sytuacji. Wtedy logika jest przed zatrzaskiem, ale działa jakby była wokół niego.
    • 5:
       
      CommentAuthorgienekp
    • CommentTime10 Sep 2022 zmieniony
     
    No a teraz projekt, który był troszkę wcześniej.
    Nakręcony kartami S-XEGS nie zauważyłem, że MaxFlashe lecą na adresach a nie na danych :)
    Kompletnie mi nie przyszło do głowy, że można coś samymi adresami robić. A że dane troszkę trudniej się robi, więc poprzeczka była wyżej.
    Tak czy siak prezentuję projekt jaki z tego wyszedł bo może kiedyś komuś taka wiedza się przyda, choćby edukacyjnie. Takiego standardu nie było, a że otwieram go totalnie i można z nim robić co się chce, nawet handlować, no to jakby ktoś chciał jakąś gierkę wydać i miał opory czy czasem jakieś licencje go nie blokują, to może wziąć ten projekt i będzie super.

    Kody są tu:
    ->link<-

    Płytka zgodna z obudowami Sikora i na szablonie Mq jest tu:
    ->link<-

    I dla porównania jak się GALem "robi" dane:
    nPHI2  = ( !PHI2 );

    nRW = ( !RW );
    CCTL = ( !nCCTL );
    nA4 = ( !A4 );
    A = ( !A5 ) & ( !A6 ) & ( !A7 );
    B = ( A5 ) & ( !A6 ) & ( !A7 );

    nCE = ( nS5 # nRW );
    trig = ( A & CCTL & nRW );
    ntrig = !trig;
    mode = ( B & CCTL & nRW );
    nmode = !mode;

    RD5.D = !( ( trig & A4 ) # ( ( !trig ) & ( !RD5 ) ) );
    RD5.ar = 'b'0;
    RD5.sp = 'b'0;
    RD5.OE = 'b'1;

    A13.D = ( ( trig & D0 ) # ( ( !trig ) & A13 ) );
    A14.D = ( ( trig & D1 ) # ( ( !trig ) & A14 ) );
    A15.D = ( ( trig & D2 ) # ( ( !trig ) & A15 ) );
    A16.D = ( ( trig & D3 ) # ( ( !trig ) & A16 ) );
    A17.D = ( ( mode & D0 ) # ( ( !mode ) & A17 ) );
    A18.D = ( ( mode & D1 ) # ( ( !mode ) & A18 ) );


    Czyli zamiast Ax jest Dx. Z tym, że przy danych już musi być na opadającym PHI2 więc ten trik z wpuszczeniem zegara do GALa i wypuszczeniem w negacji dla pinu dedykowanego do zatrzaskiwania musi być. Przy poprzednim rozwiązaniu jest to niekonieczne (adres można łapać i na narastającym zboczu).

    atr2max jest z tym zgodny. A to dlatego, że jak robimy
    LDX #$03 ; np. 3-ci bank
    STA $D500,X

    to ustawiamy i adres i dane.

    Więc robiąc jakiś program można go zrobić "podwójnie" zgodnym. I z maxflashem1Mbit i z tą płytką, która jest troszkę inaczej. I w ogóle można sobie powymyślać coś w tym GALu jeszcze i zrobić jak się komu podoba.
    c.d.n

    P.S. jak się ogarnę to i te płytki powysyłam gratisowo chętnym do testów.
    • 6:
       
      CommentAuthorpirx
    • CommentTime12 Sep 2022
     
    krótkie pytanko, bo na cartach się za bardzo nie znam - czy jest możliwość / istnieje kart, który by miał 32KiB ciągłej pamięci - od $4000 do $bfff, bez żadnego bankowania, po prostu 32 kilo.
    Jakby był, to by się na niego dało naszego skorcza zrobić.
    • 7:
       
      CommentAuthorpirx
    • CommentTime12 Sep 2022
     
    no dobra, pewnie się nie da, najwyżej od $8000 do $bfff, ale może jest jakaś magia(?)
    • 8:
       
      CommentAuthorPecus
    • CommentTime12 Sep 2022
     
    To ja Ci odpowiem :)
    Nie da się :)
    • 9:
       
      CommentAuthorgienekp
    • CommentTime12 Sep 2022
     
    ATARI chciało mieć tylko 2 przełączane banki. Pierwszy $8000-$9FFF i drugi $A000-$BFFF. Ale jakby trzeba ciągłości to możnaby jednym bankiem to zrobić. Przy INIT kopiować po 8k bajtów z banków najpierw do $4000-$5FFF potem przełączyć bank i skopiować do $6000-$7FFF potem do $8000... I na koniec zostawić $A000 i wyjść z init. RUN carta i system zacznie jakby od $4000 do $BFFF były dane.
    • 10: CommentAuthortebe
    • CommentTime12 Sep 2022 zmieniony
     
    tia, to może od razu 16MB, taki podręczny carcik do Rapiduska ;)
    • 11:
       
      CommentAuthorjhusak
    • CommentTime12 Sep 2022
     
    @pirx - takie gry się po prostu kopiuje z kartridża i uruchamia :) Trwa to moment niezauważalny.
    • 12:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2022 zmieniony
     
    W międzyczasie dopłynęły płytki z cartem w wersji S-XEGS 512kB. Wszystko działa więc publikuję.
    Projekt jest na bazie ->link<-
    Zamiast GALa i zatrzasku, jest jeden większy GAL. Reszta wszystko tak samo. Wiadomo jak to jest teraz z dostępnością części, więc zawsze to jakaś alternatywa.

    A i nie ma żadnych problemów z hazardami, bo do zapamiętania banku użyte są wprost przerzutniki w GALu.

    Płytki są tu: ->link<-

    A program GALa tu: ->link<-

    Tak edukacyjnie jak robiłem zatrzaskiwanie z trzecim stanem na GALu:
    nPHI2  = !PHI2;
    nRW = ( !RW );
    nCE = ( ( nS4 & nS5 ) # nRW );
    trig = ( ( !nCCTL ) & nRW );
    RD45.D = !( ( trig & D7 ) # ( ( !trig ) & ( !RD45 ) ) );
    RD45.ar = 'b'0;
    RD45.sp = 'b'0;
    RD45.OE = 'b'1;
    A13.D = ( ( trig & D0 ) # ( ( !trig ) & A13 ) );
    A14.D = ( ( trig & D1 ) # ( ( !trig ) & A14 ) );
    A15.D = ( ( trig & D2 ) # ( ( !trig ) & A15 ) );
    A16.D = ( ( trig & D3 ) # ( ( !trig ) & A16 ) );
    A17.D = ( ( trig & D4 ) # ( ( !trig ) & A17 ) );
    A18.D = ( ( trig & D5 ) # ( ( !trig ) & A18 ) );
    A13.OE = !nS4;
    A14.OE = !nS4;
    A15.OE = !nS4;
    A16.OE = !nS4;
    A17.OE = !nS4;
    A18.OE = !nS4;
    Footer


    Kształt płytki zaczerpnąłem z projektu od @x_angel. Z mojej strony nie ma żadnych ograniczeń, można z tym robić co się chce komercyjnie i niekomercyjnie. Natomiast jeżeli @x_angel dał jakieś limity licencyjnie to takie będą.
    • 13:
       
      CommentAuthorgienekp
    • CommentTime27 Apr 2023 zmieniony
     
    Dorzucam do puli projekt kolejnego typu carta. MaxFlash 8Mbit pełny 1Mbajt na dwóch kostkach SST39SF040 PLC.
    Projekt płytki jest tu: ->link<-
    A wsady do GALa są tu: ->link<-
    W zależności od wsadu może być OLD (42;0x2A) lub NEW (75;0x4B).
    Wszystko "open". Można sobie robić z tym co się chce.
    • 14:
       
      CommentAuthorMq
    • CommentTime27 Apr 2023
     
    Dobra robota.
    Jedną mam tylko uwagę dla tych, którzy będą chcieli sobie zrobić MaxFlasha na podstawie tego projektu.

    GienekP, Ty cały czas uparcie używasz we wszystkich tych kartridżach kości 39SF040 jednocześnie nazywając kartridż MaxFlash, tymczasem nie jest on zgodny z MaxFlash kiedy użyjemy takich kości.
    Kartridż MaxFlash musi mieć kości zgodne z AM29F040.

    Oczywiście to tylko kwestia wsadzenie odpowiednich kości, a kartridż pozostaje taki sam, ale różnica jest bardzo zasadnicza. Kości te różnią się wielkością sektora. Jeżeli zaprogramujemy sobie np. składanki gier, albo gry nie tworzące zapisów na kartridżu, to wszystko nam zadziała identycznie na obu kościach - mam na myśli sytuację gdy programujemy tylko raz kartridż od razu pełnym wsadem.
    Problem pojawi się w momencie kiedy zaczną z kartridża korzystać gry przystosowane do zapisu stanu gry, hiscore itp. na kartridżu. Gry takie mają procedury kasowania pojedynczego sektora(sektorów) i nie zrobią tego właściwie na niewłaściwej kości.
    • 15:
       
      CommentAuthorgienekp
    • CommentTime28 Apr 2023 zmieniony
     
    @Mq

    Racja!

    Zapomiałem dodać. Wszystkie te carty są READ ONLY! Nie mają zapisu, dlatego typ pamięci nie ma wtedy znaczenia.

    Natomiast trzymam się zasad z tabeli z emulatora, który w sumie też nie zapisuje ->link<-

    Tylko jak nazwać cart który może być 42 lub 75 z emulatora? A sumaryczna docelowa funkcjonalność to, że jest plik CAR i chciałbym sobie zrobić to samo ale w realu.

    Generalnie wydaje mi się, że jeżeli carty mają zapis to nie powinny być robione na GALach bo jeżeli są GALe to ktoś raczej posiada programator. Tutaj wszystkie są na GALach (których kolejny termin sprzedaży się znowu przesunął), przez co układ robi się bardzo prosty do budowy i polutowania.

    Karty nie na GALach i z zapisem to już otwieranie otwartych drzwi. Technologia jest i u Ciebie i u Kuby :)

    Natomiast gdyby udało mi się zrobić ATR2CAR z zapisem to będzie to dla kostek 39SF040 ponieważ mniejszy sektor jest łatwiejszy do zaimplementowania. Ale ten deser to jeszcze nie teraz ;)
    • 16:
       
      CommentAuthorPeri Noid
    • CommentTime28 Apr 2023
     
    Nie jestem pewien, czy dobrze rozumiem, ale chodzi o zapis nie w celu programowania, a w celu zapisania np. stanu gry, tablicy wyników czy innych tego typu danych. Tego się nie robi programatorem.
    • 17:
       
      CommentAuthorgienekp
    • CommentTime28 Apr 2023 zmieniony
     
    @Peri Noid
    Dokładnie tak.

    Czyli np.:
    - Space Harrier (typ OLD) - w sumie to jedyny jaki znam 1MBajtowy co zapisuje, to nie zapisze stanu
    - OnEscape (typ NEW - i chyba to jest jedyna oficjalna gra w typie NEW co potrzebuje 1Mbajt) - będzie działać normalnie bo nic nie zapisuje

    Jeszcze jest taki trik co robi @jhusak, że produkuje takiego sprytnego XEX/ATR co potrafi pustego carta z ATARI zaprogramować. Czyli bez programatora i NIE stan gry ale cały cart. No to też nie zadziała.

    Żeby był zapis na GALU to zabrakło JEDNEGO pinu :)
    A następny GAL w kolejce już niepraktyczny i lepiej to robić "niegalowo" :)
    • 18:
       
      CommentAuthorKaz
    • CommentTime28 Apr 2023
     
    Kolony 2106 potrzebuje minimum carta 256 KB i używa zapisu stanów gry.
    • 19:
       
      CommentAuthorMq
    • CommentTime28 Apr 2023 zmieniony
     
    Kuba zrobił swój soft do programowania kości z poziomu Atari, ale jest rozbudowany kombajn też Maxflash Cartridge Studio, który generuje atr z programikiem do programowania kości pamięci i z wsadem do owego zaprogramowania.

    Wspomniany Space Harrier działa zarówno na wersji old jak i new maxflasha. Nie ma sensu robić wersji old kartridża, bo każda gra jaka powstała działa na obu wersjach new/old. Kartridż old istnieje niejako przez pomyłkę, bo jak dystrybuowano maxflasha, to powstała jakaś partia, która błędnie startowała z banku 127 i trzeba to było uwzględniać później, bo sporo ludzi ma do dziś taką wersję. By design ten kartridż powinien wstawać z banku zerowego i nowe kartridże proponuję robić tylko w taki sposób.

    Gier na pełen megabajt jest więcej. Jest Atari Blast!, który nic nie zapisuje, jest też Jim Slide, który zapisuje pokonane levele w tabelce. Są też liczne składanki, ale to też read only.

    Zapisu dokonują też gry FloB (szereg statystyk i osiągnięć, postęp gry, wyniki) i Tensor Trzaskowskiego (pokonane etapy, wyniki na etapach, ustawienia opcji gry, np. język, szybkość opadania przedmiotów). Obie te gry działają na 8Mbit/4Mbit - one po prostu mieszczą się w 4Mbit, więc drugiej kości pamięci nie wykorzystują.

    I jeszcze temat GAL-a. Ja zrobiłem szereg testów swoich różnych prototypów na zwykłych układach TTL i chociaż mi wszystko działa, to jednak na niektórych komputerach zdarza się czasami błąd przy zapisie, który jest bardziej wymagający jeśli chodzi o dokładność timingów niż odczyt. W ostatnich dniach zacząłem budować nowy prototyp z małym GAL-em, który robi tylko sygnały sterowania kościami CE, OE i WE. Okazuje się, że jeśli te sygnały wygenerujemy sobie GAL-em, to unikamy wszelkich problemów z timingami, bo mamy je idealnie równiutko i wszystko śmiga na każdym komputerze bez problemu. Wydaje mi się, że choćby z tego powodu warto stosować GAL-a w miejscach gdzie precyzja timingów jest krytyczna. Oczywiście jatari cart Kuby Husaka działa poprawnie, bo mam takowy kartridż również do testów, ale jego zaprojektowanie było obarczone większą ilością pracy na etapie prototypowania i poprawiania tych nieszczęsnych timingów. Zrobienie tego samego na GAL-u pozwala na dużo szybsze prace projektowe, bo po prostu odpalamy i od razu działa dobrze.
    • 20:
       
      CommentAuthorgienekp
    • CommentTime28 Apr 2023 zmieniony
     
    @Mq

    A widzisz, bardzo cenne informacje przekazujesz.

    Się zastanawiałem po kiego grzyba wersja carta startująca z ostatniego banku. Zwłaszcza jak może być 512kB/256kB i wtedy bądź tu mądry który jest ostatni. Tzn. jak mam grę 256kB a kostkę pamięci 512kB to muszę dwa identyczne biny skleić, żeby to wstało.

    Tu racja, że GALe dość dobrze trzymają zbocza, bo one w środku są dużo szybsze niż oficjalny czas z pinu IN na pin OUT. Więc nic się nie opóźnia i nie robi hazardów. Przykład, jeden pin jest po jednej bramce, a drugi po trzech. Odpowiedź jest niemal w tym samym czasie. Tę cechę mają też CPLD i FPGA bo drivery co wypuszczają sygnał na pin są dużo wolniejsze od rdzenia w środku.

    Na pewno wszystkie OLD wstaną na NEW?

    Bo podmieniałem nagłówek w pliku CAR dla emulatora, żeby to sprawdzić i nie działało. Tylko teraz nie wiem, w którym to było. Dlatego też zrobiłem DWA wsady do GALa i taki i taki. Inaczej po co się kłopocić.

    To teraz pytanie za 100 punktów. Na GALu brakło mi jednego pina. Ale nie brakłoby jakby była jedna kość 8Mbit czyli np. AS29CF800.
    Czy te algorytmy zapisu łykną AS29CF800 zamiast dwóch AM29F040?

    SST39SF040 wybrałem tylko dlatego, żeby "zróżnicować" możliwości na wypadek braku części na rynku, co mnie ostatnio dość często dotyka i nie tylko hobbistycznie ale i biznesowo.

    Ale nic nie stoi na przeszkodzie, żeby narysować carta co ma tylko dwie kostki AS29CF800 i ATF22V10C. Jeżeli procedurki zapisu potrafią tego zgreda ruszyć, to taki cart obskoczyłby od tego dziwka co ma 128kB do tego wypasionego 1MB i wszystkie po drodze w wersji NEW i OLD. Byłaby to tylko kwestia wsadu do GALa bo ten 128kB to ciut inny jest.
    • 21:
       
      CommentAuthorMq
    • CommentTime28 Apr 2023
     
    Oficjalnie były (i nadal są, bo są w sprzedaży z tego co wiem) dwie wersje Atarimax Maxflash. Jedna była 1Mbit(czyli 128kB) i druga była 8Mbit(czyli 1MB). Oba mają taką samą koncepcję bankowania, ale oba różnią się tym, który adres odłącza kartridż.

    Tylko w obrębie linii 8Mbit mamy do czynienia z wersją old i new, bo tak jak pisałem, pierwsze partie miały jakieś tam niedopracowanie i omyłkowo (gdzieś czytałem, że autorzy to pzyznali kiedyś) startowały z banku 127 zamiast 0. Ponieważ łatwiej było przyznać się do tego i poprosić koderów u uwzględnianie obu wersji niż wymieniać wszystkie kartridże sprzedane, więc do dziś mamy to uwzględniane i w emulatorze też są obie wersje. W dobrym tonie jest uwzględniać to w nowym sofcie, jeśli ktoś pisze soft pod maxflasha i chce go dać społeczności, która posiada taki kartridż. Natomiast jeśli ktoś tego nie robi, no to już nic nie poradzisz. Niektórzy robili/robią tak soft, że oba banki potrafią zastartować, wtedy soft zadziała na każdym kartridżu. Niektórzy pisali dwie wersje softu (dwa wsady new/old). A niektórzy w ogóle o tym nie wiedzą i mają to gdzieś, robią co im się podoba, a potem na forach przynajmniej jest nowy temat pod gównoburzę, że coś komuś nie działa i to na pewno celowa dyskryminacja:-)

    Ja uważam, że nowe kartridże należy robić tylko i wyłącznie startujące z banku 0. Oryginalny Atarimax Maxflash też już tylko tak jest robiony obecnie.

    Jeśli chodzi o kartridż 1Mbit, to miał on sens kilkanaście lat temu, kiedy była różnica w cenach mniejszej i większej pamięci. Dziś ten kartridż można spokojnie odstawić jako przedawniony i robić tylko 8Mbit.

    Jeżeli natomiast mówimy jeszcze o ostatniej wersji pojemności - czyli 4Mbit, to taki kartridż nigdy w ogóle nie istniał jako odrębny produkt. Jest to po prostu 8Mbit, w którym nie ma drugiej kości pamięci, bo np. pod daną produkcję wystarczy połowa pojemności. Tak są zrobione kartridże do FloB-a i do Tensora.

    Pojedyncze kości 8Mbit nie są dobrym kierunkiem, bo ich dostępność jest znacznie mniejsza niż kości 040 i jest mały ich wybór, a cena też zwykle większa. Czy algorytmy zadziałają, to nie wiadomo, a nawet jeśli tak, to każdy to inaczej oprogramowuje, więc nie wiemy czy wszystko na tym pójdzie. Myślałem kiedyś o tym, ale stwierdziłem, że nie ma sensu tak kombinować. Oczywiście jak chcesz sztukę dla sztuki zrobić, żeby było mniej kości, to jak najbardziej można. Natomiast dla mnie liczy się łatwa dostępność układów, zamienników itd., dlatego dwie kości 040, mały gal16v8 i osobno TTL z zatrzaskami to jest najbardziej pewne rozwiązanie i tak to teraz projektuję do kolejnej wersji moich kartridży.
    • 22:
       
      CommentAuthorjhusak
    • CommentTime28 Apr 2023 zmieniony
     

    Mq:

    Oba mają taką samą koncepcję bankowania, ale oba różnią się tym, który adres odłącza kartridż.

    Nie jest to prawda do końca. Z tego co testowałem w wersji 1MB każdy adres powyżej d50f odłącza kartridż, a nie jak jest w Atari800 zakodowane. Testowałem to wiem. Czyli śmiało można pisać do D580 żeby wyłączyć oba kartridże.
    Opisałem to na atariki pod "AtariMax".

    Mq:

    Oczywiście jatari cart Kuby Husaka działa poprawnie, bo mam takowy kartridż również do testów, ale jego zaprojektowanie było obarczone większą ilością pracy na etapie prototypowania i poprawiania tych nieszczęsnych timingów.


    Nieprawda, że większą ilością pracy. Cały kartridż powstał na podstawie samouczka Zenona i jak powstał tak został zrobiony i tak zadziałał z palca. Ale trochę zmóżdżenia mnie to kosztowało, zwłaszcza przy 1 MB, w którym można jeden scalak wyjąć, jeśli chce się mieć read only. Nie miałem natomiast przypadku "ta płytka nie zadziałała" i trzeba było poprawiać. Także prototypowanie to kilka płytek cynowanych, działających :) Może po prostu nie wiedziałem, że trzeba uważać na timingi :) Żart. Pilnowałem teoretycznie czasów propagacji na bramkach, a w praktyce zadziałało.

    Co do startu z ostatniego banku to sobie ułatwili ewentualne mapowanie dyskietek czy obrazów dysków. Kiedyś XXL mnie pytał, dlaczego ja tak nie zrobiłem, bo tak on musi wpisać do kodu (krótkiego) kilka nadmiarowych bajtów przeliczających numery sektorów.


    gienekp:

    Na pewno wszystkie OLD wstaną na NEW?


    To zależy od tego, jak ustawione są wektory. Trzeba poświęcić kilka bajtów na przestawienie banku i skok do tego na przeciwległym końcu. Jeśli gra tak ma, to wstanie z obu, jeśli nie, to tylko z tego, co na niego jest napisana.
    • 23: CommentAuthormono
    • CommentTime28 Apr 2023
     
    @jhusak: Zerknij łaskawie do Atariki do dyskusji na swoim haśle.
    • 24:
       
      CommentAuthorgienekp
    • CommentTime28 Apr 2023 zmieniony
     
    No ciekawe rzeczy piszecie...

    Z tymi cenami to są jaja. Parę dni temu, dwóch chińczyków oferuje układ. Jeden za 7 dolców a drugi za 50. Sprawdziliśmy z kumplem co to za firmy (bo niby różne), to są w tym samym mieście na tej samej ulicy, ale różne numery. Albo jeden ściemnia, albo ceny są z sufitu jak u arabskiego kupca, albo nie wiem... jakiś dom wariatów.

    No tak patrząc na Mousera to (bez VATU):
    - AS29CF040-55CCIN - 32,26zł (dziwnie drogo, wydawało mi się, że było taniej)
    - konkurencyjny SST39SF040-70-4I-NHE (na tym zrobiłem) - 13,05zł
    - 8Mbitowy AS29CF800B-55TIN (w obudowie TSOP-48 ale jak jest zapis to podstawek nie trzeba) - 40,96zł
    - Mały GAL ATF16V8B-15PU - 5,72zł
    - Dyży GAL ATF22V10C-15PU (który ja używam i który miał być 10 dni temu ale nie ma) - 10,69zł
    - zatrzask dla małego GALa SN74AHCT273N (chociaż ja bym to robił drugim małym galem) - 3,60zł

    No to tak pi razy drzwi cart bez zapisu (ten co pokazałem) to Duży GAL i dwa SST39 czyli 36,79zł

    Cart z zapisem to albo: duży GAL i 8Mbitowa czyli 51,65zł,
    albo 2xAS29CF040 + mały GAL z zatrzaskiem czyli 73,84zł

    Hmm, to ten zapis podnosi koszt od 50-100% na kostkach w zależności od technologii.
    "Panie to są drogie rzeczy!" :)

    Tensor ma 512kB? Bo pod HexEdytorem wygląda jakby 128kB starczyło.
    • 25:
       
      CommentAuthorMq
    • CommentTime28 Apr 2023
     
    Kuba sprostowałeś to co pisałem, przyjmuję do wiadomości. Może coś źle zapamiętałem, ale wydawało mi się, że coś kiedyś pisałeś, że musiałeś kombinować z tymi sygnałami przy zapisie. No ale tak jak mówię, mogłem coś pomylić skoro tak piszesz.

    W takim razie biorę to wyłącznie na siebie: moje walki z timingami na TTL-ach trwały tak długo, że żałuję tego straconego czasu i wolę to robić na GAL-ach jednak.

    gienekp, tak, Tensor ma 512. Nie dlatego że potrzebuje, tylko dlatego że to ten sam kartridż co do FloB-a. Dodatkowo wykorzystuje któryś tam wyższy sektor do sejwowania.
    • 26:
       
      CommentAuthorgienekp
    • CommentTime28 Apr 2023 zmieniony
     
    @Mq

    Tensor w XEX ma 34784B. To 512kB to trochę z rozmachem :)
    • 27:
       
      CommentAuthorMq
    • CommentTime28 Apr 2023
     
    Stać mnie:-)
    • 28:
       
      CommentAuthorgienekp
    • CommentTime18 May 2023
     
    Taka ciekawostka, jeśli chodzi o GALe.
    Dla cartów zatrzaskiwanych na adresach (czyli MaxFlashe itp) wystarcza ten najwolniejszy ATF22LV10CQZ-30PU (działa na 3.3V i 5V)
    ->link<-

    Ale jak trzeba na danych (np. S-XEGS) to już ten najwolniejszy "gubi banki". Dla tej grupy ja stosuje ten najszybszy ATF22V10C-7PX
    ->link<-

    Gdzie jest granica po środku to nie wiem, bo nie są dostępne inne GALe żeby sprawdzić każdy przypadek.

    Ale może ktoś wie ile nano sekund jest trzymana wartoś dla danych?
    • 29:
       
      CommentAuthorgienekp
    • CommentTime26 May 2023
     
    Robię sobie kolekcję różnych cartów, w sensie zamieniam CAR (czyli obrazy emulatora) na prawdziwy cartridge i powiem wam, że z tym standardem Maxflash to jest jeden wielki bajzel. No bo o ile jeszcze jak jest 128kB to maxflash1mbit niby to załatwia, ma co prawda specyficzne bankowanie ale przynajmniej coś jest.
    Ale jaja są jak coś zajmuje np. do 256kB (PrinceOfPersia, SpartaDOSX+MAN) lub do 512kB (kilka gierek no i konwersje ATR2JAC). Wtedy bierze się standard na wyrost maxflash8mbit. No a tu BINy raz startują z ostatniego banku, raz z zerowego. A to przecież to jest zupełnie inna logika. I wcale nie jest tak że to jest zgodne w którąś stronę. Załóżmy, że projekt ma 256kB (patrzę na PoP). To muszę zrobić CAR co ma 1MBajt, umieścić bank startowy w ostatnim i zerowym (bo nie wiadomo kto co będzie miał). I teraz jak ktoś będzie chciał wyprodukować z tego BINa normalny hardware to programuje 2 pamięci flash po 512kB gdzie jedna jest zajęta w połowie a druga ma tylko ostatni bank startowy. I kupę elektroniki na PCB po to tylko, żeby spasować się z babolem maxflasha8mbit. Oczywiście pod hex-edytorem można to poprzekładać i dać kostkę pamięci dokładnie taką jak potrzeba ale zamieszanie jest spore.

    A skoro Kuba wymyślił J(atari)Cart i ta struktura ma tylko zalety (przełącza dotykiem adresów, startuje zawsze od 0) to czemu nie ma jej uporządkowanej w standardzie CAR do:
    J(atari)Cart8kB
    J(atari)Cart16kB <- to DWA PRZEŁĄCZANE banki podstawiane w jeden obszar
    J(atari)Cart32kB
    J(atari)Cart64kB
    J(atari)Cart128kB <- maxflash1mbit to nie to samo
    J(atari)Cart256kB
    J(atari)Cart512kB <- taki format jest najtańszy najbardziej pancerny i najłatwiejszy do budowy
    J(atari)Cart1MB <- tutaj łaskawie wprowadzono | 75 | 800/XL/XE | 1024 | Atarimax 1 MB Flash cartridge (new)

    ?

    tak jak to ma np.: S-XEGS
    | 33 | 800/XL/XE | 32 | Switchable XEGS 32 KB cartridge | |
    | 34 | 800/XL/XE | 64 | Switchable XEGS 64 KB cartridge | |
    | 35 | 800/XL/XE | 128 | Switchable XEGS 128 KB cartridge | |
    | 36 | 800/XL/XE | 256 | Switchable XEGS 256 KB cartridge | |
    | 37 | 800/XL/XE | 512 | Switchable XEGS 512 KB cartridge | |
    | 38 | 800/XL/XE | 1024 | Switchable XEGS 1 MB cartridge | |

    S-XEGS nie za bardzo nadaje się do robienia toolsów bo jednak zajmuje więcej RAMu.
    • 30:
       
      CommentAuthorMq
    • CommentTime26 May 2023 zmieniony
     
    Prince of Persia działa normalnie na standardowym kartridżu wyposażonym w 512kB i startującym z banku 0, Sparta też.

    Co do tego, że jest jakiś tam bajzel między małymi kartridżami a większymi, to myślę, że może to być ze względów historycznych. Przecież pamięci duże są zawsze drogie, a małe są tanie (w danym momencie historii zmienia się tylko dookreślenie co to znaczy mała i duża pamięć). Dlatego projekty są/były na mniejsze pamięci, a potem robiło się kolejne projekty na większe pamięci. I tak np. jeśli ktoś zrobił kiedyś kartridż 8kB, to przecież w standardzie nie przewidział, że kiedyś powstanie 1MB, a to wymaga dużych zmian. Bardziej bez sensu wydaje mi się pomysł tworzenia kartridży "w dół". Mianowicie jaki sens istnienia ma w ogóle jataricart 8kB? Kość 512kB kosztuje tyle samo co kość 8kB, a w dodatku jest dostępna łatwiej. 128kB kosztuje tyle samo co 512kB, a roboty przy produkcji jest też tyle samo z taką i taką kością, bo fizycznie kości są identyczne. Dla mnie dzisiaj ma sens tylko 512kB i 1MB.

    Każdy soft tworzony obecnie potrafi wstać z banku 0, więc zamiast tworzyć kompatybilności sprzętowe, zamknął bym temat kartridżem 4Mbit i drugim kartridżem 8Mbit identycznym z jedną kością mniej i tyle. Jak coś nie jest kompatybilne, to lepiej grę dostosować niż mnożyć byty sprzętowe.

    Nie zrozum mnie źle Gienek, ale myślę, że to że np. Ty tworzysz nowe kartridże i robisz wsady do GAL-i pozwalających na różne bankowanie, powoduje, że przyczyniasz się do rozwoju bałaganu. Im więcej takich otwartych konstrukcji z różnymi bankowaniami do wyboru, tym większa szansa, że programista każdy będzie inaczej robił soft.
    • 31:
       
      CommentAuthorgienekp
    • CommentTime26 May 2023
     
    Ale mi chodzi o przejście z CAR do "reala". To jest zupełnie inne perspektywa. I próbuje ogarnąć ten "bajzel", właśnie żeby było jak najmniej rozrzutu sprzętowego. Ideałem byłby cart, który obskakuje cały zakres pamięci bez żadnych zmian sprzętowych. I wtedy można to zrobić jedną logiką i wstawiać tylko wybraną pamięć. Czyli, ma 512 to biorę 512-tkę i nic więcej nie wnikam, nie muszę umieć, rozumieć, pamiętać :).

    A tak trzeba dawać programowalny układ GAL i robić wsady na różną konfigurację, bo po prostu mamy ulepa historycznego, gdzie każdy widział tylko swoje i nie patrzył na to ogólnie jakie będą tego konsekwencje.

    Ja to doskonale rozumiem, że kiedyś były fizyczne carty i potem dla zachowania dla potomnych zostały zgrane do plików CAR. I te ID w pliku CAR opisują to co kiedyś. Logiczne...

    Natomiast obecnie jest tendencja odwrotna. Ludzie wyciągają z archiwum plik CAR (to jest mój punkt startu) i się głowią, na co to zapisać. Czyli jak zrobić, żeby CAR "przeistoczył" się w fizyczny identyczny odpowiednik. Zwykle PCB do tego już dawno nie ma. I trzeba się jakoś ratować GALami, cartami wielosystemowymi itd. A przy jednym standardzie sprzętowym, można by poprawić stare CAR na to nowe uporządkowane raz na zawsze. I wtedy jedno PCB załatwiałoby sprawę. I o tym właśnie piszę. Żeby był JEDEN hardware, w całym zakresie, prosty, logiczny. I w zasadzie nie ważne jaką pamięć się wstawi, będzie działać. Najwyżej pamięć się zroluje, ale jak wstaje coś z banku 0 to nie ma kłopotu.

    Patrzę od strony robienia toolsów (!). Zwykły konwerter ATR2CAR, jeżeli mam dyskietkę SD to na 128kB pamięć wejdzie. Na ED lub DD idealna jest 256kB. A na taką dwustronną potrzeba 512kB. OK, tylko w jakim standardzie wyprodukować plik CAR? Dla 128kB Max1Mbit a dla pozostałych na wyrost Max8Mbit? Oba niekompatybilne, różna PCB, różny wsad do GALa. Masakra powstaje przy ED (133120) bo muszę wziąć CAR w standardzie Max8Mbit. I fajnie, że "Ja Wiem", że to tylko dla CAR. Tylko potem ktoś inny weźmie CARa i pomyśli, że faktycznie trzeba takiego byka na 2x512kB. Pytanie po co?

    BARDZO brakuje czegoś na 512kB. Nawet Maxflash Cartridge Studio wyprodukuje nam coś na jedną kostkę 512kB, ale takiego ID dla CAR nie ma, w sensie nie ma odpowiednika w formie pliku CAR, żeby jednoznacznie powiedzieć ile to ma.

    Zaglądnąłem do SpartaDOSa, czy by go nie spasować jakoś do RAMCARTa. Patrzę jak bankuje, są tylko DWIE wersje. Jedna 128kB (maxflash1mbit) i druga maxflash(8mbit), która to ma MANy i zajmuje nie więcej niż 256kB. Nie potrzeba nawet 512kB. To samo z Prince of Persia. Wiadomo, że jak coś zajmuje 256kB to wejdzie do 512kB i do 1MB. Tylko, że jak plik CAR jest 1MBajtowy to skąd wiadomo, że armata na muchy nie jest wymagana?

    Ścieżka S-XEGS ma fajnie to rozwiązane, ale bankuje od razu 16kB i gorzej się jest minąć z RAMem. Z kolei jakby człowiek chciał zrobić jakiś malutki tools na 8kB to jaki CAR zrobi odpinanie RD5? Trzeba brać 128kB z unikatowym bankowaniem (czyli osobny PCB lub wsad do GALA, czyli znowu nowy hardware) lub zapisać CAR w 8MBit i liczyć na to, że ktoś się pokapuje, że nie potrzeba 2x512kB.
    • 32:
       
      CommentAuthorMq
    • CommentTime27 May 2023
     
    Więcej filozofowania jest w tym co piszesz, niż jakiegoś sensu działania.
    Zawsze było tak, że jak się projektowało soft pod kartridż, to trzeba było sobie też do tego równolegle zaprojektować sam kartridż. Czyli albo musi współpracować programista z elektronikiem, albo osoba musi znać się i na sofcie i na sprzęcie.
    Jak ktoś wpada na pomysł żeby zrobić coś na carta, ale chce wykorzystać istniejącego, to musi wiedzieć jakiego i się na tym znać, albo znać jakiegoś jednego i na niego pisać.
    Kartridże są różne i mają swoje zalety. Np. bankowanie danymi pozwala oszczędzić rejestry na 5 stronie, a więc można równolegle wpiąć coś jeszcze a tą stronę. Z kolei bankowanie adresem zajmuje stronę w dużej części lub całą, ale za to jest oszczędność cykli i szybkość.
    Takie rzeczy związane z kartridżami po prostu trzeba wiedzieć, żeby cokolwiek programować, dokładnie tak samo jak trzeba znać GTIA, jak trzeba znać Pokeya, Antica itd.
    A że jest pełno różnych kartridży? No cóż, każdy może sobie zaprojektować jeszcze jakieś kolejne. Na zdrowie:-)
    • 33:
       
      CommentAuthorgienekp
    • CommentTime27 May 2023 zmieniony
     
    @Mq
    No dobra, to teraz patrz. :) Najnowszy emulator ATARI800. Dodano nowe wpisy.
    ->link<-
    | 86 | 800/XL/XE |    8 | XE Multicart (8KB)
    | 87 | 800/XL/XE | 16 | XE Multicart (16KB)
    | 88 | 800/XL/XE | 32 | XE Multicart (32KB)
    | 89 | 800/XL/XE | 64 | XE Multicart (64KB)
    | 90 | 800/XL/XE | 128 | XE Multicart (128KB)
    | 91 | 800/XL/XE | 256 | XE Multicart (256KB)
    | 92 | 800/XL/XE | 512 | XE Multicart (512KB)
    | 93 | 800/XL/XE | 1024 | XE Multicart (1024KB)


    A co to jest ten Multicart:
    On the bootup, last 8KBs are mapped to $A000-$BFFF. Banks are switched by data written to $D5xx, by bits D6-D0. To select 16KB cart, bit D7 must be on.


    No to jak się dodaje takiego cudaka, który jakoś ma pojemność i nawet zapomniane 8kB, startuje z ostatniego banku co przy rożnych pojemnościach powoduje tylko zamieszanie, wybierany "danymi", a to z czasem na ATARI będzie coraz bardziej szwankować. To dlaczego nie dodać coś co by uporządkowało serię maxflas/jacart, która to dość mocno się przyjęła?
    Jakoś "| 38 | 800/XL/XE | 1024 | Switchable XEGS 1 MB cartridge" nigdy nie powstał ale teoretycznie jest możliwy do zrobienia więc jest logicznie na liście.

    ...chyba, że to działa tak, że trzeba samemu zrobić kod do atari800 i wysłać im gotowe pliki. To by zmieniało postać rzeczy.
    • 34: CommentAuthortebe
    • CommentTime27 May 2023
     
    robisz poprawkę, a oni albo to zaakceptują albo nie
    • 35:
       
      CommentAuthorMq
    • CommentTime27 May 2023
     
    Gienek, sam sobie w zasadzie odpowiedziałeś na wszystko o czym tu piszesz:-)
    Ja pozostaję na stanowisku, że dokładanie kolejnych typów bankowania tylko po to, żeby ich było więcej na wyrost jest bez sensu. Podobnie tworzenie nowego sprzętu, który ma niepotrzebne nikomu dodatkowe możliwości bankowania jest bez sensu. Tak jak wcześniej pisałem tworzy to bałagan niepotrzebny i ryzyko, że w przyszłości będzie więcej softu, który będzie pod różne wydumane typy kartridży.
    Moim zdaniem to jest poprawne, że Maxflash występuje w emulatorze tylko jako 1Mbit, 8Mbit new i old. Dlaczego? Ano dlatego, że emulator ma emulować faktycznie istniejący sprzęt, a nie dokładać możliwości istnienia sprzętu wyimaginowanego. Kartridż Maxflash jest faktycznym komercyjnym produktem i jako taki jest emulowany, no i bardzo dobrze.
    jatari nie jest nowy pod względem tego, że był konstruowany jako naśladujący maxflasha. Widzisz ja np. robiąc swój kartridż walczyłem o to, żeby był zgodny z maxflashem w 100%. A więc odpadały kości 39SF na przykład, odpadały nietypowe pojemności. Po prostu chciałem konkretnie zrobić taki kartridż, żeby później gra wydana na niego była możliwa do odpalenia przez osoby, które przykładowo posiadają oryginalnego maxflasha. Bałagan wprowadza np. fakt wsadzenia do kartridża kości 39SF i nazywanie go nadal zgodnym z maxflashem, bo zgodny nie jest. Uważam, że jataricart powinien mieć też jakieś swoje nazwy pełniejsze i odmiany, żeby było wiadomo np. jakiej wielkości ma sektory. W takim wypadku gdyby był to powtarzalny produkt, miał konkretne parametry, wiadome, to fajnie by było jak by się znalazł w emulatorze pod swoim własnym numerkiem. Z tym że tworzenie wszystkich możliwych kombinacji na wyrost w emulatorze jak napisałem wyżej jest bez sensu. Emulator powinien wg mnie odzwierciedlać faktycznie istniejący sprzęt, przy czym nie sprzęt istniejący w jednym egzemplarzu na świecie, tylko taki, który zaistniał szerzej i jest używany powszechnie.
    • 36:
       
      CommentAuthorgienekp
    • CommentTime27 May 2023 zmieniony
     
    Jednak będę upierał się przy swoim :) Ale jestem otwarty na kontrargumenty ;)

    Epoka przenoszenia real do virtual już minęła. Już zgraliśmy hardware, zeskanowaliśmy stare zdjęcia obrazy... W zasadzie już wszystko poszło do chmury. I coraz mniej ma znaczenie co było prawdziwym hardwarem. Jaki materiał użyto na płótno.
    Teraz jest czas z virtuala do reala. Projektuje się wirtualnie, a potem obrabiarki, drukarki 3D, maszyny do PCB itd. Wszystko idzie z virtuala do reala.
    Do czego piję.
    W 2020 roku Kuba opracował standard J(atari)Cart256(kB) ->link<-
    Moim zdaniem najlepszy, najbardziej logiczny i przyszłościowy, bo otwarty, nie przyspawany do jednej firmy i poprawny elektronicznie. Kuba wyprzedził "szachowo" pięć ruchów do przodu, do których dopiero niedawno dobrnąłem. I tak podejrzewam, że zrobił to bo widział zamieszanie związane z maxflashem. Ale musiałby się sam Kuba wypowiedzieć ;)

    Natomiast w życiu bym na to nie trafił, gdyby nie to, że robiąc toolsa Kuba zwrócił mi uwagę na taki "obiekt". No bo ja zaczynając od virtuala do reala, zacząłem od emulatora i tego co tam ma, czyli standardu CAR. Jest CAR, emuluje to i to, tak i tak. Tak samo, RAMCARTa bym nie ruszył gdyby nie to, że mono zrobił upgrade w ATARI800. Po prostu takie czasy, że już w zasadzie wszystko robimy na PC (ja akurat na macu) a ATARI dostaje wypucowany produkt końcowy.

    CAR nie ma nic wspólnego z fizycznymi układami. Virtualny CAR nie mówi nic o AM29F040, czy SST39. No więc zakładanie że CAR z ID(42) to maxflash teoretycznie jest błędne. No tylko jak robię narzędzie co produkuje CAR z kodem 42 to jak to nazwać? A potem jak AVGCart obsługuje taki CAR to dalej jest maxflash? Przecież AM29F040 tam nie ma. Ale "Gra" działa. No właśnie, bo już jest inna epoka. Nie ma płótna ale jest van Gogh na LCD.

    Dlatego jak zobaczyłem, że nową listę ID dla CAR w ATARI800 rozszerza się o jakieś badziewia, a nie ma tam czegoś co powinno być podstawowym standardem to "walę pięścią w stół" :)

    Tzn ja się wcale nie upieram, żeby od 8kB do 1MB wszystko rypać. Natomiast w ostatnim czasie dostałem więcej zapytań o zrobienie carta 8kB niż jakiegokolwiek innego.

    Tak czy siak J(atari)Cart256(kB) zasługuje na emulację. Ale 512 i 128 też. Bo jak będzie emulowany to momentalnie zaczną powstawać realne PCB. Po prostu jest to logiczne i pragmatyczne w odniesieniu do obecnej epoki :)

    Rozumiem też, że krucjatę za tym powinienem zacząć od upgrade dla atari800, w końcu to też projekt OPEN ;)
    • 37: CommentAuthormono
    • CommentTime27 May 2023 zmieniony
     

    gienekp:

    CAR nie ma nic wspólnego z fizycznymi układami.

    Opis typu 3 i 45 ->link<-

    gienekp:

    Nie ma płótna ale jest van Gogh na LCD.

    Impast daje dodatkowy efekt światłocienia. Nie wiem czy to się da na LCD.
    • 38:
       
      CommentAuthorgienekp
    • CommentTime27 May 2023 zmieniony
     

    mono:

    Impast daje dodatkowy efekt światłocienia. Nie wiem czy to się da na LCD.

    Nikt tego nie podważa. Ale na LCD trafia to do każdego. A płótno ma tylko jeden ;)
    • 39:
       
      CommentAuthorMq
    • CommentTime28 May 2023
     

    gienekp:

    CAR nie ma nic wspólnego z fizycznymi układami. Virtualny CAR nie mówi nic o AM29F040, czy SST39.

    W altirra ustawia się w konfiguracji jakie kości są w emulowanym kartridżu. Co ciekawe są tam też dla maxflasha wymienione 39SST, ale jest napisane że sektor ma mieć wtedy 64kB, więc coś nie halo, teraz to zauważyłem...

    gienekp:

    A potem jak AVGCart obsługuje taki CAR to dalej jest maxflash? Przecież AM29F040 tam nie ma. Ale "Gra" działa.

    Nie do końca prawda. AVG owszem obsługuje pliki car, ale w przypadku rzeczonego maxflasha na przykład robi tylko odczyt takich kartridży, a zapisu już nie. Wyjątek stanowi gra FloB, dla której autor AVG zrobił hack i jest specjalna wersja gry, która zapisuje do pliku i zmieniony firmware samego AVG, bo tak wprost to nie działa.

    Piszesz też dużo o tym, że uważasz taki a nie inny kartridż za najlepszy itd. Ok, Ty tak uważasz, ale ja już np. nie:-) Kartridży jest dużo różnych, do różnych zastosowań. Ja np. bardzo lubię standard maxflasha, ale tylko 512k lub 1M, innych nie lubię. Oprócz tego lubię bardzo SIC! i też używam. Używam też XEGS, bo też lubię. A w ogóle to najbardziej lubię zwykłe kartridże z samą pamięcią 8k lub 16k bez żadnej innej elektroniki, to jest super. Aha, lubię jeszcze kartridże robione z fajnymi patentami na samoodłączanie się po wczytaniu programu, mam na myśli różne wersje kartridży turbo do magnetofonów. Kartridż w Atari to dla mnie nie tylko nośnik z pamięcią, to jest dodatkowo możliwość konstruowania różnych fajnych rozwiązań i świetnej zabawy przy tym. Nie zgadzam się też z tezą o przenoszeniu się w świat pecetów w kontekście zmiany epoki. Bawimy się w retro bo lubimy, a nie bo musimy:-)
    • 40:
       
      CommentAuthorgienekp
    • CommentTime28 May 2023 zmieniony
     
    No właśnie, tylko zobacz, że doceniasz stare konstrukcje bo je już masz. Z tej perspektywy "nowe" jest niepotrzebne, a wręcz jest zagrożeniem, że "stare" stanie się niepotrzebne. Kłopot w tym jak się startuje od zera to nie ma jak zacząć. Wojno-covidowe zamieszanie spowodowało, restart na rynku odtwarzania starych technologii. 512-tek przez pół roku nie było. TTL raz są takie raz siakie. Nawet GALe już są w kopii nie do końca zgodne z poprzednikami. Generalnie technologia dla 5V została mocno wygaszona i w to miejsce oferuje się coś nowego, w niższej cenie ale niekoniecznie dobre dla sprzętu retro. Przecież ja przed zabawą w carty pytałem w wielu miejscach o jakieś PCB i kicha. Jeden odsyłał do drugiego. Miał... ale się skończyło. Jedynie aukcje Sikora dały ratunek.

    Całkiem możliwe, że układów 5V będzie z czasem coraz mniej z coraz mniejszym odtwarzaniem rynkowym. To też może się okazać, że zabawa z ATARI będzie mocno ograniczona. Będziemy coraz bardziej w virtualu i wejście na real to będzie zrządzenie losu.
    Dlatego ja jestem za rozwijaniem czegoś co będzie pomostem pomiędzy starym a nowym z jak największym potencjałem na przetrwanie. I moim zdaniem przetrwa tylko OpenSource bez narzuconych standardów, że tu ma być taki rezystor, tu taki układ a tu taki kształt PCB.

    Tak, że będę forsował standard J(atari)CartXYZ(kB) :)
    • 41:
       
      CommentAuthorPeri Noid
    • CommentTime28 May 2023 zmieniony
     
    Są jeszcze inne rozwiązania - takie, przy których możesz mieć absolutnie wszystko co sobie wyobrazisz, ograniczy cię chyba wyłącznie wyobraźnia. Wystarczy popatrzeć na to: ->link<- (mam nadzieję, że link będzie działał). Nie mówię o tym konkretnym wcieleniu a jedynie o pomyśle. Nowoczesna technologia, cena wydaje się kłaść na łopatki rozwiązania klasyczne. A przyszłość dostępności - podobna.
    • 42:
       
      CommentAuthorgienekp
    • CommentTime28 May 2023
     
    @Peri Noid
    Też jestem zwolennikiem takich rozwiązań :)
    Stockowe ATARI z super klastrem obliczeniowym ale wciąż na złączu i w obudowie carta :)
    • 43:
       
      CommentAuthorMq
    • CommentTime28 May 2023
     

    gienekp:

    No właśnie, tylko zobacz, że doceniasz stare konstrukcje bo je już masz.

    Nie mam. Po prostu lubię. kiedyś widziałem, bawiłem się. Jak zachce mi się pobawić którymś z tych starych kartridży, to po prostu sobie taki zrobię:-) Mam w planach jeszcze kilka sentymentalnych powrotów do starych konstrukcji, tylko czasu na to brakuje.
    Trzeba rozróżnić dwie rzeczy: jeden lubi nowoczesne konstrukcje, a inny lubi zabawę w odpowiedniki starych konstrukcji. Rozmowa o tych kartridżach i standaryzowaniu itp. przypomina mi trochę porównywanie stacji dyskietek do SIO2SD. Że niby nie ma już dyskietek, a za to są karty SD. Owszem, ale jak chcę się pobawić dyskietkami, to nie jest to dla mnie przeszkodą, że ktoś uważa, że nie ma skąd wziąć stacji, albo dyskietek. Oczywiście ktoś może mieć takie zdanie, a ja w tym czasie bawię się dyskietkami.
    • 44:
       
      CommentAuthorgienekp
    • CommentTime28 May 2023 zmieniony
     
    Tu się zgadzam w 100% (nawet też mi to przyszło do głowy, że to jest podobnie z tym SIO :) ). SIO2SD jest fantastycznym uzupełnieniem stacji dysków. W żaden sposób z tym nie koliduje. Można mieć to albo/i to. Jeżeli ma być sentymentalnie i w klimacie to tylko stacja. Ale jak robi się coś zupełnie innego (a to jest mój przypadek) a trzeba coś do szybkich testów to SIO2SD jest idealne.

    I teraz jak np. idę od strony toolsów np. robię ATR2CAR ładny z GUI itd. to chcę, żeby istniała jakaś ogólnie dostępna platforma docelowa. Nie ma znaczenia jak się nazywa, kto i na czym to robi. Byleby w ogóle istniała. Inaczej praca poleci na marne.

    ATR2CAR jest dla S-XEGS. Natomiast dla maxflashów musiałem zrobić ATR2MAX i ATR2JAC. Ale ten drugi to ulep bo nie mam 128/256/512. Dlatego zacząłem od hasła "bajzel" i porządek :)

    Mam też kolejny tools na tapecie, kompletna alfa, że w atari800 zapisuje się stan i automat zamienia stan na plik CAR. Jak puścisz taki CAR to ATARI dokładnie od tego momentu wstaje. Nawet nie wiem jak to nazwać, bo to niby frezer w emu a starter w real. No i znowu mi wyszło, że 128/256 w bankowaniu maxowym jest najlogiczniejsze. 128 dla ATARI 64kB a 256 dla ATARI 128kB. No i logicznie, żeby to był jeden standard dla ewentualnej PCB.

    To wszystko są PC-towe narzędzia. Ale wynik ląduje na ATARI.
    Dlatego ta krucjata :)
    • 45:
       
      CommentAuthorMq
    • CommentTime29 May 2023
     
    Rozumiem dokładnie o czym piszesz. Standardy są rzeczą, która śni się wielu, ale myślę, że bardzo trudno jest wprowadzić taki, który się przyjmie i stanie faktycznie standardem. Dlatego myślę, że zamiast robić wielkie porządki, to lepiej równolegle stworzyć coś swojego w sposób jednolity, niż chcąc zaspokoić każdy standard na raz jednym standardem wybudować potworka. Ja lubię prostotę konstrukcji i jedną wersję.

    gienekp:

    Mam też kolejny tools na tapecie, kompletna alfa, że w atari800 zapisuje się stan i automat zamienia stan na plik CAR. Jak puścisz taki CAR to ATARI dokładnie od tego momentu wstaje. Nawet nie wiem jak to nazwać, bo to niby frezer w emu a starter w real. No i znowu mi wyszło, że 128/256 w bankowaniu maxowym jest najlogiczniejsze. 128 dla ATARI 64kB a 256 dla ATARI 128kB. No i logicznie, żeby to był jeden standard dla ewentualnej PCB.


    I właśnie mi logicznie na takie coś wychodzi zupełnie coś innego. Mi wychodzi 512kB. Jeden kartridż, zgodny i z maxflashem. Czyli może to być np. jatari - przecież to jest gotowe rozwiązanie, po co chc3esz robić kolejne?
    Co do kości: kupiłem jatari od Kuby na potrzeby testów i porównań (Kuba pomógł mi trochę w analizie moich błędów, ale to odrębny temat). I w tym jatari dostałem kość HY29F040, czyli Kuba też stara się być zgodny z maxflashem jednak, bo takie kości widzi również soft od maxflasha.

    Tak że co tu porządkować? Zostaw wszystko tak jak jest, a jak chcesz tworzyć fajny soft, który będzie działał u wielu ludzi, to zrób tak jak ja zrobiłem wydając gry: wybrałem kartridż z bankowaniem najpopularniejszym: maxflash 8Mbit z możliwością skrócenia do 4Mbit. Tak uważałem wybierając ten standard jako "standard" i nadal uważam, że jest to droga najsensowniejsza do takich zastosowań.
    • 46:
       
      CommentAuthorMq
    • CommentTime29 May 2023
     
    Aha, a odnośnie tego toola, że freezujesz na emu a odpalasz na Atari, to się tak nie uda chyba, bo jeszcze rejestry sprzętowe by trzeba jakoś zrzucić i poustawiać odpowiednio, nie wystarczy sama pamięć, więc nie wiem czy tak się w ogóle da coś takiego zrobić. Tak działa freezer programowy wbudowany w QMEG. Niby fajnie śmiga, ale niektóre gry działają, a inne nie po takim zafreezowaniu i odfreezowaniu późniejszym.
    Z drugiej strony są freezery sprzętowe i działają w pełni, więc jakoś się da, nie wiem jak się to dokładnie robi, nie zgłębiałem nigdy tematu, tak mi tylko przyszło do głowy z czym trzeba by się zmierzyć przy takim pomyśle.
    • 47:
       
      CommentAuthorgienekp
    • CommentTime29 May 2023
     
    TO niech będzie 512kB.(!!!) Popieram! Z reszty rezygnuję :) Ale niech będzie chociaż to :) Bo nie ma tego ID w CAR. Już 50% problemów zniknie (tzn dla mnie teraz). Nawet Maxflash studio robi 4MBit, a nie ma tego w CAR. Łaskawie ostatnio dodano 8MBit (NEW).

    Obczaiłem, że EMULATOR zrzuca wszystko. Tzn on wie wszystko :). Czyli tam w tym pliku jest stan wszystkich rejestrów. Więc od EMU->REAL jest łatwiej. Bo w drugą stronę to tylko trik jak było w AMIGAch, że to cały czas jakieś urządzonko nasłuchiwało magistralę i ekstra wiedziało co było wpisywane do rejestrów.

    Na szczęście w ATARI nie ma rejestrów takich zmiennych stanowych (czyli że stan zależy od wartości zadanej i stanów poprzednich). Tzn. chyba nie ma :) Czyli taki "starter" (bo nie wiem nawet jak to nazwać). Wypełnia najpierw RAM (w sumie 512kB wypełniło by też rozszerzenia pamięci), potem ustawi STOS, podłoży na stos bity procka ze skokiem ostatniego PC i zakończy RTI. Jedynie co nie mogę zrobić, to jak odtworzyć się jeżeli aktualnie zafrezowało w przerwaniu.
    Ale to jest bajka na inny wątek. Jak będzie na tyle gotowe, że coś będzie po ludzku działać to puszczę public. A docelowo i tak to jeszcze nie jest co ja chcę. Bo chcę, żeby ten "stan" pobrało z sieci ;)
    • 48:
       
      CommentAuthorMq
    • CommentTime29 May 2023
     
    Ja do tego podchodzę tak: jest jeden(!) tylko kartridż. Ten kartridż to maxflash 8Mbit w wersji new. Natomiast 4Mbit to ja traktuję jako swego rodzaju hack (nadal jest to 8Mbit, tylko po prostu nie używamy banków z drugiej połowy kartridża i tyle).
    • 49:
       
      CommentAuthorgienekp
    • CommentTime29 May 2023
     
    No właśnie musisz traktować jako hack i obejście problemu bo jest dziura na 128/256/512. Tak samo jak się produkuje CAR to trzeba go zrobić 1Mbajtowy, mimo że wypełniony jest np. w 1/8. Jakby zrobić standard: start z banku 0, łapanie na dotyk adresu, on/off na bit7 i sprawa załatwiona. Nie musi się to nazywać Maxflashem, nawet lepiej, żeby się to tak nie nazywało, bo bajzel tego carta przejdzie na nowe i wprowadzi tylko zamieszanie. Może to być J(atari)Cart, lub cokolwiek. Nazwa zupełnie nie ma znaczenia. Przecież sprzętowa realizacja tego już dawno istnieje.

    Inaczej wpadamy w błędne koło. Nie róbmy nowego standardu, bo stary format jest dobry i po co nowy. No ale w nim się nie da 512kB. Da się ale trzeba "zhakować". No to jak trzeba zhakować to chyba dobry nie jest? Ale jak zrobimy nowy standard to namieszamy i stary już nie będzie taki dobry jak był. Ale nigdy dobry nie był. Był tylko czasem trzeba zhakować... Kiepska sprawa ;)
    • 50:
       
      CommentAuthorMq
    • CommentTime30 May 2023 zmieniony
     
    To "hakowanie" jest w cudzysłowie. To nie jest żaden hack, tylko po prostu robisz krótszy plik. W czym jest problem? Przecież napisałem, że właśnie tak to działa: standard nazywa się "8Mbit new" ale działa w nim dowolna pojemność od 8kB do 1MB. Jak chcesz to możesz w tym standardzie zrobiś dowolną pojemność, tyle że ja robię fizycznie tylko 4Mbit lub 8Mbit, bo inne pojemności fizycznie nie mają sensu. Wykonanie kartridża 8k, 16k, 32k, 64k, 128k, 256k, 512k - to jest identyczny koszt oraz nakład pracy, więc robię wszystko na 512k i reszta najwyżej zostaje pusta. W czym problem?

    A w ogóle zadam inne pytanie: jaki jest cel Twojego dyskutowania tutaj w ogóle o tym? Narzekanie, że coś Ci się nie podoba, czy może masz jakiś plan i chcesz coś zrobić? Bo jak dla mnie, to trochę szkoda czasu na to całe bicie piany. Powiem szczerze: ja już coraz rzadziej pisuję na forach, bo właśnie tak to wygląda najczęściej, że jak cokolwiek napiszesz, to potem chcąc kulturalnie dokończyć rozmowę, trzeba w nieskończoność dyskutować w kółko o tym samym. Ja bym wolał, żeby wymiana informacji i wiedzy prowadziła do jakiegoś celu, a jak takowego nie ma, to po co marnować ten cały czas?