Full house regnatix

[assbuster]

Die Binaries für Regnatix sind voll 32 kByte.

Wie erweitert man in Zukunft das Trios Betriebssystem (mit weiteren Kommandozeilen Befehlen) ?

Ich finde keine Assembler Zeilen in der Hive Trios Systemsoftware.
(vielleicht habe ich auch nicht alles Source files durchgeschaut)

Ist es geplant zumindest den Betrieb von SD Card und Regnatix SRAM
Transfer Routinen im cog Ram mit schnellem Assemblercode zu schreiben ?

[drohne235]

Die Binaries für Regnatix sind voll 32 kByte.

Du meinst wahrscheinlich den Loader im Verzeichnis flash? Diese Datei wird ja nur beim Systemstart aus dem EEPROM geladen. In ihr befindet sich ein winziges Programm, welches in der COG 0 gestarte wird, den Rest des Speichers als Heap verwaltet und Programme von SD-Card laden und starten kann. Compilierst du die Datei mit der Option "Forth", dann befindet sich neben dem Loader im Heap das Forth, welches in den anderen COG's gestartet wird. Unabhängig davon wird aber immer in COG0 der Loader gestartet und bleibt resident!
Compilierst du mit der Option "Regime", so lädt der Loader die Datei reg.sys von SD-Card in den Heap und startet sie. Diese Datei enthält normalerweise die Kommandozeile Regime, aber man kann sich auch eine SD-Card bastelm mit dem StarTracker in der reg.sys, der dann halt automatisch startet.

Wie erweitert man in Zukunft das Trios Betriebssystem (mit weiteren Kommandozeilen Befehlen) ?

Den Quelltext von Regime selbst findest du in der Datei "system\regnatix\regime.spin" und sie hat compiliert noch über 22KByte frei - da ist also noch massig Platz für interne Erweiterungen. Unabhängig davon kannst du Regime natürlich bequem mit externen Kommandos erweitern, die halt aus dem Systemverzeichnis nachgeladen werden. Das bietet sich für Funktionen an, welche nicht so oft benötigt werden. Das Kommando "sysconf" oder "time" sind solche Beispiele, die Quelltexte findest du im gleichen Verzeichnis wie Regime.

Ich finde keine Assembler Zeilen in der Hive Trios Systemsoftware.
(vielleicht habe ich auch nicht alles Source files durchgeschaut)

Zum Beispiel im Loader (siehe oben) findest du den drv:ext (SerielleSchnittstelle von Forth fürs externe Terminal) im DAT-Block. Ansonsten sind fast alle Treiber (VGA, TV, Key/Mouse, HSS, SD-Card, SIDCog usw.) in Assembler geschrieben, das sind die zeitkritischen Sachen. Ohne PASM könnte man halt zum Beispiel kein VGA/TV-Signal per Software ausgeben. Auch die Kernroutinen für SD-Card sind in PASM realisiert. Die meisten Quellen dazu findest du im Lib-Verzeichnis.
TriOS selbst aber, also die Kommandozeile, die Tools und auch die Routinen im IOS sind komplett ganz bewußt in Spin geschrieben. TriOS ist der Einstieg und soll so einfach wie möglich sein, was mit Spin möglich ist. Assembler ist da schon Level 2.

Code: Alles auswählen

Ist es geplant zumindest den Betrieb von SD Card und Regnatix SRAM 
Transfer Routinen im cog Ram mit schnellem Assemblercode zu schreiben ?

Ich habe oft darüber nachgedacht einen PASM-Backbone (in jedem Chip eine iCOG zur Kommunikation) zu schreiben und einige Routinen sind auch schon fertig. Aber es stellt sich dabei eine grundlegende Frage: Was bringts? Klar ist PASM sehr schnell, aber ist die Geschwindigkeit der Kommandozeile und Tools nicht ausreichend? Spin ist im Verhältnis zu PASM sehr kompakt und Speicher ist im Hive ein wertvolles Gut. PASM würde TriOS nicht nur schneller, sondern auch komplexer machen. Ich persönlich tendiere momentan mehr dazu, TriOS platzsparend und sehr simpel in Spin realisiert zu lassen. Es ist in meinen Augen wirklich ausreichend schnell und ziemlich griffig was die Struktur betrifft.

Ein anderer Aspekt ist der Bus zwischen den Chips an sich: Betrachtet man es genauer, so erkennt man, das der Bus nicht wirklich vergleichbar mit einem Bus in einem 8Bitter ist, sondern es handelt sich vielmehr um einen Metabus, welcher drei Plexi verbindet. Nimm nur den Grafikmodus 0: Bei der Darstellung von Vektorobjekten kommt man bei dem Sternobjekt zu einer Leistung von ca. 18000 linien pro Sekunde. Da die einzelnen Einheiten parallel und überlappend arbeiten, würde eine PASM-Routine diesen Wert kaum noch steigern. Spin ist da schnell genug die Metakommandos über den Bus zu senden und das Graphics-Objekt mit Daten zu füttern. Je komplexer die Objekte/Operationen werden, um so günstiger ist dieses Verhältnis. Ein zweites Beispiel - das kopieren von Dateien auf SD-Card: Warum die Daten über den Bus zu Regnatix schaffen? Lass sie doch einfach in Administra und kopiere dort, das geht in Rekordzeit, Regnatix gibt nur noch die Kommandos und die Spin-Routinen für den Bus sind dafür mehr als schnell genug. Anders ist das natürlich, wenn wir die Datei in den eRAM laden wollen... (Das liegt daran, das der eRAM eigentlich ein unintelligentes Relikt aus der Urzeit ist und damit ein wenig aus dem System fällt.) Was ich damit sagen will: Man muß bei der Parallelverarbeitung in den Propellerchips und noch mehr im Hive an vielen Stellen ein wenig anders denken.

Ansonsten: Sag niemals nie! Da ich eh immer nur mache was mir Spaß macht, kann das durchaus mal werden. Aber wenn du magst, kannst du das Thema gern beackern.

TriOS hat ja jetzt schon einen guten Stand erreicht. Ich bin dabei, einige gut nutzbare Grafikmodis einzufügen, die auch komfortabel zu verwenden sind. Nebenher stelle ich diverse Tools, Games und Demos/Codefragmente in den Toolboxen zusammen. Da TriOS ausreichend schnell ist und eine gute Ausgangsbasis bildet, wären verschiedene Tools erstmal viel wichtiger: Ein Texteditor, ein Hive-Commander, ein Tiles-Studio, ein Tool um Vektorobjekte zu zeichen und in Spincode auszugeben, Soundeditoren usw. Ein Handbuch wäre auch eine tolle Sachen. Das ginge alles schon in TriOS so wie es ist, deshalb liegt mein Fokus momentan nicht auf dem PASM-Backbone.

[assbuster]

oh ja, in der lib directory habe ich nicht geschaut.
Da ist aber jede Menge Assembler.
Ansonsten sieht man bei meinen Fragen gleich, daß ich noch keinen Hive gebaut
oder compiliert habe, sondern auf die Leerplatine des 3. Generationsdurchlaufes warte.