DISKUSSION: "Die neue Maus unter CAOS"
von Ralf Kästner
Ich möchte dem Aufruf von Mario Leubner folgen und einige Gedanken zu einer zukünftigen Einbindung einer Microsoft- bzw. PC-System-Mouse ins CAOS äußern.
Die Überschrift ist mit Absicht so gewählt, da meiner Meinung nach die Möglichkeiten der Maus als vollgrafisches Eingabegerät in den z. Z. vorhandenen Treibern nur ungenügend ausgenutzt werden. Wenn man die bisherigen Lösungen betrachtet, stellt man fest, daß die Maus im Wesentlichen zur Steuerung des (Text)Cursors "mißbraucht" wird. Die 3 oder 2 Maustasten emulieren bestimmte Tasten der Tastatur, wobei i.d.R. eine Taste für den User/Programmierer frei zur Verfügung steht.
Das war dann bereits alles, für den Anfang reicht das sicher erst mal aus, man muß ja auch zunächst Erfahrungen mit Neuheiten sammeln. Ich möchte betonen, daß dies eine sehr bequeme Variante für den Programmierer ist, da er die Maus nicht extra im Programm berücksichtigen muß, nicht zuletzt habe ich zugunsten einer schnellen und unkomplizierten Lösung diese Form der Einbindung in "UNIPIC 1.0" gewählt, es funktioniert ja auch gut aber ist das schon das Machbare? Ich glaube nicht, wenn wir uns umschauen.
Auf allen grafikfähigen Heim- bzw. Personalcomputern gibt es grafische Benutzeroberflächen, welche die Fähigkeiten der Maus ganz anders nutzen (MacOS - Apple / GEOS - C64 / GEM - Atari ST / WINDOWS - PC usw.). Auch wenn es so etwas auf dem KC noch nicht gibt, sollten wir uns nicht den Weg verbauen, diese durchaus auch bei uns vorhandenen Möglichkeiten zu nutzen, die Maus sollte aber vom Betriebssystem unterstützt werden, da sie per Interrupt und damit sehr hardwarenah programmiert werden muß.
Stichwort COM1...4, wenn diese Verwaltung jedes Anwenderprogramm machen soll, gehen von vornherein mehrere kByte verloren, da das Betriebssystem ausgehebelt werden muß und für alle seriellen Kanäle eigene Int-Routinen im Programm bereitgestellt und initialisiert werden müssen. Wir sollten also scharf nachdenken, vielleicht auch ein wenig länger, damit am Ende ein maximaler Nutzen für alle herauskommt!
Nach dem Studium der von Mario bereitgestellten Quelltexte zu den Maustreibern stellte ich fest, daß genau wie eben beschrieben, vorgegangen wird. Mir standen diese Quellen nicht zur Verfügung, deshalb hatte ich mir bereits im Mai/Juni dieses Jahres den PC vorgeknöpft, WINDOWS gestartet, die dortige Mausbedienung studiert und analysiert. Es ist zwar nicht gerade originell aber darauf aufbauend habe ich "rückwärts" für den KC einen neuen Maustreiber entwickelt, welcher alle Möglichkeiten der Maus ausnutzen kann.
Dieser Treiber soll in "UNIPIC 2.0" eingesetzt werden und eine vollkommen getrennte Bedienung über Keyboard bzw. Maus realisieren. Das dabei verwendete Prinzip der Einbindung ins Programm ist ohne Weiteres auch im CAOS machbar und bietet dadurch völlig neue Möglichkeiten der Bedienung, nach dem gleichen Prinzip lassen sich auch alle anderen grafischen Eingabegeräte (Geräte, welche grafische Koordinaten liefern) ins CAOS integrieren, wobei eine einheitliche Schnittstelle vom CAOS zum rufenden Anwenderprogramm geschaffen ist.
In jedem Programm gibt es Eingaberoutinen, welche bestimmte Eingabecodes erwarten und entsprechend darauf reagieren. Im CAOS benutzt man i.d.R. INTB (UP 16H). Dieses Programm wartet auf eine Eingabe vom aktuellen Eingabekanal und gibt den Eingabecode an das rufende Programm zurück, es ist vollkommen egal, woher er kommt. Im Normalfall (durch Zeiger INTAB auf 0B7BBH) ist es das Keyboard, welches über KBD (UP 04H) abgefragt wird, welches wiederum über KBDZ (UP 0EH) den Tastenstatus abfragt und nach Betätigen einer Taste, diese quittiert.
KBDZ ist die unterste Schicht von CAOS, an dieser Stelle muß sich auch die Maus bemerkbar machen. Viele MC-Programme umgehen leider KBDZ und testen direkt Bit 0,(IX+8), dazu muß man also auch abwärtskompatibel bleiben. Diese Vorgaben schränken den Spielraum schon erheblich ein, es bietet sich aber die von mir gewählte Variante an.
Die Beseitigung der Nachteile der bisher existierenden Maustreiber ist eigentlich nur möglich, wenn sich die Maus anders meldet, als die Tastatur. Dazu ordnet man der Maus bzw. jedem anderen grafischen Eingabegerät eigene Codes zu, welche von anderen Eingabegeräten nicht genutzt werden dürfen. Außerdem ist eine strikte Trennung zwischen Eingabe- und Ausgabe-Codes erforderlich!!! Dazu die folgende Skizze, welche alle aus der 1., spätestens 2. Informatikstunde kennen dürften:
- allgemein:
EINGABE - INFORMATIONSVERARBEITUNG - AUSGABE - CAOS-Menü:
KBD - CAOS-Menüschleife - CRT - Anwenderprogramm im KC:
KBD - ANWENDERPROGRAMM - CRT
Besonderheiten bilden im KC die ESC-Codes, diese werden "leider" durch KBD abgefangen und, am Anwenderprogramm vorbei, direkt an CRT geschickt, man kann u.a. die Bilder umschalten, ohne daß das laufende Programm etwas mitbekommt, was mitunter sehr nachteilig sein kann.
Zurück zu den Codes, die Maus liefert als Eingabegerät logischerweise Eingabecodes, welche über die zugehörige Interruptroutine bereitgestellt werden. In den bisher existierenden Treibern waren das emulierte Tastencodes, so daß für das Anwenderprogramm Maus = Keyboard ist. Eine reine Mausbewegung oder die Bewegung der Maus mit gedrückter Taste ist so nicht erkennbar, von anderen Extras, wie Doppelclick oder Autorepeat bei gedrückter Maustaste ganz zu schweigen.
Was steht nun in CAOS eingabeseitig noch zur Verfügung? Belegt sind (grob gesagt) durch die Tastatur 00 ... 7FH und 0F1 ... 0FFH, der Joystick emuliert diese Codes, übrig bleibt also der gesamte Bereich von 80H ... 0F0H, wenn man den "Schattenbereich" der Steuercodes von 80H ... 9FH nicht in Betracht zieht, bleiben 0A0H ... 0F0H übrig.
Nachdem ich mehrere Versuche und Varianten durchprobiert hatte, habe ich mich für den Bereich von 0E0H...0EFH entschieden. Diese Codes sollen dabei nicht nur der Maus zur Verfügung stehen, ich würde es als Schnittstelle für grafische Gerätetreiber bezeichnen, das sind alle Geräte, welche Punktkoordinaten liefern können mit maximal 3 Tasten. Unabhängig vom Gerät sind folgende Zuordnungen festgelegt:
Bewegungscodes
E0 Bewg. mit gedrückter Taste links, mitte & rechts E1 " links & mitte E2 " links & rechts E3 " links E4 " mitte & rechts E5 " mitte E6 " rechts E7 Bewg. ohne Taste
Gerätetastencodes
E8 Taste rechts gedrückt E9 " losgelassen EA Taste mitte gedrückt EB " losgelassen EC Taste links gedrückt ED " losgelassen EE Doppelclick links EF Dreifachclick links
Durch diese Zuordnung lassen sich beispielsweise sowohl Microsoft- als auch PC-System-Maus und auch grafisches Tablett unter einen Hut bringen, wobei nicht jedes Gerät alle Codes erzeugen kann. Der Anwendungsprogrammierer hat aber dadurch feste Vorgaben und vor allem eine definierte Schnittstelle. Komplikationen dürften sich auch nicht ergeben, da diese Codes eingabeseitig bisher nicht existieren. Man kann so auch IX+13 und Bit 0,(IX+8) verwenden, wobei wahlweise CAOS UP 0EH oder 16H/04H ohne Änderungen zur Abfrage verwendet werden können.
Der Treiber für externe Tastaturen an V24 sollte diese Codes bei Notwendigkeit ausfiltern und nicht an CAOS weiterleiten. Diese Variante schränkt auch die Darstellung des Mauspfeils nicht ein, man kann ihn fesseln, zeichnen oder wegnehmen wie in den letzten News beschrieben wurde.
Das Wichtigste ist aber - KBD muß alle Codes an das rufende Programm zurückgeben !!! Hierin besteht der wesentliche Unterschied zu den bisher existierenden Treibern und erst dann kommen die Vorteile dieser Einbindung zum Tragen. Die Maus versteckt sich nicht mehr über die emulierten Tastencodes oder intern in der KBD (s. Quelltexte letzte News) vor dem Anwenderprogramm, sondern meldet alle Aktionen mit den neuen Codes.
Nur so haben wir auch auf dem KC die Möglichkeit mit Techniken wie Drag & Drop, Mauspfeilmanipulation bei gedrückter Taste, Ziehen, Markieren von Textpassagen mit der Maus usw. zu arbeiten. Auf diese Art und Weise können die spezifischen Eigenschaften und Möglichkeiten der Maus den Programmierern zugänglich gemacht werden, wobei das Betriebssystem "die Arbeit macht".
Es hat sich auch bereits bewährt, bestimmte Vorarbeiten zur Auswertung von Mausaktionen in der Interruptroutine vorzunehmen und auf die o.g. 16 Codes aufzuteilen, es schließt nämlich Timing- bzw. Positionsprobleme aus, wenn die Maus schnell betätigt/bewegt wird und der KC nicht so schnell darauf reagieren kann, die Erzeugung des Doppelclicks aus 2 Clicks mit der linken Taste innerhalb einer bestimmten Zeit läßt sich per Interrupt auch besser erzeugen als im Anwenderprogramm.
Nun genug der Theorie, kommen wir zur Praxis. Ich habe mich auf Grund des reizvollen Themas nun doch entschlossen "UNIPIC 2.0" über einen frei beweglichen Mauspfeil und über Tastatur bedienbar zu machen. In Ermangelung anderer Quellen habe ich den genannten neuen Maustreiber bereits eingebaut.
Er arbeitet nach den eben beschriebenen Vorgaben. Er liefert die o.g. Tastencodes an die programminterne INPUT-Routine und stellt in Arbeitszellen die vollgrafische Mausposition und die zugehörige absolute Cursorposition nach jeder Aktion zur Verfügung. Der Mauspfeil wird direkt in der INPUT-Routine dargestellt. Die INPUT-Routine berechnet aus absoluter die relative Cursorposition im aktuellen Fenster und legt sie auch in Merkzellen ab, befindet sich die Maus außerhalb des aktuellen Fensters, wird ein Bit gesetzt, was durch das Programm entsprechend ausgewertet wird.
Der Treiber erzeugt einen Doppelclick und realisiert auch für die linke Maustaste ein Autorepeat, wenn man sie gedrückt hält und die Maus nicht bewegt. Die Zeit, welche für den Doppelclick zur Verfügung steht, richtet sich nach der eingestellten AUTOREPEAT-Verzögerung (0B7E0H), ist diese abgelaufen, wird der bis dahin mögliche Doppelclick getötet.
Es ist zwar noch ein ganzes Stück Arbeit notwendig, um das Programm komplett an die neuen Möglichkeiten anzupassen, man kommt aber bereits jetzt in puncto Bedienung dem großen WINDOWS auf dem PC ziemlich nahe. Die Einbindung in mein Programm ist allerdings nur eine Insellösung, so etwas muß das Betriebssystem machen. Ich hatte bereits die Möglichkeit den jetzigen Stand einigen KC-Usern zu demonstrieren - es wurde positiv bewertet.
Knackpunkt der ganzen Angelegenheit ist der etwas höhere Aufwand in der CAOS-Steuerschleife und im MikroDOS, da für die Maus (s.o. Skizze) zusätzliche Reaktionsprogramme und damit mehr Speicher notwendig sind. Im CAOS sollte es aber meiner Meinung nach möglich sein, die im letzten Artikel genannten Anwendungen zu integrieren, man muß ja nicht auf alle Codes reagieren, im MikroDOS kann das möglicherweise ZAS machen.
Entscheidend für mich als Programmierer ist aber - sobald ein Anwendungsprogramm läuft, soll mir die Betriebssystemeingabe melden, was die Maus macht und was die Tastatur und das getrennt, ganz gleich, in welcher Form es auch immer ins CAOS eingeht oder nicht!
Seit kurzer Zeit steht mir ein älteres Buch zur GEM-Programmierung auf dem Atari-ST zur Verfügung, wo sämtliche Funktionen des GEM aus der Sicht des Programmierers erklärt werden. Auch dort wird eine ähnliche Trennung von Eingabegeräten vorgenommen, für die Maus gibt es u.a. die folgenden GEM-Eingabefunktionen (GEM kann preemptives Multitasking):
- neue Mauszeigerform definieren
- Mauszeiger auf Bildschirm aus
- Mauszeiger auf Bildschirm ein
- Maustastenveränderungsvektor umbiegen (wird bei jeder Betätigung einer Maustaste aufgerufen)
- Mauszeigerbewegungsvektor umbiegen (wird nach jeder Mauszeigerbewegung aufgerufen)
- Mausbewegungsvektor umbiegen (wird bei jeder Bewegung der Maus aufgerufen und dient normal zum Zeichnen der Mausform)
- Mausstatus feststellen (liefert den Status der Maustasten und Koordinaten des Mauszeigers)
GEM erweitert hierbei das TOS des Atari um eine grafische Benutzeroberfläche, genau wie WINDOWS das MS-DOS des PC erweitert, das eigentliche Betriebssystem bzw. der Maustreiber muß also die Aktionen der Maus an das Anwenderprogramm weitergeben, was in diesem Fall eben GEM bzw. WINDOWS ist, diese beiden wiederum werten jetzt schon bestimmte Aktionen der Maus aus und nehmen dem übergeordneten Programm das Öffnen und Verwalten der Fenster, die Nutzung der Schnittstellen, graf. Ausgaben usw. ab.
So etwas haben wir zwar noch nicht, um es aber überhaupt entwickeln zu können, muß das Betriebssystem alle Aktionen der Maus ungefiltert passieren lassen und auf eine festgelegte Art und Weise weitergeben. Macht es das nicht, muß jeder Programmierer mit eigenen Treibern und Routinen arbeiten oder mit den Einschränkungen durch das Betriebssystem leben, an dieser Stelle ist dann aber auch die Weiterentwicklung von CAOS beendet, was sehr schade wäre, ein KC-WINDOWS kriegen wir bestimmt auch noch hin!