Regime

[drohne235]

@drohne235

Die einzigen belegten Adressen vom IOS im eRAM sind von $0FFFAC - $0FFFFB.
Sehe ich das richtig ?
Ich frage deshalb, weil ich den Ringpuffer von Regime in's eRAM legen will ... wäre ja blöd wenn ich da was überschreibe

Genau, die belegten Systemvariablen befinden sich am oberen Ende des eRAM's. Wahrscheinlich packst Du den Puffer in den hRam - da ist ja auch noch mehr als genug Luft, allerdings ist diesen Freiwild sobald eine BIN-Datei gestartet wird.

Im eRAM wäre es schon richtig, dafür bräuchte man eine einfache Speicherverwaltung - dann könnte man die Puffer und andere Variablen resident und geschützt nutzen.

[Rainer]

So, wird langsam

.

An der Farbausgabe muß ich allerdings noch einiges tun *lol*
Batchdateien laufen schon rudimentär .. fehlen halt noch die ganzen "goto", "choice", usw. - Geschichten.

Der Speicher vom Propeller scheint im Moment noch Grenzenlos zu sein ... ich komme nicht mal in die Nähe von Platzschwierigkeiten im Moment.

Gruß.
Rainer

[drohne235]

Coooool!

Mit dem Speicher das ist auch so meine Erfahrung: Ich hab bisher in Regnatix auch noch nicht den Speicher ausgeschöpft. Als ich beim Entwurf über den externen Speicher damals nachdachte waren wahrscheinlich die Augen größer als der Hunger! Man ist da so geschädigt durch die Selbstverständlichkeit, das bei einem berühmten Betriebssystem nicht mal ein Maustreiber in 32 KByte passen würde.

Ich habe heut mit digger am Telefon über genau dieses Thema geschwätzt: Hat der Propeller nun zu wenig RAM? Wenn man nur einen Propeller hat wird es schnell eng, aber im Hive sieht die Situation schon ganz anders aus. Selbst wenn man im Hinterkopf hat das der C64 mehr Speicher als ein Prop hat darf man nicht vergessen das der C64 auch alle Funktionen (Grafik, Sound, Floppy...) in diesem Speicher verwalten musste. Im Hive verteilt sich das über drei Subsysteme und wenn man es vergleichen wollte müsste man sagen, dass der Hive 96 KByte RAM zur Verfügung hat - halt nur verteilt für die einzelnen Funktionskomplexe. SPIN ist als Bytecode schon recht kompakt und ich finde für solche Sachen wie eine Kommandozeile auch ausreichend schnell - da sind dann 32 K eine Menge Holz.

[Rainer]

So, neuer Befehl, neues Glück

"cogs" zeigt belegte/freie Cogs an.

Nun die Frage: Ist es für euch sinnvoll, auch die Belegung der beiden anderen Propeller zu wissen, oder ist das für euch ohnehin irrelevant ?
Ich müsste dazu nämlich das IOS erweitern (was kein Problem ist) .. aber wenn's keiner braucht, dann lasse ich es.



Gruß.
Rainer

[scotty]

...
Nun die Frage: Ist es für euch sinnvoll, auch die Belegung der beiden anderen Propeller zu wissen, oder ist das für euch ohnehin irrelevant ?
...

Nettes Feature und ich denke, wenn wir Administra mit einem flexiblen Loader ausstatten wollen, können wir die Cog-Belegungs-Abfrage ganz gut brauchen. Also weitermachen!

[drohne235]

Als sinnvolles Feature hatte ich folgendes abgespeichert: Eine einfache Verwaltung des Bellatrix-Treibers, d.h. es werden im eRam als Systemvariable zwei Dateinamen gespeichert - der Name des Standardtreibers (z.B. vid.bin) und der Dateiname des aktuell aktiven Treibers (z.B. stint.bin) wenn der Startracker gestartet wird. So kann eine entsprechende ios-Funktion selbst entscheiden ob beim Beenden einer Anwendung evtl. wieder der Staandardtreiber neu in Bellatrix geladen werden muß und es wird ein unnötiges laden verhindert.

Die COG-Auslastung ist cool und wird interessant wenn wir residente Programme realisiert haben, dann könnte man vielleicht auch noch einen COG-Besitzer anzeigen.

Was mir grad auffällt: Eigentlich müßte er ja COG 1 auch als belegt anzeigen (läuft ja Regime drauf). Vielleicht könnte man den eigenen Prozess mit einem anderen Symbol darstellen? Wobei man es auch nicht zu kompliziert machen muß - brauchen ja nur sinnvolle Features rein. Bin mal auf den Batchprozessor gespannt... Ob man eine Batch in einer extra COG laufen lassen könnte? Würde das Sinn machen?

[Rainer]

Als sinnvolles Feature hatte ich folgendes abgespeichert: Eine einfache Verwaltung des Bellatrix-Treibers, d.h. es werden im eRam als Systemvariable zwei Dateinamen gespeichert - der Name des Standardtreibers (z.B. vid.bin) und der Dateiname des aktuell aktiven Treibers (z.B. stint.bin) wenn der Startracker gestartet wird. So kann eine entsprechende ios-Funktion selbst entscheiden ob beim Beenden einer Anwendung evtl. wieder der Staandardtreiber neu in Bellatrix geladen werden muß und es wird ein unnötiges laden verhindert.

Gute Idee. Im Moment würde ich mich damit aber verzetteln .. ist vll. was für den , der die Speicherverwaltung schreibt

Die COG-Auslastung ist cool und wird interessant wenn wir residente Programme realisiert haben, dann könnte man vielleicht auch noch einen COG-Besitzer anzeigen.

Das wird ein bischen schwierig. Teilweise starten Programme für eine einzige Funktion schnell einen neuen Cog und beenden den wieder. Da kriegt das "darunterliegende Überwachungsprogramm" nicht mit davon

Was mir grad auffällt: Eigentlich müßte er ja COG 1 auch als belegt anzeigen (läuft ja Regime drauf). Vielleicht könnte man den eigenen Prozess mit einem anderen Symbol darstellen? Wobei man es auch nicht zu kompliziert machen muß - brauchen ja nur sinnvolle Features rein.

Jo, habe vergessen, meinen eigenen Prozess abzufragen *grml*
Wird noch geändert.

Bin mal auf den Batchprozessor gespannt... Ob man eine Batch in einer extra COG laufen lassen könnte? Würde das Sinn machen?

[/quote][/quote]
[/quote]

Bin ich noch am überlegen. Könnte ziemlich in's Auge gehen, wenn 2 Prozesse auf SD zugreifen, z.B.
Im Moment benutzt der Batchprozessor die Funktionen von Regime. Ich werde die Funktionen wohl extrahieren und in ein eigenes Prgramm verfrachten .. mal sehen.
Erst schreibe ich mal den Code für die Befehle. Ich brauche ja erst mal einen Überblick, was der Batchprozessor alles können muß.

Gruß.
Rainer

[Rainer]

Was mir grad auffällt: Eigentlich müßte er ja COG 1 auch als belegt anzeigen (läuft ja Regime drauf). Vielleicht könnte man den eigenen Prozess mit einem anderen Symbol darstellen? Wobei man es auch nicht zu kompliziert machen muß - brauchen ja nur sinnvolle Features rein.

Hmmm .. gerade noch mal getestet .. die Routine scheint in Ordnung zu sein.
Regime läuft doch auf COG 0 .. andere Cogs sind frei, da ich sie belegen kann.
Folgender Code:

Code: Alles auswählen

  c := cog[1] := cognew(@entry, 0)
  c := cog[2] := cognew(@entry, 0)
  c := cog[3] := cognew(@entry, 0)
  c := cog[4] := cognew(@entry, 0)
  c := cog[5] := cognew(@entry, 0)
  c := cog[6] := cognew(@entry, 0)
  c := cog[7] := cognew(@entry, 0)

ergibt in der Auswertung:


[EDIT]
Gerade nochmal getestet:
Wenn ich mir "c" nach jedem Start eines Cogs ausgeben lasse, kriege ich bei jedem Start >= 0, was ja Erfolg bedeutet. Nur bei Cog 0 kriege ich -1, was ja auch richtig ist.
Allerdings muß ja in Regnatix ein Lader sein, um Regime zu starten .... irgendwie habe ich gerade Gedanklich einen hänger *grübel*
[/EDIT]

[EDIT2]
Ok, einen letzten Test gemacht:
Alle 8 Cogs gestartet mit Ergebnis : -1,1,2,3,4,5,6,7
Gleich danach nochmal versucht alle Cogs zu starten
Ergebnis: -1,-1,-1,-1,-1,-1,-1,-1
Also ließen sich beim ersten mal 7 Cogs erfolgreich starten, beim zweiten mal keiner mehr ... was ja genau so sein sollte.
Ich finde den Fehler nicht (wenn es denn einer ist). Ich schau mir mal jetzt den Loader von Regnatix an. Vielleicht killt er sich ja selber beim laden von Regime.
[/EDIT2]

[EDIT3]
HA !
ios.printdec(cogid) --> 0
Da "cogid" ja die Nummer des den Befehl ausführenden Cogs anzeigt .. und das Regime ist, läuft Regime auf COG 0
Ich habe mir jetzt mal die Routine im Loader angesehen .. die Zeile "cognew(INTERPRETER, spinptr+4)" macht mich etwas stutzig, da INTERPRETER = $f004 ist .. und das ist die Interpreteradresse im ROM vom Propeller. Irgendwie glaube ich, Cog 0 startet sich dadurch selber mit dem nachgeladenen Code, was ziemlich cool wäre
Normalerweise nimmt man dafür "coginit" wenn ich mich nicht täusche.
Nebenbei: Ich weiß, ich nerve .. aber das interessiert mich jetzt
[/EDIT3]


Gruß.
Rainer

[drohne235]

Zum Loader-Geheimnis: Der Loader läuft im Normalfall immer im Hintergrund. Das erkennt man dadurch das man in Regime externe Programme starten kann, denn das macht streng genommen nicht Regime, sondern der Loader. Beim starten einer BIN-Datei in Regime, oder aus einer anderen Anwendung heraus über das ios, passiert folgendes:

Code: Alles auswählen

PUB load | len,i,stradr1,stradr2                        'startet bin-datei über loader
{{ldbin - startet bin-datei über loader}}
  ios.paraset(@tib + os_nextpos)                        'parameterstring kopieren
  ios.ldbin(os_nextpara)

Die Funktion ios.paraset kümmert sich erstmal um die Parameter welche hinter dem Kommandostring stehen. Diese werden in die Systemvariable im eRam kopiert, damit das aufgerufenen Programm diese auswerten kann, aber das ist jetzt nicht ganz so interessant. Nur zur Orientierung findet man diese Variable am Anfang der ios definiert:

Code: Alles auswählen

PARAM           = $0FFFAD       '64 Byte                'Parameterstring

Als nächstes wird die Funktion ios.ldbin mit einem Zeiger auf den Komandostring (den Dateinamen des zu startenden externen Programms) aufgerufen. Der Code dafür sieht folgendermaßen aus:

Code: Alles auswählen

PUB ldbin(stradr) | len,i,stradr1,stradr2               'loader: startet bin-datei über loader
{{ldbin - loader: startet bin-datei über loader}}

  len := strsize(stradr)
  stradr2 := lflagadr + 1
  repeat i from 0 to len - 1                            'string in loadervariable kopieren
    byte[stradr2][i] := byte[stradr][i]
  byte[stradr2][++i] := 0                               'string abschließen
  byte[lflagadr][0] := 1                                'loader starten

Wo zum Teufel wird dabei eine BIN-Datei gestartet? Die Antwort lautet: Nirgends! Schauen wir uns an was genau passiert. Eine Schleife kopiert den übergebenen String (unsere Datei die gestartet werden soll) irgendwo hin. Wohin das ist kann man nicht im ios erkennen, es ist einfach ein Bereich der durch den Zeiger "lflagadr + 1" definiert ist. Die Lösung des Rätsels findet man im Code des Loaders (os-1-reg-loader.spin) selbst.

Auf der Mauer auf der Lauer:

Um den Knoten schon ein wenig vorweg zu entwirren - du hast es wahrscheinlich eh schon vermutet - nicht Regime lädt und startet die BIN-Dateien, sondern der Loader, welcher in einer anderen COG im Hintergrund auf der Lauer liegt. Der Loader selbst ist extrem klein gehalten und "verbraucht" den gesamten restlichen Speicher in Form einer Variable - dem Heap.

Code: Alles auswählen

VAR
  byte  heap[PROGLEN]                                   'programmspeicher

Die ios-Funktion ldbin(stradr) nun kopiert den Dateinamen in die Loader-Variable lname[16], welche sich genau einen Byte hinter lflag befindet. (Deshalb lflagadr + 1)

Code: Alles auswählen

  byte  lflag                                           'flag zur steuerung des loaders
  byte  lname[16]                                       'stringpuffer für dateinamen

(Man sollte also auch tunlichst vermeiden die Reihenfolge oder Definition dieser beiden Variablen zu ändern, sollte ich vielleicht mal im Kommentar erwähnen!?)

Danach wird lflag auf den Wert 1 gesetzt - das Startsignal für den Loader aktiv zu werden: Er killt alle restlichen COG's, lädt die BIN-Datei in den Heap und startet den SPIN-Tokenprozessor aus dem ROM (cognew(INTERPRETER, spinptr+4)) mit einem Zeiger, welcher auf den Code im Heap weist. Dann löscht er lflag und legt sich wieder auf die Lauer.

Das starten von BIN-Dateien ist also schon ein Zusammenspiel von zwei Prozessen/COG's. Kille einfach mal die unterste COG in welcher der Loader lebt, dann sollte zwar noch Regime laufen, aber es können keine Programme mehr gestartet werden.

[Rainer]

[Hat sich erledigt]
Tut mir leid wenn ich Dir wiedersprechen muss, aber....
Ein cogstop(0) killt Regime.
Nichts geht mehr, nur bellatrix läuft noch sichtbar (Bildschirm ist da) .. Administra wohl auch, kann ich gerade aber nicht überprüfen.
[/Hat sich erledigt]

Ich kann Deine erklärung ja nachvollziehen, aber die Praxis zeigt mir einfach ein anderes Bild .. oder ich mache irgendwo einen Fehler.

AAAAAAAAAhhhhhhhhhhhhhh.
Grade nochmal geschaut ... ich habe "ios.startram" aktiv, da ich ja ständig neue Versionen teste.

Das würde Sinn machen
Trotzdem war's nicht umsonst ... wieder viel gelernt.
Danke nochmal für Deine Mühe.

[EDIT]
So, gerade getestet. Datei auf die SD kopiert und den Hive gestartet ... "cogs" eingegeben-->2 Cogs belegt.
Ich bin sooo ein Trottel .. die halbe Nacht um die Ohren geschlagen weil ich unbedingt rausfinden wollte was da faul ist*grml*
Das kommt davon wenn man einfach nur ios-Funktionen benutzt ohne zu wissen, wo die genau was auslösen.
[/EDIT]

Gruß.
Rainer