@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).

Eh... dopiero teraz doczytałem ten drugi akapit.
Wygląda zatem, że jedyną taką sekwencja są jednobajtowe NOPy w 65C02.

Opowieść z cyklu, że na Placu Czerwonym rozdają rowery...

Typowy XXL jest typowy :) Spróbuj, proszę, podchodzić trochę mniej bezkrytycznie do tego, co przeczytasz gdzieś w internecie, gdyż nie trzeba ostrego jak brzytwa umysłu, żeby zorientować się, że następny rozkaz nie może być czytany w cyklu zapisującym wynik działania poprzedniego rozkazu.

To o czym czytałeś tyczy się tylko niektórych instrukcji modyfikujących rejestry, w których owa modyfikacja następuje podczas czytania opcode'u następnego rozkazu. Np. lda #0 w pierwszym cyklu czyta opcode, w drugim operand, który jest ładowany do akumulatora właśnie w tym trzecim cyklu, w którym czytany jest opcode następnego rozkazu.

A gdyby jakiś odpowiednik "FujiNet" dla ST?
No jest Netusbee, ale to kabel a nie wifi i zapewnia bardzo cienką warstwę - bardzo dużo trzeba oprogramować po stronie ST, przez co cierpią transfery.

Nawet chyba nie trzeba przepisywać tego na dasm. Trzeba przeorganizować te źródło, żeby mads wygenerował z tego surowy obraz cartridża, czyli bez żadnych nagłówków i od adresu $8000 (opcjonalnie madsem można wygenerować też header). Upewnić się, że program używa tylko ramu dostępnego w konsoli. Potem podpisać obraz za pomocą 7800sign. Trochę roboty jest i potrzebny jest ktoś kto już takie rzeczy ogarnia. Ja niestety w praktyce się mało znam. Ale rzecz jest do ogarnięcia.

Tutaj widać jakie Maria ma możliwości. Są tylko po prostu trudne do wykrzesania. Zwyczajnie brakuje czasu CPU żeby wygenerować te wszystkie fajne display listy i brakuje RAMu żeby je pomieścić.

Skoro mamy dość standardowego peceta, który nazywa się Atari, to pytanie "ale czy to jeszcze Atari?" traci rację bytu, a przynajmniej mocno zmienia znaczenie :)

O... nie myślałem, że pięćsetki były aż tak popularne.