/////////////////////////////////////////////////////////////////////////////// / / / 27.02.93 / / P*ST: / / Christoph Conrad / / Adalbertsteinweg 113 / / 5100 Aachen / / / / E-Mail Direkt: / / MAUS: Christoph Conrad @ AC3 / / / / E-Mail Gateways: / / FIDO: Christoph Conrad % Maus AC3 2:242/2.6 / / ACHTUNG: evt. neu / / Christoph Conrad % Maus AC3 2:242/42.333 / / USEnet: Christoph_Conrad@ac3.maus.de (keine ueberlangen Mails!) / / Zerberus: Christoph_Conrad%ac3@zermaus.zer / / Pronet: MAUS:AC3:Christoph_Conrad / / Internet: conrad@pool.Informatik.RWTH-Aachen.DE / / (selten, bitte keine ueberlangen Mails!) / / BTX: Seite *35008024#, im Formular ausfllen / / Christoph_Conrad@AC3.MAUS.DE.UUCP / / (kostet 90 Pfennig) / / / / Falls Sie irgendetwas entdecken, was Sie st”rt, oder Verbesserungsvorschl„ge/ / haben, nur zu: schreiben Sie mir ber EMail (vorzugsweise) oder P*ST. / / / / Wenn Sie Fehler im Basic finden, schreiben Sie mir! / / / / Ich kann weder die juristische Verantwortung noch irgendeine Haftung fuer / / eventuelle Schaeden an Daten oder Programmen uebernehmen, die direkt oder / / indirekt auf die Benutzung dieser Patches zurueckzufuehren sind! / / / /////////////////////////////////////////////////////////////////////////////// +++++++++++++++++++++ FRAGE: Ich h”re immer, Line-A sollte nicht verwendet werden. Warum eigentlich? Nun, wie bekomme ich denn dann meine Compilerbibliothek (GFA3BLIB) Line-A frei? Im folgenden bedeute LA LINE-A! ANTWORT: Dazu ein Auszug aus dem Profibuch, 10te Auflage: [ZITAT:ON] Die Architektur des Betriebssystems spricht allerdings eindeutig gegen die Benutzung der Line-A-Routinen. Diese stellen n„mlich die untere Ebene des VDI-Bildschirmtreibers im ROM dar. Mit ihrer Verwendung verbaut man sich also eine eventuelle Nutzung eines anderen (schnelleren) Bildschirmtreibers! Auch ist eine Existenz der Line-A-Routinen nur fr die ST-Modi (also 320 * 200, 640 * 200 und 640 * 400) garantiert. Schon bei 256-Farbgrafik (spezielle Grafikkarte bzw. TT in der 'niedrigen' Aufl”sung) sind die M”glichkeiten der Line-A-Schnittstelle ersch”pft (siehe COLBIT0 bis COLBIT3). [ZITAT:OFF] Falls Sie jetzt nur Bahnhof verstanden haben: KEINE PANIK! Eine entscheidende Folgerung dieser Aussagen ist, das Programme, die Line-A Routinen benutzen, nicht unbedingt korrekt auf allen Graphikkarten laufen! Ergo: weg damit. Zum Patchen lesen Sie bitte beiliegenden Text LIBPATCH.TXT *** Im Interpreter $A009/$A00A Show/Hide Mouse rauspatchen! Das gibt zwar leichte "Flecken" beim Bewegen der Maus im Interpreter, aber dafuer keine beim laufenden Programm! *** Auf eine saubere Schachtelung von hidems/showms (ueber GRAF_MOUSE AES 78) achten! Zu jedem Hide ein Show, sonst gibt's "Flecken". Maus nicht anschalten, wenn sie schon an ist, wie in der Regel nach dem Start von GEM-Programmen, sonst "Flecken". *** FOLGENDE BEFEHLE MEIDEN: CRSCOL CRSLIN MOUSE MOUSEK MOUSEX MOUSEY SETMOUSE RC_COPY SHOWM HIDEM SPRITE ACHAR ACLIP ALINE APOLY ARECT ATEXT BITBLT HLINE L~A PSET PTST GET PUT SGET SPUT FILESELECT FILESELECT # Bei Verwendung ohne #datei_nummer: INPUT INPUT$ LINE INPUT ...und gegebenenfalls entsprechende VDI/AES-Befehle nutzen! Ein u.a. im MAUSnet kursierender Text von Uwe Ohse gibt weitere nuetzliche Tips und Hinweise, unter anderem Ausweichbefehle. Hier eine kurze Zusammenfassung: MOUSE/MOUSEK/MOUSEX/MOUSEY -> (AES) GRAF_MKSTATE SETMOUSE -> (AES) APPL_TPLAY SHOWM/HIDEM -> (AES) GRAF_MOUSE FILESELECT -> (AES) FSEL_INPUT FILESELECT # -> (AES) FSEL_EXINPUT SPRITE -> (VDI) vro/vrt_cpyfm ACHAR -> (VDI) TEXT ACLIP -> (VDI) CLIP ALINE -> (VDI) LINE APOLY -> (VDI) POLYLINE ARECT -> (VDI) PBOX ATEXT -> (VDI) TEXT BITBLT -> (VDI) BITBLT q%(),z%(),d%() HLINE -> (VDI) LINE PSET -> (VDI) PLOT oder v_pmarker bei grob > 200 Punkten PTST -> (VDI) POINT GET/PUT/SGET/SPUT -> (VDI) BITBLT RC_COPY -> (VDI) BITBLT >> Ohne Gewaehr auf Vollstaendigkeit! +++++++++++++++++++++ FRAGE: Wo finde ich denn Hinweise auf GEM-konforme Programmierung? ANTWORT: Tim Orens ProGEM. Dieser Text von 1985, inzwischen wohl in den meisten M„usen zu finden, gehoert mit zum besten ueber 'Professionelle GEM'-Programmierung. Weiterhin gibt es das Buch 'Vom Anf„nger zum GEM-Profi' der Gebrder Geiss. Ein wenig unbersichtlich, aber sonst ganz gut. Unverzichtbar ist allerdings das 'Profibuch' von Jankowski/Reschke/Rabich, vor allen Dingen als Referenz. +++++++++++++++++++++ FRAGE: GFA bietet doch so sch”ne eigene Befehle fr Fenster. Taugt das was? ANTWORT: Ich rate von der Verwendung der GFA eigenen Fensterverwaltung ab. Diese war in frueheren Versionen fehlerhaft, ob heute, wer weiss? šbers AES ist es genauso 'einfach' oder 'schwierig'. +++++++++++++++++++++ FRAGE: Mein Programm strzt mir manchmal ab. Ich kann beim besten Willen keinen Fehler finden. Was kann das sein und wie finde ich das raus? ANTWORT: SysMon und TempleMon verwenden. TempleMon kann in vielen MAUS-Boxen gesaugt werden, SysMon direkt beim Autor Karsten Isakovic Wilmersdorferstr. 82 1000 Berlin 12 bezogen werden. Zum Zeitpunkt des Absturzes kann man so zumindest den letzten verwendeten Systemaufruf feststellen und evt. falsche Parameter. Eine weitere gute M”glichkeit ist die Verwendung von TRACE procedurename (siehe Handbuch). Wenn man nun alle getraceten Zeilen in eine vorher ge”ffnete Datei schreibt (PRINT #1,TRACE$) l„sst sich die Absturzstelle schnell lokalisieren. Ebenso ntzlich kann der Turbo-C/Pure-C Debugger sein, wenn man das Programm mit Symbolen bersetzt. Ein weitgehend unbekannter Fehler betrifft die GFA-Basic eigene Speicherverwaltung. Der Fehler ist in allen 3er Versionen. Abhilfe: an 'h„ufig' durchlaufene Stellen ein ~FRE(0). Probieren Sie mal folgendes (danach neu booten): ' Compilerversion mit $m ' statt RESERVE RESERVE 1000 $m 4711 ' RESERVE damit's etwas schneller ' abstrzt aber eigentlich unn”tig ' Die (**) Zeilen braucht man ' beim Interpreter, damit ' nach dem RESERVE auch wirklich ' danach (FRE() MOD 16) == 0 gilt ' minus 4: wegen Backtrailer bei rest16$ ' beim Compiler falls $m XXXX ' mit (XXXX MOD 16)<>0 rest16%=(FRE(0) MOD 16)-4 ! ** IF rest16%<0 ! ** ADD rest16%,16 ! ** ENDIF ! ** rest16$=STRING$(rest16%,0) ! ** ' (FRE() MOD 16) == 0 jetzt erfllt str$="AHAH" DO @crash(str$) LOOP PROCEDURE crash(str$) str$="OHOH" RETURN +++++++++++++++++++++ Noch zwei Goodies zum Schluss: - Der Interpreter bricht das Mergen von Files, die ASCII 4 (EOT == End of transmission, CONTROL D, Pfeil nach links) enthalten, ab der ASCII 4 enthaltenden Zeile ab. Unter UN*Xen ist ASCII 4 das Dateiendezeichen, was auf einst recht grosse Ambitionen von GFA-Systemtechnik hindeutet. Folgender Patch unterbindet dieses Verhalten: Gfabasic 3.50 D Laenge 102519 Byte Dateioffset $96CC: $6702 -> $4E71 Gfabasic 3.6 D TT Laenge 104770 Byte Dateioffset $91C0: $66 -> $60 - Der CALL-Befehl im Interpreter Version 3.6 D TT der Groesse 104770 Byte ist aufgrund eines Tippfehlers (movem.l a4/a6,-(sp) anstatt movem.l a4-a6,-(sp)) fehlerhaft. Dateioffset $34AF: $0A->$0E +++++++++++++++++++++ Aktuelle Versionen dieser Library liegen immer in der MAUS AC3. Viel Spass beim Programmieren wuenscht Ihnen chris.