Tips & Tricks für Programmierer: Desktop-Panne, Malloc-Probleme
In der April-Ausgabe des ST-Magazins passierte uns eine kleine Panne: Keines der angekündigten Programme wurde abgedruckt [1]. Das ist um so ärgerlicher, als wir im Artikel auf Listings verweisen, die Sie als Leser gar nicht finden konnten. Dies möchten wir nun nachholen. Neben dem Assemblerlisting finden Sie außerdem eine neue, komfortablere Version in C, die sowohl als Programm als auch als Accessory läuft. Das GFA-Basic-Programm erhalten Sie auf unserer aktuellen Leserservicediskette.
Unser C-Programm ist nun auch in der Lage, Farbbildschirme zu invertieren und die korrekte neue Farbpalette ins Desktop-Info zurückschreiben. Dies war nicht ganz einfach, denn Atari verwendet für sein Kontrollfeld-Accessory eine recht eigenartige Formel zur Errechnung der Farbwerte. Es rechnet die im XBIOS-Format gespeicherten Farbwerte nämlich in VDI-Farben um. Diese unterscheiden sich von den XBIOS-Farben durch ihr Format. Das VDI verarbeitet exakt 1000 verschiedene Farbintensitäten. Da sich jede Mischfarbe auf einem Monitor aus einem Rot-, einem Grün- und einem Blauanteil zusammensetzt, verarbeitet das VDI insgesamt 10003, also eine Milliarde Farben. Der ST bringt auf seinen Monitor jedoch nur 83 Farben, also nicht mehr als 512. Beim STE sind es 163, 4096, Farben. Demzufolge muß das Programm die Hardwarefarben in passenden Verhältnissen in die VDI-Farben umrechnen. Beim Kontrollfeld-Accessory hat Atari sich dafür folgende Formel einfallen lassen:
VDI-Farbintensität = (Hardware-Farbintensität * max. VDI-Farben + 1/2 max. VDI-Farben)/Anzahl der Hardware-Farben
Was bedeutet diese Formel für die Praxis? Gesetzt den Fall, die Desktop-Info-Datei würde für eine Farbintensität den Wert sieben enthalten. Dann würde sich nach der obigen Formel der Wert
(7 * 1000 + 1/2 * 1000) / 8 = 937.5
ergeben. Dieser Wert würde das Kontrollfeld in der VDI-Funktion vs_color() als ein Farbwert verwenden. Obwohl die gewählte Hardware-Farbe den höchsten in der ST-Hardware überhaupt wählbaren Wert (nämlich sieben) enthält, ergibt sich für die eingestellte VDI-Farbe nach dieser Formel nicht etwa der höchst mögliche VDI-Wert (nämlich 1000), sondern eben nur 937.5. Genauer gesagt, ergibt sich nur 937, denn TOS rechnet ausschließlich mit Integers, und die sind bekanntlich ganzzahlig. Ähnliches ergibt sich beim Einsetzen der Intensität null (völlig dunkel):
(0 * 1000 + 500) / 8 = 500 / 8 = 62.5 (62)
Als VDI-Farbe wählt das Kontrollfeld-Accessory auch hier nicht den Extremwert null, sondern 62. Durch die Unfähigkeit des ST-Grafiksystems, mehr als acht Farbintensitäten darzustellen, ergibt sich für beides die gleiche tatsächliche Farbe.
Die Hardware des STEs ist in der Lage, doppelt so viele verschiedene Farbintensitäten zu produzieren. Ataris Kontrollfeld-Accessory spricht aber bislang nur die vom ST bekannten acht an. Sollte Atari jedoch ein neues Kontrollfeld-Accessory veröffentlichen, das alle Farbintensitäten des STEs anspricht, so müssen Sie unser Listing daran anpassen. Da der Inhalt der DESKTOP.INF-Datei bis heute undokumentiert ist, müssen wir uns hierbei auf Spekulationen verlassen. Wir vermuten, daß Atari Farbwerte von $0 bis $F verwenden und diese als ASCII-Zeichen »0« bis »F« ins Desktop-Info eintragen wird. Die Anpassung daran nehmen Sie vor, indem Sie den Inhalt der Variable »cols« von acht auf 16 erhöhen. Das Programm kann dies automatisch erledigen, wenn es TOS 1.6 erkennt. Ob Sie diese Erkennung wirklich verwenden, sei Ihrem Geschmack überlassen. Solange ein passendes solches Kontrollfeld nicht existiert, ist die Zeile unnötig. Sollte Atari das Kontrollfeld anpassen, übernehmen Sie die Zeile
if (version == 0x106) cols = 16;
ins Listing, die passende Stelle ist dort markiert.
Laurenz Prüßner
Malloc - Probleme
Die TOS-Speicherverwaltung war seit den ersten TOS-Versionen aus dem Jahre 1985 problembeladen: Da war zunächst einmal das 40-Ordner-Problem. GEMDOS legte für jeden einmal geöffneten Zugriffspfad einen internen Speicher an, um Datenzugriffe zu beschleunigen. Leider war es nicht in der Lage, diesen reservierten Speicher wieder freizugeben, so daß der Speicherüberlauf und Systemabsturz absehbar waren. Weiterhin standen für jeden laufenden Prozeß nur etwa 20 »Malloc«-Blöcke zur Verfügung, danach lehnte GEMDOS jede weitere Speicheranforderung rigoros ab. Nach fünf Jahren harter Entwicklungsarbeit und zwei fehlerhaften Programmversionen ist es Atari nun mittlerweile gelungen, die Fehler ab TOS 1.4 zu beseitigen.
Ein Problem stellt sich dem ST-Programmierer jedoch nach wie vor: Durch viele »Malloc (GEMDOS 72), » Mfree« (GEMDOS 73) oder »Mshrink« (GEMDOS 74) - Zyklen zerlegt TOS den freien Speicher mehr und mehr in kleine Bruchstücke, die an verschiedenen Stellen des Speichers liegen und nicht mehr einen zusammengehörigen Block bilden. Viele Programme erkundigen sich zu deren Start, wieviel Speicher Ihnen zur Verfügung steht. Dies erledigen Sie mit
Malloc(-1L);
Dabei sollten Sie als Programmierer jedoch nie aus den Augen verlieren, daß Sie durch diese Funktion ausschließlich die Länge des größten noch freien Speicherbereichs erhalten. Wenn Sie sich informieren wollen, wieviel Speicher Ihrem Programm insgesamt noch zur Verfügung steht, dann reservieren Sie mit
Malloc (Malloc(-1L));
den größten freien Speicherbereich und erkundigen sich hinterher, ob noch ein weiterer Speicherblock zu belegen ist. Dies führen Sie so lange fort, bis GEMDOS Ihnen mitteilt, daß definitiv kein Speichersegment mehr erhältlich ist, dann liefert die GEMDOS-Routine nämlich als Ergebnis 0 (kein Speicher mehr frei). Unser Programm demonstriert dies, indem es den gesamten freien Restspeicher errechnet und dessen Größe ausgibt.
Die angeforderten Speicherblöcke müssen Sie nicht unbedingt wieder freigeben, denn beim Aufrufen einer » Pterm« oder »Pterm0«-Funktion, gibt das GEMDOS grundsätzlich alle vom beendeten Programm belegten Speicherblöcke frei. Dennoch empfiehlt es sich, dem System immer etwas freien Restspeicher zu lassen, damit auch Accessories oder TOS selbst noch Speichersegmente anfordern kann. Atari empfiehlt, immer etwa 8 KByte unbelegt zu lassen, um den reibungslosen GEM-Betrieb zu garantieren.
Laurenz Prüßner