Ein paar Informationen zu OS-9

  • Was anderes, wo kann man denn superschnelles RAM bekommen?

    Wonach muss man da suchen?


    Für OS9 Level 2 und Level 3 ist eine richtige MMU empfohlen.

    Das Banking des CoCo-3 ist da nur eine Notlösung.

    Ich möchte auf einen Raster von 2K oder 4K runterkommen.


    Dazu benötige ich ein RAM mit 256 Bytes, das extrem schnell ist, so 20ns.

    Die Alternative wäre ein sehr großer CPLD, was ich vermeiden möchte.

  • Was anderes, wo kann man denn superschnelles RAM bekommen?

    Wonach muss man da suchen?

    Ich würde nach PC cache RAM suchen, das gibt es ab 8 ns (z.B. IDT71B74), und es sollte auch einigermaßen leicht aus Altbeständen zu beschaffen sein.

  • Aber es ist halt ... "etwas" überzogen.

    64K!!

    Naja, so lange das Gehäuse nicht riesig ist und die Chips einfach zu beschaffen sind, macht ein bisschen Überkapazität doch nichts aus? Der Standby-Stromverbrauch von statischem RAM fällt ja auch nicht sonderlich ins Gewicht.

  • 64 kBit = 8 kByte...

  • Auch wieder wahr. :)



    Es gibt da noch eine Alternative.

    Was heißt Alternative, das wäre eigentlich das Non-Plus-Ultra: eine Motorola MMU MC6829


    Leider ist das MC6829 wohl nicht zu bekommen außer bei Großhändler die mit mir sowieso nicht sprechen würden. :(



    Das MC6829 macht genau was das RAM macht aber noch viel viel besser!

    • Task Schutz (nur Task#0 kann die Register ändern)
    • autom. Umschaltung bei Interrupt zum Task#0
    • autom. Erkennung von RTI und Rückkehr zur Memory Map des User Task#!!!!!
    • kann bis zu 2MB Adressieren bei einer Auflösung auf 2K!!!
    • kaskadierbar auf bis zu 8 MMU (wer's braucht ... mir würde eine vollauf genügen)


    Genau DAS braucht mein OS9 System.

    Das löst alle meine Anforderungen.

  • Das neue Board wird unter NitrOS9 Level 2 laufen.


    Das bedeutet Platz ohne Ende:

    • Jeder Task kann die gesamten 64K voll RAM haben (kein einziges Byte verschwendet für ROM oder IO)
    • beim Aufruf einen OS9 Service oder eines Interrupts wird automatisch in den System Task#0 geschaltet
    • Jeder Task kann zusätzlichen RAM anfordern über einen Banking Bereich
    • man kann gemeinsame RAM Bereiche haben mit anderen Tasks
    • es braucht keinen IO und keinen ROM Bereich (das handelt das OS9)
    • der Speicher ist geschützt
    • das OS und die IO sind geschützt
    • es gibt 4 Tasks (Speicher Belegungen) - 0: System, 1: DMA, 2,3: User
    • man könnte es erweitern auf bis zu 32 Tasks, es lassen sich bis zu 8 MMU ganz einfach kaskadieren




    Der physikalische Adressraum hat eine Größe von 2MB und ist in 1024 "Pages" unterteilt.


    Der Adressraum der CPU hat natürlich nur 64K und ist in 32 Blöcken zu je 2K aufgeteilt.


    Jeder dieser 32 Blöcke kann auf jede Page verschoben werden.

    So erhält die CPU einen sehr flexiblen Zugriff auf den gesamten physikalischen Adressraum von 2MB.


    Die CPU sieht also 32 Speicher Blöcke, wo jeder dieser Blöcke irgendwo im physikalischen Adressraum liegen kann.

    Dazu braucht es 32 Zeiger mit 10 Bit Breite um diese Speicher Map zu beschreiben.

    Dieses Set aus 32 Zeiger wird als TASK bezeichnet.


    Eine MMU verwaltet 4 Tasks, also 4 x 32 Zeiger auf den physikalischen Adressraum.

    Man kann bis zu 8 MMU kaskadieren um bis zu 32 Tasks zu haben.


    Um von einer Speicher Map zu einer anderen zu schalten, muss man nur die Tasknummer in die MMU schreiben.

    So macht Multitasking richtig Spaß ...


    Die MMU kann aber noch mehr.

    Sie erkennt automatisch einen Reset, einen IRQ oder einen SWI Befehl.

    Und sie wechselt automatisch in den System Task.

    Die CPU legt noch brav die Register und Rücksprungadresse auf den Stack ...

    ... dann schaltet die MMU um auf Task#0 und die CPU fetched den Vektor für IRQ oder SWI.


    Dazu gibt es "priviligierten Code".

    Nur der Task#0 "sieht" die MMU Register.

    Daher kann kein User Task und auch nicht der DMA die Speicherkonfiguration verändern.

    Der Speicher ist perfekt geschützt.

    Ein User Programm kann das System nicht zerstören.

    Es läuft in seiner virtuellen Speicher Welt die das OS eingestellt hat und kommt nicht heraus.



    Das geht schon in die Richtung, die beim PC erst seit dem Intel 386 funktionieren.

    Der ist natürlich 16/32 Bit breit, und hat das ganze Paging voll integriert in der CPU.



  • Bei eBay wird derzeit ein Motorola SC67475P angeboten, der angeblich ein MC6829 sein soll. Ich konnte im Netz keinerlei Informationen zu diesem ominösen SC67475 finden. Kann das jemand bestätigen? Warum gab es dann zwei Typ-Bezeichnungen von ein- und demselben Hersteller?

  • Bei den späteren 68k-Baureihen war es üblich, daß Vorserienexemplare eine aufgedruckte Nummer hatten, die mit der späteren nicht viel Ähnlichkeit hat. Hier ist so eine Liste. Im weiteren Produktionsfortschritt nannte Motorola diese z.B. XC68030 ("Engineering Sample") und ab Serienreife MC68030. Zusätzlich wurde i.A. die Maskenrevision aufgedruckt. Man kann davon ausgehen, daß die frühen Versionen noch mehr oder weniger "nette" Fehler aufwiesen. Für die 68060-CPU haben das hier ein paar Amiga-Leute dargestellt.


    Ob Motorola so was Jahre vorher bei dieser 8bit-Baureihe auch schon so pflegte, weiß ich nicht. Möglich wäre es ...


    Ergänzung: hier gibt's ein Foto eines "Engineering Sample" eines XC6800. Dabei findet sich die Bemerkung, daß es PC68xx gab. An solche meine ich mich auch in der 68k-Welt zu erinnern. Das war die Vorstufe zum XC-Schritt.

  • Bei eBay wird derzeit ein Motorola SC67475P angeboten, der angeblich ein MC6829 sein soll. Ich konnte im Netz keinerlei Informationen zu diesem ominösen SC67475 finden. Kann das jemand bestätigen? Warum gab es dann zwei Typ-Bezeichnungen von ein- und demselben Hersteller?

    Ich hab mal drei von den finnischen MMU's geordert.


    Die Platine wird auch schon langsam ...

    In zwei drei Wochen kann ich dir sagen ob es funktioniert. :)

  • Ich habe mich entschlossen das OS9 Board auf zwei Platinen aufzuteilen.



    Das hat mehrere Vorteile:

    • es ist ganz modular
    • ich spare den großen CPLD zugunsten eines GAL
    • wer Arduino nicht mag, der kann statt dessen zwei IO Boards verwenden (UART, SD Card)
    • das Arduino IO Board kann ich auch für den W65C816 verwenden


    Das Ganze ist stapelbar.

    - RAM/ROM Board

    - OS9 MMU Board

    - IO Boards




    Aber wenn alles gut laufen sollte, dann mach ich wahrscheinlich noch einen OS9 Single Board Computer daraus.




  • It's Done!


    Die Layouts sind fertig.

    Eine Nacht darüber geschlafen.

    Fine Tuning gemacht und bestellt ...


    Der CPU Platine habe ich noch einen 74138 spendiert.


    Leider gibt die MMU nicht aus, wenn die MMU Register im Zugriff sind.

    Also musste ich den MMU Bereich von 1FFF00 bis 1FFF7F selbst aus kodieren.

    Sonst hätte ich die MMU Register nicht lesen können, weil da ja normalerweise ROM ist.


    Nun ja, dazu benötige ich alle Adress-Leitungen von A7 bis A20 ...

    Der GAL hätte dann nur noch zwei Leitungen für IO Select gehabt.

    Der 74138 hat nun den Vorteil, dass ich alle 8 IO Bereiche als Signal heraus führe.


    Alle 8 IO Bereiche benötigen jetzt nur 2K, damit kann man alle IO gleichzeitig als Fenster einblenden.

    Jedes der 8 IO Fenster hat 256 Bytes zur Verfügung (8 x 256 --> 2K).

    Das sollte genügen für jede erdenkliche Erweiterung.



    Das CPU Board:


  • Eine MMU für Arme?




    Nee.

    Weil ich ein Elektronik Weichei bin, hab ich mich entschlossen, die Inbetriebnahme des CPU Board ohne MMU zu machen.


    Der Adapter Sockel kodiert die Memory Map fest in 4 x 16K Blöcke:

    • die untersten 16K sind im RAM an der physischen Adresse $5C000 (Adresse im RAM ab $5C000)
    • der zweiter 16K Block ist unbelegt
    • der dritte 16K Block ist der IO Bereich ab $17F800
    • der oberste Block ist im ROM an der physischen Adresse $18C000 (Adresse im EPROM ab $5C000)


    Es funktioniert!! :)



  • Das wäre super cool. Halte uns doch bitte auf dem laufenden!

    Diese finnischen MMU funktionieren alle 4 tadellos.

    Also, soweit ich das beurteilen kann.


    Natürlich ist bei der Komplexität dieses Bausteins ein vollständiger Test etwas schwierig ...



    Nachdem nicht mal 6829 drauf steht, war ich ja etwas unsicher.


    Aber es läuft mal garantiert:

    • mit 3 MHz Takt (obwohl kein C oder sowas drauf steht
    • man kann alles wie beschrieben konfigurieren
    • das Speichermanagement arbeitet wie beschrieben
    • es läuft im Dauerbetrieb (24 Stunden) ohne nennenswert warm zu werden



    Hab ich schon erwähnt, wie sehr mich die MMU begeistert?


    Die 63C09P greift auf 2MB zu, es ist keine große Sache, keine Komplikation wie normales Banking.

    Das OS ist abstrahiert und braucht keinen Platz im logischen Adressraum.

    Der User Code ist in seiner virtuellen Blase, wie eine VM nur halt in Hardware.


    Genial!!



    Ich hab mir schon Gedanken gemacht, wie man sowas mit einem EPM7064 + einem Fast RAM + ein paar TTL nachbauen kann.

    Aber es ist jedenfalls aufwendig und braucht viel mehr Platz.

    Von den Kosten gar nicht zu reden.

  • Gut, jetzt wird es ernst.

    Jetzt kommt die Anpassung des NitrOS9, nachdem die Hardware fertig ist.


    Da ich mehr als genug ROM habe, werde ich das ganze NitrOS9 im ROM laufen lassen.

    Es benötigt eh nur 20K.


    Und die Modul Treiber für SD Karte und Arduino Hardware natürlich ebenfalls ins ROM.


    =====


    Das NitrOS9 wird wohl längere Zeit in Anspruch nehmen.


    Deshalb werde ich erst mal ein Mini OS fertig stellen.

    Dass man die Hardware besser untersuchen kann.

    Es wird wohl sowas ähnliches werden wie der MiniMon beim 6809 Kit.

  • Ich hab' mal bei utsource nach dem MC6829 gesucht und ... nichts gefunden, auch eBay glänzt durch Unkenntnis. Der Chip ist bekanntermaßen nicht zu bekommen, womit Du leider der einzige bist, der am Ende das Projekt realisiert. Gibt es da wirklich keinen anderen Weg ?


    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. Man braucht für ein Grundsystem 4 Eurokarten und einen 19"-Einschubgehäuse. Letzteres setzt die Einstiegskosten leider schon recht hoch an. Eventuell läßt sich aus den Schaltplänen Honig saugen und ein Ersatz für den MC6829 basteln.

  • Ich hab' mal bei utsource nach dem MC6829 gesucht und ... nichts gefunden, auch eBay glänzt durch Unkenntnis. Die Chip's sind bekanntermaßen nicht zu bekommen, womit Du leider der einzige bist, der am Ende das Projekt realisiert. Gibt es da wirklich keinen anderen Weg ?

    Ich hab meine von dem finnischen Verkäufer jlithen:

    https://www.ebay.de/usr/jlithen


    Er hatte viel mehr von den Dingern.

    Und auf seinen Chips steht: Motorola SC67475P

    Aber es funktioniert tatsächlich exakt so wie eine 6829 MMU.


    ============


    An einem anderen Weg bin ich auch schon dran.

    Eine Ersatzschaltung.

    Bestehend aus einem CPLD (ATF1504/EPM7064), einem schnellen 10nS SRAM (W24257AK-10) und TTL Zeugs.


    In meinem Kopf ist das schon ziemlich konkret.

    Die Bauteile habe ich bereits beim Ali geordert.


    Das Datenblatt und diese Motorola Application Note (AN-859) beschreibt die Funktion der MMU wirklich gut.

    Man kann das sehr gut nachbauen mit etwas Aufwand.

    Sollte man die Chips nicht mehr kriegen.

  • 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. Man braucht für ein Grundsystem 4 Eurokarten und einen 19"-Einschubgehäuse. Letzteres setzt die Einstiegskosten leider schon recht hoch an. Eventuell läßt sich aus den Schaltplänen Honig saugen und ein Ersatz für den MC6829 basteln.

    Sieht sehr interessant aus.

    Leider nur ein OS9 Level 1.

  • Das Gute an der selbst gebastelten MMU ist, dass die Task# Anzahl riesig ist:

    • 256 Tasks bei 16K
    • 512 Tasks bei 32K


    Ich denke, das kann man kaum ausnutzen bei 2MB. :)





    Im übrigen könnte man alle 16 Bit des SRAM nutzen, anstatt nur 10 wie die MMU.


    Ich spiele noch mit dem Gedanken ein Bipolares RAM zu nutzen.

    Aber ich kann kein passendes finden.

    Vielleicht kriegt man die noch schwerer als die MMU?


    Also vielleicht doch schnelles SRAM ...

  • Im übrigen könnte man alle 16 Bit des SRAM nutzen, anstatt nur 10 wie die MMU.


    Ich spiele noch mit dem Gedanken ein Bipolares RAM zu nutzen.

    Aber ich kann kein passendes finden.

    Vielleicht kriegt man die noch schwerer als die MMU?


    Also vielleicht doch schnelles SRAM ...


    Okay das schnelle SRAM ist da! :)


    Mit der Schematic spiele ich noch herum.

    Inzwischen habe ich überlegt ob ich mehrere MUX und LS245 verwende um den Bus zu trennen.

    Aber all das wird nur kompliziert.


    Die MMU Hardware besteht jetzt aus drei IC:

    1. zwei Stück SRAM , 32K mit 10nS Zugriffszeit
    2. ein großer CPLD ATF1504-84 (oder EPM7064-84)


    Die Anzahl Task größer als 256 ist unsinnig bei 8 Bitter.

    Aber dafür gibt es andere Goodies, mehr Adressraum und Flags:

    • 16MB physikalischer Adressraum
    • 256 Tasks
    • Write Access Flag
    • Read Access Flag
    • Execute Flag (Fetch Access)