Soundsystem

[laserjones]

Ich sag ja, am besten wir machen den Administra-Code zur Laufzeit variabel - dann kann jede Anwendung ihren ganz eigenen Administra-Treiber aktivieren, welcher den entsprechenden Anforderungen gerecht wird.

Schon klar, aber ich möchte halt, wie schon gesagt, ein Soundsystem haben, das in der Lage ist, mit Netzwerk- und SD-Code zu koexistieren, daher möchte ich vorab einschätzen, welche Ressourcen es dann guten Gewissens verbraten darf.

[Rainer]

Ich sag ja, am besten wir machen den Administra-Code zur Laufzeit variabel - dann kann jede Anwendung ihren ganz eigenen Administra-Treiber aktivieren, welcher den entsprechenden Anforderungen gerecht wird.

Schon klar, aber ich möchte halt, wie schon gesagt, ein Soundsystem haben, das in der Lage ist, mit Netzwerk- und SD-Code zu koexistieren, daher möchte ich vorab einschätzen, welche Ressourcen es dann guten Gewissens verbraten darf.

laserjones spricht da schon einen, wie ich meine, wichtigen Punkt an.

Wir sollten mal klären (jetzt oder später), WAS denn genau das Basissystem beinhaltet. Macht wahrscheinlich keinen Spaß Anwendungen, Spiele, usw. zu programmieren und weiterzugeben, wenn ich immer dazu schreiben muß, welche expliziten Treiber wo zu sein haben, damit es läuft.
Also EINE Standardsystemkonfig, die ich bei jedem annehmen kann. Das gilt für Sound, Grafik, SD, usw. Andernfalls müsste ich zu jedem Programm alle Treiber jeweils mit in die ZIP packen und einen Starter schreiben, der mit bload die MCU's bestückt.

Das man alles selber ändern kann ist ein cooles Feature ... kann und soll ja auch jeder machen. Aber wir brauchen einen "Grundhive", wo alles außer irgendwelchen "Spezialgeschichten" sofort läuft.
Wenn jemand den "16 Mio. Farben-1680x1050-Superduper-Grafiktreiber" geschrieben hat, kann man den ja dann zum Standard machen.

Gruß.
Rainer

[drohne235]

naja, das schöne am treiberkonzept ist ja das das es zur laufzeit variabel ist. egal welches system ich real als os oder gui fahre, die anwendung sollte in bellatrix und administra ihren eigenen treiber laden können. schön wäre eine ios-funktion, welche dann bei beendigung der anwendung die konfigurierten standarttreiber wieder aktiviert damit die entsprechende oberfläche läuft. wenn man mehrere aufrufhierarchien zulassen möchte könnte man einen stack für die treiberkonfiguratin realisieren.

ich sehe den gemeinsamen nenner in ebend jener loadermechanik für die drei chips - damit wäre eine gemeinsame basis da und es wäre maximal flexibel. aber das sollte man wirklich genauer diskutieren, hatte ich auch vor anzusprechen wenn die hardware bei allen soweit ist. ich glaube momentan macht das noch nicht so viel sinn, alle müssen erstmal ihr system aufbauen und ein wenig damit rumexperimentieren. aber dann sollten wir wirklich gemeinsam eine gute basis schaffen. es ist überhaupt kein problem meinen "werkstattcode" komplett zu verwerfen, so viel arbeit steckt da nicht drin und eine solide basis ist da einfach wichtiger. so wie ich das softwaretechnische potential einschätze haben wir gemeinsam die paar rudimentären tools inklusive dem startracker in kürzester zeit angepasst und erweitert.

ein flexibler und möglichst kleiner loadermechanismus würde auch den wechsel zwischen verschiedenen betriebssystemen sehr einfach machen - und ich denke das ist ein gebiet auf welchem jeder gern mal experimentieren möchte.

[laserjones]

Wir sollten mal klären (jetzt oder später), WAS denn genau das Basissystem beinhaltet. Macht wahrscheinlich keinen Spaß Anwendungen, Spiele, usw. zu programmieren und weiterzugeben, wenn ich immer dazu schreiben muß, welche expliziten Treiber wo zu sein haben, damit es läuft.

Genau. Klar, wenn ich einen 64-stimmigen Super-Synthesizer schreibe, bringt der seine eigenen Soundroutinen mit und macht sich in Bellatrix komplett breit. Aber wer ein Spiel programmiert, ist vielleicht froh, wenn er auf ein fertiges Soundmodul zurückgreifen kann, das Musik und Effekte mit geringem Ressourcenverbrauch erzeugen kann. Eben wie HSS, nur etwas besser, weil der HIVE ja auch mehr Ressourcen hat als die Hydra. Ob dieses Modul dann mit dem Spiel geladen wird oder vom Standard-Basis-HIVE bereitgestellt wird, ist dabei für mich vorerst zweitrangig - mir ging es im Moment um eine Einschätzung, welche Ressourcen ein solches System verbraten darf, ohne die anderen Funktionen von Bellatrix zu beschneiden.

Kann Bellatrix denn prinzipiell auch Software direkt von SD bzw. ext. RAM laden, oder muss das immer über das EEPROM laufen? Meinst du das mit "Loadermechanismus"?

NACHTRAG: Ich meinte natürlich Administra, nicht Bellatrix!

[Janaha]

Halloe.

Ich glaube das mit den Resourecen werden wir am Ende wohl stark vom Betriebsystem abhängig machen müssen. Und ohne einen Hive in Händen wage ich da noch keine Handfeste Prognose, was so ein System später verbrauchen dürfte. Wenn ich ein wenig in meine Glaskugel schauen darf, würde ich sagen das das absolute Basissystem nur einen der Cog auf jedem Propeller wirklich permanent belegen dürfte. Dieser eine Cog, müsste dann als Minimum die Funktionalitäten ausführen können, um beliebiege Programmteile und Daten zwischen den Cog's austauschen zu können und diese Teile dann auf den anderen Cog's zu starten. Funktionen, wie Sound, Video, VGA, SD-Card zurgiff und Netzwerkzugriff würde ich aus dem Kernlen in eigenen kleinen Treibermodulen auslagern und nur bei bedarf starten. Wobei nichts dagegen spricht, eine art Autostart- Prozedur aufzusetzen, die beim einschalten schonmal den SD- Treiber startet und sich auf der SD- Card z.B. sowas wie eine "Autoexec.Bat" sucht und ggf. ausführt. Ob dann ein Windowsbasiertes System startet, oder eine einfache Dosshell wäre dann von den vorlieben des Anwenders abhängig und seiner autoexec.

Grüße
Janaha

[Rainer]

Kann Bellatrix denn prinzipiell auch Software direkt von SD bzw. ext. RAM laden, oder muss das immer über das EEPROM laufen? Meinst du das mit "Loadermechanismus"?

Mit der IOS-Funktion "PUB bload(stradr) | n,rc,ii,plen" hat drohne ja schon ein Nachladen von Treibern vorgesehen (im Moment nur für Bellatrix).
Regnatix kann damit die MCU neu bestücken und dann neustarten.
Das wollte/will er für alle MCU's schreiben (bzw. zusammen mit uns).

Regnatix kann auch für die anderen beiden das eRAM auslesen und diese an die MCU's "weiterleiten". Außerdem kann man die Kontrolle des eRAM auch an andere MCU's weitergeben.
Administra kann natürlich alleine auf SD zugreifen und ist damit in dem Fall unabhängig. Die beiden anderen brauchen aber zwingend Administra für SD-Zugriff.

Gruß.
Rainer

[drohne235]

Jo, Rainer hat es in wenigen Worten schon geschrieben. Da ich aber jetzt schon einen ellenlangen Text geschrieben hab muß ich euch damit noch ein wenig quälen. Vielleicht beleuchtet er die Sache nochmal genauer.

> Funktionen, wie Sound, Video, VGA, SD-Card zurgiff und Netzwerkzugriff würde ich aus dem Kernlen
> in eigenen kleinen Treibermodulen auslagern und nur bei bedarf starten. Wobei nichts dagegen spricht,
> eine art Autostart- Prozedur aufzusetzen, die beim einschalten schonmal den SD- Treiber startet und sich
> auf der SD- Card z.B. sowas wie eine "Autoexec.Bat" sucht und ggf. ausführt. Ob dann ein
> Windowsbasiertes System startet, oder eine einfache Dosshell wäre dann von den vorlieben des
> Anwenders abhängig und seiner autoexec.

Zumindest für Bellatrix und Regnatix ist das ja momentan schon so realisiert: Beide Chips laden nur einen minimalen Loader aus dem EEProm. Der Regnatix-Loader lädt dann von SD-Card die Datei sys.bin, welche quasi das OS beinhaltet, startet diese Anwendung in der zweiten Cog, bleibt aber selbst resident um auf Befehl andere Anwendungen starten zu können. Was ihr in die Datei sys.bin packt ist euer Bier - bei mir ist es momentan die Kommandozeile "Regime" (geiler Name , aber ihr könnt dort auch eure Aquariensteuerung oder den Code für einen Melodiegong bunkern - einfach einen (fast) normale Spin-Code compilieren und als Binärdatei auf der SD-Card als sys.bin abspeichern.

Der Administra-Loader startet auch aus dem EEProm, wartet aber auf ein Image (auch eine normale BIN-Datei), welches das gebootete OS in Regnatix ihm sendet (bei meiner CLI momentan die Datei vga.bin), startet diesen Treiber, beendet sich dann aber, so dass für den Treiber in Bellatrix alle Cogs zur Verfügung stehen. Der Treiber selbst kann aber über eine Funktion einen Reset von Bellatrix auslösen und somit wird der Miniloader wieder aus dem EEProm geladen und wartet auf ein neues Treiberimage - so kann jede Anwendung den Code in Bellatrix austauschen.

In Administra ist das ganze aber ein wenig komplizierter: Der Regnatix- und der Bellatrix-Loader konnten direkt oder indirekt auf die FAT16-Routinen in Administra zugreifen um eine Anwendung bzw. einen Treiber zu laden. Administra selbst kann aber nicht auf die eigenen FAT16-Routinen zugreifen und sich selbst an den Haaren aus dem Sumpf ziehen - sofern man nicht einen Administra-Loader realisiert, welcher schon FAT16 beherrscht. Hmm, keine Ahnung ob das jetzt irgendwie rüber kommt... Man könnte aber wie bei Bellatrix einen Resetmechanismus realisieren, wobei Regnatix den Treiber aber im eRam zwischen puffern muß, da ja nach dem Reset erstmal keine FAT16-Funktionalitten in Administra zur Verfügung stehen. Das hat Rainer ganz richtig erkannt und das ist auch ein wenig der Grund warum ich es bisher nicht realisiert ahb - es erscheint mir irgenwie noch nicht "einfach" genug, kann aber sein das es die einfachste Variante ist.

Vielleicht ist es auch gut sich den momentanen Bootmechanismus vorzustellen , indem man seine Evolution betrachtet. Als ich mit dem Hive angefangen hab, hatte ich die SD-Card noch nicht verwendet. Jeder Chip hatte sein Programm als eine Art Bios in seinen Flash bekommen. Man kann das auch jetzt noch problemlos nachstellen: Administra hat ja eh noch sein festes Bios im Flash, in den Flash von Regnatix könnte man die Datei sys.bin flashen (welche im Formalfall die Kommandozeile aber auch ein anderes beliebiges Programm enthalten kann) und in den Regnatix-Flash brennt man nicht den Loader, sondern einfach diregt den Treiber. Nach dem Einschalten wird in jeden Propeller der Flash geladen und aktiviert.

Das war anfänglich zum Testen ok, aber bald wollte ich ja flexibel Tools und Anwendungen von SD-Card starten können. Also habe ich den Regnatix-Loader geschrieben: Ein winziges Programm, welches beim Einschalten aus dem Flash gestartet wird, ein System (sys.bin) über Administra von SD-Card bootet und sich dann resident schlafen legt. Man beachte: Der Regnatix-Loader wird nicht beendet, sondern er wartet nach dem laden und starten der datei sys.bin auf Kommandos von ebend dieser Anwendung. Tippe ich in der Kommandozeile dann ein Kommando ein und es ist kein internes Kommando, wird geprüft ob es eine entsprechende Datei auf dem Datenträger gibt. Ist das der Fall sendet die CLI ein Kommando an den Loader, welcher ja noch in der ersten Cog resident lauert, damit dieser die CLI killt und die entsprechende neue Datei in den Ram lädt und startet. Wird eine normale Anwendung wieder beendet gibt es über eine ios-Funktion wieder ein Kommando an den Loader, er killt das Anwenderprogramm und startet wieder sys.bin.

Das war schon ein toller Fortschritt, aber bald sah ich, dass es sehr unflexibel ist, wenn in Bellatrix nur ein Code möglich ist. Die Gründe kann wohl jeder nachvollziehen. Also habe ich auch einen Loader für Bellatrix programmiert. Wie bei Regnatix wird auch dieser Loader beim starten des Systems geladen, lädt aber nicht aktiv seinen Code von Administra (da ich persönlich Bellatrix als Slave ansehe), sondern wartet auf ein Image, welches Regnatix sendet! Nun mußte ich nur noch das OS bzw. die Kommandozeile (quasi sys.bin) anpassen, damit diese nach dem starten ein Image von Administra lädt und an Bellatrix sendet - der Grafiktreiber (momentan verwendet die Kommandozeile die Datei vga.bin dafür). Im Gegensatz zu Ragnatix dachte ich mir aber, dass dieser Treiber nicht unbedingt resident sein muß und lasse ihn nach dem Laden des Treiberimages einfach beende, wodurch eine Cog für den Treiber selbst frei wird. Der Treiber kann aber über eine Funktion, welche von Regnatix aufgerufen wird, ein Reboot von Bellatrix ausführen, wodurch dieser Vorgang neu gestartet werden kann. Das Kommando (und die gleichlautende ios-Funktion) bload macht genau dies: Es sendet zum aktuellen Bellatrix-Treiber ein Reset-Kommando, wodurch dieser wieder seinen Loader aus dem EEProm startet und auf ein neues Image warte, welches bload gleich darauf sendet. Mit "bload tv.bin" kann man so den TV-Texttreiber einfach in der CLI aktivieren.

Jo, so funktioniert das momentan. Wenn wir jetzt auch noch für Administra solch einen Treiber realisieren, könnte man drei Dateien (z.B. adm.bin, bel.bin und reg.bin - ein Vorschlag) definieren, welche beim Einschalten/Reset automatisch geladen werden und das Bootsystem repräsentieren. Ein Austausch dieser Dateien, oder ein anderer Datenträger mit anderem Inhalt der Dateien würde auch ein anderes System starten. Man bräuchte wirklich nur diese drei universellen Treiber und wäre maximal flexibel. Auch ein Kommando (z.B. "sysload osx wäre denkbar, mit welchem man einfach ein neues system bootet.

[laserjones]

(z.B. adm.bin, bel.bin und reg.bin - ein Vorschlag)

Ich würde sysadm.bin, sysbel.bin und sysreg.bin verwenden, das sagt etwas mehr aus und sorgt dafür, dass die drei Dateien in alphabetischen Listen untereinander erscheinen.
Alternativ: loadadm.bin, loadbel.bin und loadreg.bin.

Das war jetzt mein gigantischer kreativer Beitrag zu der Unmasse von Grips, die im vorigen Beitrag steckt.

[drohne235]

Das war jetzt mein gigantischer kreativer Beitrag zu der Unmasse von Grips, die im vorigen Beitrag steckt.

Ach was, das klingt irgendwie nur komplex wenn man es aufschreibt. Aber du wirst sehen: Wenn man den Hive schrittweise aufbaut, findet man ganz automatisch genau zu diesen Gedankengängen. Da folgt ganz logisch ein Schritt dem anderen. Insofern ist der Hive idealerweise als Bausatz selbst in Funktion zu setzen.

[Rainer]

So, habe mich mal ein bischen schlau gemacht, was Filter, Wellenformen, usw. angeht.
Schwer verdauliche Kost für mich um ehrlich zu sein. Wellenformen waren ja noch einfach, aber dann gings los

Das Thema ist aber ziemlich spannend. Auf meinen Reisen durchs Netz bin ich dann letzendlich bei analogen Synthesizern hängengeblieben .. lieber Gott, was für ein fetter Sound ! Der "Oberheim" hatt's mir am meisten angetan. Schade, das ich so verdammt Talentfrei bin, was spielen von Musikinstrumenten angeht

Wenn wir auch nur annähernd so was hinkriegen würden (natürlich digital) würde ich Luftsprünge machen

Hört es euch mal an.
http://www.youtube.com/watch?v=PHgP9phs ... re=related
http://www.youtube.com/watch?v=5W9b4Krvp-Q

Gruß.
Rainer