Also, TriOS hatte ich eigentlich als Namen für die überarbeitete Version des jetzigen Codes angedacht, denn so richtig hatten wir ja bisher keinen Namen. Momentan möchte ich, wie oben beschrieben, den bestehenden Quelltext systematisch ordnen und vervollständigen, um ihn von einer Werkstattversion in eine einfache, weiterhin vordergründig auf Spin basierende Version zu überführen. Einfach und gut dokumentiert für Einsteiger und erste Experimente, Basis für weitere Schritte. Später kann man dann das ganze erweitern (mehrere Anwendungen, Nachrichtensystem...) Momentan ist es ja mehr eine Copy-Past-Version um ein wenig zu spielen - ungeordnet, keine einheitliche Struktur der Dokumentation, teilweise keine Dokumentation, keine Programmbeispiele usw. Der Aufbau, Doku und erste Programmbeispiele wird dann Teil 3 vom Tutorial. Mit Verzeichnissen hat man dann erstmal mehr Komfort und mit dem Administra-Loader kann man zur Laufzeit mit einem entsprechenden Kommando (ohne Flashen) ein komplett anderes System laden.
Ich hab jetzt ein wenig über das Konzept eines Nachrichtensystems nachgedacht, drei mal mit schreiben angefangen und einen Haufen Text gerade wieder gelöscht...
Die Essenz: Für mich persönlich unterscheide ich momentan zwei verschiedene Aspekte in Bezug auf das TriOS:1. Eine sinnvollere und universellere Adressierung.
2. Ein multitaskingfähiges Nachrichtensystem.
Ich möchte diese beiden Punkte gern trennen, da ich denke, dass Punkt 1 wichtig ist für eine geordnete und sinnvolle Erweiterung des Hive, aber Punkt 2 (noch) nicht unbedingt für die netten kleinen Experimente und Spielereien nötig ist. Punkt 2 sehe ich quasi als Level 3 ...
Der Grund ist ganz einfach:
Der Hive ist auf der einen Seite ein Retrospielzeug, ein netter Zeitvertreib, um mal ein kleines Spiel zu schreiben, um zu lernen wie das Ganze im Detail funktioniert. Alle diese Dinge kann man ganz gut mit der schon per Hardware realisierten Multitaskingmöglichkeit realisieren. Ein Grund warum es den Hive gibt, ist, dass ich es liebe einen Computer einzuschalten, und in Sekunden erscheint ohne großes Geschwafel ein einfache "ok" und der Spaß kann beginnen.
Bei einem solchen System ist man noch ganz dicht an der Hardware, aber man kann dennoch schon damit experimentieren. Um ein Game zu schreiben oder wie beim Magischen Auge einen Motor, ein paar LED's und Sensoren zu bedienen ist das genau richtig. Wenn man an diesem Punkt die Sache zu kompliziert macht ist der Spaß an diesen Sachen erledigt und ein ausgewachsenes Nachrichtensystem wäre zu komplex denke ich. Momentan "schmiegt" sich das IOS ja ganz geschmeidig an das System an und ist deshalb, trotz der fast ausschließlichen Verwendung von SPIN, noch ausreichend schnell. Die meisten Funktionsaufrufe sind sehr einfach im IOS - die Komplexität wird dabei in die Slaves verlagert. Fast alle Funktionen sind aus der Sicht von Regnatix "Primitive", rufen also keine weiteren Unterfunktionen auf. Das ist natürlich nicht ganz korrekt, denn man muß ja quasi die Subroutinen in Administra und Bella mit hinzurechnen, aber durch die physische Trennung ist die Anwendung in Regnatix echt gekapselt und in einer robusten Art unabhängig. Auch mental ist man ein wenig gezwungen die Dinge nicht zu sehr zu vermischen und exakter zu modularisieren: Für mein Schachprogramm habe ich einen Bellatrix-Code geschriebe, der die kompletten grafischen Ausgaben und Eingaben zur Verfügung stellt. So wird Bella quasi zu einer "Schachgrafikkarte". Ich kann einen Prop mit diesem Code theoretisch an einen anderen Prozessor hängen und er kann diese Funktionen nutzen, ein Schachbrett darstellen und steuern, Figuren bewegen, Markierungen setzen, Abfragen, welche Figuren angeklickt wurden, Text in zwei Logfenstern anzeigen usw. Der eigentliche Schachcode braucht sich um diese Sachen nicht mehr zu kümmern, ist völlig davon getrennt. Das gleiche machen ja letztlich auf Softwareebene auch alle Bibliotheken und auch Spin-Objekte, aber im Hive ist man da ein wenig mehr gezwungen die beiden Pole - Hardware und Software - auseinanderzuhalten. Ist wahrscheinlich eine rein mentale Sache, aber ich finde das ganz gut. Was ich aber letztlich sagen will: eine komplexere Struktur wie zum Beispiel ein Nachrichtensystem könnte da die klaren Grenzen wieder verwischen, weil es halt schon wieder ein Stück "virtueller" ist.
Ist so eine Virtualisierung nun gut oder schlecht? Auf der anderen Seite soll der Hive ja auch die Möglichkeit bieten mit seiner "sonderbaren" Struktur zu experimentieren, und wenn es dann sogar möglich wäre mehrere Benutzeranwendungen gleichzeitig zu starten - tolle Geschichte. Aber ich denke, letztlich ist das der Gegenpol zum Retro- und Hardware-Experimentalplattform, also mehr der nächste Schritt (und wahrscheinlich nix für mich
.Nochmal zurück zum Ausgangspunkt: Ich denke eine universellere Adressierung wäre vielleicht ganz interessant. In jedem Fall macht sie Erweiterungen einfach, obgleich man auch das wahrscheinlich mit einem kleinen softwaretechnischen Wasserkopf, und damit mit Geschwindigkeit erkauft. Aber die Adressierung muß wirklich einfach und schnell sein, ohne viel Aufwand, da das Ganze ja in Spin laufen soll.
aber wir werden wohl nicht drum herum kommen, dass sich einer bereit erklärt die Sourcen zu pflegen, Erweiterungen, die aus der Community kommen, einzuarbeiten, und den anderen dann als neue Version offiziell bereitzustellen.
Um für Erweiterungen eine Basis zu haben räume ich ja grad den bestehenden Code auf und überarbeite ihn. Die gravierendste Änderung ist momentan die Verwendung der FATEngine. Bin grad dabei: da ist einiges zu tun. Das Konzept ist ein wenig anders und ich bin mir jetzt sicher, dass ich auch von der FATEngine eine an den Hive angepasste Version machen muss. So reagieren die Routinen auf Fehler mit der Übergabe eines Stringpointers, der dann auf die Fehlermeldung weist. Das ist zwar lustig, wenn man diese Fehlermeldung gleich ausgeben will, aber so richtig "maschienenlesbar" ist das nicht. Da müssen Fehlernummern rein. Aber letztlich gibt es keine Alternative. Ich ändere lieber die FATEngine (Code gut strukturiert und lesbar), als das fsrw-Objekt (grausig strukturierter Code). Zumal fsrw nicht mit Verzeichnissen umgehen kann, der seek-Code nicht funktioniert und keine Bootfunktion drin ist.
