HIVE-Project

Soooo .. du Meister unserer Hive's und natürlich auch alle anderen

du hast ja jede menge skizzen in der Galerie ..
Wie wäre es denn mal mit einem, ich hasse die dinger und wage es fast nicht auszusprechen, Ablaufdiagramm der derzeitigen CLI ?

Denn um ehrlich zu sein würde ich die Grundfunktionen des Hive's gerne auf dem was du derzeit hast aufbauen.
Wahrscheinlich müsste man einige Sachen ändern, darin seh ich aber technisch kein Problem, auch wenn wir es als Grundgerüst benutzen.
Das wichtigste wäre, das wir aus den Grundfunktion deiner CLI, also sprich FileSystem, BIN's laden, Programme/Treiber starten/beenden eine Schnittstelle bauen ..

Das Grundsystem, das muss GAR NICHTS Interaktives können ! Von der CLI an sich zu reden verwirrt in dem Zusammenhang sicherlich ..



Zum Laden von Treibern / Programmen hab ich eine viel interessantere Frage
Nehmen wir als Beispiel mal die Netzwerkkarte
Kann ich mit 2 Programmen gleichzeitig auf die Karte zugreifen wenn ich den NetzInterface Treiben seperiere?
ODER kann jedes der 2 Programme einen eigenen Treiber mitbringen? Wie ist es denn dann Hardware Technisch mit der Ansteuerung?

Sprich das ist alles zu kompliziert .. Schreiben wir einen HardwareManager!
Dieser könne die Treiber bei bedarf laden oder bereits vorhalten, je nach Priorität des Treibers. Ein Tastaturtreiber sollte immer vorgehalten werden, ein Netzwerkkartentreiber nur bei Bedarf .. Spart COGs und RAM
Der HWManager könnte dann DIE Zentrale Schnittstelle sein für Alle Programme und wäre somit das Grundgerüst unseres Hive ..
Als Schnittstelle würde er jeder Anfrage eines Programmes eine ID verpassen um die Antwort des Treibers auf die Anfrage zurückgeben zu können.
Als ordentliche Schnittstelle würde unser Manager zum Beispiel auch nicht nur einen Tastatur oder Netzwerkkarten Treiber kennen .. Im endeffekt kann dem Manager sch.. egal sein welchen Treiber er Läd, der muss sich nur an eine von uns kreirte Schnittstellenbeschreibung halten.
Wenn euch jetzt die Frage kommt, muss der Manager dann ALLE funktionen die ein Treiber mit sich bringt KENNEN?
NEIN, wozu auch? Dann wäre es ja NULL Praktikabel .. da wären wir bei JAVA der eine bestimmte RE braucht um zu funzen ..
Nein, wir würden in unserem Programm unsere Schnittstelle befehlen dem Tastaturtreiber eine Nachricht zu kommen zu lassen. unser manager ist ein reiner Postbote, den geht der Inhalt nichts an. Der Muss nur eines Wissen: Empfänger, Absender. Das muss er sich merken.
Steht in der Nachricht für den TastaturTreiber nun drin er soll den Monitor ausschalten reagiert der Treiber entsprechend und schickt nen Error zurück an den Absender und unser Programm teilt uns mit das wir idioten sind so einen Befehl an den TastaturTreiber zu schicken

Achja, da fällt mir was ein, Systemweite Errorcodes ! Und wenn die nur als Textfile auf der SD-Karte liegen ..

Meine Frage, da kein Hive zum testen .. Umsetzbarkeit? Praktikabel?

Also die CLI - zu finden in den Quelltexten als regime.spin - empfinde ich als zu rudimentär um da aufwändige Ablaufdiagramme zu machen. Einfach mal in den Quelltext schauen, ich denke das erklärt sich fast von selbst. Was die allgemeine aktuelle softwaretechnische Struktur betrifft - also die Loader, ios, Bootvorgang - fasse ich mal den Stand zusammen und poste es hier.

Ich denke momentan sollten wir die Sache auch nicht zu kompliziert machen. Viele Dinge erklären sich fast von selbst wenn man den Hive aufbaut und nebenher ein wenig in den Quellen wühlt und experimentiert. (Zumindest hab ich so die Hoffnung. Ist ja momentan mehr eine einfache und pragmatisch orientierte Werkstattversion, welche man bei einigen Punkten bestenfalls als Vorschlag für bestimmte Lösungsmöglichkeiten ansehen sollte. Ich persönlich würde da jetzt auch keine großen Sachen planen bevor man nicht ein Gefühl für die Möglichkeiten entwickelt.

Du hast natürlich in einem Punkt völlig recht: Sobald die Zeit reif ist sollten wir zusammen mal schauen wie wir auf einen gemeinsamen Nenner als Arbeitsgrundlage kommen, bevor es mit den eigentlichen Bastelprojekten losgeht.

Nur mal so schnell "hingeworfen" und noch nicht wirklich durchgedacht.

Folgende Dinge müssen bedacht werden (alle ohne Wertung gut/schlecht).

- Die Treiber müssten sich beim "Postboten" anmelden, damit der Bescheid weis und eine Liste führen kann
- Das Anwendungsprogramm muß dem Postboten sagen, wohin es gehen soll. Dieser muss dass dann natürlich in seiner Liste nachsehen, was Zykluszeit kostet.
- Cogs arbeiten ja unabhängig voneinander. Da braucht man dann eine Queue wo Aufträge warten müssen ... was wieder Zeit kostet.

Messaging über Pipes, <whatever> und Queues sind nicht gerade das, was ich persönlich als trivial ansehen würde.

Ich will damit aber nicht sagen, das es nicht machbar ist. Sollten wir schon mal darüber nachdenken.

Gruß.
Rainer

Jaja .. CLI ist simpel, soweit schon klar .. Wenn man sie denn dann mal in Aktion gesehen hat bestimmt.

Das wenn es kein interner befehl ist du nach nem Prog auf der SD suchst war auch nicht gaanz genau was ich meinte

Ablaufdiagramm in dem Sinne das man die genaue Reihenfolge sieht in der was geladen wird und von wem und vorallem wohin ..
(Ich glaube das macht uns noch ein wenig durcheinander da wir es noch nicht selbst gesehen haben sondern nur aus deinen Texten/Bildern kennen)



Zu dem was du schreibst, Rainer .. Jain
Der Treiber muss sich nicht unbedingt am System anmelden .. von wem sollte der Treiber denn gestartet werden?
Wenn das System ihn startet weiß es de fakto das der Treiber da ist und aktiv

Der Postbote muss eher wissen wo seine Treiber zu liegen haben, bzw deren ".ini" datei in der drin stehen könnte
[Config]
Name=Network Interface Driver 0.1a
File=drvNI.bin
Typ=drvNI
Prio=0 (Als Wertungssystem welcher Treiber zu bevorzugen ist, falls mehrere vom Gleichen Typ da sind [Automatische Konfiguration])

(JA, ich liebe ini Dateien ! )

Das Anwendungsprogramm muss dem Boten wo es hingehen soll, richtig! Aber mein Gedanke war das man ihm nicht sagt rede mit drvNI.bin sondern das es eine Anfrage an den Typ drvNI sein soll ..
Das Programm selbst sollte sich einen dreck drum kümmern mit welchem Treiber es redet und wie dieser funktioniert, hauptsache es ist der richtige
Als beispielaufruf:
GetData(Typ, Message [,..])
Typ = Typ des Treibers
Message = Nachricht an den Treiber

Welche Treiber es gibt und welcher verwendet wird muss der Manager selbst wissen, oder man sagt es ihm mittels Konfigurations Datei (.ini ?;) )
Der Manager weiß dann in dem Falle natürlich auch ob er den Treiber noch laden muss oder ob er schon geladen ist.

Pipes, klar, gerne .. ich mag Pipes
Andererseits programmiere ich gerne in c/c++ also mag ich auch Listen
Wir sollten nicht immer nach dem trivialsten suchen .. nicht bei So etwas, da sollte das effektivste konzept erarbeitet werden. Auch wenn uns das mehr zeit kostet, aber bei so etwas ist das dann doch wichtig
Wobei man die Abarbeitung der Messages auch erst mal mit dem trivialsten lösen kann und dann später umbauen, das betrifft ja in dem Sinne keine funktionalität der Schnittstelle, bis auf die Responds ..
bzw wären Pipes das geschickteste, ansonsten "hängt" das system an der stelle bis der Treiber eine Antwort liefert

Also, das Problem mit der Zykluszeit ist: Wir kommen nicht drum rum!
Sobald es komplexer wird als die derzeitige CLI (spekulation!) musst du dich damit auseinandersetzen wer welche Rollen übernimmt


PS:
Natürlich wäre es auch möglich das sich der Treiber am System anmeldet, ABER .. willst du alle Treiber von Hand starten ?
start Network
start Browser
und dann wehe dir du vergisst das starten des Netzwerkinterfaces vorm starten des Browsers? hab ich keine lust drauf ..
Natürlich könnte der Browser checken ob alles was er braucht läuft und wenn nicht es selbst starten, aber das hätte ich ungerne in jeder Anwendung integriert .. das soll die Schnittstelle tun

Ich schreib zu viel


edit: Das Ding heißt nu offiziell 'mailman', jemand Patentrechtliche einwende ?

Ich will sicher niemanden bremsen, aber ich denke wir sollten bei allem den Retro-Gedanken im Hinterkopf behalten ... das war die Zeit als man einen Homecomputer noch völlig allein in seiner Gesamtheit erfassen konnte. Wenn wir jetzt mit den durchaus coolen aber neuesten Softwaretechnologien (Piplining, Precess-Sheduling, etc.) loslegen, schiessen wir hoffentlich nicht an diesem Ziel vorbei.

Aber das ist nur mein subjektiver Senf, lasst euch von mir bloss nicht hinsichtlich eurer Ideen bremsen.

Gruss digger

nunja .. Also ich halte Pipes z.b. nicht gerade für neumodisch ?
Pipes, egal in welcher Form der Implementierung wurden schon immer benutzt um Programme miteinander reden zu lassen ..


Der subjektive Senf zählt, solange er Objektiv ist.

Subjektiv gesehen habe ich bisher nichts genannt was nicht auch ein retro-pc bereits gemacht/gehabt hat

Aber um beim Thema Retro zu bleiben, würde ich sagen wir können uns etwas an Linux orientieren.
Nicht was irgendwelche Programmier Modelle angeht, sondern am Grundprinzip:
Kernel + shell = lauffähiges system
Eine Grafische Oberfläche, so reizvoll das auch ist hat nichts mit dem system zu tun .. das wäre eine eigene Applikation wie X für mich, auch auf dem Hive

Es gibt ja verschiedene Konzepte von Retro-PC's ..

Einigen wir uns darauf: Wir wollen einen Retro-PC bauen und Programmieren, der die zur verfügung stehende Hardware so Optimal ausnutzt wie wir es hinbekommen und trotzdem den Leuten die Möglichkeit bietet 'moderne' Techniken zu nutzen. Zum Beispiel die Netzwerkschnittstelle, einen VGA modus, etc

Das ist es was ich damit versuche, unseren Hive Flexibel zu gestalten, mit einem Grundsystem das den Anwendern(also uns) die freie wahl lässt was wir an funktionen nutzen

Ähm ... mal was ganz Grundsätzliches: Wir reden doch hier nicht von einem Multitasking-Betriebssystem, oder? Zumindest sehe ich dafür keinen ernsthaften Sinn auf dem HIVE. Wenn aber (neben dem TRIOS) immer nur eine Anwendung läuft, kann die doch ihre eigenen Treiber mitbringen und starten. Wozu dann ein externer Manager? Wenn wir anfangen, alles zu modularisieren, wächst der Verwaltungsaufwand extrem - dann schreibt jemand eine neue Version eines Treibers, und plötzlich laufen Anwendungen nicht mehr, weil sie eine ältere Version erwarten ...

Es ist doch gerade das Schöne am Propeller, dass man mit wenig Aufwand auf fertige Software-Objekte zurückgreifen kann, also muss man für ein Programm nicht alle Treiber selbst neu schreiben, aber man kann sie trotzdem fest ins Programm integrieren und muss sie nicht als separaten Task laufen lassen (separat im Sinne eines separat geladenen Programms - natürlich kann und wird ein Treiber zumeist auf einem eigenen Cog laufen).

Klar, wenn wir natürlich irgendwann ein standardisiertes Fenster-GUI hätten, wird Multitasking interessant und damit auch externe Treiber. Aber ich glaube ja, dass das alles auf einem HIVE Overkill wäre. Sollte jedenfalls nicht Bestandteil eines Basissystems sein.

Oder denken wir hier aneinander vorbei? Ich habe wenig Ahnung von diesen Dingen und finde hackticks Texte auch schwer verständlich (für mich).

Erst einmal will ich sagen, das ich absolut begeistert bin, was hier allgemein so an Ideen aufkommt.
Ich lese das alles wirklich gerne .. und ich lerne schon jetzt viel.

Wir haben nur das "Problem", das der Propeller nicht wirklich eizuordnen ist. Seine Stärke ist gleichzeitig seine Schwäche. Mit dem Ding kann man mit etwas Geschick (nahezu) alles bewerkstelligen ... leider aber nicht alles gleichzeitig wg. den begrenzten Resourcen. Das sollte uns aber nicht aufhalten

Man kann es ja auch mal von einer anderen Seite aus betrachten.
Wenn euch jemand fragt, was der Hive denn überhaupt ist, was sagt ihr dann ?

- Ein Heimcomputer wie die von Früher, mit begrenzten Resourcen, begrenzte Hardwaremöglichkeiten mit denen man leben muß, kaum erweiterbar (wie im heutigen Sinne), aber eine lustige Kiste, mit der man einen haufen Spaß haben kann und bei dem das Wissen das man haben muß überschaubar bleibt.

- Ein vollkommen offenes System, ähnlich einem PC mit Linux, an dem man alles anschließen kann, wenn man nur die richtigen Treiber hat, nicht mehr ganz so leicht zu verstehen wenn man "in die Tiefen" vordringt, aber unheimlich spannend wenn man es tut.

Für mich ist der Hive eine Mischung von beidem. Ich kann mich bestimmt Stundenlang mit SPIN amüsieren und ein Programm schreiben, ohne mir auch nur entfernt Gedanken um Bildschirmtreiber machen zu müssen.
Ich kann aber auch sehr tief einsteigen und unglaubliche Sachen machen ... eben ganz wie ich will ... heute das, morgen was anderes.

Aber das allerbeste ist, ich kann das Ding jederzeit softwaretechnisch komplett "Nullen" und was anderes aufspielen ... und damit einen großen Teil der (in Software nachgebildeten) Hardware gleich mit. Das würde einem bei einem Homecomputer wie auch bei einem PC schon etwas schwerer fallen.
Außerdem sind da ja auch noch die Anwendungen (ein OS ist ja kein Selbstzweck). Ich werde da drauf sicher diverse Spiele spielen, im Hivenet rumlungern und anderen Kram machen ... ihn also einfach nur benutzen.

Ich glaube auch, das sich "Standards" beim Entwickeln ergeben werden

Ich sag's euch ... das wird spannend

Gruß.
Rainer

Aber das allerbeste ist, ich kann das Ding jederzeit softwaretechnisch komplett "Nullen" und was anderes aufspielen ... und damit einen großen Teil der (in Software nachgebildeten) Hardware gleich mit. Das würde einem bei einem Homecomputer wie auch bei einem PC schon etwas schwerer fallen.

Schön geschrieben Rainer.

Hinzufügen möchte ich noch den Hardwareaspekt und die sich daraus ergebenden Facetten: Alle haben als Basis die gleiche Hardware, welche man bis zu einer bestimmten Ebene selbst erschaffen kann und die auch wirklich verstehbar ist. Fällt ein Chip aus kann den jeder selbst wechseln und ist auch in der Lage selbst die Diagnose zu stellen was im System los ist. Und es gibt keine Firma xyz von der wir bezüglich der Geräte abhängig sind und welche das System beim Konkurs mit in den Tod reißt. Alles ist so einfach das ich heute verschwinden könnte und ich bin sicher ihr würdet eure Hives trotzdem zum Leben erwecken können.

Und wartet mal ab: Wer das Gerät selbst aufgebaut hat bestimmt wird auch fähig sein die eine oder andere Hardwareidee vielleicht selbst zu realisieren: Selbst ist die Drohne!

laserjones hat geschrieben:Ähm ... mal was ganz Grundsätzliches: Wir reden doch hier nicht von einem Multitasking-Betriebssystem, oder? Zumindest sehe ich dafür keinen ernsthaften Sinn auf dem HIVE. Wenn aber (neben dem TRIOS) immer nur eine Anwendung läuft, kann die doch ihre eigenen Treiber mitbringen und starten. Wozu dann ein externer Manager? Wenn wir anfangen, alles zu modularisieren, wächst der Verwaltungsaufwand extrem - dann schreibt jemand eine neue Version eines Treibers, und plötzlich laufen Anwendungen nicht mehr, weil sie eine ältere Version erwarten ...

Multitasking .. Nunja, der Sinn ist schon gegeben .. wir haben 3x8 COGs zur verfügung ..!
Ein Externer Manager deshalb:
Netzwerkkarte .. ICH will nicht das jedes bekloppte Programm meine Karte mit eigenem treiber anspricht und dem ding womöglich auch noch willkürlich ne IP vergibt oder ich dem das jedes mal sagen muss !

Wieso sollte nach neuschreiben/aktualisieren eines Treibers denn ein Programm nicht mehr funktionieren ?
(Es ist nun nicht gerade so als ob wir viel unterschiedliche Hardware haben im Hive, jeder hat das selbe)
Das wäre ja das feine daran .. die Programme erwarten keine Version oder einen bestimmten Treiber .. die schicken nur ne anforderung und erwarten eine Antwort .. von Wem? das kann den Programmen doch egal sein!
Ein Programm "ping" würde dann nur noch ..
GetData(drvNI, "icmp 192.168.1.1")

laserjones hat geschrieben: Es ist doch gerade das Schöne am Propeller, dass man mit wenig Aufwand auf fertige Software-Objekte zurückgreifen kann, also muss man für ein Programm nicht alle Treiber selbst neu schreiben, aber man kann sie trotzdem fest ins Programm integrieren und muss sie nicht als separaten Task laufen lassen.

muss ist das Stichwort, man MUSS nicht
Treiber muss ja dann nicht jeder neu schreiben .. Gerade das ist ja das Argument für ein Verwaltungstool.
Treiber fest ins Programm integrieren halte ich für programmiertechnischen schwachsinn. Ich will nicht jedes mal in nem prog irgendwelche treiber initialiesieren wenn ich sie brauche und dann mit dem reden ..

Das vergrößert die ganzen programme, einen garbagecollector haben wir nicht und es kommt zu treiberkonflikten !

laserjones hat geschrieben: Klar, wenn wir natürlich irgendwann ein standardisiertes Fenster-GUI hätten, wird Multitasking interessant und damit auch externe Treiber. Aber ich glaube ja, dass das alles auf einem HIVE Overkill wäre.

Nicht meine intention, aber Overkill ist es auf keinen fall .. Wir haben 3x8 COGs von denen man auch ruhig alle nutzen kann und zwar nicht nur um nen heartbeat anzuzeigen

laserjones hat geschrieben: Oder denken wir hier aneinander vorbei? ich habe wenig Ahnung von diesen Dingen und finde hackticks Texte auch schwer verständlich (für mich).

Das ist ohne weiteres möglich

Mein ansatz war ja das man das als grundlage nimmt .. und mit sowas als Grundlage kannst du dann an Software auf deinen Hive aufspielen was du willst und kannst darauf entweder retro games laufen lassen oder eine grafische oberfläche .. ODER beides, wonach dir gerade ist !

Also zusammenfassend:
Wir haben extrem viele Möglichkeiten wie wir den Hive gestalten KÖNNEN .. für eine müssen wir uns im endeffekt entscheiden! Und ich persönlich würde die flexibelste/interessanteste Möglichkeit nutzen wollen.

Rainer hat geschrieben: Ich kann mich bestimmt Stundenlang mit SPIN amüsieren und ein Programm schreiben, ohne mir auch nur entfernt Gedanken um Bildschirmtreiber machen zu müssen.
Ich kann aber auch sehr tief einsteigen und unglaubliche Sachen machen ... eben ganz wie ich will ... heute das, morgen was anderes.

GENAU das will ich damit erreichen
Das jeder Coder ein Game oder eine Anwendung schreiben kann ohne sich über das was im Hintergrund groß abläuft Gedanken machen zu müssen und auf der Anderen Seite auch jeder Coder einen Treiber verbessern, einen neuen schreiben oder gar die ganze Schnittstelle erweitern kann