CUBIX - n8vem

    Beim stöbern im Netz bin ich auf eine interessante Sache gestoßen: CUBIX

    Kennt das jemand?



    Es ist ein komplettes DOS für ein Motorola 6809 System:

    • Unterstützung von bis zu 8 serielle Ports
    • Unterstützung von bis zu 4 Floppy Laufwerke
    • Unterstützung einer IDE Festplatte
    • es ist eine komplette Tool Palette dabei, samt Assembler, Editor, Forth, BASIC etc.
    • alles im Source Code Verfügbar
    • alles perfekt dokumentiert


    Der Clou: es passt alles in ein 8KB ROM


    Ja richtig gelesen ACHT KILO BYTE!!!


    Schon klar es gibt FLEX, OS9 und NitrOS.

    Aber das CUBIX besticht durch seinen Minimalismus.



    Ich hab mir heute die Sourcecodes angeguckt, speziell die IO Driver.

    Im Grunde muss man nur die drei IO Driver anpassen und das müsste eigentlich schon auf meinem 6309 SBC laufen.



    Es juckt mich in den Fingern, Ich denke ernsthaft darüber nach das CUBIX zu portieren.

    Speziell weil ich mit der OS9 Sache nicht so gut weiter komme ...

    ... vielleicht ein Zwischenschritt.



    Quellen:

    DAVES OLD COMPUTERS - CUBIX INFORMATION

    n8vem-overview

    Das CUBIX läuft auf meinem SBC. :)


    Das war wirklich super easy.

    Das meiste Gefummel hat man, die Disketten Images zu erzeugen.


    Wirklich nett das CUBIX.

    Könnte man jetzt ausbauen.

    MMU fähig machen, eine eigene System Bank.

    Sodass Benutzer Programme wirklich die ganzen 64K haben ...




    Aber eigentlich will ich ja immer noch OS9.

    Jetzt weiß ich wenigstens, dass die SBC Hardware rund läuft.


    Wahrscheinlich krieg ich den OS9 Port nur hin, wenn ich mir einen Emulator bastle für meinen SBC ...

    Zitat von ThoralfAsmussen

    Was fehlt denn am OS-9 ?

    Ich hab schon eine halbe Ewigkeit gebraucht bis ich es kompilieren konnte.

    Zuerst unter Windows gescheitert.

    Dann extra eine Linux Maschine angeschafft, da ging es dann easy.

    Aber da tu ich mich schwer mit den Tools die mir da fehlen.

    Inzwischen läuft das kompilieren unter MingW ganz gut..


    Hab versucht den Kernal zu patchen und bestehende Treiber.

    Aber es kommt nicht mal ansatzweise hoch.

    Ich müsste es irgendwie debuggen, die Hardware dazu fehlt mir.


    Aber mit dem Emulator müsste es dann möglich sein.

    Da kann man den Boot Vorgang vernünftig analysieren.



    Der Emulator läuft jetzt mal ansatzweise.

    Die MMU, RAM und ROM und die LED Anzeige sind implementiert.

    Versuche gerade die serielle COM und die Floppy Laufwerke rein zu basteln.


    Da ist noch einiges zu tun ...

    Ich dachte an drei Terminal Fenster:

    • eines wie ein Monitor mit dem man die virtuelle CPU steuern kann (Breakpoints, Singlestep, Disassembler ...)
    • eines für die virtuelle serielle Schnittstelle
    • eines für Logging, wo man ausgeben kann was das Ding so treibt

    Das CUBIX 1.3 hat einen Bug.


    CUBIX kann mit Festplatten bis 32MB umgehen.

    Leider kann das interne FORMAT nur bis 16MB korrekt formatieren.


    Es kommt kein Fehler bei größeren Platten.

    Aber die Sector-Link-Map wird nicht allokiert, deswegen zerstört sich das Disk Image im Betrieb.




    Ich habe das gefixed im Source Code, wenn es wer braucht ...




    Und ich arbeite an einem Windows Commandline Tool, das mit CUBIX Diskimages umgehen kann.


    Bisher funktioniert:

    • Struktur Info Anzeige
    • Directory anzeigen mit Attribute und LOAD Adresse
    • Sektor MAP anzeigen und prüfen
    • Sektor Verkettung anzeigen und prüfen

    Was noch rein kommt:

    • Disk Image formatieren
    • Disk Image erstellen, wenn man die Geometrie angibt
    • Dateien extrahieren
    • Dateien ins Imagefile schreiben
    • Bereinigung (wie DOS Checkdisk) - CUBIX hat zwar ein solches Tool aber der PC ist 'etwas' performanter ...





    Die Beta-Test Phase des CUBIX Disk-Image Tool ist angelaufen. :)


    Falls jemand testen mag, ich freue mich über Feedback, Fehler Reports etc.




    Es hat mich erstaunt, wie komplex das Tool jetzt geworden ist.

    Zuerst habe ich mir das Ganze viel einfacher vorgestellt.


    Nun ja jetzt ist es fertig, der geplante Funktionsumfang ist implementiert.

    Es müssen nur noch die Fehler gefunden und gefixed werden.









    Eigentlich wäre es praktisch, wenn man direkt SRECORD Dateien verarbeiten könnte und dann al Binary in das Image File schreiben.


    Das werde ich noch einbauen.

    Damit kann man die CUBIX System Programme direkt in den SYSTEM Ordner schreiben oder in eine Startdiskette.



    Das wäre auch noch ein Feature, über das man nachdenken könnte:

    - eine Bootdiskette erstellen

    - die Harddisk bootfähig zumachen


    Bei mir befindet sich ja das ganze CUBIX im ROM.

    Aber dieses n8vem System bootet offenbar von Diskette oder Harddisk.

    Es hat nur ein 2K großes Minisystem im ROM: ein Hex Monitor, Loader und CUBIX Boot.


    Das CUBIX OS füllt eine Spur des Datenträger.

    Die Sektoren werden nacheinander ab einer fixen Adresse geladen.

    Ich frage mich, wie CUBIX die Sektoren gegen überschrieben schützt?


    Natürlich kann man die Sektoren als belegt markieren.

    Aber die Kette wäre ja verwaist, das CHKDSK würde es wieder freigeben?

    Hat jemand eine originale CUBIX Start Diskette?

    Dann könnte ich mir angucken, wie man das richtig macht.

    Das CUBIX ist wirklich genial. :)

    Ich mag das OS inzwischen sehr.

    Es ist minimalistisch, aber es hat alles was man so braucht.

    Es gibt sogar einen eigenen Assembler und einen C Compiler.


    Schade dass es 11K (samt IO Block und System RAM) braucht.



    Die Systemaufrufe funktionieren genau wie beim OS9 mit SWI und einem Folgebyte.


    Das bietet sich geradezu an für ein System mit einer MMU:

    - eine Bank für Benutzerprogramme mit 64K RAM

    - eine Bank für CUBIX


    Der SWI Befehl schaltet automatisch in die System Bank.

    Beim Retourweg müsste man das CUBIX pimpen.

    Und natürlich bei allem wo CUBIX in die Benutzer Bank greifen muss.


    Leider sind einige System Programme nicht vollständig gekapselt.

    Die sind abhängig von direktem Zugriff auf System Ressourcen.

    Okay, das CUBIX Tool BOOTGEN.EXE positioniert einfach auf den vorletzten Track des Datenträger und schreibt das ganze OS raus. :D


    Keine Prüfung ob diese Sektoren frei sind.

    Keine Aktion nach dem schreiben, die Sektoren werden nicht belegt.


    Wenn jemand die System Diskette zu voll macht, selber Schuld ... :D

    Das CUBIX Tool LDIR hat einen Bug, es läuft in einer endlos Loop.

    Es ist gefixed und funktioniert nun tadellos.


    Das FORTH in dem CUBIX läuft wirklich sehr gut, sehr beeindruckend. :)



    Die S-Record lib ist auch fertig.

    Um die Funktionen zu testen habe ich ein kleines Tool gemacht.

    Es kann mit allen Arten umgehen die Motorola dokumentiert hat: S0, S1, S2, S3, S5, S6, S7, S8, S9


    Ich bau den SREC Code jetzt ein im Disk Image Tool und im Emulator.





    .

    Zitat von for(;;)

    Diddl : machst Du das alles im Emulator? In dem von Dave Dunfield oder hast Du da selbst noch Hand angelegt

    Nee, ich verwende nicht den Simulator von Dunfield.


    Es läuft alles auf meiner 6309 SBC Hardware.

    Ganz in real.


    Allerdings habe ich einen SBC Emulator geschrieben.

    Der verhält sich exakt wie meine SBC Hardware.

    Dadurch geht alles viel schneller und einfacher.

    Single step sogar zum Boot Zeitpunkt, wenn man es braucht.

    Das CUBIX Disk Image Tool kann jetzt auch direkt mit S19 Dateien umgehen.


    Im Falle von S19 Systemdateien benötigt man auch kein Description File mehr.

    Das Tool geht dann von default Einstellungen aus:

    • Ordner [SYSTEM]
    • Extension "EXE"
    • LOAD Adresse aus dem SREC File
    • Attribute: RWED


    Anbei ein ZIP das enthält:

    • ImgTool.exe (Win32 Commandline)
    • alle CUBIX Tools als S19 (einfach neu assemblieren bei Bedarf)
    • einem .cmd File das eine Harddisk Image Datei (32MB) erstellt und alle S19 importiert (-f:FF1FF)


    Wenn man eine System Diskette machen möchte statt einem Harddisk Image, dann einfach den Befehl ändern auf:

    Code
    ImgTool.exe system_a.img -f:50209
(80 Tracks, 2 Heads, 9 Sectors)



      




    .

    Das Dunfield FORTH ist deshalb so irre schnell, weil es nicht alles in Pseudocode wandelt und interpretiert.

    Vielmehr ist es wohl eine Art Zwischending zwischen Interpreter und Compiler.


    Gespeichert Worte werden mit JSR direkt aufgerufen!


    Beim 6809 Forth ist es Pseudocode.

    Der Aufruf eines Wort braucht daher nur 2 Byte.

    Ist aber deutlich langsamer.


    Manche Dinge sind aber wieder eine Art Pseudocode direkt nach dem JSR.

    Genau so wie er Strings beim CUBIX direkt nach dem SWI Befehl ablegt.


    Raffiniert gemacht.



    Der BASIC Interpreter ist mehr eine Notlösung.

    Es funktioniert zum Beispiel PRINT "HELLO WORLD" aber PRINT "HELLO WORLD! "; geht nicht.

    Es hat auch Probleme mit Kleinbuchstaben in Strings??


    Kann es sein, dass diese CUBIX Maschinen nur Großbuchstaben kannten?

    Das CUBIX habe ich etwas verbessert, damit es mit der MMU und dem Banking umgehen kann.

    Da alle Systemaufrufe mit SWI gemacht werden, ist das keine große Sache.


    CUBIX läuft nun in der MAP des Task#0 und die User Programme laufen auf Task#2.

    Damit befinden sich nun alle Programme in einem geschützten Bereich.

    Das CUBIX und die System RAM Bereiche sind nun geschützt vor dem Zugriff durch Programme.


    Leider können die Programme aber trotzdem nicht den gesamten Speicher frei benutzen.

    Die Programme sehen zwar nun 64K freien RAM, aber leider nicht das CUBIX.

    Das CUBIX kann nicht so einfach den Speicher ab $D000 des Task#2 zugreifen.

    Dazu müsste man sehr umfangreiche Änderungen im CUBIX machen ... :(


    Die Freude ist leider etwas getrübt.


    ====


    Aber dafür läuft jetzt FLEX.

    Zumindest im Emulator.


    Auf der Hardware muss noch was getan werden.

    Der Arduino muss neue Befehle lernen.

    Damit man die Größe der Sektoren umschalten kann zwischen 512 Byte (CUBIX) und 256 Byte (FLEX, NITROS, OS9).

    Dann sollte es auch auf dem SBC Board laufen.


    Leider setzt FLEX auf eine Sprungtabelle und die Programme nutzen auch den direkten Zugriff auf OS Variable im RAM.

    Damit ist es völlig untauglich für den Betrieb mit mehr als 64K.


    Aber es gibt extrem viel Programme für Flex.

    Das ist schon mal richtig cool.