Hallo Dirk,
danke erstmal für prompte Antwort.
Nun, da ist mir beim Abtippen wieder mal ein kleiner Fehler unterlaufen.
Der Sprung erfolgt ja nicht wieder ins Label "Verzoegerung" sondern allesamt hinter dem brlt-Befehl nach "Verzoegerung1".
Die Sache mit dem Brlt Befehl ist ja die, daß er nur zusammen mit einem anderen definierten Befehl hier CPI also Compare-Befehl, hier auf die nächstfolgende Programmzeile, hier "Auftanken" von Register temp1 - Fortfahren im Programm springt, wenn das zu dekrementierende Register kleiner als 1, also Null wird.
Damit aber nicht wieder auf den Anfang gesprungen wird, solange diese Bedingung nicht erfüllt ist, wird auf ein hinter dem BRLT-Befehl stehendes Label verwiesen, in dem Falle also Verzoegerung1, nicht Verzoegerung, sonst würde sich das Register ja wieder auf den vollen Wert laden und die Schleife würde immer von vorne mit Subtrahieren zu tun haben. Von daher ein zweites Label ohne den "Nachladevorgang".
(Zu Beginn der zweiten Schleife soll dann aber der Ladewert des ersten Registers wieder vollgeladen werden.
Dieses Register wird ja dann im folgenden Befehl nicht dekrementiert sondern ein anderes (temp2). Ist das leer, sprich kleiner 1, dann erst return zum Hauptprogramm, so daß beide Schleifen sich also quasi wie Zähler verhalten, die sich "multiplizieren" in ihren Werten und nicht nur zwei Register, die nacheinander etwas Vorgegebenes abziehen.
Die Lade-Werte können nun auch variiert werden.)
Wenn man so will, bestimmt die "zweite" Schleife die Anzahl, wie oft die "erste" Schleife durchlaufen werden soll.
Nun nochmal zur eigentlichen Frage.
Der Simulator (Debugger) läßt bei "Auto-Step" den gelben Pfeil-Cursor so schööön rauf- und runterspringen bei den Schleifen. Aber erst bei "Ladewerten" ab etwa Hex90 oder - wie oben angegenen Hex84.
Wird ein niedrigererer Wert auch nur in einen Teil der Schleifen"register" eingegeben, läuft der Cursor einmal durch und springt dann an die Stelle zurück, wo der auf den recall-Befehl folgende stand und setzt dort das Programm fort.
Das ist doch eine Macke des Simulators. Wer konnte ähnliches berichten?
Gerade bei kleinen Zeitschleifen wäre es doch interessant zu erfahren, was zum Beispiel nach dem dritten Aufruf der Schleife passiert etc.,
255 x Schleifendurchlauf - Cursorspringen interresiert keinen, ja, führt zu argem Verdruß, da man keine halbe Stunde warten möchte.
Wer hat hier schon ähnliche Beobachtungen mit dem Debugger gemacht oder ist hier evtl. ein "Windows"-Problem hintergründig am Werkeln?
Also, das Ganze soll eine Art Lauflicht darstellen, aber nicht mit den Befehlen, die im STK500-Testprogramnm angegeben sind.
Zunächst kommt es auf die Zeitschleifen an.
Diese sollen auch nicht ständig durchlaufen werden, sondern irgendwie so, daß ich das noch einstellen kann, zum Beispiel, daß deren Durchlaufhäufigkeit noch variiert werden kann im Sinne einer Beschleunigung oder Verlangsamung.
(Soweit bin ich aber noch nicht-hi).
Dann ist die Darstellung der LEDs invertiert. Das heißt, eine Null im Programm läßt die LED leuchten.
Was im Klartext heißt, die Ausgabe muß invertiert werden, damit nur immer eine Leuchtdiode "rennt".
Dies erreiche ich dadurch, daß der Registerwert vor bzw. nach dem Rorate (rol) Befehl in ein anderes Register kopiert wird mit "mov", dann mit com invertiert wird und so zur Ausgabe gelangt.
Es ergab sich das weitere Problem, daß dann immer nur von Leuchtdiode 2 an das Lauflicht startete.
Und so weiter. Habe aber wohl IMHO ne passable Lösung dafür gefunden, siehe angehängtes "Prögchen" . Hier wird wieder Registerinhalt "verglichen" etc.
Also, werde den Quellcode mal hier reinstellen, momentan nicht im dem Kopf (Internetcafe) nur auf der heimischen Platte.
Bis dann
Gruß Oskar01
Es geht weiter:
Habe ein paar wichtige Screenshots zusammengezipt ( die 1,7 MB-großen bunten Bildchen mit Hilfe von Scannerbildbearbeitungssoftware in Schwarzweiß-PNGs umgemodelt).
Man sieht auch deutlich, daß die Register für die Serielle Schnittstelle aktiviert dargestellt werden, weil wohl Port D damit standardmäßig korreliert ist. Soll uns aber hier nicht weiter stören. Der Cursorpfeil steht auch oft an der Stelle, wo der vorausgegangene Befehl in der I/O-Darstellung erst nachklapperte. Also auch nicht weiter stören lassen dadurch.
Also mit F11 step by step durchgeorgelt, dann jeweils ein paar Screenshots. Video wäre zu lang, wills aber vielleicht auch mal probieren, bitte etwas Geduld.
So, hier nun das getestete "neue" Progrämmchen,
das ein Lauflicht darstellt, bei dem die LEDs zunächst etwas langsamer "links" geschoben, dann etwas schneller "rechts" geschoben werden.
Dabei gab es noch ein paar Problemchen zwischenzeitlich mit den Zeitschleifen, die nunmehr als drei Binärzähler hintereinander aufgestockt wurden.
Es ergab sich ein Aha-Effekt, insofern, daß von mir immer irrigerweise angenommen wurde, man könne im Assembler-Programmablauf ohne Sprungbefehl direkt auf die im Listing angegebene nächste Befehlszeile springen lassen, auch wenn dort ein Label vorangestellt ist, was Dirk oben auch schon erläutert hatte.
Das ist IMHO ein "alter" BASIC-Programmierer-Fehler. Da ich auch noch manchmal mit GWBASIC (Token) und QBASIC (editorbezogen) arbeitete, setzte ich ja den "linearen" Programmaufbau mit den fortlaufenden Listing-Nummern 100, 200, 300 etc. zugrunde.
Label ohne Listing-Adresse gibt's da ja dort nicht (jedenfall für den Anfänger so). Unterprogramme werden ja im klassischen BASIC- wie bekannt - etwa mit GOSUB etc. eingeleitet und mit RETURN abgeschlossen. Aber immer mit vorangestellter Absolutadresse im Listing. Da mußte ich erst ein bisschen umdenken.
)