Quick-Tips

Line-Width-Register Falcon030

Wer sich schon auf den „allen“ STEs mit den leistungsstarken Hardwarescroll-Eigenschaften beschäftigt hat. wird darüber erfreut sein, daß ATARI alle die dafür vorgesehenen Register im Falcon030 übernommen und sie an der gleichen Adresse belassen hat. Es ist also weiterhin möglich, die Bildschirmadresse wortweise zu verändern (dbaselow: $FF820D) und den Bildbeginn pixelweise zu justieren (hscroll: $FF8265). Um nun aber einen größeren Bildschirm zu verwalten, also die Wortanzahl pro Zeile zu erhöhen, existiert ja bereits das Line-Width-Register (linewid: $FF-820F), in dem die Anzahl der Wörter steht, die am Zeilenende übersprungen werden sollen. Dieses Register war bisher nur 1 Byte breit und ermöglichte es somit nur, 255 Wörter pro Zeile zu überspringen. Auf dem Falcon reicht dies bei weitem nicht mehr aus, denn z.B. in der Truecolor-Auflösung von 320*200 ist eine Zeile schon 320 Wörter breit, und es ist leider nicht möglich, den Bildschirmbereich doppelt so breit anzulegen (für butterweiches Horizontal-Scrolling), denn das würde einen Wert von 320 für linewid erfordern. Glücklicherweise hat ATARI diesmal mitgedacht und das Register auf Wortbreite vergrößert, indem das neue Byte direkt vor dem alten plaziert wurde und somit im Normalfall (linewid < 256) kompatibel zum STE bleibt, weil das Low-Byte ja immer noch übereinstimmt. Das wortbreite Line-Width-Register befindet sich nun also an Adresse SFF820E und sollte im Falle der Abänderung in eigenen Programmen bei Verlassen wieder restauriert werden. Dem flüssigen Scrollen in alle Richtungen steht nun nichts mehr im Wege. Viel Spaß beim Experimentieren.

Natalie Lübcke

Falcon030 bootet von A:

Einige Programme, vornehmlich Spiele, müssen von Laufwerk A: gebootet werden. Falls diese nicht über den Boot-Sektor, sondern über ein AUTO-Ordner-Programm auf der Diskette gestartet werden, tritt das Problem auf, daß der Falcon030 immer von der internen Festplatte bootet. Drückt man nach einem Kaltstart während der Speichertests zweimal „Alternate-A“ (der erste Tastendruck wird benötigt, um den Speichertest abzubrechen), bootet der Falcon030 ohne Festplatte vom Laufwerk A:.

Gunnar Bargatzky

TWIST denkt mit!

Durch die Fähigkeit der Datenbank Twist, Berechnungen in Datenfeldern schon während der Eingabe vorzunehmen, lassen sich zahlreiche nützliche Dinge realisieren. Man kann das z.B. nutzen, um beim Erzeugen eines neuen Datensatzes, gewisse Felder mit einem Wert vorzubelegen. Die Formeln für die Felder lauten:

1. Textfelder:

Len(Land)==0?"D":Land

Ist das Feld leer, ist seine Länge 0. Sodann bewirkt die Formel, daß ein "D" hineingeschrieben wird. Enthält das Feld jedoch bereits einen Inhalt, wird dieser im ELSE-Zweig (nach dem Doppelpunkt) der Formel wieder ins Feld geschrieben und bleibt somit unverändert.

2. Zahlenfelder:

IsUndef(Zahl)?0:Zahl

TWIST unterscheidet bei Zahlenfeldern, ob deren Inhalt 0 ist oder noch nichts eingegeben wurde. Der Sinn der Sache liegt in den Statistikfunktionen.

Das führt jedoch zu Nebenwirkungen: wenn man z.B. drei Zahlenfelder addieren will und eines davon keinen Inhalt hat, wird die Rechnung nicht ausgeführt. Durch folgende kleine Formel, wird der Inhalt dann automatisch mit 0 gefüllt, wenn er noch nicht eingegeben war.

3. Datumsfelder:

IsUndef(Datum)?Today(): Datum

Die letzte Formel schreibt das aktuelle Datum in ein Feld.

S. W. Sommer

Debuggen von Accessories

Programmieren Sie Accessories? Sind Ihre Accessories als Programm lauffähig, nur damit ihnen mit einem Quelltext-Debugger zu Leibe gerückt werden kann? Haben Sie schon mal einen Fehler in Ihrem Accessory vermutet, und wollten Sie schon immer mal sehen, was in dem Accessory alles so abgeht? Haben Sie vielleicht schon mal einen Fehler in ein Accessory eingebaut, dem Sie nach stundenlanger Suche auf die Spur gekommen sind? Haben Sie aus lauter Verzweiflung schon mal versucht, ein in C geschriebenes Accessory mit Templemon zu debuggen?

Wenn Sie glücklicher Benutzer eines TURBO- oder PURE-C- Debuggers sind, können Sie Ihre Accesories auf Quelltextebene debuggen! Wie das geht? Ganz einfach: Kopieren Sie den Debugger samt TC.CFG oder PC.CFG auf Ihr Boot-Laufwerk, und ändern Sie den Datei-Extender des Debuggers in .ACC und die zu debuggenden Accessories in PRG um. Der Debugger verweigert beim Laden einer Datei mit dem Extender .ACC seine Mitarbeit. Booten Sie den Rechner neu, der Debugger wird ganz normal gestartet. Wählen Sie im Menü 'File‘ 'Load ...'. Das war’s, es kann losgehen.

Was Sie nicht machen dürfen: Das geladene Accessory mit 'run Program reset' anhalten und danach den Debugger terminieren. Wenn Sie einen Editor aufrufen wollen, muß dieser wahrscheinlich ebenfalls als Accessory lauffähig sein. Das habe ich noch nicht nachgeprüft. Der PURE-C-Debugger vom 03.02.93 macht größere Fehler beim Berechnen des Speicherbedarfs des geladenen Accessories. Woran das liegt, habe ich noch nicht herausgefunden. Die PURE_C- und TURBO.C-Debugger laufen nicht unter MultiTOS. Es gibt sicher noch mehr Mängel und Probleme. Vielleicht haben Sie etwas zu diesem Thema zu sagen, und schreiben einen Quicktip.

Holger Nassenstein

Rätselhafte Ausfälle

Rätselhafte Ausfälle (z.B. gelegentliche Rechnerabstürze oder nicht funktionierende Erweiterungen, insbesondere HD-Module) bei älteren 1040- oder Mega-STs werden oft durch verschmutzte oder oxidierte Verbindungsstecker zwischen Netzteil und Platine verursacht. An diesen Billigsteckern können unter Umständen über 0,5 Volt abfallen, so daß man zwar am Netzteil eine Betriebsspannung von 4,9 bis 5,0 Volt mißt, der Rechner aber im Grenzbereich von 4,4 Volt läuft. Als Abhilfe dient entweder das Reinigen des Steckers (Vorsicht mit Kontaktspray; es kann die Platine, insbesondere die IC-Fassungen, angreifen!) oder, womit man Problemen dauerhaft aus dem Weg geht, Steckverbinder ganz entfernen, die Kabel anlöten und das Netzteil mittels Lüsterklemmen mit der Rechnerplatine verbinden. Hierbei muß jedoch unbedingt auf richtige Polung geachtet werden!

Christian Rupp

Maus legal positionieren

Die Mausposition manipulieren, GEM-konform, unabhängig von Maustreiber, TOS-Version, Grafikkarte usw.? Ohne größere Umstände? Unmöglich? Nein! Man greift einfach zu einem kleinen Trick und simuliert für die AES-Funktion appl_tplay eine Mausbewegung. Fertig!

Andreas Barkhoff

PROCEDURE PosMouse(x,y: WORD);

(*  Positioniert den Mauszeiger an der Position x,y 
    (c)1993 by MAXON-Computer 
    Autor: Andreas Barkhoff 
    geschrieben in (Pure) Pascal *)
VAR
    Buff: ARRAY_4; (* Array aus vier Integern *)
BEGIN
    Buff[0]:= 0;    (* muß Null sein *)
    Buff[2]:= 2;    (* Code für Mausbewegung *)
    Buff[2]:= x;    (* x-Koordinate *)
    Buff[3]:= y;    (* y-Koordinate *)
    appl_tplay (ADDR(Buff),1,100); (* abspielen *)
END;

Nur lauffähig unter 640x400?

Viele Programme, die sich auf dem ST etabliert haben (z.B. TEMPUS, GFA-BASIC, GFA-DRAFT), scheinen auf dem TT arge Schwierigkeiten zu haben, was die Auflösungen betrifft. Für die original Video-Hardware mag das zutreffen, hier ist ein Arbeiten nur unter 640x400 duochrom möglich. Aber wenn eine Grafikkarte ins Spiel kommt [schon wegen der 60 (Flimmer-) Hz anzuraten), wandelt sich das Bild. Hier laufen TEMPUS, GFA-BASIC, GFA-DRAFT und ergo! sogar mit 1280x1024 Pixeln Auflösung, auch Write On funktioniert einwandfrei. Diese Programme bekommen keine Probleme mit der Auflösung an sich, sondern können anscheinend nicht mehr als eine Bitplane im Grafikspeicher verarbeiten. Solange also die duochrome Betriebsart nicht verlassen wird, kommen diese Programme auch mit allen höheren Auflösungen klar. Ich wage sogar die Prognose, daß auch andere Programme, von denen es heißt, sie könnten nur im ST High-Modus betrieben werden, mit einer Grafikkarte Auflösungen, die darüber liegen, verarbeiten können. Einen Versuch ist es allemal wert.

Thomas Müller

---

---