fang ich frohen Mutes an meine Vorstellung eines auf Propeller Chip's basierendes OS in die Tat umzusetzen.
So ein zusätzliches Display hat einen unschätzbaren Wert wenn es darum geht ein Multicore OS in Assembler zu schreiben (Pasm kann ich noch nicht Schlaf).
So lange wenigsten noch ein Debug Cog von den 24 läuft kann man sich schön sämtliche wichtigen Werte anzeigen lassen um den Fehler schneller einkreisen zu können.
Es macht auch Spass auf dem Display nur zu zuschauen wie der Scheduler neue Prozeesse auf freien Cogs verteilt oder wie Speicherbereiche in Form von bunten Pixelnfeldern blinken.
Natürlich sind aussagefähige Stackbilder gekreschter Prozesse ebenso möglich wie auch wärend der Entwicklung sinnvoll. Ich möchte auch nicht zum Debugen immer den PC über serielle Links verbunden haben.
Ich habe einige Zeit investiert um mir ein schönes OS Konzept auf die Beine zu Stellen.
Eines der wichtigen Designmerkmale ist die Auflösung des Master / Slaves Konzeptes wie es z.Z. das IOS benutzt. Daher werden die Steuerleitungen (Ausser Addresslatch /AL und eventuell /WR) neuen Aufgaben zugefürt.
Auf den verbleibenden Steuerleitungen soll ein bidektionaler Komminikationverkehr statt finden. Sinn und Zweck des Ganzen ist ein Mechanismus zu realisieren welcher es jedem Prozess erlaubt (unabhängig auf welchem der 3 Chips er läuft) auf die gesammten Resourcen des HiVe's Zugreifen zu können.
Dar das Hardwaredesign keine direkte Kommunikation z.B. zwischen Bel. und Adm. zuläst mündet die Resourcenverwaltung in eine art Job -Mangement. So kann z.B. ein Prozess der vom Scheduler in einem freien Cog auf einem beliebigen der drei Props. Aufträge zur Allokation der Resourcen absetzen.
Es gibt keinen Grund warum nicht ein Prozess der gerade "Zufällig" auf Administra läuft nicht auch in den Genuss von eRAM kommen soll. Genau so kann ein Prozess der z.B. auf Bellaltrix augeführt wird ebenso auf das Feilsystem von Administra zugreifen.
Der aufwerksamme Leser unter Euch wird sicherlich den Einwand haben das ein kompeliertes Programm schon bei der Programmierung "wissen" muss auf welchenm Chip es laufen wird.
Oder anders gesagt jedes Programm müste über eine art "R"ios "B"ios "A"ios
verfügen um z.B. die passenden Busmasken der jeweiligen Chips zu benutzen. Dieses Problem wird vom Prozess "Loader" so gelöst das er vom Prozess "Scheduler" mit einer ProzessID "geimpft" wird.Diese ID ist nichts anderes als die CogID des nächsten freien Prozesses multipliziert mit der auszuführenden ChipID. Z.B. CogID 7 * ChipID 2 ergibt die Systemweite eindeutige ProcessID 14.
In diesem Beispiel geht nun der Loader hin holt die Busmasken für ID 14 und schreibt sie an vereinbarter Stelle. Das kann vor COGNEW direkt im Binary sein oder im eRAM oder sonst wo.
Fakt ist auf jeden Fall das der Anwenderprozess nicht vorher wissen muss wo er zur Ausführung kommen wird. (Liebe Kinder von den möglichen Childprocesses erzähl ich euch nach dem Hände waschen)
Alle Resourcen des HiVe's und die Damit verbundenen Dienste werden über das bidiektionale Jobmangement allen Prozessen zur Verfügung gestellt vergleichbar mit den Messagequeue's von X11 und Windows.
Die "Dienste" Kapseln die Anwendungen von den realen Resource die da wären KEY, MOUSE, TV, VGA, SOUND, RAM, FILE, BUS, PC-HOSTLINK, USB(*)
Zugegeben ich bin wirklich heiss darauf das OS in die Tat umzusetzten und hoffe zur gegebener Zeit das vereinzelte Drohnen ein par kleine Tools, Anwendungen oder Spiele auf dem OS Proggen werden.
Ich will künftigt lieber mit dem stromsparndem HiVe "Spielen" als ständig den PC laufen zu haben. Klar zum Online gehen bleibt der PC auch bei mir erste Wahl was ich aber auf jeden Fall erreichen möchte ist das man den HiVe einschaltete einen Editor startet Quellcode tippt kompeliert und Spass hat.
Ich werde auch weiterhin das IOS Projekt im Auge behalten und warte auch schon auf die HiVe "Task Forth" Initiative
. Wer meine OS Ergüsse in kürze Testen möchte kann auch seine bisherige FAT16 HiVE SD Karte benutzen. Iich werde zwar ein anderes Filesystem implementieren welches aber auch in Form einer etwas grösseren Datei in friedlicher Koexistens auf der HiVE SD existieren kann. Wer schon mal VMWare, Bochs, QEMU oder andere virtuelle PC's benutzt kennt ja bestimmt das Prinzip wie virtuelle Festpatten, CD/DVD ROM's mit beliebigen Filesstemen "nur" als Datei existieren.
So das reicht erst einmal und ich werde zur gg. Zeit auch ein par Skizzen hier hochladen da habt Ihr Drohnen schon mal etwas zum "schmunzel".
Krative Grüsse Joshy
(*) Ich arbeite dran hat aber noch keine hohe Priorität und vielleicht kann ich Janaha mit ins Boot holen und unsere bisherigen bescheidenen USB Kenntnisse bündeln in einen erteinmal recht einfachen HiVe USB Host.
und unmittelbar kam mir noch eine verrückte Idee: Man muss den 8bit Bus ja nicht unbedingt parallel nutzen! Was wäre wenn man aus einem parallelen Bus 8 serielle Verbindungen macht und damit wie mit einer Art Pipe dynamisch je nach Anforderung Prozesse verbindet? Ich lasse bei diesem Gedanken mal ganz bewußt Erwägungen zur Geschwindigkeit außer acht. So könnten gleichzeitig acht Prozesse miteinander reden, unabhängig in welchem Chip sie sich befinden, zumindest sofern man es schafft das dynamisch zu verwalten. So könnte ein Prozes in Regnatix mit einem Prozess in Administra reden und ein anderer Prozess ebenfalls in Administra gleichzeitig mit einer Cog in Bellatrix. Könnte sowas funktionieren? Wäre allerdings echt nur was für Verrückte...
Nachdem ich jetzt zwei lauffähige Hives hier stehen haben (HIVE 55 hat noch bei mir sein neues Zuhause gefunden) bin ich an der adaptierung meines Forth. 
Ich hoffe nächste Woche soweit zu sein das ich genaues berichten kann.