Dodatek A

Płyta główna komputera ATARI 800XL.
Po lewej stronie widoczne kości pamięci RAM.

Wykorzystanie pamięci w komputerze domowym Atari może być trudne. Większość pamięci jest zarządzane przez system operacyjny, wewnętrzny kartridż lub DOS, zostawiając bardzo niewiele pod bezpośrednią kontrolą programisty. Daje to programiście bardzo mało swobody przy układaniu planu wykorzystania pamięci w programie. Przy odpowiednim planowaniu nie musi to stanowić poważnego problemu.

STRONA ZEROWA

Najważniejszą pamięcią RAM dla każdego programisty w języku asemblera jest strona zerowa. Jest ona absolutnie istotna dla wskaźników i staje się bardzo użyteczna do przechowywania często używanych zmiennych, ponieważ kod napisany dla zmiennych ze strony zerowej jest bardziej zwarty i wykonuje się szybciej. Stąd programista w języku asemblera pragnie wiedzieć, ile komórek strony zerowej może wykraść na własny użytek. Ten dodatek nie pokryje używania komórek strony zerowej zdefiniowanych i używanych przez oprogramowanie firmowe. Zamiast tego zajmuje się on ich użyciem, gdy oprogramowanie firmowe jest wyłączone lub ignorowane.

Dolna połowa strony zerowej (adresy $00-$80) jest zarezerwowana na użytek systemu operacyjnego. Te 128 bajtów jest niezbędnych dla całego szeregu usług, które udostępnia system operacyjny. Większość programów będzie używało tylko pewną część tych usług. Stąd wiele komórek w tym obszarze nie będzie używanych przez system operacyjny podczas wykonywania programu. Szczególnie 43 bajty od adresu $50 do $7A jest używane tylko przez edytor ekranowy i sterownik ekranu. Większość programów będzie używać własnych list wyświetlania wraz ze swoimi własnymi sterownikami ekranu. Wtedy te 43 bajty stałyby się dostępne podczas wykonania programu. Podobne rozumowanie zastosowane dla innych komórek przeznaczonych dla funkcji specjalnych zwolniłoby nawet więcej komórek.

Niestety, w tym rozumowaniu tkwi główny błąd. Departament oprogramowania w firmie Atari ciągle dokonuje ewaluacji wydajności systemu operacyjnego i robi zmiany w kodzie. Obecnie występują dwa uiaktualnienia systemu operacyjnego — Rev A i Rev B. Funkcjonalnie są prawie identyczne; oprogramowanie pracujące pod Rev A prawie na pewno uruchomi się pod Rev B. Planowane jest więcej uaktualnień i jest wysoce prawdopodobne, iż niepełne wykorzystanie tych 43 bajtów zostanie poprawione w przyszłych wydaniach systemu operacyjnego.  Stąd każdy pakiet oprogramowania, który podkrada te 43 bajty lub jakiekolwiek inne z dolnej połowy strony zerowej, prawdopodobnie nie będzie poprawnie pracował, jesli zostanie uruchomiony pod przyszłym systemem operacyjnym. Dlatego oprogramowanie komercyjne nie powinno wykradać żadnych bajtów z dolnej połowy zerowej strony pamięci.

Wolnych bajtów programista musi szukać w górnej połowie strony zerowej. Te 128 bajtów jest zarezerwowane do użytku przez kartridż. Jeśli w komputerze nie został włożony żaden kartridż, to są one wolne. Jeśli w gnieździe jest włożony kartridż, to niektóre bajty są zarezerwowane dla programisty. Kartridż języka BASIC zostawia wolne tylko 7 bajtów na użytek programisty — od $CB do $D1. Programista potrzebujący na stronie zerowej więcej komórek ma tylko jedną opcję: bajty używane przez pakiet zmiennoprzecinkowy (od $D4 do $FF). Te 44 bajty można zabrać, jeśli pakiet zmiennoprzecinkowy nie jest używany przez procedury programisty. Programista nie posiada nieograniczonego używania tych bajtów; nie powinny być one używane przez żadną procedurę przerwań, ponieważ taka procedura może zaatakować podczas wykonywania operacji zmiennoprzecinkowej wywołanej przez BASIC. W górnej części strony zerowej nie ma żadnych innych bajtów, których może używać programista.

Programista pracujący w środowisku języka BASIC rzadko jest zainteresowany wysokimi osiągami i zwartością oferowanymi przez stronę zerową; przecież, jeśli szybkość i zwartość byłyby głównymi zmartwieniami, to programista nie wybrałby języka BASIC dla swojego kodu. Programistą najbardziej zainteresowanym dużymi obszarami strony zerowej jest programista w języku asemblera. Czysty program asemblerowy nie potrzebuje żadnego kartridża do swojej pracy; stąd powinien mieć dostęp do wszystkich 128 bajtów górnej połowy strony zerowej. W praktyce nie jest to tak proste, ponieważ program asemblerowy musi być debugowany, a obecnie jedynym wygodnym sposobem wykonania tego zadania jest wykorzystanie debugera z kartridża Atari Assembler-Editor cartridge. Programiści asemblerowi ze zmartwieniem zauważą, iż kartridż ten rezerwuje na ich użytek tylko 32 bajty. Chociaż jest to zupełnie wystarczające dla większości programów, to jednak nie zaspokaja apetytu programu o wysokiej wydajności. Jest jeszcze 30 bajtów więcej, które nie są używane przez program debugera w kartridżu. Są to komórki o adresach: $A4, $A5, $AD, $AE, od $DB do $E5, od $EA do $F1, $F5, $F6, od $F9 do $FB, $FE i $FF. Jeśli komórki te są wykorzystywane w programie, to programista nie powinien wracać do Edytora lub do Asemblera, gdyż inaczej mogą zdarzyć się złe rzeczy. Co więcej, nie może być używany miniasembler wewnątrz debugera.

Jeśli używasz innych kartridży lub języków opartych na dyskach, to musisz radzić sobie sam. Wiele z tych systemów używa nawet jeszcze więcej strony zerowej.

ABSOLUTNA PAMIĘĆ RAM

Inny problem, z którym mierzy się programista, przedstawia DOS. Bardzo pożądane jest pisanie programów, które pracują w 16 KB systemach kasetowych lub w 48 KB systemach dyskowych. Niestety, takie systemy mają mało wolnej pamięci, ponieważ DOS i DUP prawie całkowicie zapełnią pamięć RAM w systemie 16 KB. Istnieje kilka rozwiązań tego problemu. Jednym z nich jest utworzenie różnych wersji kodu, wersji dyskowej i wersji kasetowej. Te dwa programy będą ładowane pod różne adresy. Oznacza to, iż nabywcy wersji kasetowej nie będą w stanie przenieść jej na dyskietkę, jeśli później wyposażą swój komputer w stację dysków.

Jest inny sposób. Strona szósta jest wolną pamięcią RAM dla wszystkich systemów. Zmienne i wektory można umieszczać na stronie szóstej i używać w oprogramowaniu opartym na kasecie i na dysku. Katalog adresów procedur można wyliczyć i umieścić w czasie pracy programu na stronie szóstej. Procedury w języku maszynowym mogą następnie skakać poprzez katalog na stronie szóstej do procedur w innych miejscach pamięci RAM. Ta technika może być trudna do wykonania; nie zaleca się jej dla dużych projektów w języku asemblera. Najbardziej wartościowa jest dla dla średniej wielkości procedur asemblerowych (około 1KB-2KB) osadzonych wewnątrz programów w języku BASIC.