Bo ja piszę o standardzie w pliku CAR, a Ty nawiązujesz do fizycznego rozwiązania. I dlatego się nie rozumiemy. Ja piszę, że czegoś brakuje, a Ty przekonujesz, że wszystko jest. Na fizycznym rozwiązaniu możesz tu dać "drucik", tam przestawić i gra. Plik CAR to jest szablon. Utniesz w połowie, to nie będzie działał. Zmienisz sumę też. Zmienisz ID, masz inną interpretację.
Zacząłem od zwykłej argumentacji, że jak S-XEGS ma od 33-38 to czemu nie ma takiego analogu w jacart/maxflash, a jest potrzeby. Zwłaszcza jak są dodawane takie twory typu "XE Multicart". Fizyczne rozwiązania w ogóle nie są tu istotne.
Ja tu nie widzę, żadnej niegrzecznej rozmowy. Zwykła dyskusja, a każdą dyskusje należy zakończyć jakimś wnioskiem, inaczej to będzie zwykła paplanina. Ja wiem, że tekst czytany zawsze odbiera się bardziej negatywnie niż jest. Ale moja intencja jest czysto techniczna, żeby uzupełnić standardy o coś czego brakuje. Czyli: "Chcę przeforsować uzupełnienie standardu bo jest mi to potrzebne".
Ok, widzę, że udało mi się sprowokować myślenie podobne do mojego u Ciebie - chociaż być może od początku myśleliśmy tak samo:-)
A więc mamy wnioski.
Pierwszy, z którym się zgadzam: warto dodać te "brakujące" standardy do obsługi car. Faktycznie ja cały czas myślałem o fizycznym rozwiązaniu, a Ty pisałeś o car. W car mogły by być wszystkie opcje, co pozwoliło by na tworzenie różnych wielkości plików na przykład, a potem kilka takich standardów tak na prawdę pasowało by do jednego fizycznego kartridża. Ewentualnie można by w takim fizycznym kartridżu dawać inne wielkości kości, ale bez zmiany logiki samego kartridża. Obawiałem się że za chwilę ktoś wymyśli, że każda wielkość kartridża będzie miała np. wyłączanie w innym banku. Tak jak jest z maxflash 1Mbit i 8Mbit. Powinien 1Mbit mieć to tak samo jak 8Mbit. No bo np. 4Mbit ma tak samo jak 8Mbit. A tu taki babol pod tytułem 1Mbit w sumie psuje standard...
Drugi wniosek jest taki, że w takim razie jak chcesz to forsować, to nie powinieneś dyskutować o tym na forum z randomowymi ludźmi, tylko napisać do autorów emulatorów, albo być może samemu zrobić taką obsługę car jaka być powinna i wtedy uzgodnić to z autorami emulatorów. Generalnie to są wszystko tematy, które wymagają jakiegoś nakładu pracy i chęci współpracy. Dyskusja o tym na forum nie przyniesie moim zdaniem żadnego efektu, bo każdy co najwyżej może tu napisać "weźmy się do roboty i zrób mi to":-)
Dodam jeszcze, że ja zrobiłem błąd "tytuł tego wątku". Bo w stronę 256 i 512 poszedłem od strony 1Mbit. I z tego formatu "PLUS" się wycofuję i żadnych narzędzi nie będzie. Bo ja myślałem, że 2Mbit to będą 2 razy 1Mbit. Ale 1Mbit zaburza całą resztę więc 2Mbit jeszcze bardziej to miesza. Tu był mój błąd. Nawet w ATR2CAR takie przełączanie zrobiło się, że tak powiem mocno popieprzone. A uświadomił mnie do tego standard JACART, który to schodzi w dół z 8MBit(NEW). To zejście jest logiczne i łatwe do zrobienia, chociażby dla konwertera z ATR. Bo będzie tylko jeden algorytm.
Jak nie pisać TU jak tutaj są "przodownicy" od projektowania cartów? Jesteś i TY i jhusak i x_angel i inni. No to jak was nie przekonam to tym bardziej bosów od ATARI800.
"Chytry" plan polega na tym, że jak dokończę z GUI ATR2CAR to bombarduję do bosów o upgrade atari800. Jak oni powiedzą, że "po co to" (a na bank tak będzie) to ja dam przykład waszych rozwiązań, które to dawno na rynku są i działają i nawet przecież Ty gry wydajesz i wszystko jest OK. A jak w Atari800 będzie to na pewno AVGCart też to będzie miał i dla wielu ATR kabelek SIO nie będzie potrzebny. CAR jest "szybszy", a już mam pomysł, żeby kopiowanie danych z poza adresu banku 8kB szły bez czekania na VBLANK. Tylko carty z bankowaniem 8kB uzyskają największą prędkość.
... to teraz dokończyć upgrade dla ATAR800. ;) Tylko nie wiem, czy nie kodować na upgradzie "mono" bo za jednym zamachem poszedłby też ram-cart. Oba carty koncepcja ATR2CAR obskakuje i są mi po drodze.
Jakby co, to produkcyjny Jatari Cart ma pamięci 128/256/512 kB jedną albo dwie, czyli możliwości jest 9. Ponadto pamięci mogą być różnego typu i w ogóle pełna dowolka. Pierwszy (nr 0, boot) flash ma opcję sprzętowego zabezpieczenia przy pomocy rezystora i nożyka do tapet.
W sumie nie głupie 256+512, gdzie 256 jest "WriteProtect" (np. SpartaDOS tam siedzi) a 512 wirtualny ATR. Tylko 256+512 daje 768 ale pomiędzy 256 i 512 będzie luka w bankowaniu. Zdubluje 256 w tym obszarze, czy będzie "FF"?
Oczywiście tak jak było dyskutowane, wszystkie te typy CAR można obskoczyć fizycznym jednym rozwiązaniem sprzętowym, czy to rozwiązaniem maxflasha, czy to od jhusak czy od Mq.
Ważne, że można ładnie zamykać nowe/stare rozwiązania w "kontener" o optymalnej wielkości, a nie na siłę zawsze brać obraz CAR sugerujący potrzebę użycia flash 1Mbajt.
Teraz trzeba przekonać Pana od AVGcarta i Altirry, żeby również rozszerzyli swoje dzieła o nowe CAR.
P.S. O DCarcie jeszcze podyskutujemy. Na razie obraz do testów z programem Acid800 w kodzie CAR 112 (0x70).
P.P.S. SpartaDOSX tak naprawdę z manualem wymaga tylko 256kB. Więc można go zamknąć w kontener JACART_256kB.
P.P.P.S Jeszcze taki przykład, gra Robbo zamknięta w JACART_64. Takie coś można sobie fizycznie wpakować i na maxflashe8mb(new) z jedną i dwoma pamięciami i na maxflasha1mb, na wszystkie carty od jhusak i mq no i na dcarta.
