Ja tam bym sobie marzył, żebyśmy się nie radykalizowali i doceniali, że są ludzie, którym się chce coś robić na malucha, ale jestem za stary, żeby nie mieć złudzeń, że...

Ale nie oszukujmy się. Atari jest zwyczajnie technologicznie kilka lat za C64. To co u nich można zrobić z palcem w nosie w standardowej ilości pamięci, na Atari wymaga zaprzęgnięcia wielu sztuczek i smarowania pamięcią (wiem do czego sprowadzało się robienie Flimbo's Quest). Oczywiście, że można pisać gry i dema na stock, ale nie oczekujmy wtedy, że te produkcje dorównają tym z C64. Pytanie, czy twórcom będzie sprawiało frajdę robienie czegoś pośledniej jakości. W porównaniach jesteśmy zatem niejako skazani na spadanie w dwa skrajne obszary ocen. Albo "kupa, na C64 można lepiej", albo "kupa, bo robi to co C64 a wymaga bazyliona bajtów RAMu".

A to zależy czy w CC65 czy ASM

Tak. FASTLOAD brzmi fajnie.
W sumie... teraz zaświtała mi w głowie idea, że tylko bufory na pamięć ekranu, DMA sampli i dysku oraz cokolwiek dotykam blitterem muszą być w ST ramie, a cała reszta mogłaby być też i w TT ramie. Nie wiem tylko, czy to jest warte zachodu w porównaniu do wymagania, aby po prostu było wolne dla dema (max) 3.7 MB ST ramu, skoro liczbę STków z TT ramem można liczyć wg Adama na palcach jednej ręki, a nie zakładam, żeby demo odpalało się poprawnie na TT albo Falconie.

Żebyście tylko nie rozumieli mnie źle. Nie planuję potworka zjadającego cały RAM. Pytałem się tylko o limity, których nie można przekroczyć, bo będę pisał narzędzia, które mi tą pamięcią będą automatycznie zarządzały i chcę je jakoś nastroić kiedy mają wywalać błąd.
W każdym razie wielkie dzięki, bo dużo się z tego wątku dowiedziałem.

Drugi rozdział Atari Compendium opisuje format pliku GEMDOSowego. Pod offsetem 0x16 jest pole PRGFLAGS, które ma bity określające do jakiej pamięci ma być załadowany proces.
@sqward wg tego opisu jeżeli ustawi się te pole na 0 to program nie zostanie załadowany do TT ramu. Źle to rozumiem, czy to nie są dobre informacje?

Osobiście przyznam, że u mnie zainteresowania zataczają koło i idea pisania rzeczy działających na stocku staje się kusząca - szczególnie, że popularne stają się cartridge, które dość dobrze mogą zaspokoić zapotrzebowanie na pamięć.
Chciałbym jednak dorzucić swoje 5 groszy do dość popularnej idei wspomnianej teraz przez Sikora. Pisanie aplikacji korzystającej z dodatkowych zasobów gdy są, ale działającej wolniej itp gdy ich nie ma nie jest zabawne ani trochę. Większości zwyczajnie nie da się zrobić bez pamięci, a nawet jeśli, to w większości algorytm musiałby być na tyle inny, że to mogłoby tylko mniej więcej wyglądać tak samo, a z konieczności działać zupełnie inaczej. To może sprawdzić się do długich dem, w których party mieszczą się w 64kB i są zwyczajnie doładowywane z dysku gdy nie ma ramu, lub z banków, gdy są. Podobnie z multilevelowymi grami. No ale gołym okiem widać, że są to dwa rodzaje produkcji, bo dodatkowy RAM daje możliwości, których nie da udawać doczytując z dysku gdy trzeba.

@Kroll - Dzięki, widzę, że można wycisnąć naprawdę dużo, więc jest sporo marginesu.
@Adam - Planujemy demo plikowe doczytujące się z HD na STE i nie mam pojęcia co wyjdzie z kompatybilności z większymi Atarkami, więc na pewno ograniczę się do standardowej pamięci ST.
Nie rozumiem jeszcze do końca zależności mshrink i malloc. Planuję zrobić proces, który będzie zajmował malutko (mało code, data i bss), który rozejrzy się po zmiennych systemowych sprawdzając ile jest pamięci i wtedy zrobi mshrink na tyle pamięci ile mu potrzeba. Nie wyczytałem w docach, żeby mshrinkiem dało się tylko zmniejszać pamięć a nie powiększać, dlatego nie zakładałem, że będę wołał malloc (mam negatywne odczucia  co do runtime'owego zarządzania pamięci).

Demo będzie doładowywane z dysku, bo muzyka będzie strumieniem (więc odpada problem alloców playera muzyczki). Ja mam dość czyste atari STE (TOS 2.06) z 4MB RAMu na którym mam tylko sterownik Putnika do Ultra Satana. Nic poza tym. Nie byłem po prostu pewny, czy ta konfiguracja nie jest zbyt syntetyczna i czy ludzie nie mają załadowanych więcej rzeczy, bo jestem zupełnie zielony w kwestii "co się miewa" w STkach, a nie chciałem zgrzytów jeśli okaże się, że uruchomi się tylko u mnie.
W każdym razie skoro padła tu liczba 3.7 MB, to póki co uznam to za górny limit, jaki można wymagać i słuszna informacja, żeby jasno zdefiniować w opisie ile się wymaga i ludzie będą mogli się do tego dostosować (w granicach rozsądku). Dzięki!

To jakieś kodowanie arytmetyczne żę tam są potrzebne mnożenia?

Nie wiem jak z lutowniczego punktu widzenia, ale 65C02 nie ma żadnej przewagi nad 65C816 a ma niekompatybilności nie tylko w postaci braku nielegali ale nawet coś gorszego - kilka instrukcji ma inny czasu wykonywania, co może rozwalić nawet rzetelnie napisany kod.

Jak już idziemy w niekompatybilność to jeżeli byłby tylko dostępny, to 65CE02 byłby o wiele ciekawszy (Commodore 65 miał mieć go na pokładzie).