Nigdy tego nie wiesz. Wystarczy, że ktoś zainstaluje NVDI z dużym cachem na fonty wektorowe i pół mega zniknie. Najlepszym rozwiązaniem jest Mshrink() zaraz po odpaleniu programu i potem Malloc tego co potrzebujesz, ewentualnie error jeśli Malloc() zawiódł.

Oczywiście zawsze znajdzie się jakaś maszyna z takimi sterownikami, które zajmą absurdalnie dużo pamięci. Bardziej interesujący jest przypadek rozsądnej konfiguracji jakie ludzie mają na biurkach i oglądają na nich dema. Nie twierdzę, że chcę wymagać na maksa, tylko właśnie się zastanawiam jaki wyznaczyć sobie górny limit, bo gdy demo będzie już napisane i okaże się, że jednak przesadziłem, to już będzie trochę późno. Jak 4MB to 64*64kB to nie wiem czy 60*64kB jest jeszcze rozsądnie osiągalne, czy bliżej 56*64kB albo jeszcze mniej.

Nie znam dokladnej wartosci. Jedyne co mi przychodzi to empiryczny test. Zrób sobie bianarki testowe które maja kilka wariantów wielkości rezerwowanego bloku bss. Albo jedna ktora ma test w pętli z mallociem i zobacz kiedy zwroci Ci bład. Test przeprowadziłbym na rh majac clean boot, ale ladujac sam driver hdd (ktory?), bo tak zakladam dema sa puszczane na parties. Mówisz o STE wiec można by dyskutować czy TOS 1.6 i 2.06 zachowa się dokładnie tak samo - nie wiem. Aha, wez tez pod wzglad ze sam player muzyki moze tez wewnatrz zrobic Ci malloc (np ztcp gdy masz muzyke ym z perkusja na dma sound o ile nic nie mieszam). PS podpytaj tez ludzi na #atariscne na ircnet - dobre zrodlo wiedzy o 16&32bit

EDIT: pomysł Cypriana z podaniem info o pamięci w pliku NFO jest także spoko imho

A te 3.7 to Cyprian podałeś jako faktyczną estymatę czy tylko przykład? ;)

Jest to bezpieczna wielkość z mojej głowy.
Z tego co pamiętam to u mnie HDDriver z pamięcią cache zajmował około 64kB. TOS zajmuje również nie więcej niż kilkadziesiąt KB. Dodałem 200kB na jakieś akcesoria i wyszło mi 3.7MB

Najwięcej możesz wycisnąć robiąc trackdemo, wtedy teoretycznie możesz mieć prawie całą pamięć -pierwszy kilobajt i -TOS. Jeżeli demo ma być odpalane z TOSa, to zrób jak sugerował Sqward - na starcie Mshrink (bo TOS normalnie przydziela procesowi całą dostępną pamięć) i potem Malloc. Innym rozwiązaniem jest użycie sekcji BSS, wówczas gdy wolnej pamięci będzie za mało TOS da o tym komunikat. Generalnie wydaje mi się że spokojnie można liczyć na 3.5MB i naprawdę ciężko mi sobie wyobrazić (na ten moment ;)) demo które potrzebowałoby więcej.  To co wskazał Kroll to też nie jest ostateczna wartość bo Hddrivera można różnie skonfigurować, i wówczas będzie różnie.

A jak bardzo potrzebujesz dużo pamięci, możesz wykorzystać TTram, ale ilość STków które go mają można policzyć prawdopodobnie na palcach jednej ręki. Ja mam, więc mi nie przeszkadza :P

Co prawda moje doświadczenie w ST jest małe, ale ja to robię tak, że definiuję odpowiednio dużą sekcję BSS i niech TOS się martwi (choć chyba nic mojego póki co nie wymaga więcej jak 520 :) ).

Mshrink zmniejsza wielkość przydzielonego bloku
Malloc/Mxalloc rezwerwują obszar pamięci

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?

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.

Z ustawianiem flag ttram/altram w binarce i tworzeniem sobie bufora ramki w BSSie może być problem na sprzętach z alt/tt ramem, bo bufor ramki skończy w ten sposób w fastramie (,ale to dosyć ekstremalny przypadek, który już przerabiałem). Więc bss/data sobie można używać, ale bufor ramki lepiej sobie zaalokować dynamicznie/jawnie z st ramu z odpowiednim alignmentem. Idealnie by było na początku programu zalokować sobie 1 ciągły bufor MShrink() + Malloc/MxAlloc(w zależności od os'a) i tym jakoś zarządzać sobie według uznania. Jak nie ma wymaganego minimum to zamykasz program. Co do funkcji Malloc/Mxalloc() są ok, jak się ich dużo nie używa. No i warto rozważyć, żeby demo działo na nowszych sprzętach, ale potrzebna jest większa ilość kodu do setupowania/wykrywania ficzerów sprzętu itp. Nie jestem pewien, ale debugery moga sobie przechowywać jakieś rzeczy w górnych obszarach pamięci, chyba że piszesz bezbłędnie i wszystko działa od 1 strzała i ich nie potrzebujesz ;), więc pewnie trzeba zostawić jakiś margines.
W moich STe mam dostępne 4mb+8mb, w mega STe 4mb+6Mb (przestrzeń adresowa jest zajęta przez vme). Istnieje też możliwość ładowania os'a do fast ramu.

Jest parę różnic, z tych istotnych dla dema to:
- dodatkowe 4 cykle (dla procesora 8Mhz) BLiTTERa na każdy przebieg blittingu;
- pamięć cache;
- oraz 16MHz;
- TOS 2.0x.
Domyślnie system startuje z 8MHz noCache, ale warto się upewnić czy nie zostało to włączone w międzyczasie.
Cache jest typu write-through, czyli każdy zapis ląduje od razu w RAM. Ponoć użycie BLiTTERa czyści pamięć cache ale tego nie sprawdziłem.
W TOS 2.0x inaczej niż w 1.x obsługiwany jest dysk -dodatkowo wykorzystano Timer-C. Więc jak zmienisz coś w obsłudze MFP, to nie odczytasz danych.

domyślnie system przydziela całą dostępną pamięć aplikacji: od miejsca startu aż do memtop:

Może być tak że na górze pamięci coś siedzi, na przykład bufor "_FRB".