Hive.Sphinx

[yeti]

@mpark,

Do you have Propeller Tool compatible version of all of the Sphinx programs available somewhere? It would make it easier to do the keyboard driver switchout that I'm attempting.

OBC

Jetzt wird's wohl echt spannend: In SphinxOS kommt wieder Bewegung.

Wir sollten um Doppelarbeit zu vermeiden also Aribas Version schlicht nur "sauber" zum Laufen bringen, ggfs mal Mike Greens C3-Version anschauen und ansonsten ruhig abwarten in welche Richtung OBCs Aktivitäten SphinxOS nun bewegen.

Derweil können wir auf GGPPClone, SOMProp oder C3 unter SphinxOS in Ruhe den Spincompiler zerlegen, zersägen und hoffentlich ein bissl besser verstehen...

----------
Edit: --typos

[drohne235]

Zusätzlich müsste auch die Zeichenausgabe- und die Dateisystemroutine zentral zugänglich werden. Dann wird die Anpassung einfach.

[yeti]

Zusätzlich müsste auch die Zeichenausgabe- und die Dateisystemroutine zentral zugänglich werden.

Sind sie doch!

Dann wird die Anpassung einfach.

Schau mal die Filenamen der SphinxOS-Quellen an: Einige Dateien gibt es als ${NAME}.spn und als i${NAME}.spn.
In ${NAME}.spn ist der jeweilige "Treiber" implementiert. Dieser kommuniziert über seinen Rendevouz-Bereich im Hub mit dem Rest des Systemes. Das Anwendungsprogramm muß nur wissen wie man diesen Bereich bedient, also welchen Code man da reinschreibt um welche Aktion auszulösen und in welchem Format was zurück kommt. Dieses ist im zugehörigen i${NAME}.spn-File definiert.

Denk an CP/M... systemabhängig ist nur das BIOS. Das BDOS baut darauf auf und bietet dann der Applikation die weltbekannten Systemaufrufe die wir alle noch runterbeten können, z.B. Systemcall 9: cconws - String auf die Konsole ausgeben.

Wem das jetzt von z.B. (ATARI-)TOS oder MSDOS her bekannt vorkommt, braucht sich nicht zu wundern: Das sind alles CP/M-Nachfahren auf verschieden verschlungenen Wegen...

---> http://www.seasip.demon.co.uk/Cpm/index.html

[drohne235]

Also brauchen wir nur passende i-Dateien (Interface-Dateien?) zu erstellen. Ein kleines Problem gab es noch mit dem Dateisystem, da der Treiber in Sphinx zwei gleichzeitig geöffnete Dateien zulässt. Der aktuelle Administra-Code kann das nicht. Aber die Ramdisk im TriOS kann bis zu acht gleichzeitig geöffnete Dateien verwalten, also hab ich das als Ausgleich angedacht. Muss man halt nur alle nötigen Dateien vorher in die Ramdisk kopieren. Später hab ich an einen kleinen Manger gedacht, welcher diese Aufgabe automatisch wie bei einer einfachen Projektverwaltung übernimmt. So kann man auch jedem Projekt auf SD-Card ein Verzeichnis zuordnen - denn Verzeichnisse verwaltet der Sphinx-Treiber nun wieder nicht.

[yeti]

Also brauchen wir nur passende i-Dateien (Interface-Dateien?) zu erstellen.

Ursprünglich verwies ich auf die i-Dateien weil man an denen sieht welche Aufrufe umzustricken sind... also im Code der Apllikation selbst...

Nun kommt mir die Idee aber eher andersrum: Die i-Dateien lassen wie sie sind und statt der jeweils zugehörigen Dateien ohne i am Anfang "Treiber" hinlegen die statt der konkreten Hardware dann eben IOS bedienen...

Ob das mehr RAM kostet als SphinxOS selbst dafür verbrät vermag ich nicht abzuschätzen...

Der Gedanke muß sich auch erstmal setzen...

Ein kleines Problem gab es noch mit dem Dateisystem, da der Treiber in Sphinx zwei gleichzeitig geöffnete Dateien zulässt. Der aktuelle Administra-Code kann das nicht.

Dann muß Administra es eben lernen.

Noooooootfalls (GIGA-Warnung! Nichts lebt länger als eine Notlösung! (Was die Frage in den Raum stellt, ob Windows als Notlösung seine Existenz begann... aber das ist ein anderer Thread...)) könnte man das vorübergehend in sxfs (oder wie das auch immer heißt) ausbügeln...

...z.B. das auszugebende File zunächst in der RAMDisk anlegen und vor Terminieren der Applikation erst ins normale Filesystem rüberschieben.

Vielleicht auch für das zu lesende File? Beim Open(...) in die RAMDisk kopieren und beim Close(...) dort wieder entfernen? Wäre irgendwie konsequent und würde den einzigen File-"Kanal" von IOS für das Hinundherschieben zwischen SD und RAMDisk freihalten...