Ein paar Informationen zu OS-9

  • Also Instruction-Fetch-Detection funktioniert wohl nur bei der -EP CPU.

    Und OS9 unterstützt das wohl erst ab Level 3?


    Mal sehen ob das beim NitrOS9 überhaupt geht?

    Na egal, die MMU Hardware unterstützt das auf jeden Fall mal. :)


    Die SRAM müssen schnell sein, 10nS ist optimal.

    Es funktionieren SRAM mit 8K, 16K und 32K.

    Allerdings werden immer nur 2x 8K genutzt.

    Aber die 32K sind am leichtesten zu kriegen, und am günstigsten.


    Leider braucht es immer zwei Bausteine, auch bei 16K und 32K.



    Also Motorola war der Welt wohl um einige Jahre voraus ...



  • Sicher gehen die auch, der CPU-Takt muß dann nur niedriger gewählt werden, damit die RAM's nicht überfahren werden. Beim 6809 NitOS9 CocoDEV-Rechner von Coco-Daddy kommt ein 512k 10ns SRAM zum Einsatz, was wiederum 25MHz CPU-Takt ermöglicht. Sind die SRAM's langsamer, wie Deine 20ns Typen, liegt der max. mögliche Takt vielleicht bei 16MHz. Aber selbst das bedeutet immer noch ein beachtlich schnelles System - also kein Grund zur Sorge. Man sollte nur nicht unbedingt mischen, denn der langsamste bestimmt den 'Takt'.

  • Ich habe welche mit 15 und welche mit 20 ns Zugriffszeit hier. Würden die auch noch gehen?

    Die 15 sind rechnerisch schon extrem knapp bei 3MHz, könnten aber noch sauber laufen.

    Bei den 20er würde ich auf 2 MHz gehen.


    Aber die 10nS sind gut erhältlich.



    Zu Level 3 konnte ich auf die Schnelle gar nichts finden. Wo ist denn der Unterschied zwischen Level 2 und Level 3?

    So ganz genau wiess ich das auch nicht.

    Hab mich noch zu wenig beschäftigt mit dem originalen OS9.

    Aber es hat sich da anscheinend schon einiges verbessert beim Multitasking, Schutzmöglichkeiten und File Handling, größere Disks und mehr RAM.



    Beim 6809 NitOS9 CocoDEV-Rechner von Coco-Daddy kommt ein 512k 10ns SRAM zum Einsatz, was wiederum 25MHz CPU-Takt ermöglicht.

    Naja es geht ja nicht um den RAM für das System selbst.

    Was ich meine ist der MMU RAM.

    Jeder Adresszugriff auf den physischen Speicher von 16MB muss da durch dieses MMU RAM.

    Hinzu kommt noch Latenz durch Adress Decoder und dem CPLD.

  • Woher hast du denn deine bezogen?

    Ich hab meine von da:

    https://de.aliexpress.com/item/1000006262411.html


    Mit 1,80 nicht gerade billig, aber die sehen aus wie neu.

    Und die funktionieren, alle 20.

  • Und womit programmierst du den CPLD?

    Oder meinst du die Software?

    Da verwende ich nach wie vor WinCUPL, wie schon seinerzeit bei der FE3.



    Ich weiß, die meisten lassen kein gutes Haar an WinCUPL.

    Aber es entspricht nicht meiner Erfahrung.

    Für mich funktioniert es.


    WinCUPL ist winzig klein und blitzschnell.

    Es hat kleine Tücken die man aber umschiffen kann.


    Ich hab mir auch das Altera Tool installiert.

    Riesig groß, braucht ewig zum installieren.

    Nach dem Start der Software ist man erschlagen von zehn tausend Features.


    Klar es kann Verilog, aber der Code in Verilog ist eher komplexer und schwieriger für mich.

  • Das gesagte gilt für das RAM der MMU genauso, Die zu bevorzugende Richtung ist natürlich so schnell wie möglich.

    Ja klar, du hast schon recht.



    Ich wollte damit nur sagen, der Mapping RAM ist extrem sensibel.

    Der Systemtakt von 3MHz ist ja ein klacks, da genügen relativ langsame Speicher Chips (250nS).


    Aber der Mapping RAM ist ja dazwischen geschaltet, als Umsetzung von logischer zu physikalischer Adresse.

    Daher verzögert der Mapping RAM ja quasi ALLES, auch die Adressen Dekodierung und alle Gatter die beteiligt sind.

    Und das bei jedem Zugriff (read, write, fetch, DMA, IO).


    Dazu kommen die Multiplexer, weil der Mapping RAM selbst ja auch "gemapped" werden muss, damit man ihn beschreiben kann.

  • Zu Level 3 konnte ich auf die Schnelle gar nichts finden. Wo ist denn der Unterschied zwischen Level 2 und Level 3?

    Zu OS9 findet man tatsächlich wenig Doku heutzutage.


    Zu OS9 Level3 gibt es nur vereinzelte Hinweise, speziell bei den Diskussionen um die MMU.

    Wahrscheinlich war Level 3 nur was für Highend Maschinen, kommerziell und wenig verbreitet.




    Es gibt tatsächlich ein NitrOS9 Level 3:

    https://github.com/n6il/nitros9/tree/master/level3


    Allerdings dürfte das leider wenig zu tun haben mit OS9 Level 3.

    Es läuft nur auf dem CoCo3 und ist eigentlich nur im Detail verbessert.

    Und es ist extrem pingelig bei der Boot Konfig.

    Es läuft nur genau so, wenn man irgendwo was ändert dann fährt es gar nicht mehr hoch.


    Ich finde im NitrOS9 auch nichts über Access Flags und dergleichen, das scheint nie implementiert worden zu sein.

    Vielleicht kann man das nachrüsten, vielleicht ist es aber eh sinnlos.


    Die MMU-16 Hardware kann es jetzt jedenfalls, falls es mal jemand probieren will.


    Die MMU-16 Doku entsteht hier so nach und nach:

    https://oe7twj.at/index.php?title=MMU

  • Ich bin etwas frustriert.


    Die MMU-16 tut genau das was sie tun soll.

    Aber es läuft leider nicht stabil am Steckboard.


    Es läuft nie länger als 30 Minuten.

    Manchmal auch nur wenige Minuten.


    Die Signale sind okay und es wird nichts warm.

    Sehr seltsam.

    Sind ja nur 3 MHz.


    Bei 2 MHz geht's so halbwegs.

    Aber selbst da ist es nicht wirklich super stabil.



    Ob es am Steckboard liegt?

    Ob es wohl läuft wenn ich eine Platine mache?

    Oder ist da generell was falsch konzipiert?


    +++


    Vielleicht baue ich mal das MMU 6809 am Steckboard auf?


    Oder mach einfach mal eine Platine?


    :(

  • Du kennst den Fingertrick vom BBC Micro ? Mal den Steve Furber bei YT suchen. Die hatten so ein ähnliches Problem - wenn sie den Finger auf einem Chip dem Board liegen hatten, wars stabil. Am Ende haben sie eine Widerstandsreihe eingelötet um den Finger auf dem Chip dem Board zu simulieren. Vielleicht ist ja hier was Ähnliches.



    edit: https://www.youtube.com/watch?v=y4WG549i3YY&t=574s

  • Kannst du die Flankensteilheit des CPLD konfigurieren? Ich meine mich dunkel zu erinnern, dass man bei Altera die Ausgänge "slow" konfigurieren konnte. Vielleicht hast du ja mit Signalreflexionen zu kämpfen, die bei den eher längeren Leitungen auf einem Steckbrett zum tragen kommen. Bei einer Platine mit kurzen Leitungen sollte es dann gehen. Auch das RAM ist ja super schnell. Also ich würde es einfach mit einer Platine versuchen, das kann nur besser und stabiler werden!

  • Ah, flankensteilheit konfigurieren...

    Guter Tipp!



    Ja ich denke auch, einfach mal eine Platine machen.


    Diese Steckboards haben auch oft schlechten Kontakt und andere komische Sachen.


    Ich bewundere die Menschen, die auf Steckboards komplette Systeme aufbauen!!

  • Wenn Du die MMU auf einem Experimentierboard aufbaus, zuerst die VCC und GND Leitungen verlegen. Die 100nF Stütz-C's an den VCC-Pins gegen Masse für jedes IC nicht vergessen (absolut wihtig). Die Versorgung muß frei von Störungen sein, also keine Peaks oder Einbrüche, ansonsten kannst Du jeden Schaltungsaufbau wegen nicht nachvolziehbarer Fehlfunktionen vergessen. Falls Du mit dem Tastkopf ran gehst und bei den Flanken klingeln bzw. große Über-/Unterschwinger mißt, der Masseklipp am Tastkopf ist eine Induktivität undbekannt dafür, das Messsignal in dieser Form zu verfälschen. Sehr gute Messergebnisse erhälst Du, wenn die Signalmasse zum Messen per kurzen Draht vom Massering an der Tastkopfspitze abgenommen wird (die Signalmasse möglichst immer am Ort des zu messenden Signal abnehmen ! Auf dem Steckbrett besonders wichtig). Das ist etwas frickelig, vermeidet aber besagte Probleme. Sollten bestimmte Signal wegen langer Signalleitung auf der Platine dennoch Probleme machen, kann auch ein Widerstand (27R...47R) direkt am Signal-Ausgang in Serie zur Leitung als Dämpfung der Leitungsinduktivität/kapazität Wunder wirken. Derartige Dämpfungswiderstände helfen auch, solltest Du die MMU-Platine auf's Steckbrett stecken, um den erweiterten Rechneraufbau zu testen. Die Steckbretter haben leider eine relativ hohe Kontaktinduktivität gepaart mit ~5pF Schaltkapazität (meine Erfahrung). Das macht die Bretter nicht unbrauchbar, man muß es nur berücksichtigen, dann geht es meistens.

  • Leitungen gekürzt, die Kondensatoren an der Stromversorgung der IC's vergrößert und anders platziert ...


    Es läuft schon recht gut.


    Sollten bestimmte Signal wegen langer Signalleitung auf der Platine dennoch Probleme machen, kann auch ein Widerstand (27R...47R) direkt am Signal-Ausgang in Serie zur Leitung als Dämpfung der Leitungsinduktivität/kapazität Wunder wirken.

    Cooler Tipp!

    Seither läuft es wie ein Uhrwerk. :)


    Auf sowas wäre ich niemals gekommen.

    Aber auf der Platine versuche ich es mal ohne das. :D



    Die Adressen MUX für das Mapping RAM und der Adressen Selektor GAL sind jetzt auch im CPLD.

    Leider komme ich mit den 84 PIN am ATF1504-84 nicht aus.

    Deshalb habe ich es nun auf zwei ATF 1504 aufgeteilt.

    Mit dem größeren ATF mit 100 PINs würde es vermutlich gehen, aber die gibt es nicht als PLCC, nur als TQFP.


    Es sind also nun 4 IC für die MMU-16:


  • Mit dem größeren ATF mit 100 PINs würde es vermutlich gehen, aber die gibt es nicht als PLCC, nur als TQFP.

    Vielleicht kann man sich den bei JLCPCB o.ä. direkt für kleines Geld bestücken lassen, dann fiele das nicht sonderlich ins Gewicht. Nur einen CPLD beharken dürfte jedenfalls deutlich einfacher sein.

  • Vielleicht kann man sich den bei JLCPCB o.ä. direkt für kleines Geld bestücken lassen, dann fiele das nicht sonderlich ins Gewicht. Nur einen CPLD beharken dürfte jedenfalls deutlich einfacher sein.

    Da wirst du sicher recht haben.


    Aber ich habe beide ATF hier, den -84 und den -44.

    Ich baue die erste Platine mal so auf.


    Es ist ganz easy die beiden CPLD Sourcen zusammen zu führen von zwei auf einen CPLD.

    Das werde ich in im nächsten Schritt machen, wenn es jemand mit dem 100 poligen TQFP Gehäuse bauen möchte.


    Alternativ kann man den 1504-44 auch ersetzen durch zwei GAL 22v10.

  • Hallo,


    ich bin neu hier in diesem Forum, ich befasse mich seit einigen Wochen mit dem Betriebssystem OS-9/68K, das bei mir auf einem Industrie-Rechner (B&R-MAESTRO) läuft.

    Bin momentan "verzweifelt" auf der Suche nach dem Ultra C-Compiler, speziell den Files: cpp, c68, o68, cc, r68 und l68.

    Es kann aber auch ein alternativer C-Compiler sein, der auf OS-9/68K läuft.

    Wichtig wäre mir, das ich aus einem C-Programm einen lauffähigen Code generieren kann nicht "nur" einen Assembler-Code (.a - File)

    Kann mir hier jemand weiterhelfen bzw. hat jemand diesen Compiler-Kit?

    Wäre sehr erfreut darüber :sunny:

  • Es kann aber auch ein alternativer C-Compiler sein, der auf OS-9/68K läuft.

    Der GCC kann 68K Code erzeugen.

    Die Makros für die OS Calls kann man sich ja einfach basteln.




    Wichtig wäre mir, das ich aus einem C-Programm einen lauffähigen Code generieren kann nicht "nur" einen Assembler-Code (.a - File)

    Ähm ...

    Das verstehe ich nicht.

    Assembler Source kann man ja einfach übersetzen.


    Den umgekehrten Wunsch würde ich verstehen, da viele Compiler ja leider keinen ASM Source mehr produzieren ...

  • ich bin neu hier in diesem Forum, ich befasse mich seit einigen Wochen mit dem Betriebssystem OS-9/68K, das bei mir auf einem Industrie-Rechner (B&R-MAESTRO) läuft.

    Wie wäre es mit einem eigenen Diskussionsthema dazu, damit dieses hier nicht zum Universal-OS-9-Thema wird? Wir haben seit geraumer Zeit immerhin eine ganze Rubrik :)


    Bin momentan "verzweifelt" auf der Suche nach dem Ultra C-Compiler, speziell den Files: cpp, c68, o68, cc, r68 und l68.

    Ich sag's der Vollständigkeit halber: OS-9/68k ist nicht ganz so frei, wie man sich erträumt. Außerdem reichen Dir die Software-Bestandteile der C-Umgebung nicht aus, denn Du benötigst auch die passenden Bibliotheken und Header-Texte.


    Es kann aber auch ein alternativer C-Compiler sein, der auf OS-9/68K läuft.

    Es gab den gcc wie auf vielen anderen Plattformen auch. Der ersetzt allerdings nur den Compiler und nicht Assembler, Linker oder Bibliotheken.


    Weiterhin ist von Bedeutung, welche Version vom OS-9/68k Du vor Dir hast.


    Wie an anderer Stelle erwähnt, tauchte vor geraumer Zeit eine OS-9-Umgebung auf Github auf. Das entspricht der OS9/68k-Version 3.0.3. Die C-Umgebung läuft auf allen 3er-Versionen, möglicherweise auch auf 2.4.


    Gruß, Ralf

  • Die Platine wird die komplizierteste Platine meiner kurzen Laufbahn als Layouter.

    Ich dachte schon fast, ich benötige 4 Layer.

    Aber es scheint nun doch auch so zu gehen ...



    Design Änderung:

    • CPLD 1 macht nun die Takterzeugung (Q und E aus dem Grundtakt)
    • CPLD 2 bekommt zusätzlich LA0 und LA1, weil sonst das Timing zu eng ist
    • CPLD 2 bekommt nur noch drei Signale vom CPLD 1: E, selMMUreg, selMRAM
    • der Mapping RAM bekommt nun zwei getrennte R/W Signale, sonst kommt es manchmal zu unerwünschte Schreibvorgänge
    • es funktionieren 2 mal 8K, 16K oder 32K am selben Board, auch gemischt
    • es funktionieren auch 15 Nano Sekunden RAMs, gerade so, von 10 Stück sind zwei zu langsam bei 3,5 MHz

  • Das Layout ist nun fast fertig.

    Die PINout im Jedec sind angepasst auf dieses Layout.


    Nur noch genau kontrollieren und testen, dann ab zum JLCPCB. :)


    Leider hat der JTAG nicht mehr drauf gepasst.

    Deshalb mach ich noch einen Programmieradapter für jene, die kein DK3 haben.


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


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


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


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


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