Leserbriefe

PASCAL-Programmierung auf dem ST

Ich besitze einen Atari Mega ST2 und den PASCAL-Compiler von CCD. Die Beschreibung der GEM-Funktionen im Handbuch des Compilers ist zwar sehr umfassend, setzt aber leider GEM-Kenntnisse voraus, die ich als ‘GEM-Anfänger' nicht besitze.

Meine Frage an Sie ist, ob Ihnen Bücher bekannt sind, die die GEM-Routinen für Anfänger verständlich, und zugleich die Handhabung vom CCD-Pascal aus beschreiben. Während meiner bisherigen Suche habe ich zwar mehrere Bücher über GEM entdeckt, die sich aber alle auf C als Programmiersprache beziehen.

(Stefan LambertSpiesen-Elversberg)

Red.: Leider ist der Markt an Büchern, die sich mit PASCAL auf dem ST beschäftigen, relativ klein. Zunächst möchten wir Sie darauf hinweisen, daß CCD seine Dokumentation zu PASCAL 2.0 völlig überarbeitet hat und sie ist zu einem Preis von 49,- DM plus 5,- DM Versandkosten für eingetragene Pascal-Plus-Benutzer bei CCD zu beziehen. Das einzige Buch, das wir ausfindig machen konnten und das sich mit PASCAL-Plus beschäftigt, geht nicht besonders stark auf GEM ein: es ist von Peter Wollschläger und heißt ATARI-ST-Programmierpraxis ST-Pascal. Da ST-PASCAL in der 2.0-Version allerdings alle GEM-Routinen vor-definiert hat, und diese im Aufruf praktisch wie in C aussehen, würden wir Vorschlägen, sich eines der sehr guten C-angelehnten Bücher wie zum Beispiel “Softwareentwicklung auf dem ATARI ST” aus dem Hüthig Verlag (Buchbesprechung Mai 1987) oder “Das Profibuch” aus dem Sybex-Verlag (Buchsprechung März 1988) anzusehen.

*

Accessories sind aber in Assembler möglich?!

Ich lese in der ST-Computer Februar ’88, daß es unmöglich sei, ein Accessory in GFA-Basic zu erstellen. Schon gut, aber es ist mit Assembler zweifellos möglich. Würden Sie bitte so gut sein und ein Accessory in Assembler abdrucken? Das Programm müßte ja nur “Hello” auf den Bildschirm schreiben. Was wichtig ist, ist, wie man ein solches Accessory initialisieren muß. Nur noch ein Wort ‘Congratulations for the quality of your magazine. As you can see, you have rea-ders far from home’.

(Bernard Boust, Le Petit-Quevilly)

Red.: Merci beaucoup! We appreciate having readers far from home and like to thank all those who send us letters from foreign countries, even Bolivia is one of them. Back to german: Sie haben recht, wir werden demnächst in einer Folge der ST-Ecke für einige Programmsprachen ein kleines Accessory-Skelett darlegen. Da an dieser Stelle Assembler zu umfangreich ist, hilft Ihnen vielleicht aber ein C-Skelett weiter (s.Listing).

extern gl_apid; 
main ()
{
    int msgbuff [8] ; /* Ereignis-Puffer */ 
    appl_init(); /*Initialisierung des GEM-AES */ 
    menu_id=menu_register (gl_apid, "Mein Eintrag") ; 
    while(l) /* Accessories enden nie ! */
    {
        evnt_mesag (msgbuff) ; /* Ist unsere Accessory gemeint ? */ 
        if (msgbuff [0]==AC_OPEN && msgbuff [3]-=menu_ud)
        { /* hier kommt ihr Programm hin. */ 
            printf ("Hello\n") ;
        }
    }
}

C-Skelett für die Programmierung eines Accessorys

*

IMAGIC-Nachlese

Nachdem ich die neueste Ausgabe Ihrer Zeitschrift gelesen habe, habe ich einige Bemerkungen, die ich unbedingt loswerden muß. Daher schreibe ich Ihnen diesen Leserbrief:

Mich irritiert in zunehmendem Maße die Inkompatibilität verschiedener Programmier- und Entwicklungssysteme. Ich beziehe mich hier auf die unterschiedlichen Objekt-File-Formate...Auf dem IBM setzt z.B. Microsoft Maßstäbe, auf dem Atari ST dagegen...? In Ihrem Artikel über “Imagic” schreiben Sie, daß es zwar möglich, aber nicht sinnvoll ist, mehr als 71 Bilder pro Sekunde im Rechner aufzubauen. Ich muß Sie korrigieren: Es ist allein schon von der Rechengeschwindigkeit des 68000 her unmöglich, ganze Bilder in dieser Zeit aufzubauen. Eine kleine Rechnung:

Der Bildschirmspeicher des ST hat immer 32000 Bytes. Der einfachste und schnellste Befehl zur Beeinflussung dieses Speichers ist im Prinzip MOVE.L Dn,(An)+; er dauert 12 Taktzyklen. Dazu kommt dann noch ein Branch, der mindestens 10 Taktzyklen benötigt. Diese kleine Schleife muß bei 8 MHz 8000 mal durchlaufen werden und dauert daher 8000* (12+10), also 176000 Taktzyklen, gleich 0.022 Sekunden. Das sind etwa 45 Bilder pro Sekunde. Es ist also nur möglich, Teile eines Bildes in weniger als 1/71 Sekunde aufzubauen, aber niemals ein ganzes Bild.

Angesichts der obigen Rechnung erscheint es mir auch zweifelhaft, ob sich wirklich ganze Bilder in 1/25 Sekunde dekomprimieren lassen. Ungepackt lassen sich in einem ST mit 1 MB auch höchstens 32 Bilder lagern, wenn man wirklich alles über Bord wirft. Das gibt etwa eine halbe Sekunde Bildervergnügen. Daher ist Ihre Beschreibung von “IMAGIC" zumindest an dieser Stelle sachlich unkorrekt. Es ist wahrscheinlicher, daß IMAGIC Bilderfolgen im Speicher hat und nur die Unterschiede von Bild zu Bild speichert und entsprechend packt. Hätte man 1000 komplett unterschiedliche Bilder im Speicher, käme etwa alle Sekunde ein Bild auf den Bildschirm, da so dichtes Packen viel Zeit braucht - hier gilt eine alte Regel: Der Speicherverbrauch ist umgekehrt proportional zum Zeitverbrauch. Nur mit einem Blitter ginge der Bildschirmaufbau schneller. Leider haben Sie in ihrem Test vergessen, den Punkt zu erwähnen, ob der Blitter unterstützt wird oder, wie in so vielen Programmen, nicht.

Red.: Zunächst einmal möchten wir uns bedanken, daß Sie sich so viel Mühe in der Berechnung der Zeiten gemacht haben. Leider müssen wir Ihnen aber mitteilen, daß Sie nicht ganz recht haben. Der Artikel von IMAGIC war gut recherchiert, allerdings haben wir uns aufgrund Ihres Leserbriefes noch einmal mit den Programmierern unterhalten. Um es vorwegzunehmen: Alle Aussagen, die im Artikel gemacht wurden, sind korrekt.

Zunächst möchten wir zur Bildkopierroutine Stellung nehmen: Die einfachste Routine wäre theoretisch mit dem Befehl MOVE.L (An)+,(An)+ zu bekommen und nicht, wie Sie schreiben, mit MOVE.L Dn,(An)+, da dieser Befehl den Bildschirm nur mit einem Wert füllen würde. Daher wird die Routine noch langsamer, was für Sie sprechen würde, weil derBefehl MOVE.L (An)(An)+ 20 Zyklen + 10 Zyklen eines DBRanches sogar 2400000 Zyklen ergeben würde. Trotzdem ist es über folgenden Trick möglich, die Routine enorm zu beschleunigen: Benutzt man den Befehl MOVEM.L (An)+ .Registerliste, so läßt sich eine Routine schreiben, die nur etwa 148000 Zyklen (entspricht etwa 54, abzüglich der Interrupts 50 Bilder) benötigt und etwa folgendermaßen aussieht:

movem.l (A0)+, Registerliste  
movem.l Registerliste, (Al) 
lea distanz (Al),(A1) 
dbra reg, label

Allerdings werden Sie feststellen, daß im Artikel nicht steht, daß 71 Bilder pro Sekunde aufgebaut, sondern dargestellt werden, was ein großer Unterschied ist. Wie Sie als Programmierer wissen, kann man beim ST durch einfaches Ändern eines Zeigers einen anderen Bildschirminhalt einblenden, was theoretisch schneller (aber wie erwähnt nicht sinnvoll) geht als 71 mal in der Sekunde! Ungepackte Sequenzen sind daher mit einer so hohen Geschwindigkeit möglich, wobei dies bei einem 4 MB-Rechner zu einer Sequenz von etwa 2 Sekunden führen würde. Möchte man längere Bilderfolgen, muß man sich damit begnügen, mit gepackten Bildern zu arbeiten. Die schnellste und speichergünstigste Art dabei ist, wie Sie schon richtig bemerkten, die Differenzkomprimierung, die sich besonders bei nicht allzu starken Unterschieden zwischen verschiedenen Bildern auszahlt. Nur bei dieser Methode ist auch möglich, über tausend Bilder in einen MEGA ST4 zu bekommen - trotzdem beachtlich, denn das bedeutet für jedes Bild 4 Kilobyte. Die Dekomprimierung dieser differenzkomprimierten Bilder ist, da hier nicht ganze Bilder bewegt werden, tatsächlich mit bis zu 25 Bildern (je nach Komplexität) möglich, was mir die Firma IMAGIC Grafik ausdrücklich bestätigte - machen Sie die Probe aufs Exempel. Eine sachliche Unkorrektheit liegt also nicht vor! Betrachtet man das Beispiel von völlig unterschiedlich gepackten Bildern, so wird bei Imagic immer noch eine Geschwindigkeit von 5-6 Bildern pro Sekunde erreicht (minimal 4 Bilder!) und nicht, wie Sie schätzten, von einem Bild. Die Zeiten sind übrigens alle ohne Blitter. Der Blitter wird von Imagic unterstützt, wobei es übrigens so ist, daß Bildausschnitte, die nicht mehr als ein Viertel des Bildschirms ausmachen, schneller über eigene Routinen bewegt werden, als wenn man die BitBlt-Routine des Betriebssystems nehmen würde, die den Blitter benutzt. Imagic repariert als erstes Programm sogar die ab und zu vorkommenden Busfehler des Blitters (siehe ST-Ecke, ST-Computer Juni ’88).

Wir hoffen, Sie davon überzeugt zu haben, daß alles seine Richtigkeit hat, und nicht aus der hohlen Hand gegriffen ist. Sollten Sie dennoch Zweifel haben, so wird sie Ihnen die Firma IMAGIC Grafik in einem Gespräch alle nehmen, außerdem läßt sich alles ausprobieren.

Zu dem Problem der Inkompatibilitäten der Entwicklungssysteme: Selbst auf dem MS-DOS-Sektor gibt es unterschiedliche Formate (nehmen Sie nur TURBO-C und Microsoft-C), so daß es dort auch nicht unbedingt besser aussieht als auf dem ATARI ST. Auf dem ST gibt es aber einen Link-Standard, der durch das Entwicklungssystem von Digital Research, das von ATARI vertrieben wird, gesetzt wurde. An dieses Format hat sich zum Beispiel CCD-Pascal gehalten, und MEGAMAX 2.0, das demnächst auf den Markt kommt, wird dieses Format auch haben - wie noch ein paar andere Systeme. Wir sind dabei, die Formate zusammenzutragen (das alte Megamax-Format ist übrigens in den Unterlagen dargestellt), aber diese Serie wird wahrscheinlich noch ein wenig auf sich warten lassen. Umwandlungsprogramme sind wahrscheinlich schwierig, da verschiedene Formate unterschiedliche Stackbehandlung von globalen und lokalen Variablen haben. Sollten Sie Entwickler sein, so wird Ihnen ATARI sicherlich bereitwillig Information über dieses Format zukommen lassen. Nebenbei: wir haben vor einigen Monaten sogar einen Linker veröffentlicht.

*

Dialogverarbeitung und Accessories in GFA-BASIC

Ich möchte bezüglich der Dialogboxenverwaltung in GFA-BASIC einige Fragen an Sie richten. Kann man die “FORM-DO”-Routine umgehen? Auch wenn in der Dialogbox nichts passiert, kann man keine anderen Programmschritte mehr ausführen lassen. Mein Ziel: Der Rechner soll Daten verarbeiten und gleichzeitig Ereignisse in der Box beachten (Interrupt?).

Können in GFA-BASIC auch Accessories geschrieben werden und wenn ja, wie?

Ist es möglich, eine Hardcopy von GFA-BASIC so zu beeinflussen, daß der Drucker eine Zeile doppelt ausdruckt, um ein dunkleres Bild zu erreichen?

Können Sie mir eine Aufschlüsselung aller GEMSYS schicken?

(Rudolf Hausmann, Steinbach)

Red.: Wie in der ST-Computer-Ausgabe 7/87 beschrieben worden ist, kann man sich auch eine eigene Form_Do-Routine ‘zurechtstricken’. Das dabei gezeigte Beispiel ist zwar in C geschrieben, es spricht aber nichts dagegen, diese Routine auch in GFA-BASIC zu realisieren. Verzichtet man auf Edit-Felder, so läßt sich die Bearbeitung stark vereinfachen, da man dann nur noch mit objc_find() aus den gegebenen x/y-Koordinaten das Objekt ermitteln muß. Eine Interrupt-bearbeitung ist schwierig, da AES- und VDI-Routinen des GEM nicht reentrant sind und daher aus dem Interrupt nicht aufgerufen werden sollen.

Accessories sind bisher mit GFA-BASIC noch nicht möglich. Wie von GFA aber zu erfahren war, wird darüber nachgedacht, in den neuen zu GFA-Basic 3.0 gehörenden Compiler entsprechende Optionen einzubauen. Da dies aber nicht sicher ist, und man sicher noch ein knappes halbes Jahr auf den Compiler warten muß, heißt die Antwort “NEIN”.

Will man eine Hardcopy-Routine mit doppelter Zeile aus-drucken, so kann man sich sicherlich eine eigene Routine schreiben. Eine einfache Manipulation ist, soweit wir wissen, nicht möglich. Vielleicht weiß ein Leser mehr?

Verzeihen Sie, aber Ihnen eine Aufschlüsselung der GEM-Befehle Ihnen zuzuschicken, ist leider nicht möglich, bedenkt man, wieviele Befehle GEM enthält. Selbst eine reine Angabe der Befehle mit Parameter würde viele Seiten füllen. Außerdem sind die Befehle (auch mit Parametern) ohne ausführliche Erklärung bei GEM nicht sinnvoll. Es gibt aber genügend umfangreiche Bücher, die sich mit diesem Thema beschäftigen und angemessene Preise haben.

*

MEGA-Tastatur

Kann man an den ST520+ eine neue MEGA-Tastatur anschließen? Mein Rechner wurde in ein PC-Gehäuse eingebaut und die neue Tastatur soll doch sehr gut

Thomas Linkmacher

Red.: Zugegeben, die neue MEGA-ST-Tastatur ist um einiges besser als die der kleineren Brüder, auch der Anschluß ist theoretisch möglich, die Tastatur wird aber normalerweise nicht einzeln verkauft. Allerdings könnten Sie probieren, sie als Ersatzteil bei Ihrem ATARI-Händler zu beziehen. Als Alternative gibt es aber inzwischen Interfaces (Schnittstellen), die es ermöglichen, PC-Tastaturen an den ST anzuschließen, und das sogar mit relativ kleinem Aufwand.

*

Anfänger

Ich bin Anfänger, und für mich stellen sich folgende Fragen: Wie werden Programmlistings in höheren Programmiersprachen in den ST eingegeben? Braucht man für jede Programmiersprache einen eigenen Compiler? Mit welcher Sprache soll man als Einsteiger anfangen, um richtiges Programmieren zu erlernen? Gibt es zu diesen Sprachen Übungsbücher mit Lösungen, um sich zu kontrollieren?

(Josef David, Wenden 1)

Im Unterschied zu Home-Computern, wie zum Beispiel dem C-64 oder dem ATARI XL, ist die Eingabemöglichkeit einer Programmiersprache in einem Personal Computer wie dem ATARI ST nicht integriert, sondern muß als Programm geladen werden. Ein solches Programm nennt sich Editor und ist eine Art Textverarbeitung, die es ermöglicht, Programmtexte möglichst schnell einzugeben. Furore wegen seiner Schnelligkeit hat in diesem Zusammenhang etwa vor einem Jahr der Editor TEMPUS gemacht.

Leider braucht man für jede Programmiersprache einen eigenen Compiler, da dieser auf die jeweilige komplexe Art derselben abgestimmt werden muß - das liegt nun einmal in der Natur der Sache.

Mit welcher Sprache man anfangen soll, darüber streiten sich bekanntlich die Gelehrten. Früher hieß es BASIC (Beginnes All Purpose Symbolic Instruction Code - Für Anfänger allgemein geeignete Sprache), allerdings verführt dieses allzusehr zum unstrukturierten Programmieren. Daraufhin wurde von Niklaus Wirth PASCAL für seine Studenten entwickelt, was auch bald auf viele Rechnern implementiert wurde.

Eine weitere sehr schöne aber zugegeben für den Anfänger etwas schwierige Sprache ist C, die “Muttersprache” des ATARI ST. Die neueste Welle ist MODULA 2, was eine Weiterentwicklung in Richtung auf noch stärkere Modularität und Strukturierung in Bezug auf PASCAL darstellt, aber selbst BASIC erlebt durch seinen Verlust der Zeilennum-mem und der Vermeidung der so verpönten GOTOs eine Wiedergeburt und hat heute schon starke Ähnlichkeit mit PASCAL. Auf Universitäten und Fachhochschulen wird heute hauptsächlich PASCAL und C gelehrt, PASCAL setzt sich auch in den Schulen durch.

Wenn ich heute noch einmal beginnen müßte, würde ich es wahrscheinlich mit MODULA 2 versuchen oder, falls man keinen Lehrer zu Verfügung hat, mit BASIC, da es darüber die meisten Bücher gibt. Achten Sie aber darauf, daß Sie schon von früh an auch in BASIC strukturiert programmieren und vielleicht gleich mit einem BASIC arbeiten, welches überhaupt keine Zeilennummem, sondern nur noch Prozeduren besitzt.

Gerade im BASIC-Bereich gibt es sehr viele Bücher, die auch teilweise für das Selbststudium mit Fragen und Antworten gedacht sind. Leider sind diese noch oft auf das alte BASIC ausgelegt, also besser einmal schauen, ob es schon etwas Neueres in dieser Richtung gibt.

*

Wie funktioniert das RCS?

Es würde mich sehr freuen, wenn Sie einmal einen Artikel über die RCS-Diskette bringen könnten. Denn darauf ist zwar eine Beschreibung über die Programmänderungen, nicht aber, wie man überhaupt ein Programm eingeben kann, was doch das Wichtigste ist. Was nützt mir sonst die Diskette? Vielleicht wäre so ein praktischer Artikel für manchen interessant.

(Wilhelm Leurs, Bonn)

Red.: Richtig! Das haben wir uns auch gedacht, als wir unser zweites Sonderheft herausbrachten. Deshalb haben wir den ersten Artikel des Sonderheftes einer Einfühmng in das RCS und den zweiten der Verwendung der vom RCS erzeugten Dateien gewidmet. Ich bitte Sie daher, einmal in unser zweites Sonderheft hineinzuschauen; dort werden Sie alle wichtigen Informationen bezüglich der Handhabung des Resource Construction Sets finden. Übrigens: Im RCS können Sie keine Programme eingeben, sondern nur die bekannten Dialogboxen und Menüleisten erstellen. Die dann abgespeicherte Datei kann später in eigenen Programmen verwendet werden.

Probleme mit dem MEGA ST

Ich hatte ein Jahr lang einen 1040 ST und jetzt, seit einem halben Jahr den MEGA ST4. Es gibt sehr interessante Programme, die aber leider auf dem MEGA ST nicht funktionieren. Wo liegt da der Fehler, und kann man etwas machen, daß auch diese Software wieder anzuwenden ist? Vielleicht können Sie mir weiterhelfen.

Red.: Wahrscheinlich haben sich die Programmierer bei ihrer Arbeit leider nicht an die von ATARI strikt gegebenen Regeln gehalten und haben zum Beispiel undokumentierte oder für spätere Betriebssystemversionen nicht festgelegte Adressen benutzt. Die beste Methode ist, sich bei den entsprechenden Firmen zu beschweren und auf Abhilfe zu pochen. Eine gute Firma kennt das Problem sowieso, hat schon längst für Abhilfe gesorgt und wird Ihnen sofort behilflich sein. Solange kann ich Ihnen nur folgenden Tip geben: Es ist auch bei eingebauten ROMs möglich, das Betriebssystem von der Diskette zu booten, so daß es sich anbietet, das alte Betriebssystem von der Diskette zu laden und nicht das der ROMs zu benutzen. Da Sie einen MEGA ST4 besitzen, spielt Speicherplatz bei Ihnen nun wirklich keine Rolle. Natürlich löst dies das Problem nicht bei Programmen, die gebootet werden müssen; da hilft nur der rettende Griff zum Briefpapier oder zum Hörer.



Links

Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]