Ein paar Informationen zu OS-9

  • Das Widerstandsnetzwerk ist ja interessant. Da möchtest Du zwei Pins abknipsen?

    Ja genau.

    Oder umbiegen

    Von dem 6 poligen hab ich 50 Stück gekauft, und es ging auch anders nicht so gut.




    Sind die Abblockkindensatoren auf der Bestückungsseite? Falls ja, stört das nicht unter den PLCC-Sockeln?

    Bei der letzten Platine habe ich mir Kondensatoren beschädigt, die auf der Unterseite waren.

    Darum mache ich sie, wenn möglich, unter den Sockel rein.


    Meine PLCC Sockel haben in der Mitte eine Aussparung, das geht sich gut aus.

    Mal davon abgesehen "schweben" die Sockel, da sind so kleine Nippel, dass sie nicht ganz aufliegen, warum auch immer.


    Aber es wird natürlich verschieden Sockel geben ...



    Die beiden zweipoligen pin-header für +5V und GND könntest du noch beschriften, das erspart späteres Rätsel-raten.

    Sehr gute Idee, werde ich machen.


    Wobei, da liegen di IO Board auf.

    Ist mehr eine Sache der Stabilität, damit die Platine satt aufsitzt.

    Alle IO Platinen haben die 4 Stiftleisten.


    Ich weiß, man könnte auch Kunststoff Schrauben oder Abstandhalter verwenden.

    Aber ich hatte diesen Einfall bei der ersten IO Platine, und jetzt muss ich kompatibel bleiben.


    Das SBC Board braucht das alles nicht mehr, da ist dann alles auf einem Board, außer die RAM Erweiterung.



    Was ist das für ein Pin Header auf der rechten Seite, der an ein Widerstandsnetzwerk erinnert? Ich konnte da keine Anschlüsse erkennen.

    Das sind Stiftleisten nach unten zum Mainboard der ByteMachine.

    Auch nur zur mechanischen Stabilität.

    Die kurzen CPU Platinen brauchen das nicht, aber die großen sind sonst ziemlich wackelig.


    Das SBC Board braucht das alles nicht mehr, da ist dann alles auf einem Board, außer die RAM Erweiterung.



    Ansonsten bin ich schon sehr gespannt und freue mich auf neue Updates!

    Ich bin auch schon sehr gespannt, ob das Ding so stabil läuft wie die 6829 MMU.


    Die CPU Platine mit der 6829 MMU läuft jetzt seit einigen Wochen durch, 7 Tage 24 Stunden.

    Das Ding Ding ist wirklich extrem stabil.

  • Mit diesem Board kann man den ATF1504-84 und ATF1508-84 beschreiben.

    Es eignet sich auch gut für eigene CPLD Projekte.


    Das Layout ist zwar ungetestet, aber es ist sehr einfach, da wird es keine Fehler geben, daher lege ich die Gerber Files gleich dazu.



    .

  • Meine PLCC Sockel haben in der Mitte eine Aussparung, das geht sich gut aus.

    Mal davon abgesehen "schweben" die Sockel, da sind so kleine Nippel, dass sie nicht ganz aufliegen, warum auch immer.


    So sehen die beiden PLCC-84 Sockel aus, die mir zur Verfügung stehen:


  • Ich bereue inzwischen sehr, meine letzten Projekte auf dem EPM7128 in PLCC basiert zu haben. Neu vom seriösen Händler werden diese Chips mittlerweile mit Gold aufgewogen, preiswert vom China-Mann sind ein wirklich sehr großer Teil entweder direkt kaputt oder fake und der verbleibende, erst einmal benutzbare Teil zeigt hier eine unterirdische Haltbarkeit bzw. Zuverlässigkeit. Oder anders gesagt: die Dinger sterben hier wie die Fliegen.


    Hast du mal probiert die "defekten" CPLD mit einer Programmierspannung zu beschreiben?




    Also ich habe 20 ATF1504-84 und 10 ATF1508-84 geordert.


    Von Haus aus ist nur ein einziger 1504-84 gelaufen.

    Mit Programmierspannung am VPP laufen die dann aber tadellos (danach auch ohne VPP).


    Es laufen nun alle 30 CPLD tadellos, kein einziger Ausfall trotz Billig Heimer Bestellung.



    Einfach 12V über einen 2,2K Ohm Widerstand auf PIN 84 (OE1) legen.

    Der Trick funktioniert auch bei den EPM7128, auch am selben PIN.


    Bei den 44 poligen ist es der PIN 44.

  • Danke für den Tipp! Mit den "dead on arrival" habe ich das noch nicht probiert, da könnte sich das aber durchaus lohnen. Für die vielen Chips aber, die erst bei mir aufgegeben haben, rechne ich mir da eher wenig Chancen aus.

  • Danke für den Tipp! Mit den "dead on arrival" habe ich das noch nicht probiert, da könnte sich das aber durchaus lohnen. Für die vielen Chips aber, die erst bei mir aufgegeben haben, rechne ich mir da eher wenig Chancen aus.

    Ich verstehe das nicht.


    Mir ist noch keine einziger ATF kaputt gegangen.

    Obwohl ich zahlreiche Fehler machte die der CPLD hätte übel nehmen können. :)



    Ich hab den Vorgang hier dokumentiert:

    ATF150x –

  • Kurzer Zwischenbericht ...


    Das Board läuft, in einer abgemagerten Bestückung, nur ein MRAM! :)

    Das Testproggi läuft seit 24 Stunden durch, fehlerfrei!



    Ehrlich gesagt, habe ich kurz mal gedacht, ich krieg es nicht zum laufen ...

    Und ohne LA hätte ich es nicht fehlerfrei bekommen.

    Und ohne der Hilfe einiger hilfsbereiter Forums Kollegen auch nicht - DANKE!!!


    Aber jetzt sind die Signale sauber und zum absolut richtigen Zeitpunkt.



    Die "light" Version läuft mit nur einem MRAM, hat also nur 19 physische Adressleitungen (512K).

    Den CPLD habe ich extra auf die Light Version angepasst, das Testprogramm ist aber dasselbe.


    Heute Abend werde ich mal den zweiten MRAM in Betrieb nehmen, damit hat es dann einen Speicherraum von 16MB.

    Da ich nun weiß, wie man den MRAM richtig benutzt, sehe ich keine Probleme.

    Das System wird auch mit dem zweiten MRAM laufen!



    Die Prototypen sehen inzwischen aus wie Igel.

    Weil ich sehr viele Messpunkte anlöten musste ... :D





  • Ich bin vor ein paar Tagen auf ein Projekt namens 'UniFlex' gestoßen. Dort kommt auch ein 6309 zum Einsatz und die Hardware besitzt ebenfalls bezüglich MMU und Betriebssicherheit einige sehr bemerkenswerte Eigenschaften.

    In der Tat ist UniFlex wirklich sehr beeindruckend.


    Das FLEX wurde von TSC entwickelt.

    Es hatte eine große Anhängerschaft.

    Und es gibt sehr viel Software und Utilities für FLEX.

    Auch viele Compiler und Interpreter.


    TSC hat dann UniFlex entwickelt.

    Es hat aber mit FLEX nichts mehr zu tun.

    Leider hat es dann schließlich zum Untergang von TSC geführt.

    Es war einfach die Ära der 8 Bitter vorbei, die 16 Bitter waren schon im kommen.


    Die Entwicklung von UniFlex kam um Jahre zu spät, es konnte sich kaum noch verbreiten.

    Für einfache Maschinen hat man FLEX verwendet, noch jahrelang.

    Für komplexe Dinge hatte man ja schon OS9 und dann zunehmend die 16 Bitter.



    Schade, denn FLEX hatte eine große Community.

    Etwas früher hätte UniFlex denselben Erfolg einfahren können.



    Interessant ist auch, es gibt ein angepasstes FLEX das als Task von UniFlex läuft.

    Das heißt, die FLEX device driver rufen einfach die korrespondierende Funktion im UniFlex auf.

    Dadurch konnte man seine FLEX Software ohne Änderung einfach im UniFlex betreiben.


    Kompatibilität war damals schon ein Thema.

  • Mal eine Frage in die OS-9-Runde. Hat hier jemand eine OS-9 Version mit Software usw. für die Atari ST Serie? Das gab es, aber hab noch nirgends Diskimages oder so gefunden? Fehlt mir daher noch in meiner Sammlung.

    Atari OS9 Image – Google Drive

  • Nach langem Kampf ist nun ein Teil Erfolg gelungen! :)



    Neben FLEX und CUBIX läuft nun endlich auch NitrOS9 Level 1auf meinem SBC-09 Board:





    Die Tests sind alle erfolgreich, das Ding läuft wie ein Uhrwerk.


    Hab ich schon erwähnt, wie toll ich OS9 finde? :D


    Es ist einfach SENSATIONELL!!!


    ====


    Und nun geht's weiter mit dem eigentlichen Ziel: NitrOS9 Level2

  • NitrOS9 Level 1 läuft absolut stabil und flink.

    Es startet von SD Karte in unter einer Sekunde, schneller als ein PET oder C64.



    Beim Start hatte ich nur zwei Floppy Laufwerke a 720K.

    Die Floppy Laufwerke werden emuliert durch einen Arduino Nano an dem eine SD Karte angeschlossen ist.

    Auf der SD Karte gibt es pro Laufwerk eine Image Datei, kompatibel mit dem DSK Format.

    Der Output vom NitrOS9 Compiler Lauf ist ein DSK und kann direkt verwendet werden.


    Das Nano-IO Board emuliert mehrere Laufwerke über Image Dateien.

    Aus der Image Datei erkennt der Nano die Laufwerks Geometrie.

    Im OS9 Modus reagiert der Nano nun auch auf Schreibzugriffe auf Sektor 0 (LSN-0).

    Damit kann die Laufwerks Geometrie nun dynamisch verändert werden.

    Das bedeutet, man kann unter OS9 mit DMODE die Geometrie vorgeben und mit FORMAT die Image Datei erstellen, vom SBC aus.



    Das Nano-IO Board emuliert natürlich auch Festplatten.

    Dazu wird derselbe Treiber (sbc09sd.dr) verwendet.

    Man benötigt einfach einen eigenen Device Descriptor.


    WICHTIG: Für Festplatten muss im DD im Feld INFO das Bit 7 gesetzt sein, sonst funktioniert der FORMAT Befehl nicht optimal!!!


    Um die Cluster Größe auf 1 zu halten, darf die Festplatte maximal 128 MB haben.

    Für einen NitrOS9 Rechner ist aber 128 MB mehr als genug.


    Für NitrOS9 gibt es den SuperDriver:

    SuperDriver - NitrOS-9


    Der SuperDriver ermöglich den optimalen Zugriff auf "modernere" Massenspeicher: IDE, SCSI, CD-ROM ...

    Der Treiber erlaubt fremde Blockgrößen (512, 1024, 2048 Byte).

    Es werden Datenträger bis 4 GB native unterstützt, größere nur über Partitionen.


    Device Driver werden geschrieben für den SuperDriver oder für das Native OS9.

    Für das Nano-IO Board gibt es zur Zeit nur den native Driver.

    Der SuperDriver ist wirklich genial, aber für den SBC09 sehe ich keine Notwendigkeit für Festplatten größer 128 MB .



    Was ich beim OS9 wirklich vermisse sind Joker in Dateinamen (*, ?).

    Abhilfe schafft "ShellPlus", damit bekommt man Wildcard Support und eine Command History wie unter Linux.

    Es kostet jedoch einige KB an RAM.

    Was bei Level 2 dann wieder vollkommen egal ist.



    Einer echter Hit ist das BASIC-09!


    Es ist interaktiv und es kompiliert.

    Da gibt es benannte Funktionen und Prozeduren.

    Das BASIC ist strukturiert, und es ist wirklich sehr schnell.

    Die Bedienung ist sehr gewöhnungsbedürftig, wenn man vom MS Basic kommt.



    C-Compiler


    Nun ja, es funktioniert.

    Ohne Festplatte macht es aber keinen Spaß.

    Das C ist etwas veraltet, aber das Binary sieht wirklich sehr gut aus.



    Das Pascal erzeugt P-Code und läuft relativ flink, aber Pascal ist nicht so meins.

  • OS9 ist soooo genial!

    Man kann Driver Code im Betrieb entwickeln, laden und testen.


    Der neue Driver hat eine höhere Revision Nummer. Sobald man den Code lädt, verwendet OS9 den neuen Code mit der höheren Revision Nummer, der alte Code bleibt geladen. Wenn es Probleme gibt, kann man den Code einfach wieder entladen und der alte, funktionierende Driver, der ja noch im Speicher ist, läuft wieder.


    Schon klar, moderne OS wie Linux können das auch. Aber OS9 lief schon 1979!!!

    1979!!!

  • Es läuft auch heute noch... Inzwischen auf über 20000 Medizingeräten...

  • Es läuft auch heute noch... Inzwischen auf über 20000 Medizingeräten...

    Heute auch noch!


    Dass man das noch nicht auf was neueres portiert hat, verwunderlich ...

    Ist die Zulassung neuer Hardware in dem Bereich so schwierig?




    Driver dynamisch laden und entladen ist eines.

    Hardware im Betrieb anschließen und entfernen (Hot Plugging) ganz was anderes.

    Bei USB ist uns das heute selbstverständlich.

    Aber ich weiß auch noch von Steckkarten die man im Betrieb rein stecken konnte.


    Worauf muss man da achten?

    Kontakte für Stromversorgung länger machen, damit die zuerst Kontakt haben?

    Irgendwas an der Bauteil Selektion, dass die nicht versehentlich den Bus blockiert?

  • Also - ich bin mir relativ sicher, daß man, wenn man bei Linux einen Gerätetreiber "über" einen anderen lädt und möglichst auch vorher die Geräte nicht abmeldet ... dann gibt es entweder Datenschrott oder ein geblocktes System.

    Sowas funktioniert noch nichtmal wirklich gut, wenn man den Treiber entlädt und dann wieder neu holt (modprobe). Dafür kann möglicherweise das Linux nichts (der Kern'a'l) sondern der Absturz liegt dann weiter oben, aber das ändert am Problem nichts.


    RISC OS kann das im Übrigen auch - das Wegreißen von Modulen und ersetzen durch andere. Aber nicht so schick wie Du (Diddl) es beschreibst. Da wird einfach das neue Modul über das alte geladen, was dann "weg" ist. Dabei kann man auch eine aktuellere Version durch eine ältere ersetzen, was man manchmal auch durchaus gut finden kann. Die Versionsabfrage - also nur Neuse darf Altes ersetzen - macht man dann üblicherweise mit Kommandozeilen"tools" (RMEnsure).


    Aber: auch da gab es das in der Form schon zeitig und man hat nie verstanden, wieso das auf anderen Geräten nicht genauso gemacht wird. Das Modulkonzept hat schon das erste RISC OS. Und die haben ziemlich sicher auch ein bißchen über OS-9 Bescheid gewußt, immerhin gab es ja diese Zusatz-CPUs für die BBC Micro Rechner und außerdem war das ja schließlich eine in Cambridge an die Universität angebundene Firma - nicht formal aber bestimmt informell, soll heißen, die waren bestimmt "auf dem Laufenden".


    Was es aber irgendwie niemals so richtig gab, war dieser Modulansatz mit einer gescheiten "Verwaltung", wo also das Modul Version und Datum kannte und man das Beides vorgeben kann. Oder nur eines. Oder ein Minimum bzw. Maximum der Versionsnummer. Ich vermute mal, daß es auch bei OS-9 nicht soweit geht, dafür müßte man dann ja auch einen Modul-/Treiberbibliothek pflegen und/oder mitliefern, was in den meisten Fällen auch nicht viel Sinn macht und das nur komplizierter als nötig.


    Guck Dir mal den TAOS Ansatz zur Routinen Ladung/Entladung an. Dort ist das noch eine Ebene tiefer und außerdem prozessorspezifisch machbar. Könnte Dir gefallen. (War mal als Amiga Nachfolger im Gespräch und es gab sogar eine demonstrierbare Software dazu - nur die Amig Jünger haben das irgendwie nicht geblickt oder nicht haben wollen; es lief auch erstmal nicht auf klassischer Hardware, hatte aber jedes Potenzial da schnell hinzukommen.)

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • OS9 Level 2


    Neben zahlreicher kleiner Verbesserungen gibt es folgende Neuerungen gegenüber L1:

    • Speichergröße mehr als 64K
    • Jeder Task kann bis zu 64K für sich alleine haben
    • Trennung von System und Usermode (Schutz)
    • Unterstützung einer MMU


    Um einige oder alle Neuerungen auch wirklich nutzen zu können benötigt man eine MMU.

    Aber nicht jede MMU unterstützt alle Neuerungen.



    Die MMU im Tandy CoCo-3 zum Beispiel ist extrem minimal ausgelegt:

    • Page Größe 8KB (statt der empfohlenen 2K)
    • nur 2 Tasks, wobei Task# 0 immer System ist
    • keine Trennung von System und Usermode
    • keine automatische Umschaltung in den Systemmode bei Taskwechsel


    Das ist bitter, der CoCo-3 profitiert daher nur von einer einzigen Neuerung im Level 2:

    • Die Speichergrenze von 64K wurde durchbrochen

    Leider stehen für den Usertask nicht die ganzen 64K zur Verfügung im CoCo-3.

    Die obersten 512 Byte sind über alle Tasks gleich.

    Das ist notwendig, weil der IRQ und der SWI Befehl keine automatische Umschaltung zum System Task macht.

    In den obersten 512 Bytes stehen die Vektoren und der Code für die Task Umschaltung.


    Es gibt auch keine Schutzfunktion, weder des Systemtask noch Speicherzugriffe außerhalb der eigenen Map.

    Jeder Usertask kann das System abschießen und andere Tasks beeinflussen.

    Auch die IO sind für jeden Task sichtbar und zugreifbar.

  • Die Implementierung der MMU im OS9 Level 2 ist eine katastrophale Bastelei.


    Der Code wird direkt im Kernal Sourcecode gepatched.

    Keine Auslagerung in ein Modul oder Treiber.

    Nicht mal eine Auslagerung in Include Dateien.

    Die haben wohl für jede unterschiedliche Hardware einen eigenen Kernal entwickelt!


    Im NitrOS9 gibt es eigentlich nur noch zwei Ziel Plattformen:

    • Tandy CoCo-3
    • MC09

    Beide Plattformen eignen sich leider nicht gut als Basis für meine SBC-MMU Hardware.



    Aber es gibt ein wunderschöne, uralte Hardware, die fast ident ist zu meiner SBC-MMU Hardware.

    Und es gibt eine OS9 Implementierung für diese Plattform ...


    Der Positron 9000 ist eine sensationelle Maschine!

    Das Ding ist einfach unglaublich!




    Nun habe ich mich mit dem Positron 9000 Kernal intensiv auseinander gesetzt.

    Das hat meine verklärte Sicht auf die Motorola MMU 6829 etwas erschüttert.


    Die schöne Welt, die im "OS9 L2 System Designer Guide" beschrieben wird, die hat auch Schattenseiten:

    Die MMU 6829 bietet "System Schutz" und echte 64K für jeden Task (protected Mode).

    Dafür zahlt man jedoch einen sehr hohen Preis!!



    Jeder Usertask hat seine eigenen 64K vollständig zur Verfügung.

    Der Code läuft in einer Sandbox die absolut sicher ist.

    Etwas das sonst nur viel neuere Systeme bieten können.


    Das funktioniert deswegen, weil die MMU 6829 erkennt, dass die CPU einen Interrupt oder SWI Befehl ausführt.

    Die MMU wartet, bis die CPU alle Register Werte auf den Stack gelegt hat.

    Genau zu diesem Zeitpunkt schaltet die MMU in die System Map und aktiviert den Superuser Modus.

    Die CPU fetched nun den entsprechenden System Vektor (in der System MAP!!) und springt zu dem System Code.


    Soweit so gut, klingt alles wunderschön.

    Doch nun fangen die Probleme an.

    Leider wollte man OS9 L2 binär kompatibel mit L1 machen, damit alte Programme einfach so laufen können.

    OS9 System Funktionen ruft man mit einem SWI Befehl auf.

    Dem SWI Befehl folgt der Funktionscode.


    Für L1 ist das keine große Sache.

    Die Systemfunktion holt sich den PC (program counter) und liest das Byte nach dem SWI Befehl (Funktionscode).

    Dann die der PC am Stack inkrementiert, damit nach der Rückkehr aus der Systemfunktion der folgende Befehl ausgeführt wird.

    Der Funktionscode wird als "übersprungen".


    Für L2 ist das selbe eine Schwerarbeit:

    • um den Inhalt des PC vor dem Aufruf zu kriegen, muss man den User Stack zugreifen
    • der Userstack liegt in der User Map, und man weiß ja nur die logische Stack Adresse in der User Map
    • also logische Adresse in der User Map umrechnen in Page Nummer und Page Adresse
    • die Page temporär in der System Map einblenden und den Wert des PC auslesen
    • der PC Wert um eins inkrementieren
    • nun ist auch der Wert des PC nur eine logische Adresse ...
    • also logische Adresse in der User Map umrechnen in Page Nummer und Page Adresse
    • die Page temporär in der System Map einblenden und den Wert des PC auslesen (Funktionscode)


    Alles in allem recht komplexer Code, einige hundert Befehle ...

    Die erzwungene L2 Kompatibilität ist sehr, sehr teuer!



    Im Falle eines Interrupt ist der L2 Mehraufwand nicht so schlimm.

    Aber natürlich sind praktisch alle Adressen 24 Bit lang statt nur 16 Bit.

    Und man muss ggf. eine Page einblenden um Modulcode ausführen zu können.


    Zugriffe in User Buffer Bereiche sind auch viel komplexer.

    Es müssen immer entsprechende Mappings gemacht werden und die neuen Offset Adressen errechnet werden.




    Fazit:


    Die Kosten für die Sprengung der 64K Begrenzung sind hoch.

    L2 läuft definitiv um einiges langsamer als L1.


    Aber es ist die Sache schon wert.

    Speziell dann, wenn man Multi User Betrieb anbietet wie die Positron 9000 Maschine.


    Die Stabilität ist halt dadurch wirklich extrem gut.

    Keine Seiteneffekte durch andere Software.

    Kaum noch Begrenzungen durch Speicher und andere Ressourcen.

  • Ein schöner Thread!


    Ich habe OS-9 auf dem Color Computer kennengelernt und dort Basic, C und Assembler programmiert.

    Nachher auf dem Atari ST und Mega STE programiert und ein bisschen Datenbank gemacht.


    Daneben auf diversen VME-Systemen geschafft und Anwendungen und Systemerweiterungen gemacht.

    XSCF => Ersatz für den SCF mit Erweiterungen

    SystemFileManager=> So eine Art /proc für OS-9


    Es ist schön in den Erinnerungen zu schwelgen!