Leserbriefe
Spracherkennung
Bei Planungen zu einer Dissertation innerhalb der Sozialwissenschaften stehe ich (und viele Kollegen und Kolleginnen) vor dem Problem, größere Mengen an Tonbandprotokollen von Interviews verschriftlichen zu müssen.
Ist es möglich, diese Aufgaben dem Computer zu überlassen?
Wenn ja, mit welchem Aufwand an Soft- und Hardware. So einfach wird es sicher nicht gehen, daß man den Kassettenrekorder an die MIDl-Schnitt-stelle hängt und ein ASCII-Text auf Diskette hinterher findet (vorhandene Hardware: ATARI 1040STF).
(Rudolf S., Berlin)
Red.: Leider ist dieses Problem lange nicht so einfach zu lösen, wie man vielleicht glauben mag. Eine Vielzahl von Wissenschaftler rund um den Erdball forschen danach, wie man am geschicktesten Sprache erkennen kann. Dabei sind Teilerfolge erzielt worden, bei denen ein begrenzter Wortschatz von diversen Rechnern schon erkannt werden können, wobei häufig aber die Einschränkung gilt, daß die Worte von einundderselben Person und dazu noch relativ gleichmäßig und deutlich gesprochen werden müssen, da größere Abweichungen durch Klangänderungen vom Rechner nicht mehr als gleich erkannt werden. Schaut man sich das Signal des Buchstabens ‘a' von zwei verschiedenen Personen an, so können die Unterschiede sehr groß sein. Die Wissenschaft forscht nun daran, welche Merkmale bestimmte Vokale oder Laute auszeichnet. Aus der schwierigen Aufgabenstellung erkennt man sofort, daß weder der ST noch die bisherige bekannte Software auf diesem Sektor auch nur annähernd dazu ausreicht, Sprache in der Praxisanwendung zu verschriftlichen. (Übrigens: An die MIDI-Schnittstelle schließt man kein normales AUDIO- (also analoges) Signal sondern ein schon in digitale Daten gewandeltes AUDIO-Signal an.) Allerdings gibt es ein Bereich, der weiter ist als die Spracherkennung: Dieser Bereich ist die Schriftenerkennung. Es gibt schon Programme (auf dem ST), die es ermöglichen, einen schon geschriebenen Text, der eventuell nur auf Papier vorliegt, mit einem sogenannten Scanner aufzunehmen und dann durch ein Programm so abzutasten, das mit hoher Wahrscheinlichkeit die Grafik erkennt und in einen normalen Text wandelt. Ein solches Programm wurde auf der ATARI-Messe unter dem Namen AUGUR vorgestellt - sicherlich werden wir es in einer der nächsten Ausgaben ausführlich vorstellen.
Ausblendung von Druckerzeichen bei 1st_Word
Die Ausblendung von Druckerzeichen auf dem Bildschirm läßt sich auch in selbstgestrickten HEX-Files problemlos erreichen: Man braucht nur in der Konvertierungstabelle hinter die HEX-Nummer des zu unterdrückenden Zeichens ein Sternchen (und sonst nichts!) einzutragen, also zum Beispiel “BA*”. Dann kann dieses Zeichen auch auf dem Bildschirmfenster nicht angeklickt werden.
(Konstantin D., Ottohrunn)
Red.: Vielen Dank für diesen Tip. An dieser Stelle möchten wir uns einmal bei allen Lesern bedanken, die uns immer wieder Tips zu 1st_Word einsenden ! Langsam könnten wir fast Serie daraus gestalten. Monat für Monat wird immer wieder gezeigt, daß viel mehr Features in 1st_Word stecken als allgemein bekannt ist. Also nur Mut beim Einsenden von Tips, sie sind gerne willkommen ... im Folgenden wollen wir aber kurz zwei Mängel von 1st_Word Plus veröffentlichen, um Anwender davor ‘zu warnen’:
Mängel und deren Bewältigung an 1st_Word Plus
Seit Anfang August unterrichte ich meine Schüler in der Anwendung von lst_Word Plus. Ich selbst arbeite schon seit fast zwei Jahren mit dem Programm und bin im Großen und Ganzen damit zu frieden. Die in den Fachzeitschriften genannten Verbesserungs Vorschläge kann ich zwar auch unterstreichen, aber insgesamt läßt sich mit dem Programm sehr gut arbeiten. An der neuen Version, die meine Schule nun bekommen hat, habe ich jedoch zwei ganz erhebliche Mängel festgestellt, die nach meiner Meinung abgestellt werden müßten:
- Das Wörterbuch lade ich von einer Extra-Diskette. Dadurch kann es Vorkommen, daß ich vergesse, die Diskette zu wechseln, wenn ich ‘Speichern & Weiter’ aufrufe. Das Programm registriert dann nicht, wenn man anschließend die Diskette wechselt, sondern bringt immer wieder die Warnbox ‘ Schreib/Lesefehler!’ . Bisher konnte ich mir in solchen Fällen damit helfen, daß ich einfach eine andere Datei aufrief und dann 'Abbruch' anklickte. Bei der neuen Version bleibt dann jedoch die Datei-Auswahl-Box auf dem Bildschirm und der Text läßt sich nicht mehr weiterverarbeiten. Es hilft nur noch ‘Speichern als...’ und der Neuaufruf der Datei, was bei längeren Dateien natürlich sehr lästig ist.
- Wenn man aus dem Menü ‘Korrektur’ versehentlich die Option ‘Korrekturende’ anstatt ‘Wort hinzufügen...’ erwischt, gibt es kein Zurück mehr. Man ist dann zum Abspeichern des Wörterbuches gezwungen, denn mit ‘Abbruch’ geht die Erweiterung des Wörterbuches verloren. Anschließend muß man die ganze Prozedur des Wörterbucheinladens wiederholen.
(Heiko M., Edewecht)
Talkshow
Ich muß ein Programm schreiben, mit dem man sämtliche Tasten- und Mausaktionen eines beliebigen Programmes aufzeichnen und danach wieder zeitlich richtig abspielen kann. Dadurch sollte es möglich sein, zum Beispiel eine Installation mit einem bestehenden Programm zu automatisieren, ohne daß man irgendeine Programmänderung vornehmen muß. Verwenden wollte ich dazu die beiden AES-Funktion APPL TRE-CORD und APPLJPLAY. In der ST-Computer 4/88 habe ich glücklicherweise die ST-Ecke ‘Und sie dreht sich doch....’ gefunden, welcher eigentlich auf die Schnelle betrachtet genau mein Problem lösen sollte. Nach genauerem Studium des Artikels ist bei mir aber die Frage aufgetreten, wie man denn nun konkret mit einem Aufzeichnungsprogramm von irgendeinem x-beliebigen Programm die Maus- und Tastenereignisse aufzeichen kann. Danach sollte es möglich sein, mittels Abspielfunktion alle zuvor aufgezeichneten Daten zeitlich richtig an das Programm zurückzugeben und dieses somit zu steuern. Dies bedeutet ja, daß zwei Programme gleichzeitig aktiv sind, wobei das eine arbeitet wie normal und das andere dessen Aktionen aufzeichnet und irgendwo abspeichert.
Wie löst man dieses Problem?
(Rene H., ATARI Schweiz AG)
Red.: Zunächst einmal möchte ich Ihren Eifer leider etwas dämpfen, denn so einfach mit Appl_trecord und Appl_tplay geht es nicht, weil für solche komplexe Aufgaben, die sogar über andere Programme als das eigene hinausgehen, sie nicht gedacht sind. Tests, die aus einer Accessory, bei gleichzeitigem Vorhandenseins des Desktops, Daten übermittelten, ergaben folgendes Ergebnis: Die Steuerung der Maus funktionierte noch einwandfrei, aber ein Klick oder gar Doppelklick kamen nicht zur Ausführung. Folgerung: Obwohl eine Accessory quasi parallel zur aktuellen Applikation lauft, ist es von ihr aus nicht möglich. Befehle mit appl_tplay korrekt zu übermitteln. Meines Erachtens ist die ganze obige Problemstellung nur auf unterster Ebene (Betriebssystemebene) zu lösen, in dem man zunächst alle externen Eingaben wie Maus und Tastatur zeitgerecht aufzeichnet. Dies kann man beispielsweise dadurch erreichen, daß man sich in den IKBDSYS-Vektor einhängt, der alle Befehlspakete des Tastaturprozessors abfängt und versehen mit einer Zeitinformation abspeichert. Beachten Sie aber dabei, daß dies alles im Interrupt passiert und ein tatsächliches Abspeichern auf Diskette von hier aus nicht möglich ist! Vielmehr müßte dies zum Beispiel durch eine Accessory geschehen, die Zugriff auf diesen Puffer hat. Beim Abspielen müßten die Daten dann aufgrund der Zeitinformation in IKBDSYS eingespielt werden. Trotzdem möchte ich darauf hinweisen, daß gerade Tastaturroutinen sehr sauber programmiert sein müssen und auch aufgrund der Interrupt-Struktur sehr schwer zu debuggen sind. Abgesehen davon kommen pro Sekunde eine Menge an Eingabeinformationen an, wobei in dem oben erwähntem Beispiel das ganze Tastaturprozessorpaket abgespeichert werden muß. Eine Realisierung dieser Ideen liegen aufgrund von Zeitmangel und Komplexität von meiner Seite noch nicht vor. Vielleicht hat ein Leser diese Ideen oder ein ähnliches Konzept schon programmiert. Andernfalls möchte ich hiermit alle Assemblerfreaks aufrufen, dieses Problem vielleicht einmal in die Tat umzusetzen.
Programmheader
Ich möchte an käuflich erworbenen Programmen Änderungen (z. B. sinnlose Alertboxen bei Programmende entfernen) vornehmen und sie dazu disas-semblieren. Zwar findet man in der Literatur Informationen über den Aufbau der Base-Paye, gibt es aber Unterlagen, welche Information sich auf der jeweiligen Diskettendatei vor dem eigentlichen Programmcode befinden? Ich möchte die Programme nicht mittels PEXEC in den Speicher laden, da dann Speicherplatz für unter Umständen große ßSS-Segmente benötigt wird.
(Jürgen H.. Gießen)
Red.: Ob nun Alertboxen am Programmende wichtig sind oder nicht, soll dahingestellt bleiben, aber es gibt Informationen über den Programmheader, die wir veröffentlichen können. Das Programmformat des ST unterscheidet sich von Formaten wie die des C-64 oder des 8-Bit-ATARI, da die Programme an jeder beliebigen Stelle im Speicher ablauffähig sein müssen und daher vom Betriebssystem noch einmal ‘in die Mangel’ genommen werden. Diese Informationen sind im Datei-Kopf, in den TEXT-, BSS- und DATA-Abschnitten und der optionalen Symbol- und Reloziertabelle vorhanden. Das Format des Datei-Headers ist in Listing 1 beschrieben.
Der erste Eintrag ist ein Assemblercode des 68000, der bewirkt, daß einfach hinter den Header zum Programmstart gesprungen wird. Die anderen Einträge geben die Länge der unterschiedlichen Programmteile an. Normalerweise sollten die drei restlichen Bytes nach der Original Digital-Research-Dokumentation reserviert sein, allerdings wird der dritte Eintrag doch genutzt, wie man im Sonderheft 2/ST Computer in TOS-Intern von Alex Esser lesen kann. Ist der Eintrag gesetzt, so wird das Programm nicht reloziert und das BSS-Segment nicht gelöscht. Wahrscheinlich sind das Anlehnungen an MS-DOS, bei denen es schon mal aus Geschwindigkeitsgründen vorkommt, daß solche Maßnahmen ergriffen werden und auf feste Adressen basierende Programme schneller zugegriffen werden kann. Ich möchte Sie auch darauf hin-weisen, daß es zum Disassemblieren von Programmen schon Programme auf dem Markt gibt, die sogar Symbole unterstützen und den Code assemblierfähig abspeichern. Aus Erfahrung kann man sagen, daß ein Arbeiten mit solchen Programmen, die in letzter Zeit vermehrt angeboten werden, sehr gut möglich ist
typedef struct
{
int ph_branch; /* Sprung an den Anfang des Programmsegments:*/
/* immer 0x601A */
long ph_tlen; /* Länge des Text-Segments */
long ph_dlen; /* Länge des Daten-Segmentes */
long ph_blen; /* Länge des BSS-Segmentes */
long ph_slen; /* Länge der Symboltabelle */
long ph_resl; /* reserviert */
long ph_res2; /* reserviert */
long ph_flag, /* nach Originaldokument auch reserviert, aller-
dings bewirkt ein Setzen dieses Eintrages ein
Nicht-Relozieren des Programms und ein Nicht-
Löschen des BSS-Segmentes */
Listing 1
PC ditto & die VORTEX-Festpiatte
Seit Juni 1988 arbeite ich immer wieder mit PC ditto auf einer VORTEX HDplus 20-Festplatte mit zwei Partitionen auf Partition D ohne Probleme! Der “Trick” liegt darin, das AHDFIX.PRG aus dem STPROGRA-Order von PC ditto auch auf die VORTEX Platte anzuwenden (vorsichtshalber habe ich ein Backup der Platte angelegt - man weiß ja nie !!!). Das AHDFIX.Prg ist im AHDFIX.DOC gut dokumentiert, so daß eine Erklärung hier entfallen kann. Eigentlich müßte dieser Tip auf alle VORTEX plus -Platten anzuwenden sein, da der Treiber wohl derselbe ist (?!).
(Martin S., Schwabach)
ST-Erweiterungen
Ist es möglich, abgesehen vom Gehäuseplatz, am 1040STF weitere Platinen wie beim MEGA-ST anzuschließen, wie zum Beispiel der Arithmetik-Coprozessor und ähnliche Erweiterungsplatinen (Graphikkarte, IEEE-Karte)?
(Hartmut B.)
Red.: Das Anschließen von Erweiterungskarten am 1040-ST(F) ist leider nicht so einfach möglich wie beim MEGA-ST, was daran liegt, daß der gesamte Bus des 68000 beim MEGA ST auf eine gemeinsame Leiste geführt worden ist. Prinzipiell ist natürlich möglich, Erweiterungen am 1040 anzuschließen, wenn man sich die entsprechenden Leitungen vom Prozessor zur Karte zieht, wobei dies natürlich mit ein wenig Arbeit und Bastelei verbunden ist. Für den Blitter gibt es übrigens schon eine Adapterplatine für den 1040, die wir in der ST-Computer 11/88 vorgestellt haben.
Probleme mit dem Icon
Ich habe Probleme, in C das Zeichen eines Icons zu verändern: Dabei habe ich im Programm folgende Zeile geschrieben:
((ICONBLK) baum [DEF].obspec) ->ib_char = 65;
Der Icontext läßt sich problemlos verändern, aber wenn man versucht, das Zeichen nach dieser Methode zu ändern, compiliert der Compiler zwar fehlerfrei, aber alle Icons sind beim Programmdurchlauf weiß. Hierzu ist noch zu sagen, daß ich nicht etwa mit lang, sondern mit OBJECT-Strukturen gearbeitet habe.
Wie kann man das fehlerfrei beschreiben ?
(Christopher K., Hagen)
Red.: Erstmal ist es sehr richtig und gut, mit Objekt-Strukturen zuarbeiten, da man ja nie weiß, ob irgendwann die Struktur mal verändert wird - dann wäre nur eine neue Compilierung nötig. Abgesehen davon liegt Ihr Problem an folgendem: Entgegen der weitläufigen Meinung beinhaltet das Strukturelement ibchar des Iconblocks nicht nur den Buchstaben, sondern auch die Farbe des Icons. Diese Farbe wird nochmal in die Farbe der Maske und des Vordergrundes unterteilt. Sie werden in vier Bits kodiert, wobei der Vordergrund in den oberen und der Hintergrund (die Maske) in den unteren vier Bits des Highbytes von ib_char kodiert sind; das untere Byte enthält den ASCIl-Code des gewünschten Zeichens. Damit ist auch klar, was Sie falsch gemacht haben: Sie haben schlichtweg die beiden Farben auf Null gesetzt! Wenn Sie ein neues Zeichen setzen möchten, so müssen Sie vorher die unteren 8 Bits löschen und dann ihr neues Zeichen in ib_char mit einer Oder-Funktion hineinmaskieren: (siehe Listing 2)
Auf diese Weise läßt sich das Zeichen sauber setzen. Auf die gleiche Art kann man natürlich auch die Farben des Icons manipulieren.
((ICONBLK)baum[DEF] .ob_spec)->ib_char &= OxfO;
/* unteres Byte löschen */
((ICONBLK)baum[DEF] .ob_spec)->ib_char |= 65;
/* Zeichen setzen */
Listing 2
KORREKTUR: Genauigkeit erwünscht
In der Ausgabe 7/88 veröffentlichten wir ein kleines Programm zur Messung von Zeiten im Millisekunden-Bereich. Leider sind uns dabei zwei Fehler unterlaufen. Wir drucken das Programm hier noch einmal ab. Die Fehler befanden sich in den mit * gekennzeichneten Zeilen: (siehe Listing 3)
‘millisec, R.Kracht, Gärtnerwiete 9, 2085 Quickborn, 29.5.88 ‘
Bild%=Xbios(2) ! Adresse des Bildschirmspeichers
Zeit%=Bild%+32200 !* Adresse der Timer-A-Interrupt-Routine
Uhr%=Zeit%+20 ! Adresse der Uhr
Lpoke Zeit%,&H8B90005 ! Anfang der Interrupt-Routine
Lpoke Zeit%+4,&HFFFA0F
Lpoke Zeit%+8,&H27CF3FF
Dpoke Zeit%+12,&H52B9
Lpoke Zeit%+14,Uhr% ! Adresse der Uhr
Dpoke Zeit%+18,&H4E73 ! rte (Ende)
Lpoke Uhr%,0 ! Uhr auf Null stellen
A%=Xbios(31,0,2,246,L:Zeit%) ! Uhr starten
Do
Void Inp(2)
U=Lpeek(Uhr%) ! Uhr lesen
U=U+U/1024 ! Uhr korrigieren
U=Int(U+0.5) ! auf volle Millisekunden runden
Print U;” msec seit Uhrenstart”
Loop
Listing 3