Meine bisherigen Erkenntnisse, was beim Klicken auf "Active Mode" in LLWin 2.1 geschieht:
- Zunächst wird eine Datei TMP.Q erzeugt, die das graphische Programm in einer Art Assembler-Sprache enthält. Es ist eine Textdatei die prinzipiell menschenlesbar ist, aber es hat mich viel Zeit gekostet, das Format einigermaßen zu verstehen.
- Dann wird vom Interface das Speicherlayout abgefragt und in einer Datei TMP.ATT gespeichert. Da das Speicherlayout für die Übersetzung der TMP.Q-Datei benutzt wird, findet man hier alle internen Funktionsbausteine des Interfaces mit deren Namen sowie die Namen der Eingänge, Ausgänge, Variablen, Nachrichten, usw.
- Die Speicheradressen aus der TMP.ATT-Datei werden benutzt, um das Programm zu bauen. Dies wird in der Datei TMP.MVL abgelegt. Zudem wird ein Error-Log in die Datei TMP.ERR geschrieben.
- Gab es einen Fehler, wird dieser als Meldung ausgegeben. Andernfalls wird das Programm aus der .MVL-Datei über die serielle Schnittstelle an das Interface übertragen
- Die TMP-Dateien werden gelöscht.
Der Trick, um das alles zu verstehen, war es einerseits, die Kommunikation am Serial-Port mitzulesen, indem ich 3 USB-Serial-Adapter verwendet habe. COM0 ist in der DosBox angeschlossen, der Adapter ist hardwaretechnisch einfach mit COM1 zusammengesteckt. Auf COM1 lese ich mit Python alles mit und schreibe es nach COM2. COM2 steckt dann am eigentlichen Interface. Und andererseits kopiere ich die TMP-Dateien aus dem TMP-Verzeichnis von LLWin heraus, bevor sie gelöscht werden.
Ich bin nach einigem Probieren jetzt so weit, dass ich mich prinzipiell in der Lage fühle, diese TMP.Q-Dateien manuell zu erstellen für ein von mir angedachtes Programm. Alles danach (Download der ATT-Datei, Auflösen der Adressen und Übertrag zum Interface) habe ich bereits mit Python automatisiert. Es scheint soweit zu funktionieren, aber ich habe noch keine komplexen Programme geschrieben. Dazu möchte ich erst die Erstellung der TMP.Q-Dateien mit Python vereinfachen.
Folgende Bausteine habe ich in der TMP.ATT-Datei gefunden. Das fand ich sehr interessant, weil dort u.a. anscheinend die vier Grundrechenarten definiert werden, die zumindest LLWin2.1 nicht kann. Und ich fand interessant, dass Bausteine, die auf dem Interface im Active Mode nicht funktionieren, dort trotzdem abgebildet sind, wie z.B. DISPLAY, MELDUNG und BEEP.
- ABS - wird zur Ablaufsteuerung verwendet, um die Transitionen ("Pfeile") aus LLWin abzubilden. Der Baustein ENDE wird dabei implizit mitabgebildet.
- APR8
- JPZ
- NOP
- BEG - steht einmal am Anfang der Q-Datei und definiert insb. die Zykluszeit. Dies ist NICHT der START-Baustein.
- END - steht einmal am Ende der Q-Datei und scheint das Gegenstück von BEG zu sein. Dies ist NICHT der ENDE-Baustein.
- Init
- VRZF - Bildet den Baustein POSITION ab
- SMOT - Bildet die Bausteine MOTOR und LAMPE ab.
- SVAR - Bildet die Bausteine VARIABLE und DISPLAY ab.
- IVAR - Bildet die Bausteine INCVARIABLE und DECVARIABLE ab.
- CMW - Bildet den Baustein VERGLEICH ab.
- EVF - Bildet den Baustein WARTE ab.
- T2D - Bildet den Baustein MELDUNG ab.
- Inif - Bildet den Baustein START ab.
- Not - Bildet den Baustein EINGANG ab.
- FD10 - Bildet den Baustein FLANKE ab.
- ABB - Bildet die Bausteine NOTAUS und RESET ab.
- ADDW
- SUBW
- DIVW
- MULW
- SCHW
- AND
- OR
- CMPW
- FD01
- FFR
- FFS
- BGW
- AWW
- ABW
- AWB
- TON - Bildet den Baustein BEEP ab.
Das TERMINAL wird dadurch abgebildet, indem die bei Programmerstellung eingestellten Werte als Konstante in den Speicher geschrieben werden.
Die Befehle, bei denen keine Anmerkung dahinter steht, scheinen in der Q-Datei nicht direkt genutzt zu werden.
Unterprogramme werden nicht durch Bausteine abgebildet. Bei der Programmerstellung wird ihr Inhalt einfach an alle Stellen kopiert, an denen sie aufgerufen werden.