Witam
Dla przypomnienia schematyczny podział pamięci A500/A500+/A600
$000000 - $07ffff 512 KB CHIP
$080000 - $0fffff 512 KB CHIP
$100000 - $1fffff 1 MB CHIP
$200000 - $9fffff 8 MB FAST
$c00000 - $dbffff 1,75 MB SLOW ( FAKE FAST )
Nie pamiętam dokładnie ale gdzieś wyczytałem że jeśli mamy na przykład 0.5 MB CHIP to pod wyższymi adresami jest odbicie tej dolnej pamięci. Z tego co pamiętam to czytać można a co z zapisem to nie wiem i trzeba by tą sprawę wyjaśnić ( najlepiej na realnej maszynie ). Wykorzystując tą sztuczkę z odbiciem w sposób zamierzony bądź jako błąd programisty ( być może dzięki temu gra chodzi ) na maszynach z większą ilością CHIP będą kłopoty.
Tak jak już zostało wspomniane znajdzie się trochę produkcji ( głównie dema ), które na dzień dobry zakładają że wszyscy mają SLOW RAM i próbują załadować pod $c00000 dane. Są też dema, które próbują czytać z $c00000 i w ten sposób badają czy mamy SLOW RAM. Nie wiem co dokładnie się dzieje przy takich próbach ale podejrzewam, że nic dobrego.
Warto zapoznać się
http://www.memphisamigagroup.net/diskmags/199104-01/UseNetQuestions - wyjaśnione jest skąd się wział programik FastMemFirst.
Znajdzie się też parę gire/dem które zakładają że mamy tylko CHIP nawet w sposób nieświadomy ( sławny brak SECTION prg,CODE_C w przykładach do asemblera ). Sam byłem zdziwiony dlaczego duża cześć moich źródeł nie działa po kompilacji po przesiadce z a600 (2mb chip ) na a1200 z fastem. Starsze wersje asemblerów zawierały bład i mimo umieszczenia dyrektywy SECTION prg,CODE_C hunk był umieszczany w pamięci PUBLIC Warto sprawdzać czy hunk faktycznie będzie umieszczony w pamięci CHIP ( na aminecie są programy, które pokazują informację o tym. Na przykłąd HunkFunk )
Jeśli chodzi o błędy związane z adresowaniem to pozostaje jeszcze adresowanie 24 bitowe ( na maszynach z procesorem 68000 ). Na maszynach 32 bitowych gra/demo idzie w krzaki przy takich numerach. Niektórzy programiści by oszczędzić bądź też przyspieszyć produkcję umieszczali w rejestrach 32 bitowych adres 24 bitowy i pozostawało ekstra 8 bitów na coś. i przy wykonaniu jmp na takim adresie wszystko jest ok na 68000 ale już na 68020 nie.
Osobna kategoria to historie z kickami i skokami do romu. Normalnie przy wywołaniu funkcji z biblioteki ( exec, graphics, ... ) trzeba umieścić bazę tejże biblioteki w rejestrze a6. Ale w kick1.3 działa też jeśli bazę umieścimy w rejestrze a5. I dlatego Emerald Mine nie uruchamia się na kick 2.0+. Poza tym wielu autorów na twardo wpisywało bądź oczekiwało konkretnych wartości w rozmaitych strukturach ( mam na myśli strukturę opisująca okno systemowe na przykład) i dlatego Amiga Basic stworzony przez MS nie działa na kick2.0+ ( jak się nie mylę ). Wielu autorów próbując oszczędzić na długości kodu i zamiast normalnie otworzyć bibliotekę jak przykazano to pobierał adres biblioteki graficznej spod adresu wpisanego na sztywno ( co było prawdą tylko na maszynie, która miała tylko CHIP ). Skoki do romu czyli pod adresy $fc0000 i wyżej też pozwalały skrócić kod. W Emerald Mine obszar romu został wykorzystany do generowania losowej liczby ( sprytne i szybkie, nieprawdaż :) )
Wystarczy, jak coś nie jest jasne albo się gdzieś pomyliłem to proszę o sygnał.
Pozdrawiam