Das AES von MultiTOS und Falcon: Stichproben

Das AES des MultiTOS zeichnet sich gegenüber den bisherigen AES-Versionen durch eine ganze Reihe von Erweiterungen aus. Diese sind nicht ausschließlich an einer Multitasking-Umgebung orientiert, sondern auch unabhängig davon interessant. Daher wundert es nicht, daß auch das AES des Falcon030 bereits einige dieser neuen Funktionen unterstützt.

Überhaupt ähneln sich AES 4.0 (MultiTOS) und 3.31 bzw. 3.40 (Falcon) in vielen Punkten, was natürlich damit zusammenhängt, daß diese AES-Versionen quasi parallel zueinander entwickelt werden. Bereits von der Optik her macht sich das durch die Unterstützung dreidimensionaler Objekte bemerkbar. Aber auch hinter den Kulissen gibt es einige Übereinstimmungen. Grund genug, sich die gemeinsamen Aufrufe und darüber hinaus ein paar MultiTOS-spezifische AES-Funktionen näher anzusehen.

3D-Kuddelmuddel

Bleiben wir zunächst bei den 3D-Objekten. Das ursprüngliche Verfahren zur Realisierung dieser neuen Objekttypen, wie es beim Falcon bis TOS 4.01 (AES 3.31) vorhanden ist, stieß auf massive Proteste bei den Entwicklern und führte zu gewissen Inkompatibilitäten. Daher wurde ab TOS 4.02 (AES 3.40) kurzerhand eine Änderung vorgenommen, die sich auch im MultiTOS niederschlägt. Die nun gültige Spezifikation läßt sich der Entwicklerdokumentation entnehmen, die zum momentanen Zeitpunkt noch nicht in schriftlicher Form vorliegt. So gesehen sind alle Angaben zu diesem Thema als vorläufig und inoffiziell anzusehen, aber niemand wird ernsthaft erwarten, daß sich hier nochmals Änderungen ergeben. Schließlich sind die Lieferprobleme beim Falcon inzwischen überwunden und bereits einige tausend Maschinen im Umlauf. Selbst in Amerika sind schon die ersten Geräte gesichtet worden. (Übrigens handelt es sich bei der aktuellen TOS-Version des Falcon um TOS 4.04.)

Mit welcher AES-Version man es überhaupt zu tun hat, läßt sich nach dem Aufruf von appl_nit() wie üblich anhand von global[0] erfahren. Auch aus einem CPX-Modul heraus muß man appl_init() aufrufen, um eine Information über die AES-Versionsnummer zu erhalten.

Das AES 3.4 unterstützt zwei Typen von 3D-Buttons, nämlich Indikatoren und Aktivatoren. Hinzu kommt ein weiterer Objekttyp speziell für den Hintergrund von Dialogboxen im 3D-Look. Bei Indikatoren handelt es sich in der Regel um Buttons, die einen Status anzeigen, beispielsweise um Radio-Buttons. Aktivatoren sind für Buttons vorgesehen, mit denen man Dialoge verlassen oder sonstwie eine Aktion hervorrufen kann.

Die Auswahl des Objekttyps geschieht anhand zweier Bits im ob_flags-Feld, wobei folgende Zuordnung der neuen Objekt-Flags gilt:

#define FL3DNONE 0x0000 /* kein 3D-Effekt */
#define FL3DIND 0x0200 /* 3D-Indikator */ 
#define FL3DBAK 0x0400 /* 3D-Hintergrundobjekt */
#define FL3DACT 0x0600 /* 3D-Aktivator */

Es empfiehlt sich, in Dialogen mit 3D-Buttons das Root-Objekt mit dem FL3DBAK-Attribut zu versehen. Gleiches gilt für Eingabefelder und Textobjekte, denn nur so wird eine einheitliche Hintergrundfarbe erhalten. Einen Eindruck von der Wirkung der neuen Objekttypen sollte man sich dadurch verschaffen, daß man per Resource Construction Set einen einfachen Dialog entwirft und ein wenig mit den erweiterten Möglichkeit herumspielt. Da für den 3D-Effekt lediglich Bits in den Objekt-Flags manipuliert werden müssen, werden keine besonderen Anforderungen an das RCS gestellt.

Alles unter Kontrolle

Das Erscheinungsbild der dreidimensionalen Objekte läßt sich mit dem neuen Aufruf objc_sysvar() abfragen und auch beeinflussen. (Dazu gibt es inzwischen bereits ein CPX-Modul, das in diversen Boxen des Mausnetzes zu finden ist.) Diese Einstellungen gelten für alle Programme, die mit 3D-Objekten arbeiten. Konfigurieren lassen sich die Farben im selektierten und deselektierten Zustand sowie das Verhalten des Textes bei einem Mausklick. Je nach Einstellung bewegt sich der Text in das Objekt hinein, so daß es wirkt, als könne man einen Button regelrecht hineindrücken. Zunächst ein Blick auf den Prototyp von objc_sysvar():

WORD objc sysvar
(WORD ob_smode, WORD ob_swhich, WORD ob_sival1, WORD ob_sival2, WORD *ob_soval1, WORD *ob_soval2)

Für ob_swhich sind unterschiedliche Werte erlaubt:

#define LK3DIND 1 
#define LK3DACT 2 
#define INDBUTCOL 3 
#define ACTBUTCOL 4 
#define BACKGRCOL 5 
#define AD3DVALUE 6

Ist ob_smode gleich 0, entspricht objc_sysvar() einer reinen Abfragefunktion. Verändern läßt sich das Verhalten der 3D-Objekte, wenn ob_smode auf 1 gesetzt wird. Bei ob_sivall und ob_sival2 handelt es sich um Eingabeparameter, Ausgaben erfolgen in ob_soval1 und ob_soval2.

Im LK3DIND-Modus lassen sich diverse Attribute für Indikatoren beeinflussen. Für ob_smode = 0 liefert das AES in ob_soval1 eine 1 zurück, falls sich der Text beim Selektieren eines Objekts bewegt, andernfalls erhält man eine 0. Ob sich die Farbe eines Objekts beim Selektieren ändert, signalisiert ob_soval2. Setzt man ob_smode auf 1, erwartet objc_sysvar() in ob_sival1 sowie ob_sival2 Werte (also 0 oder 1), die das Verhalten der Objekte ändern. In der Standardeinstellung ist ob_sival1 = 1 und ob_sival2 = 0, d.h., die Texte bewegen sich beim Anklicken, es findet jedoch kein Wechsel der Farbe statt.

Der LK3DACT-Modus bestimmt auf die gleiche Weise das Verhalten der Aktivatoren. Hier liegt die umgekehrte Standardeinstellung vor. Beim Selektieren eines Aktivators wird also lediglich die Farbe gewechselt, einen 3D-Effekt (Bewegung des Textes) gibt es nicht.

Farbspielereien

In den Modi INDBUTCOL und ACTBUTCOL lassen sich die Farben für nicht selektierte Indikatoren bzw. Aktivatoren festlegen. Ist ob_smode=0, wird diese Farbe vom AES erfragt und in ob_soval1 abgelegt. Mit ob_smode = 1 läßt sich über ob_sival1 eine neue Farbe auswählen. Der BACKGRCOL-Modus übernimmt die gleichen Aufgaben für die Farbe des 3D-Hintergrundes. AD3DVALUE schließlich ist ein reiner Abfragemodus (ob_smode = 0!) und liefert die Zahl der Pixel, um die 3D-Buttons nach jeder Seite hin vergrößert werden, damit ein 3D-Effekt erzielt wird. Bei der Abfrage dieser Werte erhält ob_soval1 die Zahl der Pixel in horizontaler, ob_soval2 die Zahl der Pixel in vertikaler Richtung. Diese Angaben sollte man beispielsweise dann berücksichtigen, wenn Buttons nahe beieinander plaziert werden sollen. Hier empfiehlt sich ein gewisser Mindestabstand, damit es beim Selektieren nicht zur Überlappung durch die Vergrößerung der Buttons im Rahmen des 3D-Effektes kommt.

Die Benutzung von objc_sysvar() sollte nur innerhalb residenter Programme erfolgen, die es dem Benutzer erlauben, globale Einstellungen nach seinem Geschmack vorzunehmen. Innerhalb anderer Applikationen hat man auf das Setzen von Parametern mit objc_sysvar() zu verzichten, denn schließlich wirken sich Änderungen nicht nur auf das aktive Programm, sondern auch auf alle anderen Anwendungen aus. Daher kommen eigentlich nur Accessories oder CPX-Module für Programme in Frage, die objc_sysvar() benutzen.

Leider unterstützt es objc_sysvar() bisher nicht, den 3D Effekt komplett abzuschalten. Dies würde dazu führen, daß die neuen Objekttypen wie die „normalen“ Buttons der bisherigen AES-Versionen erscheinen. Der neue 3D-Look ist schließlich nicht jedermanns Sache.

Informationsbedarf

Bereits in [1] wurde kurz auf den Aufruf appl_getinfo() eingegangen, mit dem sich eine Reihe systemspezifischer, für das AES relevante Parameter erfragen lassen. appl_getinfo() steht bisher nur unter Multi-TOS, also ab AES 4.0, zur Verfügung. Der Prototyp von appl_getinfo() lautet:

WORD appl_getinfo
(WORD ap_gtype, *WORD ap_gout1,*WORD ap_gout2, *WORD ap_gout3, WORD *ap_gout4)

Je nach gewünschter Information kann ap_gtype unterschiedliche Werte annehmen. Für ap_gtype = 0 erhält man Angaben über den Standardsystem-Font:

ap_gout1: Font-Höhe
ap_gout2: Font-ID
ap_gout3: Font-Typ (0 = System, 1 = FSM)

Ist ap_gtype = 1, erhält man entsprechende Informationen über den kleinen AES-Font (beispielsweise 6x6 System-Font).

Aussagen über die aktuelle Auflösung und die Farbunterstützung liefert ein Aufruf von appl_getinfo() mit ap_gtype = 2:

ap_gout1: Auflösung, in der das AES momentan arbeitet
ap_gout2: Zahl der Farben, die von der AES-Objektbibliothek unterstützt werden
ap_gout3: 1, wenn Farb-Icons unterstützt werden, sonst 0
ap_gout4: 1, wenn das neue Format für RSC-Dateien (im Zusammenhang mit den Farb-Icons) unterstützt wird, sonst 0

Die Sprache des AES in ap_gout1 erhält man mit ap_type = 3. Dabei gilt die übliche Codierung:

0: Englisch
1: Deutsch
2: reserviert
3: Französisch
4: Spanisch
5: Italienisch
6: Schwedisch (bislang nicht unterstützt)

Was die Unterstützung mehrerer Sprachen auf Desktop-Ebene angeht, so unterstützen manche Versionen des MultiTOS-Desktop aus Platzgründen nur eine einzige Sprache. Es ist nicht auszuschließend, daß MultiTOS in Zukunft externe Resource-Dateien besitzt und je nach gewünschter Sprache die entsprechende Datei nachlädt. Auf dem Falcon unterstützt das AES 3.4 im ROM weiterhin mehrere Sprachen.

Wer suchet, der findet

Bisher war ein Nebeneinander mehrerer Programme beim ATARI nur eingeschränkt möglich. Eine gewisse Form des Multitasking war allerdings schon immer in Form der Accessories vorhanden, die sich aus jedem sauberen GEM-Programm heraus aufrufen lassen. Über den AES-Aufruf appl_find() läßt sich bei den bisherigen AES-Versionen feststellen, ob sich eine Anwendung bestimmten Namens im Speicher befindet. So kann eine Applikation beispielsweise ermitteln, ob ein bestimmtes Accessory installiert ist. In der umgekehrten Richtung konnte die Verwendung von appl_find() bisher allerdings fehlschlagen. Versucht man nämlich, aus einem Accessory heraus mittels appl_find() auf die Anwesenheit einer bestimmten Hauptapplikation zu schließen, so erhält man auch für den Fall eine positive Rückmeldung, daß diese Applikation schon wieder verlassen wurde und das Desktop bereits die Kontrolle zurückerlangt hat.

Unter MultiTOS können mehrere GEM-Programme koexistieren, wobei die Unterscheidung zwischen Accessories und anderen grafischen Applikationen an Bedeutung verliert, appl_find liefert hier endlich fehlerfreie Angaben zurück. Dar-über hinaus wurde ab AES 4.0 mit appl_search() ein neuer Aufruf eingeführt, der appl_find() zwar stark ähnelt, aber erweiterte Möglichkeiten bietet, appl_find() erlaubt es, gezielt nach einem bestimmten Anwendungstyp zu suchen. Darüber hinaus kann mittels appl_search() festgestellt werden, ob sich ein bestimmter AES-Prozeß mehrfach im Speicher befindet. Es ist schließlich nicht auszuschließen, daß ein Anwender sein Lieblingsprogramm gleich mehrmals gestartet hat.

WORD appl_search
(WORD ap_smode, CHAR *ap_sname, WORD *ap_stype, WORD *ap_sid)

Die Parameter für appl_search() sind vergleichbar mit denen für die GEMDOS-Funktionen Fsfirst() und Fsnext(). So gibt ap_smode den Suchmodus an:

0: Ersten AES-Prozeß suchen, auf den der vorgegebene Name paßt.
1: Nächsten AES-Prozeß suchen
2: Liefert den Namen der System-Shell, z.B. „NEWDESK“

Wie der Name des Prozesses lautet, nach dem gesucht werden soll, wird über ap_sname spezifiziert. Hierbei handelt es sich um einen Pointer auf einen nullterminierten String mit 8 Zeichen, in der Regel um einen Dateinamen ohne Extension. Ist der Name kürzer als 8 Zeichen, muß er mit Leerzeichen aufgefüllt werden. Dies ist übrigens auch für appl_find() der Fall. ap_stype schließlich enthält Vorgaben über die Art des zu suchenden AES-Prozesses:

1: Systemprozeß
2: Applikation
4: Accessory

Nach dem Aufruf von appl_search() enthält ap_sid die AES-ID des gewünschten Prozesses. Vor der Auswertung von ap_sid ist natürlich zu prüfen, ob überhaupt ein Prozeß mit dem vorgegebenen Namen gefunden wurde. Ist dies der Fall, enthält ap_sreturn eine 1, andernfalls eine 0.

Nachrichtenverteilung

Unter MultiTOS ist die Verwendung von appl_search() in jedem Fall appl_find() vorzuziehen. Schickt man beispielsweise mit appl_write() eine Nachricht an einen anderen AES-Prozeß, muß man dabei im Hinterkopf haben, daß sich dieser unter Umständen in mehrfacher Ausführung im Speicher befindet. Ein einfaches appl_find() reicht in solchen Fällen nicht aus, da man durch diesen Aufruf lediglich einen

einzigen dieser vom Namen her identischen Prozesse ausfindig machen kann. Nur mit appl_search() kann man sicherstellen, daß alle Prozesse gleichen Namens gefunden werden. Listing 1 zeigt an einem Beispiel, wie man es mit appl_search() realisieren kann, eine selbstdefinierte Nachricht an alle Applikationen mit dem Namen „TEST“ zu schicken. Das Versenden der Message wird dabei von einer Funktion send_message() übernommen, der lediglich die jeweiligen Prozeß-IDs übergeben werden.

Wichtig ist natürlich die Überprüfung der AES-Versionsnummer vor der eigentlichen Aktion. Wird kein Multitasking unterstützt, muß appl_find() statt appl_search() verwendet werden. Mag!X arbeitet übrigens bisher mit einem eigenen Verfahren, um die Funktion von APPL_SEARCH nachzubilden.

Noch ein Hinweise zu appl_find(): Dieser Aufruf ist im MultiTOS in seiner Funktionalität insofern erweitert worden, als daß er Umrechnungen zwischen der AES-ID und der MiNT-ID eines Prozesses vornehmen kann. Enthält das high word von ap_fpname den Wert -1, erwartet appl_find() im low word von ap_fname die MiNT-ID einer Applikation und liefert nach dem Aufruf die AES-ID dieses Prozesses zurück. Wird im high word -2 übergeben, erfolgt nach dem gleichen Schema eine Umrechnung der AES-ID in die MiNT-ID. Schließlich kann es sich bei ap_fname auch um einen Null-Pointer handeln. In diesem Fall enthält ap_fid nach dem Aufruf von appl_find() die AES-Prozeßnummer der gerade aktiven Applikation.

Das Lesen von Mitteilungen

Ergänzt wurden beim AES 4.0 des MultiTOS die Möglichkeiten von app_read(). Bisher diente dieser Aufruf dazu, Nachrichten aus der Message Pipe eines Prozesses (in der/Regel des eigenen) auszulesen. Lag keine Nachricht vor, wartete appl_read() bis zum Eintreffen einer solchen. Unter AES 4.0 kehrt appl_read() auf Wunsch sofort wieder in das aufrufende Programm zurück, falls keine Nachricht vorhanden ist. So läßt sich ein periodisches Abfragen auf eventuelle Events weniger aufwendig als bisher realisieren. Die evnt-Funktionen erlauben es nämlich nicht ohne weiteres, lediglich auf das Vorhandensein einer Nachricht zu prüfen, ohne einen Prozeß gleich in den Wartezustand zu schicken. Um über das AES lediglich eine Tastaturabfrage durchzuführen, war es somit bisher notwendig, einen evnt_multi()-Aufruf mit gesetzten MU_KEYBD-und MU_TIMER-Flags bei einer kurzen Wartezeit (eventuell auch 0 ms) einzusetzen. Nur so konnte sichergestellt werden, daß, falls zwischenzeitlich kein Tastendruck erfolgte, trotzdem sofort ins Hauptprogramm zurückgekehrt wurde.

appl_read() stellt unter MultiTOS die elegantere Lösung dar, nicht zuletzt deshalb, weil dieser Aufruf verglichen mit evnt_multi() weniger Prozessorzeit verbraucht. Dies trifft insbesondere für Programme zu, die in einer höheren Programmiersprache geschrieben sind. evnt_multi() besitzt nämlich insgesamt 16 Eingabeparameter, die zunächst vom Anwenderprogramm auf den Stack gelegt und dann vor dem eigentlichen AES-Aufruf auf das intin-Array verteilt werden. appl_read() dagegen kommt mir nur 3 Parametern aus. Um unter MultiTOS mit appl_read() eine Abfragefunktion zu realisieren, wird für Prozeßnnumer ap_rid -1 übergeben. Dies besagt, daß auch dann sofort zum Hauptprogramm zurückgekehrt werden soll, wenn keine Nachricht für das eigene Programm vorliegt. appl_read() liest eine Nachricht übrigens destruktiv, eine Message wird also nach dem Auslesen aus der Message Pipe entfernt. Damit keine Nachrichten verlorengehen, ist es demnach notwendig, die gelesene Nachricht so auszuwerten, wie es auch nach einem evnt_multi()-Aufruf geschieht.

Integrierte Ressourcen

Schon seit geraumer Zeit zeichnet sich die Tendenz ab, Ressourcen nicht in Form externer RSC-Dateien nachzuladen, sondern im jeweiligen Programm zu integrieren. Dies brachte es allerdings für den Programmierer mit sich, daß die Ausmaße jedes Objekts mittels rsrc_obfix() einzeln auf die aktuelle Bildschirmauflösung umgerechnet werden mußten. Ein neuer Aufruf mit der Bezeichnung rsrc_rcfix() erleichtert ab AES 4.0 diese Prozedur.

WORD rsrc_rcfix (void *rc_header);

rsrc_rcfix() erwartet im Speicher Resource-Daten in genau dem Format, wie es eine externe RSC-Datei besitzt. Anstatt eine solche Datei mit rsrc_load() nachträglich zu laden, können die entsprechenden Daten mit rsrc_rcfix() aufbereitet werden, sofern sie sich schon im Speicher befinden. Dabei ist allerdings, wie schon bei rsrc_load(), nur eine einzige Resource-Datei erlaubt. Vor dem Programmende muß rsrc_free() aufgerufen werden.

Offenbar liefert rsrc_rcfix() stets einen Rückgabewert von 1 zurück, so daß keine Möglichkeit besteht, einen eventuellen Fehler zu erkennen und darauf zu reagieren . Ein Fehler könnte beispielsweise dann auftreten, wenn mehr als ein Resource-Datensatz mit rsrc_rcfix() umgerechnet werden soll, ohne daß in der Zwischenzeit rsrc_free() aufgerufen wurde.

Handarbeit

Es ist nicht auszuschließen, daß die neuen AES-Aufrufe noch nicht von den Libraries aller C-Compiler für den ATARI unterstützt werden. Daher an dieser Stelle eine Auflistung der Parameter, die in den AES-Arrays übergeben werden müssen, falls man den Aufruf „per Hand“ oder aus der Assembler-Ebene heraus erledigen muß:

APPL SEARCH:
control[0] = 18
control[1] = 1
control[2] = 3
control[3] = 1
control[4] = 0

intin[0] = ap_smode

intout[0] = ap_sreturn
intout[1] = ap_stype
intout[2] = ap_sid

addrin[0] = ap_sname

OBJC_SYSVAR:
control[0] = 48
control[1] = 4
control[2] = 3
control[3] = 0
control[4] = 0

intin[0] = ob_smode
intin[1] = ob_swhich
intin[2] = ob_sival1
intin[3] = ob_sival2

intout[0] = ob_sreturn
intout[1] = ob_soval1
intout[2] = ob_soval2

RSRC_RCFIX:
control[0] = 115
control[1] = 0
control[2] = 1
control[3] = 1
control[4] = 0

intout[0] = rc_return

addrin[0] = rc_header

APPL_GETINFO:
control[0] = 130
control[1] = 1
control[2] = 5
control[3] = 0
control[4] = 0

intin[0] = ap_gtype

intout[0] = ap_greturn
intout[1] = ap_gout1
intout[2] = ap_gout2
intout[3] = ap_gout3
intout[4] = ap_gout4

Wie bei AES-Routinen üblich, sind die Rückgabewerte in intout[0] nach dem Aufruf Null, sofern ein Fehler aufgetreten ist.

/* ersten Prozeß suchen */ 

    ap_smode = 0;

    if (_GemParBlk.global[0] < 0x0400)
    if ((ap_id = appl_find("TEST    ")) >= 0)
        send_message(ap_id);

    if (_GemParBlk.global[0] >= 0x0400) {
    while (appl_search(ap_smode, "TEST    ", &ap_stype,&ap_id)) {
    if (ap_stype == 2) send_message{ap_id);

/* Moduswort für nächsten Prozeß */

    ap_smode = 1;
    }
    }

Die Anwendung von appl_search()

Blick aus dem Fenster

Bereits das AES 3.30 von MegaSTE und TT brachte eine Reihe von neuen Modi mit sich, die die Fensterverwaltung betreffen. Im AES 3.31 sind zwei weitere wind_set()-bzw. wind_get()-Modi hinzugekommen:

#define WF_BEVENT 24
#define WF_BOTTOM 25

WF_BEVENT erlaubt es, die übliche WM_TOPPED-Nachricht, die das AES beim Anklicken des Arbeitsbereiches eines Fensters mit der linken Maustaste verschickt, zu unterdrücken. Stattdessen erhält die Applikation lediglich eine Nachricht darüber, daß ein Mausknopf betätigt wurde. wi_sw1 stellt unter WF_BEVENT einen Bit-Vektor dar, von dem bisher lediglich Bit 0 eine Bedeutung hat. Andere Werte für wi_sw1 als 1 sind momentan also nicht erlaubt. Um WM_TOPPED-Messages für ein bestimmtes Fenster zu verhindern, ruft man wind_set() folgendermaßen auf:

wind_set
(wi_handle, WF_BEVENT, 0x0001,0, 0, 0);

Mit WF_BEVENT ist es beispielsweise möglich, Dauerfunktionen der linken Maustaste in nicht getoppten Fenstern zu realisieren. Bisher war dies nicht denkbar, da das AES in diesem Fall eine WM_TOPPED-Nachricht verschickte, und dies auch erst dann, wenn die Maustaste wieder losgelassen wurde.

WF_BEVENT läßt sich auch bei einem Aufruf von wind_get() einsetzen, um den entsprechenden Status zu erfragen.

Um ein Fenster in den Hintergrund zu legen, läßt sich ein wind_set()-Aufruf mit WF_BOTTOM verwenden:

wind_set
(wi_handle, WF_BOTTOM, 0, 0, 0, 0);

sorgt dafür, daß das Fenster mit dem Handle wi_handle zum untersten Fenster wird. Sofern nur ein einziges Fenster geöffnet ist, passiert natürlich nichts.

Auch WF_BOTTOM kann mit wind_get() kombiniert werden. Auf diesem Weg läßt sich das Handle des untersten Fensters in Erfahrung bringen.

Neuerungen massenhaft

Die Erweiterungen im neuen AES sind gerade beim MultiTOS sehr umfangreich, so daß es kaum möglich ist, diese im Rahmen einer Zeitschrift wie der ST Computer in kurzer Zeit erschöpfend zu behandeln. Hinzu kommt der Umstand, daß im Rahmen der Weiterentwicklung des MultiTOS mit weiteren Neuerungen zu rechnen ist. In den kommenden Ausgaben werden wir in loser Folge näher auf einige interessante Aspekte des MultiTOS-AES eingehen. Offizielle Dokumentationen zur Hardware und zum TOS des Falcon sollen laut ATARI gegen einen Kostenbeitrag auch für Nichtentwickler verfügbar gemacht werden. Das wäre ein Schritt in die richtige Richtung, denn so ließe sich eine breite Basis für die Soft- und Hardware-Entwicklung auf dem Falcon schaffen.

Es bleibt zu hoffen, daß die Funktionalität des AES 3.4 demnächst auch in Form von ROMs für den TT zur Verfügung stehen wird. Im Gegensatz zum MegaSTE mit nur 256 KB ROM lassen die 512 KB ROM des TT genügend Freiraum zu diesem Schritt.

US

Literatur:

[1] Uwe Seimet: „Welche Sprache hätten ‘s denn gern?“ ST-Computer 6/93

Uwe Seimet

---

---