Ataquarium

Atari-Programmierer laufen Amok im Web! Der Baum brennt! Atari 520STF beißt Hund!

Zum Glück ging es etwas ruhiger in das Atari-Jahr, als die etwas reißerische Einleitung vermuten läßt. Dennoch konnte in den letzten Atemzügen des Jahres 2001 etwas beobachtet werden, was dann doch verblüffte: neue Atari-Portale. Die neuen Portale haben dabei gemein, das sie die Software-Entwicklung auf dem Atari fördern wollen. Praktisch gleichzeitig gingen "The Orphaned Projects Page" (TOPP) [1] und atari-source.com [2] online. Beide bemühen sich, eingestellte Programme als Open Source Entwicklern zugängig zu machen. Zum Glück fanden beide Seiten schnell zu einer Kooperation: atari-source.com wird sämtliche Open-Source-Bemühungen TOPP zur Verfügung stellen und sich eher auf die klassischen Web-Portal-Tugenden besinnen (News, Testberichte, Guides). Zumindest Anfang Januar sah atari-source.com noch etwas renovierungsbedürftig aus und war selbst in 1024*768 nicht vollständig darstellbar.

Etwas verwirrend war es wohl, als noch ein zweites "AtariSource" [3] entstand, das jedoch relativ schnell in AtariForge umbenannt wurde. AtariForge ist ein Service von Atari-Users.net und bietet Atari-Entwicklern u.a. 25 MB freien Webspace. Genutzt wird dieses Angebot bisher vom Highwire-Projekt und dem Falcon-Emulator TOS404.

TOPP of the Pops?

TOPP sucht Paten für verwaiste Atari-Projekte. Dazu zählen BubbleGEM, GEMJing, OLGA, Outside, Start Me Up!, qed, Everest und Infitra. Manche der Programme könnten zwar durchaus als "fertig" gelten, eine neue Version z.B. von GEMJing wäre aber sicherlich eine feine Sache. Kaum online, hat sich auch schon der erste Pate gefunden: Martin Elsässer (ACSpro) kümmert sich ab sofort liebevoll um das Stiefkind aus Thomas Muchs Standardfabrik: Keytab. Vielleicht wird es dann auch von mehr als nur drei Programmen unterstützt...

Ebenfalls Aussicht auf Weiterentwicklung gibt es für spareTIME. Es besteht sogar eine Möglichkeit, das der Source von Artis 4.0/Prism Paint II freigegeben wird. Im Untergrund laufen zudem Verhandlungen über andere Klassiker. Bei einigen Programmen (z.B. WinRec/WinCut) muss erst einmal der Source lokalisiert werden, ist jedoch definitiv nicht verloren.

Die Wunschliste von TOPP ist schon jetzt sehr lang und enthält einige sehr interessante Programme - nur Carrier Command wirkt etwas deplaziert...

Die Programme Everest und Infitra werden nicht mehr weiterentwickelt, aber deren Entwickler sind offen für Vorschläge.

Auch Nicht-Programmierer können TOPP helfen, indem sie Programmierer von "verwaisten" Programmen kontaktieren. Zur Recherche von Email-Adressen empfiehlt sich z.B. die Up-to-Date-Liste [4].

More than an OB_STATE

An dieser Stelle wird wieder einmal ein kleiner Eingriff in faceVALUE präsentiert. Mittlerweile haben sich in der TOS-Welt verschiedene "moderne" Bedienelemente fest etabliert. Neben Check- und Radiobuttons im Mac-Look sind die Frames ein wichtiges Mittel zur Strukturierung von Dialoginhalten. So ziemlich jede GEM-Library unterstützt sie und einige Programmierer basteln sich sogar ihre eigenen Frames - was dem Prinzip der System-Homogenität sicherlich widerspricht.

Mit faceVALUE wird ein Frame mit einem Button erstellt, der den erweiterten Objekttyp 18 hat. MagiC, TOS 4.08 und auch N.AES unterstützen Frames, benutzen jedoch die Statusflags. Da schlecht drei verschiedene Betriebssysteme an fV angepasst werden können, liegt es nahe, es mit dem umgekehrten Weg zu versuchen. Dadurch werden die Frames schon im Resource-Editor richtig gezeichnet - ganz ohne die Verwendung von Overlays. Natürlich unterstützt fV seit der Version 3 auch den MagiC-Look für Frames. Nicht verschwiegen werden soll auch die Mehrarbeit, denn es wollen mehr Statusflags gesetzt werden.

Um faceVALUE dem neuen Quasi-Standard anzunähern, müssen einige Zeilen in install_prg_def_objects eingefügt werden.

MagiC benutzt für die Darstellung von Frames das Whitebak-Flag sowie die OB_STATEs neun bis fünfzehn. Insgesamt muss also achtmal ein Kreuzchen im Resource-Editor gemacht werden, damit ein Frame erscheint. OB_STATE 12 wird zudem auch von den Numberscrollern benutzt, daher muss vor der entsprechenden IF-Abfrage angesetzt werden. Am Anfang der Prozedur wird in die Local-Liste die Variable flag_cnt¦ eingefügt. Diese Variable zählt die Anzahl der aktivierten OB_STATEs.

Vor der Zeile IF NOT @ob_state(tree&,b&,12) wird folgender Programmteil eingefügt:

IF BYTE(OB_TYPE(tree%,b&))=26
  SELECT BYTE(SHR&(OB_TYPE(tree%,b&),8))   !Frame
  CASE 0
    flag_cnt
=0
    FOR i
=9 TO 15
      IF BTST(OB_STATE(tree%,b&),i
)=TRUE
        INC flag_cnt
      ENDIF
    NEXT i
    SELECT flag_cnt
    CASE 7
      IF whitebak!
        @install_magic_obj(tree&,tree%,b&,-3,FALSE)
      ELSE
        @install_prg_def(tree%,b&,3)        !frame
      ENDIF
      CLR clear_flags!
    ENDSELECT
  ENDSELECT
ENDIF

Natürlich funktioniert das auch, wenn die MagiC-Frames nicht unterstützt werden - in diesem Fall wird die fV-interne Lösung installiert. Jetzt kann der erweiterte Objekttyp von Frames auf null gesetzt werden, der entsprechende Programmteil in der gleichen Prozedur (unter CASE 20) kann gelöscht werden. Nebenwirkungen mit Numberscrollern gab es zumindest im Test keine.

In der Resource können nun schon bei der Erstellung die Frames bewundert werden, was außerdem eine exaktere Objektpositionierung erlaubt. Einen Vergleich vorher-nachher gibt es in Bild 1. Oben ist die alte Darstellung in Interface zu sehen, unten die Darstellung mit den MagiC OB_STATEs.

Highwire to hell

Einen kleinen Nachtrag gibt es zu dem Open-Source-Browser Highwire. Dieser versteht sich nämlich mittlerweile als reine Browser-Engine. Das bedeutet, das Highwire zu einer Art Selbstbedienungsladen für Produkte wird, die auf HTML basieren. Denkbar wären ein vollständiger Web-Browser, Hilfssysteme oder ein Email-Programm mit HTML-Mail-Unterstützung. Letzteres will zumindest Mike De Petri in Angriff nehmen, da außer ihm eigentlich keiner so richtig Lust hat, für sein NOS zu entwickeln.

Neu in der "Highwire-Browser-Engine" sind GEMScript und VA_Start. Bis zum "CAB-Killer" ist es zwar noch weit, aber zumindest der ST-Guide könnte bald ausgedient haben.

Sourcewatch - BoinkOut

Wie schon in den letzten Ataquarien, möchte ich auch diesmal ein Open-Source-Programm unter die Lupe nehmen: BoinkOut [4]. BoinkOut ist ein Spiel mit einer langen Geschichte und kam immerhin auf den zweiten Platz beim MagiC Game Contest 1999. Das Programm ist durchaus nicht das einzige Breakout mit Quelltext, aber meines Wissens nach das einzige das im GEM-Fenster läuft.

Der BoinkOut-Source ist knapp 220 KB groß und kann sowohl für Atari-GEM als auch PC-GEM kompiliert werden. Das Sourcecode-Archiv enthält jedoch nicht die Leveldaten und XIMG-Bilder, deshalb sollte auch das Binary-Archiv heruntergeladen werden.

Die Spiellogik ist in den Dateien bout2, bout3 und bout4 enthalten. Alle Sound-Routinen stehen in bo_sound.c. Das Programm benutzt immer noch den Yamaha-Soundchip für Töne. Denkbar wäre hier eine Einbindung von GEMJing. External.c dient dem Ansprechen von externen Programmen. Dort steht momentan nur der Code zum Starten eines Web-Browsers. Extras.c ist die Datei, in die alles gestopft wird, was woanders nicht reinpasst: AES-Version, setzen eines Edit-Feldes und senden einer Nachricht an die Hauptschleife des Programms. Besonders interessant ist ximgload.c, in der sich XIMG-Laderoutinen befinden.

GEMScript in BoinkOut

Um in BoinkOut GS-Unterstützung nachzurüsten, sind gar nicht einmal so viele Änderungen notwendig. Falls ihnen die entsprechenden Programmzeilen bekannt vorkommen, so liegt das daran, das diese aus StartMeUp! entnommen wurden.

Im Hauptprogrammteil boinkout.c befindet sich relativ am Anfang ein kurzer #if OS_TOS-Teil. Dort können die entsprechenden Defines für GS eingefügt werden (Listing 1).

An einer beliebigen Stelle wird die Funktion doGSCommand eingefügt. Dieser Programmteil interpretiert die GEMScript-Kommandos (Listing 2).

Jetzt müssen die Routinen nur noch angesprochen werden. Die Funktionen, die AES-Nachrichten entgegennimmt heißt bei BoinkOut multi. Auch dort gibt es mehrere OS_TOS-Teile, damit BoinkOut auch auf dem PC kompiliert werden kann. In einem dieser Teile kann Listing 3 eingefügt werden. BoinkOut ist damit GEMScript-fähig. Zum Testen ist GSTest [5] von Richard-Gordon Faika sehr empfehlenswert. Mit dem kleinen TOS-Programm kann einem beliebigen Programm GS-Kommandos geschickt werden.

XIMG

Die XIMG-Laderoutinen sind so aufgebaut, das sie auch ohne dem Rest von BoinkOut nutzbar sind. Genutzt werden sie in BoinkOut für das Hintergrundbild des Spielfeldes und den Programminfodialog. Die Routinen unterstützen keine True Colour-XIMGs. Für den Titel im Infodialog wird eine Datenstruktur für das VDI definiert:

MFDB tit_buf = {0L,474,77,474/16,0,1,0,0,0};

Das Bild ist 474 Pixel breit und 77 Pixel hoch. Es liegen Bilder für verschiedene Farbtiefen vor, so das bei Bedarf die Plane-Zahl erhöht wird.

mfdb_buffersize = 2L*(long)tit_buf.fd_wdwidth*(long)tit_buf.fd_nplanes*(long)tit_buf.fd_h;

Geladen wird das Bild schließlich mit img_load(&tit_buf, titname). In dialogs.c wird das Bild in den Dialog einkopiert:

	objc_offset(about_dial,RTITLE,&x,&y);
	pxy[0] = pxy[1] = 0;
	pxy[2] = tit_buf.fd_w - 1;
	pxy[3] = tit_buf.fd_h - 1;
	pxy[4] = x;
	pxy[5] = y;
	pxy[6] = x + pxy[2];
	pxy[7] = y + pxy[3];
	vro_cpyfm(vdi_handle,S_ONLY,pxy,&tit_buf,&screen_fdb);

House of Coldfire

Zum Abschluß noch etwas über den geplanten Coldfire-Atari-Clone. Auf xtos.de wird derzeit eine Art "Atari-Anlagemodell" vorgestellt, um bspw. alte Sourcen "freizukaufen". Genaueres kann auf der xtos-Webseite nachgelesen werden, oder in dem entsprechenden Artikel in dieser Ausgabe.

Interessantes über den Coldfire-Prozessor gibt es im Web zu lesen. Einige denken, das der CF nur ein "halber" Prozessor sei, der eben nur im Embedded-Bereich seine Daseins-Berechtigung hat. Begeisterte Digital-Fotografen werden vielleicht wissen, das einige Kameras mit einer Coldfire-CPU ausgestattet sind. Auf diesen Kameras läuft Digita OS und für eben dieses Betriebssystem hat "xevious" einige Programme portiert: MAME, MESS und Doom. Statt zu fotografieren kann so z.B. M.U.L.E. auf der Digitalkamera gespielt werden. Immerhin ein gutes Beispiel das schon in der älteren Version des Coldfire Potential steckt [6].

Listings

Mia Jaap

Aus: ST-Computer 02 / 2002, Seite 28

Links