Dokumentation Scancode ---------------------- Geht es euch auch so? Euch nervt irgendwas tierisch und ihr wollt es verändern? Z.B. das ihr immer überlegen müßt, welcher Assemblerbefehl nun der schnellere ist oder ob ihr euren Ass-Code noch Optimieren könnt? Ich glaube dann habe ich das richtige für euch! Die Lösung heißt SCANCODE !!! Was ist Scancode? ----------------- Scancode untersucht Assembler-Source und gibt hiervon den Assembler-Source mit den dazugehörigen Taktzyklen aus. Dieses trifft jedoch nur auf gültige 68000 Befehle zu. Zusätzlich besitzt Scancode einen Direktdialog der es ermöglicht, direkt die entsprechende Anzahl an Taktzyklen abzu- fragen. Dazu später mehr. Leistungsmerkmale von Scancode ------------------------------ Scancode kann - ALLE Taktzyklen für ALLE 68000 Befehle ermitteln, egal mit welcher Adressierungsart oder mit welchen Operanden. - Scancode erkennt auch verwendete Variablen oder Konstanten und kann auch hieran die richtige Anzahl an Taktzyklen ermitteln! - Scancode kann, durch Optionen gesteuert, nach den Befehlen rte, rtr, rts, jmp, jsr oder bxx Zwischensummen ausgeben ( besonders nützlich wenn man nur Abschnitte oder Unter- programme optimieren will). - Scancode erkennt ungültige 68000 Befehle und stellt somit eine schnelle Hilfe für die Überprüfung von Source dar. - Scancode erkennt auch Befehle, bei denen nicht angegeben worden ist, ob sie LONG, WORD oder BYTE Adressiert worden sind. Hierbei geht Scancode davon aus, daß entweder der Befehl nur in einer einzigen Adressierungsart zugelassen ist (z.B. MULU ist immer WORD) bzw. ermittelt sich aus der Befehlstabelle den ersten Eintrag des Befehls, der (meistens) Byte ist. Ich weise deshalb darauf hin, daß jedem klar ist: wenn nicht SAUBER programmiert worden ist kommt auch SCHROTT raus! - Scancode kann Source übersetzen, der im - DEVPAC - METACOMCO - A68K Format vorliegt (andere standen mir zum testen nicht zur Verfügung). - Scancode besitzt eine Dialogschnittstelle die es ermög- licht, einzelne Befehle einzugeben und die entsprechende Anzahl an Taktzyklen direkt am Bildschirm anzuzeigen. Das ist besonders dann wichtig, wenn man am überlegen ist, welche Befehlskonstruktion die schnellere ist. - Scancode ist Giftware, also verdammt billig. - Scancode ist das einzige Programm, daß es hierfür (zum jetzigen Zeitpunkt (16.11.1992)) gibt! Scancode kann NICHT - Befehle übersetzen, die auf die 68010, 68020, 68030 oder 68040 CPU zugeschnitten sind (sofern es welche gibt ?). - Assembler-Source richtig formatieren, wenn sich in diesem Tabs befinden (sieht momentan nicht so schön aus). - ist (noch) nicht besonders schnell (siehe auch Abschnitt "Zeiten"). - gibt bei folgenden Befehlen die Anzahl der Taktzyklen nicht unbeding richtig wieder: ---> asl, asr, lsl, lsr, rol, ror, roxl, roxr, Und warum nicht? Weil bei diesen Befehlen die Anzahl der Taktzyklen davon abhängt, um wieviele Bits geschiftet werden soll. Und das kann ich nicht ermitteln, wenn ich dieses mit dem Inhalt eines Registers mache! Scancode nimmt deshlb einen Mittelwert, der nicht unbedingt mit den tatsächlichen Gegebenheiten übereinstimmen muß. Was besseres ist mir leider nicht eingefallen. Ihr seht also, Scancode ist garnicht mal übel. Gerade für die, die sich in Assembler zum ersten mal austoben wollen, ist Scancode eine tolle Hilfe. Aber auch bei den sog. Freaks kann Scancode eine Hilfe dar- stellen, den ich stelle immer wieder fest, daß einige ganz tolle Programme machen, aber die Ausführungszeit noch wesent- lich optimiert werden könnte. Auch mich zähle ich dazu! Aber wie soll man das ohne ein entsprechendes Hilfsmittel machen? Tja, jetzt habt ihr eins !!! Aufruf, Übergabeparameter ------------------------- Scancode kann NUR im CLI aufgerufen werden. Hierzu erfolgt der Aufruf wie folgt: SCANCODE Option(en) Source [Destination] Option(en): ----------- Scancode erwartet mind. eine Option! Wenn ihr keine angebt bekommt ihr einen Fehlermeldung. Optionen können sein: ? ---> Gibt einen kurzen Hilfetext aus. b ---> erzeugt hinter jedem bxx eine Zwischensumme. j ---> erzeugt hinter jedem jsr und jmp eine Zwischen- summe. l ---> erzeugt bei jeder Leerzeile eine Zwischensumme. r ---> erzeugt hinter jedem rts, rtr und rte eine Zwischensumme. t ---> sollte UNTER GAR KEINEN UMSTÄNDEN GENUTZT WERDEN ! Es dient ausschließlich meiner testerei. Wenn ihr es aber trotzdem eingebt .... selber schuld! Dann könnt ihr euch in der Zwischenzeit, in der Scancode arbeitet, eine Tasse Kaffee aufsetzen und warten! Soweit zu den Optionen, die ihr im sog. Batch einsetzen könnt. Voraussetzung hierfür ist also eine Eingabedatei die Scancode dann mit der Ergänzung ".TAKT" ausgibt oder eine von euch gewählte Datei. Die Optionen könen in jeder Reihenfolge eingegeben werden. Beispiele gefällig? O.K.: 1. Scancode jr MeinAssCode ---> Scancode liest die Datei "MeinAssCode" und gibt die Datei "MeinAssCode.TAKT" aus. Es werden dabei bei jedem JSR, JMP, RTR, RTS und RTE Zwischensummen ausgegeben. 2. Scancode rb MeinAssCode Dummy ---> Scancode liest die Datei "MeinAssCode" und gibt die Datei "Dummy" aus. Es werden dabei bei jedem RTR, RTS und Bxx Zwischensummen ausgegeben. 3. Scancode MeinAssCode Dummy ---> Scancode gibt einen Hilfetext aus! Soweit zu den Beispielen. Nun kommt der Sahnebonbon: Wenn ihr Scancode mit der Option "d" aufruft, so gelangt ihr in den Direktdialog. Hierzu muß die Eingabe im CLI wie folgt aussehen: Scancode d Das wars! Nun, was heißt hier Direktdialog? Nichts anderes, als das ihr die Befehle eingebt und Scancode euch erzählt, wieviele Taktzyklen dieser verbraucht. Wie, schon wieder ein Beispiel gefällig? Ja, ja, hier habt ihr eins: Eingabe ---> Scancode d Ausgabe ---> +------------------------------------------------------------------+ ! ScanCode Version 1.4 Copyright © 1992 by Jörg Wach (= JCL POWER) ! +------------------------------------------------------------------+ Direktdialog - Ende mit 'x' Bitte Befehl ---> Eingabe ---> move.l #variable, a1 Ausgabe ---> Taktzyklen: 28 Bitte Befehl ---> Eingabe ---> move.l a1,a2 Ausgabe ---> Taktzyklen: 4 Bitte Befehl ---> Eingabe ---> Sta a1 (für unsere alten 64er) Ausgabe ---> Kein Befehl! Bitte Befehl ---> Eingabe ---> rts Ausgabe ---> Taktzyklen: 12 Bitte Befehl ---> Eingabe ---> x Ausgabe ---> bye bye ... Ihr seht, total simplex, aber gerade bei der Programmentwick- lung bzw. wenn man mal schnell wissen will, wie lange denn so ein Befehl braucht, schnell und effektiv einsetzbar! Jau, so weit, so gut. Das kann Scancode. Einbindung in eigene Programme ------------------------------ Verdammt schwer, glaubt mirs, verdammt schwer. Zeiten ------ Scancode ist nach der Umschreibung in Amiga_E verdammt langsam geworden. Durch die Verwendung der gebufferten Eingabe konnte ich aber Scancode wieder auf den Level von Scancode unter PCQ setzen. Das nächste Release wird aufgrund einer besseren Tabellenverarbeitung nochmals um 120 - 150 % schneller sein als die jetzige Version. Die goldenen Proggi-Regeln -------------------------- Tja, also gerade für Anfäger ist es bei der großen Auswahl an 68000er Befehlen schwer, die richtigen Befehle zu verwenden. Also habe ich euch mal ein paar Tips zusammengestellt, wie man Programme schneller machen kann (erhebt keinen Anspruch auf Vollständigkeit!): 1. Nutzt die "Quick"-Befehle! Wenn es möglich ist, sollte man immer moveq, addq oder subq vorziehen. Moveq füllt euch in 4 (!) Taktzyklen ein Datenregister mit einer vorzeichenbehafteten Zahl im 8-Bit-Format (+ 127 bis - 128). Das Register wird Vorzeichenrichtig auf LONG erweitert. Addq und Subq subtrahieren sehr schnell Werte von 1 bis 8 und sind dabei erheblich schneller als die vergleichbaren Befehle ADDI bzw. SUBI. Auch Befehle wie "Move.l #10,Adresse" vergesst mal ganz schnell. Der Befehl braucht 10 Byte und 28 Taktzyklen. Besser gehts mit: moveq #10,d0 ---> 2 Byte und 4 Zyklen move.l d0,Adresse ---> 6 Byte und 20 Zyklen. Ersparnis: 2 Byte und 4 Taktzyklen. Oder wie wärs mit cmp.l #5,d0 ---> 6 Byte und 14 Zyklen ersetzt durch: moveq #5,d1 ---> 2 Byte und 4 Zyklen cmp.l d1,d0 ---> 2 Byte und 6 Zyklen. Ersparnis: 2 Byte und 4 Zyklen. Auch wenn die Grenzen für den Quick-Befehl überschritten werden (+127 bis -128) kann man doch auch bis zu den Werten 256 einiges an Zeit sparen, wie ihr hier seht: move.l #129,d0 ---> 6 Byte und 12 Zyklen ersetzt durch: moveq #256-129,d0 ---> 2 Byte und 4 Zyklen neg d0 ---> 2 Byte und 4 Zyklen. Ersparnis: 2 Byte und 4 Zyklen. 2. ASL, ASR, LSR, LSL vor Mulx bzw. Divx bei 2er Potenzen. Wenn ihr einen Wert mit 2, 4, 8, 16, 32, 64 oder 128 multiplizieren oder dividieren wollt, so nutzt nicht die MULx bzw. DIVx Befehle. Die Bit-Schiebe-Befehle sind in diesem Bereich erheblich schneller. Alles was darüber geht solltet ihr allerdings schon mit dem MULx bzw. DIVx-Befehlen behandeln, auch wenn euch ein paar Schlaumeier was anderes erzählen! Die Taktzyklenangaben bei diesen beiden Befehlen sind nämlich MAXIMALWERTE und wenn ich mich bei der Datenbeschreibung des 68000er nicht verlesen habe, kann man alles andere über diese beiden Befehle schneller laufen lassen (oder hat jemand andere Infos?). 3. Vermeidet den CLR.L-Befehl! Ich sehe es immer noch, daß ein paar Heinis schreiben --- clr.l D0 --- mit nicht zu verachtenden 6 Taktzyklen. Moveq ist einfach um 2 Taktzyklen schneller. Und Adressregister kann man, trotz gegenteiliger Meinungen, NICHT hiermit löschen! Was sollte man sich noch mit clr.x verscherzen? Seht euch folgende Aufstellung an: ---> clr.l $471111 = 28 Taktzyklen Alternative: ------------ moveq.l #0,d0 = 4 Taktzyklen move.l d0,$471111 = 20 Taktzyklen ---> Ersparnis: 4 Taktzyklen Etwas um die "Kurve" gedacht, aber schneller. 4. LEA ist auch ein Befehl! Und gar kein langsamer! Bei einigen Adressierung (z.B. 8-Bit Offset mit Addition, also sowas wie LEA $33(a0,d0),a1) ist dieser Befehl erheblich schneller und kürzer als vergleichbare Befehle. Auch ihn sollte man nutzen. Z.B. sollte man folgende Befehle durch Lea ersetzen: - movea.l #1974,a0 ---> 6 Byte und 12 Zyklen ersetzen durch: lea 1974,a0 ---> 4 Byte und 8 Taktzyklen. Ersparnis: 2 Byte und 4 Zyklen. - movea.l a0,a1 ---> 2 Byte und 4 Zyklen adda.l #1974,a1 ---> 6 Byte und 14 Zyklen ersetzen durch: lea 1974(a0),a1 ---> 4 Byte und 8 Zyklen. Ersparnis: 4 Byte und 10(!) Zyklen. So, wer jetzt meint "ach nur wegen der paar Taktzyklen macht der so einen Aufstand" der sei darauf hingewiesen, das gerade in Unterprogrammen, das z.B. pro Durchgang 200 mal durchlaufen wird, immerhin bei 4 Taktzyklen Zeitersparnis durch eine andere Program- mierung 800 Taktzyklen eingespart werden! Das ist für den Amiga eine verdammt lange Zeit!!! Wer noch andere ähnliche schlaue Tips auf Lager hat sollte diese doch mal, gerade für die Anfänger, veröffentlichen. Erklärung des Source-Codes -------------------------- Ich habe an einigen Stellen, hauptsächlich in den Prozeduren und Funktionen, den Source-Code erläutert. Verständlich ist er mit Bestimmtheit auf den ersten Blick nicht, vor allem diese wahnsinnige Tabellenverarbeitung, die mich mal wieder ein paar graue Haare mehr gekostet hat, hat es in sich. Sonstiges --------- Also, die Entwicklung selber spukte bei mir schon seit dem Februar im Kopf rum. Aber ich hatte einfach keine Lust, diese verdammte Befehls- tabelle mit allen Taktzyklen und Addressierungarten einzugeben. Bis ich dann, aufgrund der Game.Lib, unbedingt wissen mußte, wieviel Zeit einige Befehle brauchten. Und dann ging es los! Tabelle raus, nachsehen, nächsten Befehl ansehen, Tabelle nachsehen, Taktzyklen aufschreiben usw. usw. Ich hatte einfach keine Lust mehr zu dieser blöden Arbeitsweise. Also habe ich in den sauren Apfel gebissen und die Tabelle mit ihren 273 * 13 Einträgen eingegeben (macht also nur für die Tabelle 3.549 mal die Zahlen, Befehle und Steueranweisungen eintippen!!!). War eine ganz schöne Arbeit (von der Zeit ganz zu schweigen) und trotzdem, es ist was geworden. Warum das Ding nun noch fast 4 Wochen bei mir rumlag? Nun, nichts geht über ausführliche Tests und da habe ich noch manchen Fehler ausge- bügelt, denn ihr sollt ja ein vernünftiges Werkzeug bekommen (wenn ich an die Basisversion denke, au weia ....). Nichts desto Trotz kann es sein, daß sich noch Fehler im Programm, im Besonderen in der Codetabelle, befinden, denn die mußte ich im 2-Augen Prinzip eingeben und prüfen. Da aber der alte Spruch gilt "Traue nur Angaben, die du selber gefälscht hast" können in der Codetabelle noch Fehler sein. DESHALB BEI AUFTRETENEN FEHLERN ODER UNGEREIMTHEITEN SOFORT MICH INFORMIEREN! Am besten telefonisch oder per Brief bzw. Postkarte. Copyrights ---------- Wer versucht hat, das Copyright zu überlesen, dem sei nochmals gesagt: Copyright © 1992, 1993 by Jörg Wach (= JCL POWER) Dieses von mir geschriebene Programm ist GiftWare. Es darf nur als GESAMTPACKET, also mit ALLEN Dateien, weitergegeben werden. Ich untersage AUSDRÜCKLICH die gewerbsmäßige Verwendung. Eine solche liegt vor, wenn Teile des Programmes oder das Programm als Ganzes als Softwareprodukt verkauft oder verliehen wird und dieses gegen einen Geldwert von mehr als 3,-- DM (bzw. den Gegenwert in anderen Währungen) erfolgt. Außerdem untersage ich AUSDRÜCKLICH die Veröffentlichung des Programmes als Ganzes oder in Teilen in Zeitschriften. Ganauso behalte ich mir rechtliche Schritte gegen einen gewerbsmäßigen Vertrieb des Programmes vor, es sei denn, es wurde mit mir ein Nutzungsvertrag abgeschlossen bzw. meine Zustimmung liegt AUSDRÜCKLICH vor. Eine NICHTBEACHTUNG kann zu einer strafrechtlichen Verfolgung FÜHREN! So, damit habe ich alles gegenüber diesen Softwarehaien gesagt! Ansonsten darf es von jedem genutzt werden. Wen das Programm öfters genutzt wird bitte ich um eine kleine Spende (z.B. Tafel Schocko, Disketten oder -schreiber, Windeln (saubere!), Geld, Briefmarken und was euch noch so einfällt). Am LIEBSTEN wäre es mir aber, wenn ihr mir Dokumentationen über die 68010, 68020, 68030, 68040 - CPU's schickt, damit ich deren Besonderheiten auch in dem Programm abbilden kann (sofern es welche gibt). Und bitte vergesst nicht eure Kritik an mich zu schreiben, denn in den nächsten Programmen wird diese mit Bestimmtheit einfließen. Dateiverzeichnis ---------------- Scancode ---> Das Programm Scancode.e ---> Source.Code in Amiga_E (Yeah) Scancode.Doc ---> Na, was wohl ? und die entsprechenden Infofiles dazu. Historie -------- Version 1.7 --> 31.08.93 Wouter hat mein Programm durch seinen Profiler 'gejagt', und siehe da, daß Programm ist nochmals wesentlich schneller geworden. Die Kommentare von Wouter möchte ich euch nicht vor- enthalten, deshalb hier sein original-Anmerkungen: habe ICH ein überrasschung für dich: ---> ich habe scancode 10x schneller gemacht!!!!!!!!!!!!!!! <--- (also precise nür 10.7% von die originelle zeit!) das hat alles begonnen, wan ich in deine zeiten (18,6 <-> 4) in der doc gelesen habe: manchmal wist man nicht, das nuer einige kleine teilen in ein program die ganze zeit auffressen (z.b ReadStr). Ich fand es ein nützlich experiment, zu sehen wie einfach man ein program schneller machen kan mit ein profiler. mit v2.3 gibts ein profiler, un deshalb könnte ich sehen das dein program 80% mit suchen in holetakt() nach die asbefehl seine zeit verbringt, und deswegen habe ich dieses teil in ein eigene function unterbracht. (sehe source, suche nach "/***", function ist "findtabelle()"). dein originel: Execution profile for: scancode % StrLen 92376 0.000 26.572 0.000 0.004 StrCmp 93730 0.000 26.443 0.000 0.003 Char 11520 0.000 3.025 0.000 0.003 WriteF 691 0.008 5.795 0.006 0.014 holetakt 497 0.070 34.625 0.000 0.159 main 1 1.181 1.181 1.181 1.181 das kostete für mein source vector6.s in seconden: --> 22.151 ich hab StrLen (ein aufwendige function) aus die FOR geholt, und einige weitere sachen, es ist jetzt nür noch: --> 13.887 nun bin ich die suche angefangen beim richtigen buchstabe, statt am anfang: --> 8.088 also nun mal die innere FOR in assembly umschreiben: --> 4.070 und weiterhin einige WriteF in Write erzetsen, und einige überflüssige lange IF AND AND... statements einkürzen: --> 2.379 geil was? also nun kannst du ruhig in die docs schreiben: "v1.70: Wouter hat das program in ne halbe stunde 10x schneller gemacht." Execution profile for: scan % LowerStr 445 0.003 1.332 0.003 0.021 MidStr 447 0.003 1.323 0.003 0.017 EstrLen 2013 0.002 5.006 0.002 0.024 StrLen 472 0.004 1.956 0.002 0.028 StrCmp 2945 0.003 8.972 0.003 0.027 Char 830 0.002 2.065 0.002 0.024 WriteF 280 0.059 16.480 0.056 0.110 readstrbuf 498 0.017 8.643 0.003 0.058 holetakt 497 0.035 17.389 0.004 0.377 findtabelle 445 0.019 8.344 0.003 0.055 holeop 445 0.012 5.313 0.003 0.036 holebefehl 497 0.006 2.847 0.003 0.025 testvaradr 243 0.006 1.451 0.003 0.021 writef 464 0.016 7.383 0.015 0.039 main 1 10.677 10.677 10.677 10.677 wie du sehst gibts auch hier noch ne menge zu optimieren. (also diese timings sind mit v2.3i, aber die verhältnis 1:10 sollte gleich sein bei dir.) Version 1.64 --> 20.06.93 Wouter wollte gerne ein Option, mit der nach jedem Blank eine Zwischensumme ausgeworfen wird. O.K., hier ist sie: 'l'. Außerdem habe ich den Code (ein kleines bischen) optimiert. Der Befehl "move.l (ax,dx.w),ax" wurde falsch berechnet! Fehler ist behoben. Die gebufferte Ein-/Ausgabe hat die erste Zeile nie ausgegeben. Fehler behoben. Version 1.63 --> 12.06.93 Es ist jetzt 1:05. Und ich habe den Fehler gefunden! Scancode hat den VB-server nicht freigegeben, weil bei Leeraufruf kein Exit stand. Sowas blödes!!! Version 1.62T--> 14.04.93 Ha, ich habs!!! Keine gepufferte Eingabe!!! Deshalb Version 1.62T, wie TUNING! Deshalb habe ich eine eigene ReadStr-Routine geschrieben, die, mit variablen Buffern, den Input gebuffert einliest. Jetzt sind es für 22K Source nur noch 6 Sekunden! Version 1.62 --> 08.04.93 Oh, oh !!!!! Warum verbraucht denn Scancode in Amiga_E für eine 22K Datei 18 Sekunden (!!!) und Scancode in PCQ nur 4 Sekunden???? Deshalb gibt es diese Zwischerelease, um mit einem Vertikal-Blank-Interrupt die Zeiten zu messen. Version 1.61 --> 06.04.93 1. Die Lesetab-Routine wies einen Fehler auf (hat nie den Returncode -1 zurückgegeben). Fehler is wech. 2. Die Probleme mit der Darstellung von TABS ist auch behoben (endlich!). Version 1.6 ---> 05.04.93 Andre Lämmer (hey Mr. Execbase) hat mir (endlich) zwei Fehler mitgeteilt: - move.l SP,Stack liefert 36 Taktzyklen, aber move.l a7,Stack liefert 20 Taktzyklen. Okay, okay, Du hast einen gefunden. Jetzt ist der Fehler weg. - Illegal ist überhaupt nicht definiert! Oh, oh, ich töffel. Ich dachte immer, Illegal wären illegale 68000 Befehle und sind deshalb NIE definiert! So ein Quatsch! Also, ab jetzt ist ILLEGAL mit 34 Taktzyklen registriert. Vielen Dank, Andre !!!! Version 1.5 ---> 24.03.93 Was, schon wieder 5 Monate her, da ich das Programm angepackt habe? Man, man man ........ Wie die Zeit vergeht. Das Programm wurde KOMPLETT in AMIGA_E umgeschrieben (hey, danke Wouter). Keine weiteren Änderungen. Version 1.4 ---> 24.10.92 So, jetzt kann ich das Programm veröffentlichen. Habe noch ein paar kleine Fehler ausgebaut und eine kleine farbige Ausgabe im CLI eingebaut. Außerdem ist das Programm ein bischen schneller geworden durch den neuen Sprungalgorithmus (was das wohl ist???). Version 1.3 ---> 12.10.92 Ich komme einfach nicht von der Stelle! Endlich habe ich es jetzt geschafft. Dauernd hat sich Scancode bei bestimmten Konstellationen aufgehängt. Ist jetzt aber beseitigt. Version 1.2 ---> 24/25.09.92 1. Nachdem ich Scancode über einige Sources hab laufen lassen ist mir aufgefallen, daß er z.B. move.l variable(a0),$xyz nicht richtig interpretiert. Die Ermittlung eines Befehls klappt auch nicht wenn in der selben Zeile eine Labelangabe war (machen anscheinend viele). Beide Fehler sind jetzt korrigiert. Version 1.1 ---> 20.09.92 1. Habe kleine Fehler beseitigt und dabei ist es mir das erste mal passiert, daß die Code-Tab von PCQ für eine Prozedur zu voll war! Also: Splitting heißt das Zauberwort. 2. Habe mit Nils telefoniert und der meinte, ob man den Befehl eingeben müßte und das Programm dann die entsprechende Anzahl an Taktzyklen aus- geben würde. Die Idee fand ich gut und habe den 'Direktdialog' eingebaut. Ist auch für mich leichter Fehler zu finden. Version 1.0 ---> 15.09.92 Heute steht die Rumpfversion. Ist getestet und läuft sauber ab. With best wisches and nice days !! !!!!! !!!!! ! ! !!!!! !!!!! !! !! !! !! !! ! ! !! !! !! !! !!!!! !! !! ! ! !!!!! !!!!! !!! !! !! !! ! ! ! !! !!! !!!! !! !!!!! !!!!! !!!!! !! !! !!!! !! Jörg Wach !! Waitzstr. 75 !! !!!! 24105 Kiel !! Tel.: 0431/57 84 85 !! !! Westdeutschland !! !!!!! 31.08.1993