Czyli tak jak inny program alokujący dealokujący pamięć. Więc z tego można wywnioskować jedynie, że każdy program użytkownika robiąc alokację/dealokację zwiększa fragmentację pamięci. I tak jest to prawda :), no chyba, że robi alokacje dobrze i korzysta z własnego managera.  Ale to nie oznacza, że upx czy inny paker jest zły, bo robi te same rzeczy co inne programy. Pozatym skąd wiesz, może ma jakiś własny manager pamięci, który minimalizuje fragmentację?

Racja, ale po to to właśnie jest. Robisz alokację raz, albo w większych/równych blokach (w jednostkach kilku, kilkunastu bajtów w wielokrotności minimalnych minimalnych bloków w jakich pamięć jest przydzielana). Jak Ci się pamięć kończy to alokuje się następne bloki lub zwalnia. W razie potrzeby sam sobie tymi blokami wachlujesz, żeby zminimalizować dziury pomiędzy nimi (jak np. zwolnisz jeden blok w środku, to tak przykładowo piszę w dużym uproszczeniu).

Pozwolę sobie przytoczyć taką Wikipedię i cytat dotyczący fragmentacji zewnętrznej/wewnętrzej, który popiera moje twierdzenie (patrz zapis dot. memory poll):

Ale to wcale nie potwierdza tego, że menedżery są niepotrzebne do pamięci innej niż wirtualna. Przy zwykłej pamięci też mogę sobie alokować do woli, aż mi się nie skończy albo jak już będzie tak pofragmentowana, że nie będzie się dało nic zrobić. Czym się różni pofragmentowanie przestrzeni adresowej od zwykłej fragmentacji? Chyba przestrzeń adresowa też może się kiedyś skończyć?

Przez wiele systemów masz na myśli linuxa? ;)

Niestety to jest oczywiste. Zdziwiłbyś się w ilu książkach o deweloperce na systemy o zamkniętej architekturze, reset urządzenia jest proponowany do usuwania tego typu problemów. Przy wczytywaniu leveli ci mogą robić soft reset 'z partyzanta', a użytkownik nawet tego nie wie. A dlaczego? Żeby sobie zaoszczędzić sobie problemów podczas działania aplikacji i pracować na 'odświeżonym systemie'. A stosowanie ww. memory poll to standard (konsole, PCty, windy, tostery, lodówki ;)).

Bez stripa 3,2mb, po zestripowaniu 2mb z hakiem, po upxie trochę mniej niż 900kb. Binarka np. Papyrusa ma np o ile dobrze pamiętam 5mb, po rozpakowaniu pewnie z 10mb.

I powiem tak, fragmentacji na MiNCie się nie boję, bo prędzej system mi zejdzie niż wystąpi brak pamięci z powodu fragmentacji ;).

AdamK: musiałbyś mi przedstawić coś bardziej przekonującego, bo to co piszesz zupełnie do mnie nie przemawia. Nie przytaczasz żadnych konkretów. Pisanie "UPX jest zły pod MiNTem, bo tak jest i już" nie jest żadnym faktem. Lepiej byś napisał dlaczego? Bo się uruchamia i alokuje/dealokuje pamięć jak inne programy, które mogą być odpalane pod systemem? :)

Powiem tak własny manager pamięci jest zawsze lepszy niż malloc czy cokolwiek innego. Pamięć wirtualna itp. nie ma tutaj nic do rzeczy. Przez manager pamięci rozumiem tutaj, że alokujesz duży blok(i) pamięci raz(to minimalizuje trochę fragmentację) i sam zarządzasz tym co się wewnątrz tego bloku dzieje i masz własne mechanizmy do śledzenia co tam jest robione. Nie bez powodu nikt np. w we współczesnych grach nie polega tylko na systemie operacyjnym (biorąc pod uwagę, że są np. różne rodzaje pamięci: fizyczna, wirtualna, na karcie graficznej itp).  Na atari jest ST/TT ram i teraz jeszcze dochodzi pamięć na kartach graficznych PCI. IMHO bardziej cenne są zasoby systemowe tym bardziej taki manager pamięci jest potrzebny, więc nie zgodzę się, że manager pamięci jest potrzebny tylko jak jest pamięć wirtualna.  Nikt o zdrowych zmysłach nie polega w 100% na OS'ie i bibliotece standardowej C.
Pozatym tak jak pisałem, zawsze jest reset jak pamięć się skończy (reset jest często praktykowany np. na konsolach :)).

AdamK: mi to wygląda na jakieś zabobony ;). Bo co robi upx, pakuje binarkę (obecnie mam współczynnik 49%) i rozpakowuje ją w locie w czasie wykonania. Fragmentacja pamięci jest zawsze jak jest dużo alokacji/dealokacji pamięci i tego nie da się uniknąć (po to ludzie piszą własne managery pamięci).

AdamK: heheh, mintowi niewiele trzeba żeby się przewrócił. Tryb ochrony pamięci to fikcja. A fragmentacja fragmentacją, jest wszędzie, wątpię, żeby to była wina tylko upx'a :).
Czyli co? Mam rozumieć że mintem jest fragmentacja, a pod tosem już nie? Kto konkretnie to testował i z jaką wersją, że doszedł do takich wniosków?

Zmieniłem początkową konfigurację (320x240, fullscreen rozdzielczość startowa), zmniejszyłem częstotliwość zczytywania kursora myszki, zmieniłem tryb update'u ekranu (nie kopiuje całego bufora ramki co vbl tylko najmniejszą ilość zmian, był na szczęście wbudowany mechanizm trzeba go było włączyć), wyłączyłem automatyczne backupy (chyba).  Udało mi się odpalić toto pod Hatari, pod Aranymem połowicznie, bo odpala mi się tylko w oknie i myszka nie funkcjonuje (wina pewnie SDL'a). 
GRAFX żre trochę pamięci, bo nie dość, że po każdej operacji robi dumpa ekranu to jeszcze robi kopie bezpieczeństwa(dwa rodzaje) w gifach i zrzuca je na dysk. Możliwe, że wersja dla F030 będzie jeszcze szybciej chodziła, jak wyłączę support dla warstw (na razie coś jest nie tak, bo linker mi coś krzyczy). Ale i tak dopiero fastram robi jakąś różnicę. Możliwe, że program pójdzie też na TT-ce, ale nie mam jak sprawdzić.. 
Warstwy są fajne do animacji. Np. animowane gify tj. ich poszczególne klatki są pakowane właśnie na warstwy. No i odchudziłem binarkę, miała 3mb, teraz ma ~800kb ;) (magia strip'a i upx'a).

Obecnie wczytuję/zapisuję poprawnie gify, bmp, png (tylko 256 kolorów). Grafx nie lubi formatów 24/32 bitowych, ale czemu tu się dziwić ztargetowany jest własnie na 256 kolorów. Jest jeszcze masa formatów do sprawdzenia. W większości są problemy przy zapisie/odczycie palet, bo wszyscy się przyzwyczaili do lityl endiana ;).
Myślę, że jak jeszcze naprawi się pliki neo i pi1 (sprawa odczytu/zapisu palet) to wypuszczę binarkę jako betę.

temat już był wielokrotnie maglowany we wszystkie strony. Rozpiska jest tutaj z tabelką ustawień M0/M1, tak jak napisał Piesiu.
http://pinouts.ru/Video/atari_falcon030 … nout.shtml
Domyślnie jest tryb TV (dwa piny M1/M0 na high), trzeba zrobić przełącznik, który połączy pin m0 lub m1 z GND. Jeżeli demo jest tylko rgb to pójdzie tylko w trybie rgb. Jak coś jest vga only to pójdzie tylko na vga. Czasami w demach można wybrać tryb rgb czy vga przy starcie (jak się źle wybierze to wiadomo, reset). Trzeba czytać pliki README :).
Oczywiście niektóre telewizory LCD mogą sobie nie radzić - mogą nie łapać wszystkich ustawień VIDELA (parametry vsync/hsync mogą być np dla danej zaprogramowanej rozdzielczości poza zakresem) i niektóre screeny mogą być rzeczywiście 'out of sync'. Tak też może być z niektórymi trybami vga.   

pzdr!

Źródła są bardzo ukryte ;):
http://code.google.com/p/grafx2/wiki/Downloads?tm=2

Zastanawiam się nad wrzuceniem tych źródeł do jakiegoś SCM'a lub zmergować zmiany z repo gógielcode projektu.. Mogę podesłać źródła na priva... Ale potrzeba gcc i masy dodatkowych bibliotek, makefile'a też zhakowałem na potrzeby i obecnie wszystko mi się buduje z kroskompilatorem, ale teraz zbudowanie tego na atari nie powinno być problemem.

no ja właśnie to zauważyłem :) zapis/odczyt u mnie na falconie, zapisuje też źle gify, pod windą tego nie ma i wygląda wszystko ok...

good work będzie jak nie będzie bugów ;)

a nieprawda. zajrzyj sobie do specyfikacji :)... są milanowe wywołania xbiosowe i przystosowane do ctpci...

logika jest potrzebna, bo nie ma wykrycia karty, czyli sprawdzenia czy jest szyna pci czy jej nie ma, czy radek jest czy go nie ma, potem można ustawiać sobie vdi.
Jest funkcja do listowania videomodów, ale działa raczej średnio (się sypie) i nie ma trybów z alfą :/ tylko 00RRGGBB i normalnie się zirytowałem.
W tej chwili jest eksperymentalna obsługa milana, a te funkcje xbiosu są podobne (jest zmiana tylko jednej flagi w funkcji). Więc możnaby się pokusić o lekkie kopiuj-wklej. Spoko przepatrzyłem wszystko ;)....