@GienekP Widzę, że też z uporem maniaka (jak ja) używasz Mojave :D
Wg mnie ten system powinni wspomagać jak najdłużej, zwłaszcza w brew-ie oraz w popularnych bibliotekach.
Jednak nie idzie mi skompilować qtFlashBuilder - tzn udało mi się, ale brak biblioteki w określonej wersji... wywołanie /usr/local/Cellar/qt/6.1.3/share/qt/libexec/uic wywala, że brak /usr/local/opt/icu4c/lib/libicui18n.69.dylib, mam w wersji 7x. trochę pokpili sprawę... Teraz instaluję wersję qt@5 i zobaczymy.
Oczywiście popodmieniałem ścieżki w Makefile na zmienne, żeby móc je łatwo zmieniać.
ostatnio to w zasadzie może mi się tylko konsola i brew odpalać :)
Jest coraz gorzej z qt :/ Nie mam pomysłu jak ku temu zaradzić, żeby za chwilę się nie okazało, że wszystko leży. Nawet kupiłem do firmy na miesiąc nowe qt ale wróciłem do tego starego. I nie wiem co będzie dalej.
Tzn wiem. Homebrew i konsola :)
@bartgo Też kombinuję jakby tu ATRy zlepić na carta. Pomysł jest, czasu brak :) Jednego ATR to ATR2JAC zrobi i to działa.
Ha! czytałem to i owo i chyba się zapgrejduję do Catalina, tam jeszcze brew chyba działa ok bez plucia się, że unsupported.
Drugi sposób z gui to Lazarus + free pascal, ale na razie nie chce mi się kompilować podstawowy pusty projekt, ze względu na jakieś niekompatybilności w źródłach... 3 błędy i d zbita.
w sumie z ncurses trzeba by się przeprosić, sporo softu na to jest i działa :)
Jak z poziomu software uruchamianego z carta zapisywać dane na tym samym cartridge?
Wyobrażam sobie to tak: - robimy obraz car/bin, flashujemy - w obrazie będzie jakiś nasz software (Forth, Logo, Basic, C), załóżmy że jego kod kończy się na X bajtach ale car/bin dalej uzupełniliśmy do większej pojemności (np. 24 kb rozpychamy zerami do 128?) - butujemy się, odpalamy tego carta - jakieś adresy w pamięci Atari są teraz zamapowane na nasz cart? możemy smarować Poke po pamięci co zapisze na cart? możemy pisać po tych zerach co je sztucznie dodaliśmy? - jak konkretnie to zrobić, jakimi adresami pisać, zmieniać banki pamięci (jeśli to konieczne)?
Czy taka sama metoda może być użyta do JCart i Maxflash?
Jak schodzisz do szczegółów, to często coś nie bangla, a to z tego powodu, że mam (zbyt) stary Mojave, a z drugiej strony (zbyt) nowy Ventura. Ten najnowszy Sonoma i Gomorra wyrzuciłem, bo tensorflow na nim działał, jak na intelu.
@bartgo, na repo jcarta masz bibliotekę do obsługi zapisu trzech rodzajów pamięci.
Generalnie aby zapisać coś na flash musisz wykonać abrakadabra "zapisz bajt". Często musisz też wykonać abrakadabra aby sformatować sektor. Formatowanie obraca wszystkie bajty sektora na ff, a zapis polega na kasowaniu niektórych bitów, czyli na 00 nic już nie zapiszesz. Czyli rozbuchać możesz tylko ff-ami, bo wtedy można pisać.
Właśnie skomitowałem pierwszą unowocześnioną wersję przygotowywacza wsadów od GienekP do kartridży JAtariCart oraz MaxFlash.
Należało by potestować
W planach jest jeszcze dorobienie wypluwania flashera, żeby nie używać dwóch programów.
Ale to, co jest, jest ciekawe, więc się dzielę publicznie.
Do brzegu.
menu4car z repozytorium ->link<- obsługuje: - kartridże od 32 do 1024kB w mapowaniu AtariMax, czyli zapis do <$D580 zmienia bank _0-127), a zapis >=$d580 wyłącza kart.
- obsługuje kompresję apl (biblioteka apultra) - można dodać własny font, własną tęczę na górze - można dodać własny obrazek - można dodać do 108 egzeków lub kartridży <=8k, które działają natywnie - mamy do czterech stron z plikami - wsad w postaci prostego pliku csv z polami oddzielanymi pałką (|) - jak chcemy powtórnie zaprogramować kartridż, to go wkładamy w komputer z wciśniętym select i włączamy komputer, po czym uruchamiamy flasher.
Dekompresja działa szybko, gry rozpakowują się niewiele dłużej (tak ze 2 x dłużej), niż się wczytują, zwykle od sekundy do kilku sekund.
Nie chcę się wtrącać, ale czy nie chcielibyście ujednolicić się do jednego drobnego używanego już przez innych "standardu"? Wsady generowane przez Maxflash Cartridge Studio dokładają taką funkcjonalność, że jak się uruchomi komputer trzymając Option, to wtedy pomijany jest kartridż, a nie jak u Was Select. Podobnie jest w kilku dużych grach wydanych już kiedyś dawniej na Maxflasha, więc ja też robię to w swoich produkcjach tak samo, żeby utrzymać ten standard Maxflasha. Oczywiście nie ma to jakiegoś wielkiego znaczenia, ale tak tylko wspominam, bo może Wam bardziej lub mniej zależy na utrzymaniu jakiejś tam jednolitości z innymi. Przyszło mi coś jeszcze do głowy. Nie sprawdzałem tego, tylko tak sobie pomyślałem. Jak ktoś ma qmeg-a, to odpalenie kompa z przytrzymaniem Select spowoduje wejście do menu qmega zamiast normalnego startu z pominięciem kartridża. Pewnie wtedy będzie trzeba w qmegu wyłączyć kartridż i zrobić reset żeby poszedł start np. z jakiegoś urządzenia SIO, chociaż tego też nie sprawdziłem oczywiście:-) To taka garść luźnych uwag co mi się pod kapeluszem zebrały:-)
A tak ogólnie to fajne rzeczy robicie, super projekt z tym zrobieniem wszystkiego co potrzebne do jcarta od strony softu. Najgorsze są urządzenia elektroniczne mega zajebiste i rozbudowane, do których potem nie ma softu:-) U Was to co innego, klasa:-)
Dlaczego select? Bo w planach jest uruchamianie programów w Basic. A z qmegiem to się chyba pokrywa, bo jak wchodzisz do menu to i tak kartridża wyłączasz. Poza tym wyłączenie kartridża powoduje reset i można puścić select w miarę powtarzalnie.
------- edit - właśnie zakomitowałem poprawioną obsługę klawiszami konsoli - option zmienia kartę, select grę a start uruchamia.
A, no to jak wyłączenie kartridża powoduje reset, to w sumie nie ma już znaczenia którym klawiszem się pomija kartridż (np. z punktu widzenia qmega).
A już bez związku z klawiszem pomijania kartridża, to co do programów basicowych, to przecież kartridż i tak jest w tym samym miejscu w pamięci co basic, więc musisz obsłużyć samodzielnie włączanie i wyłączanie basica, klawisz chyba nie ma tu sensu (w sensie, że użytkownik do tego akurat celu nie będzie chyba miał potrzeby używać żadnego klawisza, tylko soft to sam będzie załatwiał), nie?
Niby tak. Nie myślałem jeszcze nad tym głębiej. W sumie ten option odłącza Basic, więc czy Basic, Czy cart było by intuicyjne. A w cart było by to emulowane. Warto się zastanowić.
Ciekawi mnie jak to rozwiążecie. W sumie nigdy nie myślałem o odpalaniu programów w basicu z poziomu kartridża. Może być to ciekawe i przydatne.
Powodzenia i dużo frajdy przy dalszej zabawie, bo widzę (i wiem z własnych doświadczeń że tak jest), że masz kupę radochy z zabawy tym softem. Świetnie się oprogramowuje kartridże, odkryłem to całkiem niedawno:-)
Mnie też to ciekawi, ale gienekp ma mnóstwo doświadczenia już z pracy nad atr2car. Pewnie mu to zostawię, a na razie robię generowanie flashera z menu2car. I chyba na tym przestanę :) Wtedy się pewnie gienekp uaktywni i zrobi atry i basic. Albo sobie to poczeka, a i tak natenczas już jest super.
A i tak ten flasher będzie lepszy (szybszy, bo będzie kompresja, a przynajmniej rle na FF), niż jest teraz.
Co do "Maxflash Cartridge Studio" to niestety jest to standard zamknięty. Mało tego, ograniczony do windowsa i do tego co robi. A gdy mamy swoje carty, swój soft budowany od zera, narzędzia poboczne wielosystemowe to w zasadzie po co patrzeć na coś równoległego i się dopasowywać. Lepiej to wyprzedzić i narzucić nową jakość :) Niech teraz inni nas gonią ;)
Co do /Select/. No w ATARI /Start/ jest dla boot z magnetofonu. /Option/ włącza, wyłącza BASIC. Został więc /Select/ lub /Help/. W atr2car był /Select/ i na razie tak zostało...
Natomiast z optionem to trzeba uważać. Ja się złapałem na takie coś. Zrobiłem sobie tester polutowanego carta. Po prostu randomowo przełączał banki, oraz go włączał i wyłączał. Na emu wszystko śmigało. Daje na real i masakra. Zapomniałem o prostej sprawie. Na emu mam w konfigu BasicOFF. Co oznacza, że jak wyłączamy carta na $D58x to daje RAM (tam sobie dałem bajty kontrolne). Ale przecież, gdy po włączeniu nie ma optiona to wyłączenie carta da nam BASIC. No więc stan OPTION jest w sumie istotny dla włączania/wyłączania banków.
W menu4car gdy po włączeniu naciśnięty jest select to cart zostanie wyłączony i wykonany zostanie zimny start. No a to już jest normalny reboot. To też oznacza, że żeby zdążyć i np. że jak chcemy wczytywać od kopa magnetofon to naciskamy Start+Select+Option. Jak chcemy megnetofon + basic to Start+Select, jak dyskietkę bez basic to Select+Option, a jak chcemy wejść do BASICa to sam Select. No więc Select jest kolejnym "bitem" możliwości i Option odpada. Można by to robić Helpem ale to jakoś takie dziwne.
Nie mam qmega, więc się nie wypowiem.
Natomiast co do ATR to na 99% będzie działać. Trik polega na tym, że obecnie spotykane rozwiązania polegają na dołączeniu wprost całego pliku ATR do multicarta. Natomiast u nas jest coś takiego, że jednak program PC może wcześniej coś tam pogrzebać i poprawić w tym ATR. Czyli może spróbować znaleźć skoki do SIO. No i np. może stworzyć tablicę sektorów. Zajmuje to troszkę dodatkowego miejsca na carcie ale za to wiemy gdzie na carcie jest ObrazATR:5 Sektor:35.
Chciałem zrobić ten ZAPIS na ATR i wtedy takie obrazy też by się zapisywały. Na razie poległem. Wyszło mi, że najpierw powinienem dać upgrade do EMU Atari800 co to udaje flashowanie a potem robić kod zapisu ATRów.
W każdym razie zabawa wciąga. W najbliższym czasie jak znajdę chwilkę to zrobi się GUI wieloplatformowe.
Gui wieloplatformowe - to jest coś! I będzie to wywoływać binarkę, czy zawierać w sobie te funkcje?
Imho zapis ATR na Carcie tylko li przy sektorach 128 bajtów, jak jest w 29SF040. Ponadto trzeba ATRY zapisywać wyalignowane do granic 8 kb i z przodu i z tyłu, aby mieć sektory w miejscu fizycznych sektorów we flashu.
GUI wywoła binarkę z parametrami (podstawi tmp.csv). Będzie jedno od drugiego niezależne i na początek łatwiej. Inaczej to trzeba by zrobić "libmenu4car"... w sumie też można. :)
Co do programów BAS. to ja bym to widział tak, że nie włącza się basica, ale podkłada w to miejsce basica z carta. Ale takiego lekko poprawionego. Który zamiast RAEDY zrobi CLOAD i zamiast magnetofonu pociągnie dane z carta. Wtedy cała pamięć będzie do dyspozycji. Żadne DOSy nie będą się plątać.
Tak się zastanawiam, bo się nie znam. Jak jest w innych BASICach? Tych BASIC XL, XE Turbo. Tam też basic zajmuje 8kB? Bo w sumie jakby tak z menu carta mieć i basicowe i turbobasicowe pliki od kopa odpalane to byłoby miło. :)
Z zapisem właśnie ten blok flashujący jest wredny. Bo trzeba gdzieś mieć na to bufor. A często ATRy to programy całodyskowe co panoszą się wszędzie po RAM i nie ma za bardzo jak się minąć. :/
EDIT. Taki koncept zapisu, zostawiamy jeden bank na carcie na "mijankę". Jest po ERASE więc same FF. Kopiujemy stary bank do tego FF z nowym sektorem zapisywanym. A potem już gotowca w stare miejsce. Tylko czy my tego flasha nie zajedziemy szybko?
Jak to sprytnie zrobisz, to szybko nie zajedziesz, ale tylko przy małych sektorach. Z AtariMax jest problem, bo pamięci AtariMax mają 64k banki. Moja wiedza pozwala mi stwierdzić, że ogólnie nie da się zrobić takiej struktury danych, która by ogarniała zapis do "wolnego" sektora i unikała fragmentacji jednocześnie z minimalną liczbą zapisów przy takim sektorze. Bo jak plik zapiszemy, to jego poprzednia kopia nadaje się do usunięcia. A jak? Poprzez przepisanie aktualnych plików z tego sektora w nowe miejsce. Więc 2 takie sektory by dały radę, a może i jeden w przypadku nie zapisywania więcej, niż 64 kB na raz, a to jedna dyskietka ED. Czyli przy zapisaniu jednego pliku należało by przepisać pozostałe pliki z sektora tak, żeby zwolniły jeden sektor. Trudne, czasochłonne i wyczerpujące dla flasha. W takich przypadkach lepszy RAMCart.
Ale jeśli chodzi o zastosowania niestandardowe, typu: zapisujemy w pliku, który już jest, to sprawa staje się dużo łatwiejsza, bo otwarcie pliku do zapisu ff-uje konkretne sektory i potem następuje zapis.
Ja tam bym się nie bawił w zapis do ATR, chyba że jako wisienka na torcie po wszystkim.
Racja. Zakładałem, że zapis byłby dla pamięci flash o znacznie mniejszym bloku zapisywalnym. Kombinowałem tak, że w zasadzie mamy taką matrioszkę. Bo w banku carta mamy fragment pliku ATR. Jeżeli system chce zapisać konkretny sektor ATR to w zasadzie nie ma znaczenia w jakim to banku jest, bo to taki plik w pliku. Czyli mając stary bank mogę przygotować nowy, który ma dokładnie taki sam obraz jak stary ale podmienione jest tylko 128 bajtów nowego sektora. A ponieważ mam "mapę" wszystkich sektorów względem banków (ich wskaźniki) to zostaje tylko powiedzieć, że dany fragment pliku ATR znajduje się w takim i takim banku. Sam ATR nadal będzie ciągły, natomiast banki z jego fragmentami będą rozsypane. Kłopot w tym, że ta mapa to będzie cały czas mielona i flasha zajedzie. Więc sama mapa też powinna być przesuwana. No a wtedy to się robi strasznie zakręcone. Bo trzeba by wymyślić jak randomowo powiedzieć gdzie jest mapa.
To się robi takie listy-kolejki lifo z nakrywkami, gdzie dopisujesz tylko dane na końcu, a wyszukujesz od końca do początku. Więc jak coś było później, to wcześniej to znajdziesz. I tak mapę sektorów można zrobić. Można też wykorzystać fakt, że można zapisywać bajt 8 razy bit po bicie i z tego masz 8 zapisów na komórkę - możesz uaktualniać statusy bez tracenia przestrzeni.
Właśnie wypchnąłem wersję potrafiącą zapisywać plik XEX flashujący kartridż. Zapraszam do testowania :) Z mojej strony, oprócz poprawiania błędów, jeśli ktoś znajdzie coś, to chyba wszystko. Jeśli nic się nie wydarzy, za parę dni zrobię taga i będą binarki do ściągnięcia. ->link<-
Na jaki system najpierw? Spróbuję na windzie to posadzić :) ---edit---
Posadziłem. Co prawda środowisko WSL ale powinno działać - win10. ---edit--- no i nie działa. Jaka to lipa z tymi Windowsami. Trzeba kompilować pod djgpp/mingw.
Winda 11 chętnie ale jeśli to kłopot to mam też Manjaro. Nie pali się bo pewno dopiero pod koniec tygodnia znajdę czas. Ale może inni Microsofciarze też skorzystają:)
Próbowałem użyć menu4car.exe (z repozytorium) pod Windows 7. Przy próbie dodania niektórych gier wywalił mi komunikaty: Load error "Artefakt przodków.xex". Error "Książę" does not fit, need 1263 bytes. Error "Laura" does not fit, need 182911 bytes. Error "Magia Kryształu" does not fit, need 17390 bytes.
Co robię nie tak? Inne gry się dodały. Pliki zajmuja łącznie 962kB.
Aha, ten obraz ładuję do Altirry, pokazuje mi się menu, ale żadna gra nie odpala.
Pobierz z najnowszego release, z dzisiaj wieczór (name: 20231113) A to, że się gry nie mieszczą, to jeśli to błąd, to został poprawiony w tym release. Ale może też się zdarzyć, że jakaś gra się nie mieści, ale następna się zmieści. Wtedy właśnie taki komunikat (not fit). Ta nowa wersja też wyświetla zajętość kartridża w % i w bajtach po przeleceniu całego pliku. Tytuły gier jak najbardziej z polskimi znakami, ale plik wejściowy ma być w UTF8.
Windows 11, nie działa (wersja sprzed około 30 minut): - dwuklik hałasuje że ta wersja nie będzie działać na moim komputerze - odpalenie z linii poleceń git/sh narzeka, że "cannot execute binary file: Exec format error"
O czyli to exe to nie jest kompatybilne? Jeju, jak ja się na windowsach nie znam. U siebie odpalałem i działało, ale może rzeczywiście ten WSL ma inne binarki i bez tego nie działa :/ GienekP, przekompilujesz pod swoim windowsem?
Teraz jestem przy kompie z Windows 10, pobrałem najnowszą wersję (menu4car_wsl.exe) i nie odpala się: Wersja menu4car.exe nie jest zgodna z wersją uruchomionego systemu Windows. Sprawdź informacje dotyczące systemu operacyjnego na tym komputerze, a następnie skontaktuj się z wydawcą oprogramowania.
Jutro obadam na Win 11
Jeszcze z tym poprzednim plikiem car, stworzonym w wersji z października - wcześniej tylko pobieżnie sprawdziłem kilka gier i napisałem, że nie odpalają się. Teraz przeklikałem więcej sztuk i widzę, że niektóre się odpalają. Mógłbym spakować cały folder z tymi grami i wrzucić do analizy ale wydaje mi się, że te z trainerami (prawdopodobnie spakowane) się nie odpalają.
Niestety, jak odpalasz tę wersję wsl (windows subsystem for linux) to te binarki są niekompatybilne z windowsami. Dlatego zmieniłem nazwę, że jak ktoś to wsl ma zainstalowane/uruchomione, to mu zadziała.
Odpaliłem wersję menu4car_wsl.exe spod basha Tym razem w sumie to przyczepił się do polskich nazw plików ale skompilował wsad.
Nie widzę nigdzie, żeby podał ile jeszcze mam miejsca wolnego albo zajętego przez gry.
Przykładowe tytuły, które mi nie chodzą: Mission Shark (1991)(L.K. Avalon)(PL)[h Seban][t +3 Seban][Misja hack].xex Fred (1991)(L.K. Avalon)(PL)[h Seban][t +2 Seban].xex Kult (1992)(ASF)(PL)[t Clever People].xex Podejrzewam, że chodzi o skompresowane gry z trainerami.
I teraz tak: po skompilowaniu październikowym exe'kiem gry próbowały się odpalać i wywalało z powrotem do menu carta. Po skompilowaniu dzisiejszym exe'kiem Misja wchodzi do selftestu, Fred powoduje crash Altirry. Robbo i Lasermania, które wodpalały się z carta skompilowanego październikowym działały, a teraz nie działają.
Na real hardware jeszcze nie testowałem.
Nie wykluczone, że coś robię źle - mogę podesłać moją paczkę do testów. Jest tam też ta sama kompilacja zrobiona pod Maxflash i działa.
Kuba, a po co loader siedzi/trzyma coś na stosie? Przenieś cały loader ma 7mą stronę (myślę, że zmieści się na stronie pamięci), a najlepiej niech wszystkie swoje zmienne też trzyma na 7mej stronie (liczniki na samomodyfikowalnym kodzie) i wszystko powinno się zawsze odpalić.
Chodzi o to, że tu loader w RAM jest szczątkowy, ogarnia zapis/odczyt bajtu i przechowuje parę bajtów na czas działania kartridża. Wydawało się, że te parę bajtów na stosie da radę, ale akurat Kult resetuje stos i wszystko idzie w maliny. Więc trzeba będzie zrobić kilka rodzajów loaderów :/ Pamięć na stosie jest apetyczna, bo "nic z tego nie korzysta" - i tu zonk, bo wiele specjalnych zadań chce się tu ukryć, włączając wirusy i właśnie loadery typu "stealth". Ale chyba rzeczywiście, loader z prockami pod 700 zajmujący z 40 bajtów będzie skuteczniejszy, niż zabawy ze stosem. Sprawdzimy :)
Jakoś w perspektywie tego wszystkiego adres od 700 wydaje mi się świętszy (no bo wiadomo, że tam jest loader, ze dwie strony zajmuje) niż stos. Ale pomysł ze stosem też był dobry, po prostu założenie, że stos nie jest resetowany przez pakery było błędne.
Z tą "świętością" stosu bym nie przesadzał. Chcieliśmy by cart Scorcha po Reset się kulturalnie odpalał (a jest wyłączony w czasie gry czy menu), czyli trzeba go włączyć ustawiając bank nr 0 (jedno STA) i ponownie zrobić Reset (JMP ($FFFC) ), proste. No ale gdzieś tę prockę trzeba umieścić.... padło na stos, bo to oczywiste miejsce i raptem 6 bajtów.
I wszystko pięknie działało... ale nie testowaliśmy na U1MB :)
Odpaliłem na Ultimate i nie działa!, patrzę na stos, a tam inna podobna procedurka robiąca prawie to samo.... włączająca Ultimate :) zamazała naszą. No i na U1MB wpada w pętlę resetów po naciśnięciu Reset ... sorry.
Więc najbezpieczniejsza jest 7ma strona pamięci. Będzie działało wszystko poza wynalazkami XXLa :P
@jhusak nie kompiluje się to na Windows, brak bibliotek.
@Pecus Raczej chodzi o to, że skoro jest XEX to jest to plik DOS. No to raczej programy powinny założyć, że w tle DOS jest i poprawnie ze stosu korzysta. No ale niestety programy pakują się z butami i tak naprawdę nie ma ani jednego bajta bezpiecznego w RAM. 7-dmą stronę też program zajedzie. Nie ten to inny...
To jest generalny problem standardu maxflash. On jest prosty dla elektroniki ale fatalny do obsługi. Po prostu podcina sam siebie. Już S-XEGS jest lepszy, bo gwarantuje stałość kodu w jednym z banków.
Obecnie hardwarowo ja testuje DCarta. Poszerzam standard maxflasaha o gwarantowany dostęp do kodu z carta w zakresie strony D5. Bez względu czy cart jest włączony czy nie. Z bramek jest to trudniejsze do zrobienia. Na GALu zajmuje to dokładnie tyle samo. Po takim zabiegu potrzeba dokładnie 0 bajtów w RAM.
Jakich bibliotek? Zrobiłeś git submodule init / git submodule update? Nie korzystam(y) z żadnych innych.
Udało mi sie uruchomić te 3 gry, ale Mision Shark i Fred tylko działa z kompresją strumieniową - przy zwykłej kompresji blokowej lub żadnej się wywala, a nie mam siły na razie sprawdzać dlaczego.
Podejrzewam jakiś prosty błąd w loaderze.
Loader wrzuciłem na 780, wraz z danymi zajmuje niecałe $80 bajtów.
