Jeżeli jedyny haczyk w tym FujiNecie jest to, że nie ma obudowy, to może bym spróbował o co w nim chodzi, bo nie jestem na bieżąco i nie  wgłębiałem się w temat a 200+ zł jednak jest trochę zaporowe na eksperymenty.

Trochę śmiesznie to zabrzmiało gdy TeBe użył sloganu "za moich czasów", ale gdy się pośmiałem i zastanowiłem, to doszedłem do wniosku, że dla nowych bywalców to może nie być oczywiste: pojęcie łatwo programowalnego cartridge'a dużych rozmiarów to bardzo świeży wynalazek. Dlatego zdecydowanie więcej produkcji jest na ram portb niż na cartridge. A wszystko wymaga czasu, którego takie staruchy jak my za dużo nie mają :)

@Cyprian: nie można modyfikować kodu w ROMie :)
Kod większy niż bank się zdarza, najprościej to trzymać w banku podprocedurę, która jak się kończy, to skacze do kodu przełączającego, który jest poza bankiem.

Double-post mi się kliknął.
To dopiszę tylko, że fajnie, że flashcarty stały się popularne, bo są już technicznie możliwe do taniego wykonania. Sam mam ultimate'a od briana82 i to super narzędzie. Nawet kupiłem sobie kung-fu flasha do c64 i też jest super.
Teraz tylko życia brakuje żeby pisać fajne prodki na kartridże :)

@Lewis 52 jest za ultradev. Ultratos ma swoją podstronę.

A czy fanaberia? No to zależy. Mi się na przykład trafił STE z niemiecką klawiaturą i spolszczonym TOSem 2.06UK, więc wszystko jest fajne dopóki nie chcę niczego napisać na klawiaturze. Zainstalowałem sobie Okami shell i jest niestety nieużywalny, bo nie wiem gdzie jest głupi dwukropek czy slash. Więc dla mnie już samo przełączenie wersji językowych nie wydaje się  takie głupie.

Grzybson, nie warto. Ja już próbowałem i poległem. Towarzysz XXL ma niezawodną taktykę sprowadzania dyskusji do swojego poziomu i pokonywania adwersarzy doświadczeniem.

TL;DR: to skomplikowane.

Przeszedłem crash-course programowania na Lynxa, bo w maju 2019 wiedziałem że jest coś takiego jak Lynx, a na początku września wydaliśmy grę wygrywającą compo, więc chyba mogę się wypowiedzieć.
Jeżeli to ma być coś prostego, to na takie potrzeby chłopaki lynksowcy wymyślili sobie swój prosty formacik plików binarnych *.o, który można załadować do Handy'ego oraz jest narzędzie, które obudowuje taki plik w nagłówek i buduje z niego pełnoprawny obraz cartridge'a.
Minusem tego rozwiązania jest to, że jest to jednostrzałowiec - zwartość musi mieścić się w 64kB, bo ładuje się od razu cały i uruchamia i to byłoby na tyle.
Lynx potrafi jednak o wiele więcej. Cartridge mają tam pojemność od 128 do 512 kB (1 MB można wycisnąć bankowaniem) i są dość przyjazne w obsłudze, bo całą pamięć dzielą na 256 stron i można sobie dowolną z nich zaadresować i po prostu czytać. Trudną rzeczą do przeskoczenia jest tylko zarządzenie tą przestrzenią. Trzeba wymyślić sobie jakiś wirtualny filesystem i umieć stworzyć samemu obraz cartridge'a. Pikanterii temu dodaje fakt, że Atari wymyśliło szyfrowanie i nagłówek carta zawierający loader musi być zaszyfrowany, więc trzeba zbudować sobie narzędzie lub zestaw narzędzi, które to ogarnia. No i wtedy można osiągnąć dość dużo, np napisać sobie Mortal Kombat w którym same klatki animacji postaci zajmują więcej niż dostępna pamięć konsoli i dogrywa się je w locie.

Nasz pakiet, którym zbudowaliśmy Lynx Qusta można ściągnąć stąd. Jest tam mój tool ogarniający wszystko oraz pełne źródła. Ale domyślam się, że lektura nie jest łatwa.

To nie jest tak, że powinna albo nie powinna. Autor aplikacji sam decyduje o kręgu odbiorców. Inne wymagania może mieć demo, które doceni garstka scenowców, a inne gra, która strzelałaby sobie w stopę, jeżeli nie odpalałaby się na powszechniejszych konfiguracjach.

Kurde. Za szybko to leci... dla mnie zawsze będziesz tym 14-latkiem chodzącym krok za Tatą Grzybsona

Ten emulator ma swój wątek na AtariAge. Może tam spytaj.

No jest wiele opcji. Rozwiązanie z odpowiednią sekcją BSS chyba jest najprostsze, bo TOS sam wyświetli odpowiedni komunikat jak pamięci będzie za mało. Wyobrażam sobie, że takie bardziej zaawansowane scenariusze pewnie mają znaczenie przy większych Atarkach, które mają multitasking, ale w przypadku zwykłego ST ze zwykłym TOSem i tak wychodzi na jedno.
Doczytałem jeszcze teraz dokumentację i rzeczywiście przeczytałem, że TOS przydziela zawsze wszystko, a mshrink (alternatywna nazwa setblock) rezerwuje konkretny obszar, więc nie ma tam mowy o zwiększaniu pamięci bo i tak na starcie ma się maksa.

Ja myślę, że przykład, ale mnie zadowala i będę podpierał się autorytetem tego wytrawnego STkowca ;)