Sprich mit mir - Der Atari STE lernt sprechen

Es war einmal ein Atari-User, der setzte sich an einen Macintosh - dort geschah Wundersames! Zu Aktionen auf dem Bildschirm ertönten die unterschiedlichsten Geräusche. Dem Atari-User gefiel dieses wohl, allein sein Atari konnte solches nicht. Dabei besaß sein STE doch diesen gar prächtigen DMA-Sound. Nun denn, da wer Abhilfe zu schaffen!

Die erwähnte Fähigkeit des Apple Macintosh geht auf ein Programm zurück, das klassische Funktionen wie Fenster öffnen/schließen, Tastaturklick oder das Zeichnen von Dialogboxen überwacht und zu jeder Aktion ein kleines Sample spielt. Wie läßt sich dieses Programm nun auf einem ST realisieren?

DMA bringt‘s

Für die Besitzer von Rechnern mit DMA-Sound-Hardware (STE/TT) ist die Lösung dieses Problems auf der TOS-Diskette enthalten. Im Archiv »GEMSOUND« finden Sie das Programm »GEMSOUND.PRG« für Ihren AUTO-Ordner und das CPXModul »SND_CPX.CPX«, weiches zu den anderen CPX-Modulen gehört. Den Ordner »SAMPLES« kopieren Sie in das Wurzelverzeichnis ihrer Boot-Partition/Diskette. Nun noch neu booten und ihr STE/TT zeigt sich nunmehr von der geschwätzigen Sorte. Wenn Sie allerdings mit dem originalen Desktop arbeiten, werden Sie noch nicht viel von den gesampelten Tönen hören. Erst nach dem Start eines GEMProgrammes (z.B. 1st Word) kommt der volle Genuß. Das Programm »GEMSOUND.PRG« klinkt sich über XBRA in den AES/VDI-Trap ein und lauert dort auf AES-Aufrufe. Kommt ein AES-Aufruf, für den ein Geräusch definiert ist, wird das betreffende Sample gespielt. Dank der DMA-Sound-Hardware geschieht dies ohne merklichen Rechenzeitverlust. Da der originale Desktop die AES-Aufrufe leider nicht über den TRAP-Handler tätigt, sondern die Routinen direkt anspringt, sind die Geräuschuntermalungen nur in einem gestarteten GEM-Programm zu hören. Besitzer von alternativen Desktops (Gemini, Neodesk, Ease usw.) sind wieder einmal im Vorteil. Der geänderte Tastaturklick und der System-Beep sind auch im Desktop sowie in TOS-Programmen zu hören, da ab TOS 1.04 hierfür spezielle Vektoren vorhanden sind.

»GEMSOUND.PRG« besteht aus drei Modulen: In »COOKIE.C« sind zwei Routinen zur Verwaltung des Cookie Jar enthalten. »get_cookie()« erfragt den Wert eines Cookies, »make_cookie()« legt ein neues Cookie an. Hier ist zu beachten, daß make-cookie bereits einen installierten Cookie Jar benötigt.

In »SOUND_AS.S« verstecken sich die Assemblerroutinen. Zum Verbiegen der Vektoren dienen »set_gem« und »set_click«. Nach erfolgreichem Verbiegen zeigt der Vektor für den Tastaturklick auf »new_click«, der System Beep zeigt auf »new_beep« und TRAP 2 (AES/VDI) läuft ab sofort über »new_gem«. Diese drei Zwischenstationen fangen die durchkommenden Ereignisse ab und prüfen sie auf Verwertbarkeit. Ist diese gegeben, startet »do_it()« (in main()). Anschließend wird noch je nach Bedarf die Originalroutine aufgerufen.

Der eigentliche Krachmacher ist »start_sound«. Diese Funktion erhält im Register a0 die Anfangs- und in a1 die End-Adresse eines Samples. Im Register d0 entscheidet ein Flag, ob ein Sound durch einen anderen abgewürgt wird oder nicht. Diese Verteilung der Übergabeparameter erlaubt es, die Funktion direkt aus dem C-Teil aufzurufen: »void start_sound (char *anfang, char *ende, int reset)«. Wichtig: Diese Eigenschaft gilt nur für Pure/Turbo C, andere Compiler übergeben die Parameter auch gerne über den Stack.

Der Beginn des Samples landet im Frame-Start-Register ($FF8902-$FF8906). Das Ende des Samples wandert in das Frame-Ende-Register ($FF890E-$FF8912). Das Sound-Mode-Register ($FF8920) wird mit 1 (Mono, 12.5 kHz) geladen und das Ganze durch Beschreiben des Sound-DMA-Registers ($FF8900) mit 1 (DMA-Sound ein) gestartet. Ebenfalls wichtig: Diese Funktion darf nur im Supervisormodus aufgerufen werden.

Es bleibt nun noch der Main-Teil »GEMSOUND.C« übrig. Zunächst prüft das Programm mittels des Cookie Jar auf die An- bzw. Abwesenheit der DMA-Sound-Hardware sowie von GEMSOUND.PRG. Sind beide Tests zur Zufriedenheit ausgefallen, werden die Samples mit load_sample() geladen. Nun wird die C_SOUNDS-Struktur mit sinnvollen Werten gefüllt und mit make_cookie() unser Cookie »GSND« angelegt. Ist auch dieser Vorgang erfolgreich abgeschlossen, verbiegen wir die Vektoren für den Tastaturklick sowie System-Beep auf unsere Routinen und verankern das Programm mit Ptermres() im Speicher. Die Funktionen do_it() und play_it() kommen erst bei der Sample-Ausgabe zum Einsatz. Mit do_it() wird in der C_SOUNDS-Struktur anhand der AES-Nr. nach einem Sample gefahndet. Wurde do_it() fündig, startet play_it() die Geräuschbelästigung.

Das CPX-Modul

Treuen Lesern des TOS-Magazins wird bereits das vermehrte Aufkommen von CPX-Modulen aufgefallen sein. Wer den CPX-Kurs des gleichen Autors verfolgt hat, wird auch mit dem Quelltext zu diesem Modul zurechtkommen.

Während der Bootphase installiert »SND_CPX.CPX« die Abspielroutinen von »GEMSOUND« im AES/VDI-Trap und ordnet den AES-Aufrufen die Geräusche zu. Die Zuordnung läßt sich mit diesem CPX-Modul auch jederzeit nach eigenen Wünschen gestalten. Doch zunächst ein Blick auf das Pull-Down-Menü »Optionen«. Der Menüpunkt »Sounds« schaltet die ganze Spielerei ab bzw. an. Via »SReset« stellen Sie ein, ob ein Sample das andere abwürgt oder die Samples trotzdem zu Ende gespielt werden. Damit Sie nicht im akustischen Dunkel tappen, können Sie sich die Samples auch mit »Sample spielen« vorab zu Gehör bringen. Die Zuordnung der Samples zu den AES-Aufrufen erfolgt über Pop-Up-Menüs, die sich unter den schattierten Namen verbergen. Es können zwanzig AES-Aufrufe mit einem von maximal zwanzig Samples belegt und einzeln an- oder ausgeschaltet werden.Wem die »Zwanziger-Grenze« zu niedrig ist, kann durch Erhöhen von »#define MAX_SAMP 20« in »SOUNDS.H« das Ganze noch ausweiten. Wer sich bei dieser Gelegenheit sowieso gerade durch den Quelltext arbeitet, sollte sich auch noch die Mechanismen zur Kommunikation mit dem residenten Programm »GEMSOUND« (aus dem AUTO-Ordner) zu Gemüte führen. Zu diesem Zweck wird von »GEMSOUND« ein Cookie mit der Kennung »GSND« angelegt. Der Inhalt dieses Cookies ist ein Zeiger auf eine »C_SOUNDS«-Struktur, über die auch andere Programme mit »GEMSOUND« Kontakt aufnehmen dürfen und so die Zuordnung verändern oder ein Sample abspielen. Die benötigten Strukturen sind in »SOUNDS.H« definiert und sehen wie folgt aus:

typedef struct
{
	char name[15];	/* Name des Samples */
	long laenge;	/* Die Länge des Samples */
	long *anfang;	/* Zeiger auf den Anfang */
}	SINF;
typedef struct
{
	int fix;	/* TRUE, wenn GEMSOUND aktiv */
	int r_flag;	/* Sound unterbricht anderen */
	int ruhe;	/* »Wenn TRUE, dann RUH« */
	int max_sound;	/* Anzahl der Samples */
	void (*play) (SINF *sound, int super);
	long (*set_vec) (void);	/* Neuer AES-Trap */
	struct
	{
		int nr;	/* Nr. des AES-Aufrufs */
		int sound;	/* Nr. des entspr. Samples */
		int an;	/* TRUE/FALSE=Sound An/Aus */
	} gem_inf[MAX_SAMP];
	SINF sounds[MAX-SAMP];	/* Sample_Infos */
} C_SOUNDS;

Die Samples

Wer eigene Samples hören möchte, muß diese nur in den Ordner »SAMPLES« kopieren und neu booten. Die verwendeten Samples sind im »SampleWizard«-Format abgelegt (»*.SMP«). Es können nur Mono-Samples mit 12.5 kHz Abtastrate verwendet werden. Je nachdem, welcher Sampler verwendet wurde, kann es sein, daß die Samples sehr verrauscht klingen. In diesem Fall müssen die Samples umgerechnet werden. Für diesen Zweck eignet sich das Programm »DMA_SOUND«, das Sie auf der TOS-Diskette 9/91 finden.

Und wenn der User seinen Atari nicht wegen der seltsamen Geräusche erschlagen hat, dann BEEEPEN sie noch heute. (ah)