Quick-Tips

FPU-Patch für Anwendungen unter MagiCMac

Viele ATARI-Programme machen einen sog. "Bus-ErrorTest", um daran zu erkennen, ob bestimmte Hardware-Bausteine im Rechner installiert sind. Dazu führen sie einen Testzugriff auf bestimmte Speicheradressen durch, und wenn sie dort keinen Bus-Fehler erhalten, gehen sie davon aus, daß die erwartete Hardware ansprechbar ist.

Die neuen PCI-Macs können leider dort, wo sich in der Regel solche Bausteine befinden, keinen Bus-Fehler auslösen. So gehen dann die Programme davon aus, dort bestimmte Funktionalitäten nutzen zu können und funktionieren deswegen nicht korrekt.

Eine Gruppe von Programmen, beidenen dieses Problem auftritt, sind solche, die mit Pure C und Pure Pascal erstellt wurden und Floating-Point-Operationen durchführen. So z.B. das bei Pure Pascal mitgelieferte Demo-Programm EYES.PRG oder auch Calamus SL.
Alle diese Programme benutzen dieselben Floating Point-Routinen, die anfangs prüfen, ob evtl. eine speziell für den Mega ST vorgesehen Zusat-FPU ("SFP004") installiert ist, um diese dann zu nutzen. Ist sie nicht vorhanden, werden die Berechnungen auf übliche Art mit der normalen CPU vorgenommen. Das bedeutet, daß die SFP004 nicht zum Laufen solcher Programme benötigt wird, jedoch bei Vorhandensein automatisch genutzt wird. Wegen des oben beschriebenen Problems bei PCI-Macs glauben alle diese Programme, daß dort diese SFP004 installiert ist.

Abhilfe liefert ein Patch-Programm (erhältlich in der Redaktionsmailbox). Dieses Programm verändert jene Routine, die das Vorhandensein der SFP004 prüft, so, d aß sie die SFP004 nie mehr erkennt, selbst wenn das so veränderte Programm auf einem Mega ST mit installierter SFP004 liefe. Wenn Sie ihre Programme nicht auf einem PCI-PowerMac starten müssen, brauchen Sie dieses Patch-Programm auch nicht benutzen; es schadet allerdings auch überhaupt nichts, wenn sie es bei allen ihren Programmen anwenden - sie verlieren dadurch nur die winzige Option, bei Start dieser Programme auf einem Mega ST mit SFP004 einen kleinen Geschwindigkeitsgewinn zu erhalten.

Hinweis: Auch wenn der Patch bei Calamus die entsprechenden SFP004-Abfragen entfernen kann, hilft das nichts viel, weil Calamus einen Prüfsummen-Check durchführt, der dann nicht mehr stimmt. Wenn Sie Calamus auf einem PCI-Mac benutzen wollen, müssen Sie eine angepaßte Version vom DMC anfordern.

Thomas Tempelmann

Abfrage benutzerdefinierter AES-Mitteilungen

Neben den Standard mitteilungsereignissen können die AES auch mit benutzterdefinierten umgehen. Sie werden mit appl_write() an eine beliebige Applikation verschickt (siehe z.B. Gemini). Diese dürfen auch länger als die standardmäßig definierten 16 Bytes sein. Auch wenn ein Programm diese Meldungen nicht auswerten soll, muß es die zusätzlich im Message-Buffer abgelegten Daten trotzdem lesen. Wie dies zu geschehen hat, steht im Profibuch ST-ST E-TT unter "AES.Ereignis-Bibliothek. Mitteilungs-Ereignisse".
Leider scheint zumindest die AES-Version 3.2 (TOS 2.x, 3.x) einen kleinen Bug zu haben. Sie verschicken bei mehrmaligem Druck (Autorepeat) auf den Balken oder den Pfeil eines Fenstersliders neben der WM_ARROWED-Meldung auch weitere 16 Bytes, die zusätzlich gelesen werden sollen. Dies scheint bereits die nächste Message zu sein. Aber Vorsicht, wenn man diese einfach mit appl_read() liest, bleibt der Ereignisverwalter der AES hängen und ist nur mit mehrmaligem Mausklickin ein Fenster zum Weitermachen zu bewegen. Zur Abhilfe schreibe ich die gelesenen Daten mit appl_write() wieder in den eigenen Ereignisbuffer zurück (siehe Listing). Bei den AES 4.x (z.B. MultiTOS) tritt dieser Fehler nicht mehr auf.

Volker Hemsen

// (c)1995 by MAXON Computer //
// Autor: Volker Hemsen //

    int mbuf[8], ap_id;
    ap_id:=appl_init();
    ...
    evnt_mesag(mbuf);
    if (mbuf[2]>0)
    // Es müssen weitere Daten gelesen werden 
    {
        int *puffer; 
        puffer=malloc(msg[2]); 
        // genügend Speicher reservieren 
        if (puffer!=OL)
        // wenn's keinen gibt, sieht's böse aus
        { 
            appl_read(ap_id, mbuf[2], puffer);
            // Daten lesen 
            if (puffer[0]=WM_ARROWED)
            // bei WM_ARROWED-Mitteilungen  
                appl_write(ap_id,mbuf[2],puffer);
                // alles wieder zurückschicken 
            mbuf[2]=0;
            // hier unbedingt 0 eintragen
            free (puffer); 
            // ... und Speicher wieder freigeben.
        }
    }


Aus: ST-Computer 11 / 1995, Seite 120

Links

Copyright-Bestimmungen: siehe Über diese Seite