Einschalten, Hacken und Spaß haben! :)
So, mal wieder weiter in diesem Film… 😉
Ich habe nun ein wenig mit PropForth experimentiert und viel darüber nachgedacht, wie wir ganz allgemein zu einer praktikablen Lösung für eine Programmiersprache auf dem Hive kommen. Mein erster Plan sah ja einen reinen Forth-Hive vor, was bedeutet, dass auf allen drei Props ein Forth läuft. Aber diese Variante habe ich momentan aus Zeitgründen und wegen fehlender Motivation etwas nach hinten geschoben. Vielmehr begeistere ich mich momentan für eine Lösung, welche den Hive zu einer Forth-Spin-Chimäre macht und ich möchte das auch ein wenig begründen:
- Eine reine Forth-Lösung zu erstellen wäre eine ziemlich langwierige Geschichte, denn man müsste vorerst alle nötigen Treiber (VGA, FAT32, Sound usw.) komplett in Forth nachempfinden. Da geht mir eindeutig der Spaß und die Leichtigkeit der vielen tollen OBEX-Objekte ab!
- Man könnte versuchen einen Mechanismus zu entwerfen, welcher ein Interface zu Spin-Objekten realisiert. Auch irgendwie eine ziemlich aufwändige Sache und sehr schädlich für die knappen Ressourcen in Bella und Administra. Also keine gute Idee Spin und Forth in einem Prop zu mischen. In Regnatix dagegen könnte man auf fertige Spin-Objekte verzichte. Die meisten Objekte realisieren ja IO-Devices, was aber mehr in den Aufgabenbereich der beiden Slaves fällt. In Regnatix brauchen wir mehr die Möglichkeit, interaktiv und ohne die Hilfe eines Host-Computers Metacode zu schreiben, welcher die Slaves steuert.
- Idee: Wenn man genauer darüber nachdenkt, haben wir ja schon eine interessante Schnittstelle zwischen Forth und Spin, sofern man Spin- und Forth-Objekte im Hive entsprechend anordnet: diese Schnittstelle ist der Bus zwischen den Props! Wenn wir also Bella und Administra zu reinrassigen Spin-Chips erklären und das Gehirn in Regnatix unter die Kontrolle von PropForth stellen, haben wir doch genau das was wir wollen:
- Wir können für die Treiber in den Slaves all die tollen Spin-Objekte der Community einfach und unkompliziert nutzen. Die Einbindung ist dabei völlig stressfrei.
- Zwischen Forth und Spin gibt eine klare und saubere Trennung, die ganz in Hardware realisiert ist. Wenn man möchte, kann man es so betrachten, dass in den beiden Slave-Chips quasi SPIN-Bibliotheken untergebracht sind, welche man von Forth aus nutzt.
- Wir haben mit Forth nun einen Ersatz für Regime, in Form einer komplette Entwicklungsumgebung, welche die schon vorhandenen IO-Ressourcen und den entsprechenden SPIN-Code dennoch nutzen kann. Forth bietet uns Interpreter, Compiler, Kommandozeile und quasi eine Skriptsprache. Letztlich ist im Konzept auch eine einfache Speicherverwaltung enthalten.
- Der bestehende interaktive Forth-Core lässt uns ca. 20 KByte freien Speicher in Regnatix. Das ist eine Menge Holz für reinen Metacode! Für Daten stehen ja dem Forth noch die 1 MByte eRAM zur Verfügung.
- Die Entwicklung von TriOS und Forth können sich gegenseitig befruchten: Neue Code-Varianten von Administra und Bellatrix können dank der einfachen Bus-Schnittstelle ausgetauscht werden.
- Ohne großen Aufwand haben wir ein Forth mit Dateisystem, Grafik und Sound. Da Forth ja quasi der Inbegriff der Experimentierfreude ist, bietet sich die Forth-Spin-Chimäre perfekt als Einstieg in diese Programmiersprache an.
- Fazit: Einschalten, Hacken und Spaß haben! 🙂
Aber jetzt mal Butter bei die Fische:
Installation des Experimentalsystems
- Download des aktuellen Archives: http://hive-project.de/board/viewtopic.php?f=7&t=428
- Wie beim TriOS gibt es einen Ordner flash mit entsprechenden Unterordnern für die Chips. Administra und Bellatrix sind soweit sicher klar:
- admflash.spin —> Administra-Flash
- vga.spin —> Bellatrix-Flash
In Regnatix wird ein aktuelles PropForth (momentan Version 4.0a) eingerichtet. Vorerst versuche ich mit dem Core auszukommen, um möglichst viel Speicher frei zu haben. Spracherweiterungen kann man ja schnell nachladen um sie zu nutzen. Der Ablauf der Installation in Regnatix:
- 02-PropForth.spin —> Regnatix-Flash
- Nun sollte sich das Forth schon nach einem Reset in einem Terminalprogramm (57KBaud/8n1) melden.
- Bei Bedarf das EEPROM-Filesystem installieren. Dazu die Datei fs.f im Texteditor öffnen und per Copy/Past in das Terminal einfügen. Nun wird das Filessystem compiliert. Folgende Kommandos stehen dann zur Verfügung:
fsclear – Dateisystem initialisieren
fsfree – Freien Speicher anzeigen
fsls – Dateiliste im FS anzeigen
fsread – Datei anzeigen
fsload – Datei laden
fswrite – Datei in FS schreiben
fsdrop – Datei im FS löschen
- Mit dem Kommando „saveforth“ das Image des Systems im EEPROM sichern.
- Mit „fsclear“ löschen und initialisieren wir den EEPROM, mit „fsls“ könne wir anzeigen was darin gespeichert ist – momentan nix.
- Wer möchte kann nun in der gleichen Weise wie das Filesytem die Datei PropForth.f einfügen. Dieses schreibt sich mit fswrite (steht ganz am Anfang des Quelltextes) automatisch in das Dateisystem und kann von dort schnell bei Bedarf mit „fsload propforth.f“ nachgeladen werden.
Forth-IOS (ios.f) – Erste Versuche
Damit ist das Coresystem von Propforth vorerst eingerichtet und steht nach einem Reset ohne Ladeoperation zur Verfügung, wobei es sich momentan nur über die serielle Schnittstelle meldet in einem Terminal (ich verwende TerraTerm) meldet. Nun gilt es VGA und Tastatur zu koppeln. Das ist momentan noch in einem experimentellen Stadium, da ich selbst noch die Möglichkeiten erforsche. Ist absolut spannend… 😉
Als erstes benötigen wir ein Businterface. Dafür gibt es schon folgende neuen Worte in der Datei ios.f:
bon – Initialisiert und belegt den Bus
boff – Bus in der aktuellen COG wieder freigeben
b! – Zeichen an Bellatrix senden
b@ – Zeichen von Bellatrix empfangen
a! – Zeichen an Administra senden
a@ – Zeichen von Administra empfangen
Diese Datei wie gehabt im Terminal einfügen und damit compilieren. Ein saveforth ist an dieser Stelle nicht nötig, da diese Worte ja nur einen experimentellen Charakter haben. Allerdings müssen sie nach einem Reset vorerst immer wieder neu compiliert werden. So kann man zum Beispiel schon eine Zeichentabelle ausgeben oder den Screen löschen:
: cmap ff 1 do 0 b! 6 b! i b! loop ;
: cls 0 b! 3 b! 0 b! ;
Mit folgender Sequenz kann man die Soundfunktion in Administra aufrufen, um den Heartbeat-Sound abzuspielen:
6b a! f3 a! 0 a!
6b ist die Funktionsnummer für die Administra Funktion sfxfire, f3 der vordefinierte HBeat-Ton und 0 der Kanal auf welchem der FX-Sound abgespielt werden soll. Die Parameter landen auf dem Stack und werden folgend durch das Wort a! über den Bus zum Slave gesendet. Schön an Forth: das kann man alles interaktiv über den integrierten Interpreter testen. Nächster Schritt: Wir wollen diese Funktionen öfter verwenden, also compilieren wir sie zu einem neuen Wort im Wörterbuch:
: hbeat-lo 6b a! f3 a! 0 a! ;
: hbeat-hi 6b a! f2 a! 0 a! ;
Damit haben wir zwei neuen Kommandos hbeat-lo und hbeat-hi definiert (was bedeutet, wir haben sie interaktiv compiliert), welche diese vordefinierten Systemklänge in Administra triggert. Das Prinzip sollte soweit klar sein und .
Und wie geht das nun mit dem Multitasking? Schließlich haben wir in Regnatix ja mehr als ein Forth-System zur Verfügung. Wir basteln uns zum testen mal ein Wort welches viel Text auf dem Monitor ausgiebt:
: t1 bon 100 0 do cmap loop boff ;
Wenn wir dieses Wort starten, wird es auf unserer aktuellen COG ausgeführt und wir müssen warten bis es fertig ist, also bis wir weiter arbeiten können. Das Wörterbuch aber ist für alle COGs gleich. So wäre es ja schön, wenn wir unser t1-Wort auf einer anderen COG starten könnten, um mit der aktuellen COG weiter zu arbeiten. Das geht mit folgender Sequenz:
boff c“ t1″ 5 cogx
Mit boff schalten wir auf unserer COG Nr. 6 den Bus frei, sonst gibt es Datensalat! Die folgende Sequenz bringt das Wort „t1“ in der COG Nr. 5 zur Ausführung, was man auch unschwer am Monitor erkennen kann. Nebenher kann man über die serielle Konsole aber ganz normal mit der COG 6 weiterarbeite.
Allerdings muss man beachten, dass der Zugriff mehrerer COG’s auf den Bus noch nicht mit Semaphoren gegeneinander verriegelt ist. Wenn also zwei COG’s gleichzeitig den Bus beanspruchen gibt es momentan noch einen Crash – eine Sache an die in einem nächsten Schritt integriert wird.
Ein weiteres Experiment: Wie leitet man den Ausgabestrom einer COG auf den Monitor um? In der ios.f ist dafür schon das experimentelles Wort „vga“ enthalten. Dieses startet in einer freien COG das Wort lnk>vga, welches den Eingabedatenstrom dieser COG endlos auf dem Monitor ausgibt. Darauf folgend wird die Ausgabe der aktuellen COG durch iolink mit der Eingabe unserer Terminalcog gekoppelt, so erscheinen alle Textausgaben auf dem VGA-Monitor. Wie das mit der Tastatur funktioniert kann ich noch nicht sagen, kommt noch.
Ok, das soll es erstmal von der Forth-Front für heute sein. Wie man sieht ist da noch viel zu tun, wer Lust hat – einfach experimentieren und im Forum melden!