NitrOS9-Board: Unterschied zwischen den Versionen

Aus
Wechseln zu: Navigation, Suche
(News)
 
(118 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
[[File:OS9-Board-01.jpg|right|thumb|200px|OS9 Board]]
+
[[File:6309-OS9-MMU-03.jpg|right|thumb|200px|OS9 Board]]
 
__TOC__
 
__TOC__
 
<br />
 
<br />
  
== CPU Board mit NitrOS-9 ==
+
== Mikro Computer Board ==
  
Alle UC Module können folgende Programme starten:
+
Das Ziel ist ein vollständiges Computer System auf Basis einer MC6809 bzw. einer HD6309 CPU mit NitrOS9 als Betriebssystem.
  
  
 
<br />
 
<br />
=== Die CPU ===
+
=== Das ByteMachine Board ===
  
Motorola 6809
+
Aller Anfang ist schwer, deswegen habe ich das CPU Board nicht von Grund auf selbst entwickelt. Statt dessen habe ich meine ersten Schritte mit dem Nachbau eines funktionierenden CPU Boards gemacht: '''die ByteMachine'''
  
Es gibt drei Arten von UC Module:
+
Im GITHUB gibt es das Projekt [https://github.com/c0pperdragon/ByteMachine '''die ByteMachine'''] von dem GIT User '''c0pperdragon'''. Die ByteMachine besticht durch ihre grandiose Einfachheit kombiniert mit enorm großer Flexibilität.
  
* die UC-1  ([[UC1|Details]])
 
* die UC-2  ([[UC2|Details]])
 
* die UC-1.5 ([[UC1.5|Details]])
 
  
 +
Die ByteMachine besteht aus drei Komponenten:
 +
 +
* '''CPU Board'''
 +
* '''Mainboard''': SRAM, EEPROM, Taktgenerator, Reset Signal, 8 LED und 8 digitale Eingänge
 +
* '''optionales IO Board''': serielle Schnittstelle und SD Karte
 +
 +
 +
Jede 8 Bit CPU benötigt dieselben Komponenten für ein lauffähiges System. Daher macht es Sinn, die gemeinsamen Komponenten auf ein eigenes Board zu legen. Das CPU Board macht nur die Anpassung für das Mainboard der ByteMachine. Das IO Board ist optional und wird ggf. auf das Mainboard gesteckt.
 +
 +
 +
Das Mainboard der ByteMachine hat zwei Schnittstellen, eine zum CPU Board und eine zum IO Board. Das CPU Board sowie das optionale IO Board werden einfach auf das Mainboard aufgesteckt. Man kann die CPU aber auch einfach in ein Steckbrett setzen und die Verbindung zum Mainboard über Steckdrähte herstellen.
 +
 +
 +
Die Schnittstelle zwischen CPU Board und Mainboard ist eine Stiftleiste mit 34 Pins. Über die Schnittstelle wird das CPU Board versorgt mit Strom, Takt und Reset. Das CPU Board kontrolliert die restlichen Komponenten über die Schnittstelle. Jede CPU benötigt eine minimale Anpassung um Kompatibilität zur Mainboard Schnittstelle herzustellen.
 +
 +
 +
Das IO Board ist optional. Es bietet eine serielle Schnittstelle und den Anschluss einer SD Karte. Allerdings hat das IO Board keinerlei 'Intelligenz': Sowohl die serielle Schnittstelle als auch die SD Karte werden nur über digitale IO getrieben (Soft UART und SD-Card Bit-Bang). Das IO Board wird einfach auf das Mainboard aufgesteckt, dazu dienen sie Stiftleisten auf der rechten Seite: 8 digitale Ausgänge, 8 digitale Eingänge und Stromversorgung.
 +
 +
 +
Für die ByteMachine existieren 4 CPU Boards im GITHUB:
 +
 +
* W65C02 mit 10 bis 16 MHz
 +
* W65C816 mit 10 bis 16 MHz
 +
* Z84C00
 +
* i8088
 +
 +
 +
Für die ByteMachine habe ich 4 weitere CPU Boards entwickelt:
 +
 +
* Motorola 6809P mit 1 bis 3 MHz
 +
* Motorola 6809EP mit 1 bis 3 MHz
 +
* Motorola 63C09P mit MMU 6829
 +
* Motorola 63C09EP mit MMU-16
 +
 +
 +
Es existieren Schaltbilder, Doku und Platinen Layout für jedes CPU Board. Außerdem gibt es im ROM des Mainboard für jede CPU ein Testprogramm. Das Testprogramm zeigt über die LED des Mainboard an, dass die Hardware richtig funktioniert. Es braucht nur ein EPROM am Mainboard, denn jede CPU hat ihren eigenen Speicherbereich in dem 512K großen EPROM Speicher.
 +
 +
Wenn man eine neue CPU an das Mainboard der Bytemachine anschließen möchte, dann genügen ein Steckbrett und ein paar Verbindungsdrähte. Das macht dieses Konzept so wunderbar flexibel.
 +
 +
<br />
 +
 +
=== OS9 CPU Boards ===
 +
 +
Auf dem NitrOS9 Board läuft eine Motorola CPU 6809 mit 3MHz. Alternativ kann auch eine Hitachi 6309 verwendet werden, diese CPU ist PIN kompatibel und Binärcode kompatibel. Hitachi hat aber viele Verbesserungen im Design der 6309 einfließen lassen. Die 6309 ist schneller, hat mehr Register, kann 32 Bit Operationen ausführen und hat zusätzliche Befehle.
 +
 +
Die 6309 gibt es in verschiedenen Versionen. Je nach 'Speed-Grade' der CPU ist die maximale (interne) Taktfrequenz 1, 1.5, 2 oder 3 MHz. Zudem gibt die Typen P und EP, der Unterschied ist die Taktsteuerung. Die P Typen erzeugen den Takt intern aus einem 4 fachen Grundtakt (12MHz für eine 3MHz 6309P). Die EP Typen brauchen einen externen Takt, den man mit externer Elektronik bilden muss. Bei beiden Typen steuert die CPU die äußere Beschaltung mit zwei Taktleitungen: E und Q. Die Takte E und Q sind 90° phasenverschoben. Das E Signal ist ähnlich dem PHI2 bei der 6502 CPU, man erkennt aus dem Signal die Gültigkeit der Daten am Adressbus.
 +
 +
 +
Basierend auf der Doku des W65C02 Board für die ByteMachine, habe ich drei CPU Boards entwickelt. Eines für die 6309P, eines für die 6309EP und eines wo man beide CPU Typen (P und EP) verwenden kann:
 +
 +
 +
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
 +
Image:ByteMachine_01.jpg
 +
Image:HC6309-P-EP-FO.GIF
 +
Image:ByteMachine_02.jpg
 +
Image:ByteMachine_03.jpg
 +
Image:6309-OS9-MMU16-01.jpg
 +
</gallery>
 +
 +
 +
Die CPU Boards laufen extrem stabil. Die Taktfrequenz ist sehr flexibel, die 63C09P läuft stabil mit 1, 2, oder 3 MHz. Versuche die CPU zu übertakten sind erfolgreich, bei
 +
4 MHz ist keine Erwärmung feststellbar und es läuft seit einigen Tagen fehlerfrei durch. Eine 63B09EP läuft tadellos mit 2,5 MHz.
  
 
<br />
 
<br />
=== C64 Module ganz allgemein ===
 
  
Für den C64 gibt es eine große Anzahl an Modul Erweiterungen. Das reicht von einfachen Spiel Module über komplexe Anwendungen hin zu kompletten Hardware Erweiterungen (IEEE-488, RS-2342, Hardware Speeder, neue CPU ...).
+
=== IO Boards ===
  
 +
Das Mainboard der '''Byte Machine''' stellt 8 digitale Ausgänge und 8 digitale Eingänge zur Verfügung. Im GitHub existiert zudem ein aufsteckbares IO Board, das eine serielle Schnittstelle sowie den eine SD Karte bietet (IOexpander).
  
Wir unterscheiden zwei grundsätzliche Arten:
+
Leider ist sowohl die serielle Schnittstelle als auch die SD Karte nur an den digitalen IO des Mainboard angeschlossen. Es gibt keinerlei Hardware Unterstützung. Die serielle Schnittstelle ist eine reine Software basierte Lösung (Soft-UART). Die SD Karte wird ebenso per Bit-Bang bedient, was es extrem langsam macht und die Software ist sehr aufwendig.
  
* Software Modul (Software für den C64)
 
* Hardware Modul (bringt neue Hardware)
 
  
 +
Deswegen habe ich eigene IO Boards entwickelt:
  
Die Informationen auf dieser Seite beziehen sich nur auf Software Module.
+
* '''IO Test Board''' mit 15 LED (zum Test des IO Port und Software Entwicklung)
Software für den C64 gab es entweder als Kassette, Floppy Disk oder Modul. Modul Software zeichnet sich aus durch einfache Handhabung. Einfach Modul in den C64 stecken und einschalten.
+
* '''UART Board''' auf Basis eines TL16C550 (serielle Kommunikation bis 115200Bd)
 +
* '''Nano IO Board''' mit UART und SD Card auf Basis eines Arduino Nano
  
  
Beim C64 werden in Bezug auf Software Module grundsätzlich drei Modi unterstützt:
+
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
 +
Image:IO-Test-FO.GIF
 +
Image:TL16C550-FO.GIF
 +
Image:IO-NANO-FO.GIF
 +
</gallery>
  
* 8K Modus
 
* 16K Modus
 
* 16K UltiMax Modus
 
  
 +
Alle diese IO Boards verwenden einen IO Port zum Anschluss auf einem CPU Board. Es braucht dazu spezielle, erweiterte CPU Boards, die Standard CPU Boards der Byte Machine haben keinen IO Port. Die IO Ports werden einfach auf den neuen CPU Boards aufgesteckt, quasi als dritte Ebene.
  
Später hat man aus Platzmangel Module mit "Banking" eingeführt, um die Größenbeschränkung von 16KB zu umgehen. Aber auch Module mit Banking sind zu jedem Zeitpunkt auf 16K und die drei grundsätzlichen Modi beschränkt. Der Unterschied ist nur, dass die 16K Modulspeicher ein wählbarer Bereich aus einem größeren Speicherbereich ist.
 
  
Der Banking Mechanismus ist aber nicht genormt. Deswegen ist die Software auf dem Modul beschränkt auf genau eine bestimmte '''Modul Type'''.  
+
Das '''IO Test Board''' hat 15 LED, mit einem geeigneten Test Programm kann damit die korrekte Funktion des IO Port überprüfen.  
  
 +
Die LED-0 bis 7 zeigen den Zustand der Datenleitungen D0 bis D7 bei einem Schreibzugriff auf einen IO Bereich IO-0.
 +
 +
Die LED IO-0 bis IO-6 zeigen den letzten Zugriff auf den zugehörigen IO-Bereich. Bei einem Lesezugriff wird die LED ausgeschaltet und bei einem Schreibzugriff eingeschaltet.
  
Das UC ist ein Software Modul für den C64. In dem Modul kann man ein oder mehrere Programme und Spiele speichern und am C64 ausführen. Das UC Modul hat einen eigenen Banking Mechanismus. Und es kann alle drei Modul Modi per Software einstellen.
 
  
  
 
<br />
 
<br />
  
== Erstellen einer eigenen Programmsammlung ==
+
=== Erweiterte CPU Boards ===
 +
 
 +
Die '''erweiterten CPU Boards''' stecken auf dem Byte Machine Mainboard, genau wie die Basis CPU Boards. Aber sie bieten erweiterte Funktionalität die über eine reine CPU Funktion hinaus geht:
 +
 
 +
* IO Port zum Anschluss von bis zu 8 IO Boards
 +
* optional: Banking Funktion um den ganzen Mainboard Speicher zugreifen zu können
 +
* optional: Speicher Management (MMU) um den Adressraum über einem MB verwalten zu können
 +
* optional: Interrupt Managment
 +
* optional: DMA Funktionalität
 +
 
 +
 
 +
Es sind folgende CPU Boards in Entwicklung:
 +
 
 +
* W65C02 mit 16MHz und Banking (4 x 16K in einem MB)
 +
* 6309 CPU mit [[MMU#Motorola_MMU_6829|MMU 6829]] (32 x 2K in zwei MB)
 +
* 6309 CPU mit [[MMU#Die_MMU-16_Hardware|MMU-16]]  (32 x 2K in 16 MB)
 +
 
 +
 
 +
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
 +
Image:6502-1M-FO.GIF
 +
Image:6309-OS9-FO.GIF
 +
Image:MMU-16-FO.GIF
 +
</gallery>
  
Die Erstellung einer persönlichen Programm Sammlung für ein UC Modul macht man mit Hilfe eines PC Programm: '''UC-Builder'''
 
  
 +
Auf diese erweiterten CPU Boards können die IO Boards aufgesteckt werden. Damit hat man eine schnelle serielle Kommunikation und einen effizienten Zugriff auf eine SD Karte.
  
Der UC-Builder nimmt die gewünschten C64 Programme und verpackt sie in eine einzelne Datei ('''UC Image Datei'''). Diese Datei wird in den Speicher (EPROM, FLASH) des UC Modul geschrieben. Nun steht die Programm Sammlung für den C64 zur Verfügung.
+
Das 6309 Board mit der MMU hat eine hoch effiziente Speicher Verwaltung, einen Adressraum von 2 MB und separate IO Bereiche. Zusammen mit dem Nano IO Board hat man eine Verbindung zur Außenwelt (Terminal) und einen 'Massenspeicher'. Damit ist es schon eine gute Basis, auf der man problemlos ein '''NitrOS9 Level II''' implementieren kann.  
  
 
<br />
 
<br />
=== UC Image Datei ===
 
  
Die C64 Programm Sammlung auf dem UC Modul kann man frei zusammen stellen. Dazu dient ein kleines Programm ('''UC-Builder''') am PC. Das Programm erstellt eine sogenannte '''UC Image Datei'''. diese Image Datei hat die Endung '''.bin''' und kann direkt in das EPROM (oder den FLASH) programmiert werden.
+
== Die Hardware ==
  
 +
Die Hardware ist wie im vorhergehenden Kapitel beschrieben:
 +
 +
* ein Byte Machine Mainboard mit 512K SRAM und 512K FLASH
 +
* ein erweitertes CPU Board (6309 + MMU)
 +
* ein Nano IO Board mit serieller COM und SD Karte
 +
* optional SRAM Boards 512K bis 15MB RAM
 +
 +
 +
Eventuell wird es auch eine SBC (Single Board Computer) Version davon geben (NitrOS9 SBC), wo alles auf einer Platine vereint ist.
  
Die Größe der UC Image Datei darf den verfügbaren Platz im EPROM (im FLASH Speicher) nicht überschreiten. Bei Verwendung eines W27C040 darf die Image Datei eine maximale Größe von 512KB haben. Die Größe setzt sich zusammen aus der Summe der einzelnen C64 Programme plus der Größe des '''UC-Loader'''. Der UC-Loader ist ein C64 Programm, das für die Bedienung des Modul (UC-Menü) notwendig ist.
 
  
 
<br />
 
<br />
=== Der UC-Loader ===
+
=== Memory MAP ===
 +
 
 +
Der '''physikalische Adressraum''' hat eine Größe von einem oder mehreren Megabytes. Dem gegenüber steht eine CPU die nur 64K adressieren kann ('''logischer Adressraum'''). Diese Diskrepanz wird gelöst durch den Einsatz einer MMU (Memory Management Unit).
 +
 
 +
 
 +
Bei der MMU von Motorola (MC6829) hat der physikalische Adressraum eine Größe von 2MB und ist in 1024 Seiten (Pages) zu je 2K (Page $000 bis $3FF) unterteilt.
 +
 
 +
Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.
 +
 
 +
Bei der MMU-16 hat der physikalische Adressraum eine Größe von 16MB und ist in 8192 Seiten (Pages) zu je 2K (Page $000 bis $1FFF) unterteilt.
 +
 
 +
 
 +
Beide MMU splitten den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.
 +
 
  
In dem UC Modul kann mehr als ein Programm gespeichert sein. Deswegen muss man die Möglichkeit haben, das gewünschte Programm auszuwählen. Die Auswahl des gewünschte Programm erfolgt über das UC-Menü. Im UC-Menü werden alle Programme auf dem Modul gelistet und können auf Knopfdruck gestartet werden.
+
Es sind 32 Blöcke die einer Page zugeordnet werden. Dazu gibt es 32 Zeiger zu je 10 Bit (MMU 6829) bzw. 16 Bit (MMU-16). Es sind also zwei Bytes pro Page (insgesamt 64 Bytes), die eine ganze Speicherbelegung (Memory Map) beschreiben.  
  
 +
Die '''Memory MAP''' ist also ein komplette 'Sicht' auf den logischen Adressraum von 64K. Das ermöglicht einen sehr flexiblen Zugriff auf den gesamten physikalischen Adressraum. Zudem kann das Block Mapping dynamisch verändert werden, sodass die CPU stets die gerade wichtigen Teile des physikalischen Adressraum im Zugriff hat.
  
Nach dem Einschalten des C64 startet der UC-Loader. Der UC-Loader schaut nach, welche Programme auf dem Modul gespeichert sind. Wenn es nur ein Programm ist, dann wird dieses direkt gestartet. Wenn sich mehr als ein Programm auf dem Modul befindet, dann zeigt der UC-Loader die Namen aller Programme am Bildschirm an ('''UC-Menü'''). Der Benutzer wählt das gewünschte Programm und der UC-Loader startet es.
 
  
 +
;Memory MAP bei der MMU 6829
  
Wenn sich ein '''File Browser''' (UC-FB) in der Image Datei befindet, dann kann man das Programm über die Taste <F1> starten. Der File Browser ist ein modifiziertes FB (File Browser) Version 2. Man kann damit Dateien auf einem Disketten Laufwerk oder einem SD2IEC anzeigen und starten. Dateien mit der Dateiendung .CRT startet der UC-FB automatisch als Modul.
+
<gallery mode="traditional" widths=250px heights=180px perrow=9 caption="">
 +
Image:Memory-Map-OS9-MMU.png
 +
</gallery>
  
  
Mit den Tasten <F7> oder <F8> kommt man in den normalen C64 Eingabemodus (C64 BASIC). Die Taste <F7> schaltet dabei das UC Modul aus. Man kann dann immer noch auf die UC-Register an der Adresse $DE0x zugreifen. Mit der Taste <F8> schaltet man zusätzlich auch die UC Register aus. Das Modul ist dadurch vollkommen unsichtbar und kann nur durch einen Modul Reset wieder aktiviert werden.
+
;Memory MAP bei der MMU-16
  
 +
<gallery mode="traditional" widths=250px heights=180px perrow=9 caption="">
 +
Image:Memory-Map-OS9-MMU-16.png
 +
</gallery>
 
<br />
 
<br />
  
=== Der UC-Builder ===
+
=== Speicher Management (MMU) ===
  
In dem Speicher des UC Modul (EPROM oder FLASH) kann man fertige Image Dateien programmieren.  
+
Das [[OS9-L2|NitrOS9 Level 2]] hat bestimmte Anforderungen an die Hardware. Neben den Mindestanforderungen von 128K RAM sollte auch das Banking bestimmten Anforderungen entsprechen. Der Grund ist die Multitasking Fähigkeit von NitrOS9, das erfordert eine blitzschnelle Umschaltung zwischen verschiedenen Speicherbelegungen (Memory Maps).
Dazu braucht man nur ein EPROM Programmiergerät.  
 
Wenn man eine eigene Zusammenstellung von Programmen machen möchte, dann braucht man den '''UC-Builder'''.
 
  
Der UC-Builder erstellt eine UC Image Datei aus einem oder mehreren C64 Programme.  
+
In einem NitrOS9 System gibt es mehr als eine Memory MAP. Es ist sinnvoll, dass das OS andere Teile des physikalischen Adressraum sieht als ein Benutzer Programm. Zudem ist  NitrOS9 in der Lage mehrere Benutzer Programme quasi gleichzeitig laufen zu lassen (Multi Tasking). Es gibt also mehrere Memory MAPs für das OS, für Treiber und für mehrere Benutzer Programme. Deshalb wird eine bestimmte Memory MAP als ''''Task'''' bezeichnet.  
Die Image Datei enthält den '''UC-Loader''', das '''UC-Menü''' (die Programmauswahl), ggf. einen File Browser ('''UC-FB''') und alle C64 Programme die in dem Modul sind. Der UC-Loader ist in dem UC-Builder bereits enthalten und wird immer automatisch in die Image Datei geschrieben. Das UC-Menü wird vom UC-Builder erzeugt und in die Image Datei geschrieben.  
 
  
 +
Jeder Task beschreibt also eine ganze Memory MAP. Eine Memory MAP besteht technisch gesehen aus x Zeiger in den physikalischen Adressraum (für jeden Block ein Zeiger). Jeder Zeiger enthält die Nummer der zugeordneten Page, also eine Zahl zwischen 0 und 1023 (10 Bit bei der MMU 6829) bzw. zwischen 0 und 8191 (13 +3 Bit bei der MMU-16). Die Zeiger sind dynamisch änderbar, also quasi ein RAM Speicher aus Sicht der CPU. Die MMU benötigt also 64 Byte RAM Speicher pro Task.
  
Für die Erstellung des UC-Menü benötigt das UC-Builder folgende Informationen zu jedem C64 Programm:
+
Das Multitasking ist natürlich nicht wirklich eine 'gleichzeitige' Ausführung von Programmen. Selbstverständlich wird immer nur ein Programm nach dem anderen ausgeführt. Um das Gefühl von gleichzeitig zu bekommen, wechselt die Ausführung der verschiedenen Tasks relativ häufig (zig mal pro Sekunde). Nun hat jeder Task seine eigene Memory MAP bestehend aus 64 Zeiger in den physikalischen Adressraum. Dank MMU muss das OS aber nur einen Schreibzugriff ausführen, um einen Task Wechsel zu veranlassen. Dazu stellt die MMU ein TASK-Register zur Verfügung.
  
* Name des Programm
+
Unter NitrOS9 werden alle Interrupts der CPU vom OS ausgeführt. Das bedeutet einen Task Wechsel in der MMU für jeden einzelnen Interrupt. Und natürlich einen Taskwechsel zurück zum Task der vorher eingestellt war. Das NitrOS9 läuft dabei immer auf Task #0.
* Art des Programm
 
* Den Dateinamen des Programm
 
  
Der ''Name des Programm'' wird dann beim Start vom UC-Loader angezeigt.
 
Die ''Art des Programm'' benötigt der UC-Loader, damit das Programm korrekt gestartet werden kann.
 
Die ''Dateiname des Programm'' benötigt der UC-Builder, damit er es in die UC Image Datei integrieren kann.
 
  
 +
<br />
 +
==== MMU Motorola 6829 ====
  
Der UC-Builder ist ein Programm für die Windows Kommandozeile. Es erstellt Image Dateien für das UC1, UC1.5 und das UC2 Modul. Wird es ohne Argumente aufgerufen, dann sucht das UC-Builder nach einer CSV Datei namens ''''''menu.csv''''''. Wenn keine Fehler auftreten beim bilden des Image, dann erfolgt nur die Ausgabe der Image Datei Größe sowie des freien Speicherplatz. Die Berechnung des freien Speicher beruht auf de Annahme, dass ein 128K EPROM (W27C010) verwendet wird. Bei Verwendung eines 64K EPROM muss man darauf achten, dass die Image Größe 0x10000 nicht überschreitet.
+
Die [[MMU-6829]] verwaltet einen physikalische Adressraum mit einer Größe von 2MB. Der physikalische Adressraum ist in 1024 Seiten (Pages) zu je 2K (Page $000 bis $3FF) unterteilt.  
  
 +
Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.
  
<u>Optionen</u>:
+
Es sind 32 Blöcke die einem der 1024 Pages zugeordnet werden. Dazu gibt es 32 Zeiger zu je 10 Bit (zwei Bytes), also insgesamt 64 Bytes, die eine ganze Speicherbelegung (Memory Map) beschreiben.
 +
Die [[MMU-6829]] stellt vier Tasks (vier MAPs) zur Verfügung. Das Mapping RAM hat also eine Größe von insgesamt 256 Bytes (64 mal 4).
  
Mit der Option '-h' oder '--help' bekommt man eine Ausgabe aller verfügbaren Optionen zum UC-Builder.<br />
 
Mit der Option '-V' oder '--version' wird die Version des  UC-Builder angezeigt.
 
  
Mit der Option '-1' oder '--UC1' wird der UC-Builder angewiesen, eine Image Datei für ein [[UC1|UC1 Modul]] zu erstellen.<br />
+
Näheres zu dieser MMU [[MMU-6829|findet man '''hier''']].
Mit der Option '-2' oder '--UC2' wird der UC-Builder angewiesen, eine Image Datei für ein [[UC2|UC2 Modul]] zu erstellen. Diese Image Dateien laufen auch in der UC1.5<br />
 
Mit der Option '-5' oder '--UC1.5' wird der UC-Builder angewiesen, eine Image Datei für ein [[UC1.5|UC1.5 Modul]] zu erstellen. Diese Image Dateien laufen auch in der UC2
 
  
Mit der Option '-8' oder '--MD' wird der UC-Builder angewiesen, eine Image Datei für ein '''Magic-Desk Modul''' zu erstellen. Die maximale Größe ist 1MB. <br />
 
Mit der Option '-9' oder '--EF' wird der UC-Builder angewiesen, eine Image Datei für ein [https://www.c64-wiki.de/wiki/EasyFlash '''EasyFlash Modul'''] zu erstellen.
 
  
Mit der Option '-m' oder '--menu-csv' kann man eine CSV Datei mit beliebigem Namen verwenden.
+
<br />
  
Mit der Option '-i' oder '--image-file' kann man den Namen der Ausgabe Datei (UC Image Datei) festlegen.<br />
+
==== Die MMU-16 ====
Mit der Option '-c' oder '--crt-file' kann man den Namen der Ausgabe Datei (CRT Datei) festlegen.
 
  
Mit der Option '-v' erhöht man die Anzahl der Meldungen, das UC-Builder wird 'gesprächiger'. Die Option kann mehrfach verwendet werden. Ab drei '-vvv' erhält man detaillierte Informationen über den Aufbau der Image Datei, also die Adresse, Bank und Länge jedes Programmes in dem Image. Es wird auch angezeigt wie das Programm geladen und gestartet wird und ob das IO Register verborgen wird.
+
Die Motorola MMU 6829 ist heutzutage kaum noch zu bekommen. Aus diesem Grund wurde die [[MMU-16]] entwickelt.  
 +
Die Arbeitsweise und die Register der [[MMU-16]] sind kompatibel zur Motorola 6829.
 +
Alle Bauteile sind auch heutzutage noch gut erhältlich.
  
  
Am Ende wirft der UC-Builder zwei Dateien aus. Die BIN Datei (EPROM Abbild) ist die '''UC Image Datei''', die direkt in das EPROM für das Modul gebrannt werden kann. Die '''CRT Datei''' ist ein 8K CRT für den VICE, damit kann man das Menü gleich kontrollieren. Allerdings kann der VICE die Programme nicht richtig starten, da der VICE die UC Hardware (noch) nicht emulieren kann.
+
Die [[MMU-16]] verwaltet einen physikalische Adressraum mit einer Größe von 16MB. Der physikalische Adressraum ist in 8192 Seiten (Pages) zu je 2K (Page $0000 bis $1FFF) unterteilt.  
  
 +
Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.
  
Die Image Dateien für Magic-Desk oder EasyFlash sind wie bei den UC-Images eine BIN Datei (EPROM Abbild) und eine CRT Datei für den VICE Emulator. Neuere Versionen des VICE Emulator können beide Arten (EasyFlash und Magic-Desk) perfekt emulieren.
+
Es sind 32 Blöcke die einem der 8192 Pages zugeordnet werden. Dazu gibt es 32 Zeiger zu je 13 Bit (zwei Bytes), also insgesamt 64 Bytes, die eine ganze Speicherbelegung (Memory Map) beschreiben.
 +
Die [[MMU-16]] stellt 256 Tasks (256 MAPs) zur Verfügung. Das Mapping RAM hat also eine Größe von 2 mal 8KB (64 mal 256).  
  
  
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
+
Näheres zu dieser MMU [[MMU-16|findet man '''hier''']].
Image:UC-Builder_00.png
+
 
Image:UC1-Tool_01.png
 
Image:UC1-Tool_02.png
 
Image:UC1-Tool_04.png
 
Image:UC1-Tool_05.png
 
Image:Screenshot 2021-11-29 144141.png
 
Image:Screenshot 2021-11-29 151254.png
 
</gallery>
 
  
 
<br />
 
<br />
  
=== Die CSV Datei für die Menü Erstellung ===
+
==== Speicher Schutz ====
 +
 
 +
Wenn nur ein Programm läuft, dann braucht man keinen besonderen Schutz des Speicherraum. Ganz anders ist es, wenn man mehrere Programme gleichzeitig laufen lässt (Multitasking). Es erhöht die Stabilität des System ungemein, wenn jedes Programm nur 'seinen eigenen Speicher' im Zugriff hat.
  
Das UC-Builder liest die benötigten Informationen aus einer Text Datei (CSV Datei).
+
Das gilt insbesondere auch für den Speicher des Betriebssystem selbst. Wenn Benutzerprogramm in den Speicherbereich des NitrOS9 schreiben können, dann kann es zu Problemen und Abstürze kommen.  
Jede Zeile in der CSV Datei steht für ein Programm (bzw. einen Menü Eintrag).
 
Mit der Option -m sagt man dem UC-Builder den Namen der CSV Datei (''-m menuFile.csv'').
 
Wenn das UC-Builder ohne CSV Dateinamen aufgerufen wird, sucht es automatisch nach der CSV Datei ''menu.csv''.
 
  
 +
All Ressourcen im System (Bildschirm, IO, Massenspeicher, Kommunikation ...) können bei einer Motorola CPU nur als quasi 'Speicher' zugegriffen werden. Daher ist eine Speicherschutz auch glz. ein Schutz aller Ressourcen im System. Zum Beispiel der Bildschirm RAM, wenn da zwei Programme glz. hinein schreiben, dann wird es wahrscheinlich chaotisch aussehen am Bildschirm den Benutzer.
  
<b><u>Beispiel einer CSV Datei</u>:</b>
 
  
Programm;          Typ;      Dateiname
+
Nun kann die CPU ja nur ihren logischen Adressraum zugreifen. Daraus folgt, die CPU kann im physikalischen Adressraum nur zugeordnete Pages verändern. Letztlich muss also nur der Zugriff auf die MMU selbst beschränkt werden, um einen Speicherschutz zu erreichen.
Hello World;        PRG;      10-Zeiler\hello world.prg
 
Fort Apocalypse;    PRG;      Games\Fort Apocalypse.prg
 
Jupiter Lander;    UltiMax;  Ultimax\Jupiter_Lander.crt
 
ExBasic-II;        CRT;      CRT\ExBasic II.crt
 
Test $C003;        BIN;      Test\UC-testc01.prg;              SYS $C003
 
TSB;                BIN;      BIN\tsb.obj.prg;                  RESET
 
Help+;              !$8000;  BIN\Help+-C64.bin;                RESET
 
  
 +
Bei der MMU 6829 ist der Zugriff auf die MMU nur im Task #0 möglich. Task #0 ist also der System Task, der die alleinige Kontrolle über das Page Mapping hat. Der Speicherschutz ist folglich alleinige Aufgabe des OS. Das NitrOS9 kann sensible Speicherbereiche einem Programm zuordnen oder eben nicht.
  
 +
<br />
  
 +
==== Maximale Speicher Nutzung ====
  
 +
Unter NitrOS9 Level 1 hatte man nie den vollen logischen Adressraum zur Verfügung. In jedem Fall musste stets ein ROM im obersten Ende des Speicher sein, weil da die Vektoren für Interrupts und SWI stehen und auch der Code dafür musste stets im Zugriff stehen.
  
 +
Dank MMU und NitrOS9 Level 2 kann nun jeder Task die gesamten 64K voll RAM haben. Es wird kein einziges Byte verschwendet für ROM oder IO.
  
Aus der CSV Datei entsteht eine UC Image Datei mit einem Menü und vier C64 Programmen.
 
Die zweite Spalte enthält den ''Typ'' des C64 Programm.
 
Diese Information benötigt der UC-Loader damit das Programm richtig gestartet werden kann.
 
  
 +
Möglich wird das durch eine besondere Fähigkeit der MMU, die selbstständig beim Aufruf einen OS9 Service (SWI) oder eines Interrupts automatisch in den System Task #0 schalten kann. Dazu stellt die CPU eigene Signale zur Verfügung, die ermöglichen der MMU die Erkennung, was die CPU gerade so macht. Im Falle eines Interrupt werden die Register auf den User Stack geschrieben, dann schaltet die MMU automatisch auf den Task #0, wodurch das System ROM sichtbar wird. Die CPU lädt den Interrupt Vektor aus dem System ROM und führt den Code aus.
  
<b><u>Spalte 1 -- Programm Name</u>:</b>
 
  
Der Programm Name wird nur für die Darstellung im UC-Menü benutzt. Der Name wird automatisch in PETSCII konvertiert, sofern dies möglich ist. Die Länge wird automatisch auf 17 Zeichen reduziert, damit es am C64 problemlos dargestellt wird.
+
Jeder Benutzer Task kann zusätzlichen RAM anfordern vom OS. Über einen Banking Bereich kann man so auch mehr als 64K Speicher zur Verfügung haben. Man kann RAM teilen mit mit anderen Tasks (gemeinsame RAM Bereiche). Es braucht keinen Platz für IO und keinen ROM Bereich in der Memory MAP eines Benutzer Task, es ist aber optional trotzdem noch möglich.  
  
Ein Sonderfall ist der Text 'F1'. Wenn der Programm Name exakt 'F1' ist, dann betrachtet der UC-Builder diesen Eintrag als 'File Browser'. Im UC-Menü wird kein Eintrag gebildet, aber es erscheint ganz unten links die Auswahl 'F1-File Browser'. Mit der Taste 'F1' wird dieser Eintrag als File Browser gestartet. Der File Browser wird immer mit aktiviertem IO Register gestartet, damit ggf. später eine Konfiguration des UC Modul erfolgen kann.
+
Der Benutzer Speicher ist geschützt vor Zugriffe eines anderen Benutzer Task. Alles Speicherbereiche des OS und die IO Bereiche sind geschützt vor den Benutzer Tasks.
  
Der File Browser kann entweder ein externes Programm oder der interne UC-FB sein. Im Falle des internen UC-FB ist der '''Programm Typ''' immer als '---' anzugeben. Und es ist natürlich kein  Dateiname nötig, die Spalte drei kann also einen beliebigen Inhalt haben.
+
<br />
  
 +
==== Spezielle Funktionen der MMU ====
  
<b><u>Spalte 2 -- Programm Typ</u>:</b>
+
Durch spezielle Steuersignale von der CPU erkennt die MMU automatisch einen Reset, einen Interrupt (IRQ) oder einen SWI Befehl. Der Task Wechsel ist ein sensibler und komplexer Vorgang. Durch die Änderung der Speicher MAP ändert sich ja unter Umständen gänzlich alles, auch der Stack und User Stack liegt plötzlich an einer ganz anderen physikalischen Adresse. Die MMU zählt CPU Takte, damit die Umschaltung der Speicher MAP immer an dem exakt definierten Zeitpunkt statt findet.
  
Der '''Programm Typ''' steuert, wie das Programm geladen wird. Zudem bestimmt es die Konfiguration der UC Hardware vor dem Programm Start. Zudem wirkt sich der Programm Typ aus auf die Start Option, sofern diese nicht manuell eingestellt wird (siehe Spalte 4).
+
Der Wechsel zum System Task #0 erfolgt voll automatisch. Die CPU sichert die Register noch in der User MAP und fetched die Vektoren bereits in der System MAP. Dann wird der Code des OS bzw. einer Modul (Hardware Treiber) ausgeführt. Die Rückkehr zum User Task erfolgt in der Regel durch ein RTI. Da muss der RTI Befehl noch aus der System MAP gelesen werden, die Rücksicherung der Register muss aber bereits vom Stack des Benutzer Task erfolgen. Der Zeitpunkt des Task Wechsel in der MMU ist sehr sensibel. Zum Glück übernimmt das NitrOS9 diese Aufgabe.
  
  
;Folgende Kürzel sind in der Spalte ''Typ'' erlaubt:
+
Der Schutz des OS vor Benutzer Code und der Schutz des Benutzer Code vor anderem Benutzer Code erfolgt nur durch das Paging. Der Schlüssel dazu ist die Konfiguration der MMU. Deshalb kann die MMU Konfiguration nur verändert werden durch "privilegierten Code". Die MMU Register sowie der Paging RAM können nur verändert werden, wenn der Task #0 aktiv ist. Mit anderen Worten, für DMA und Benutzerprogramme ist die MMU unsichtbar.
  
;PRG
+
Nach einem Reset ist die MMU in einem speziellen Modus. Die Adressleitungen PA11 bis PA20 sind high, daher muss das Start ROM im oberen Ende des physikalischen Adressraum liegen. Da liegen auch die MMU Register und der MMU RAM. Bei der NitrOS9 Platine liegt die MMU an der Adresse 1FFF00 bis 1FFF7F (128 Bytes). Es ist egal ob die MMU Register sichtbar sind oder nicht, in diesem Adressbereich ist das ROM immer ausgeblendet.
: normales BASIC Programm, das an der Adresse $801 geladen und mit RUN gestartet wird
 
;BIN
 
:  ein Programm mit Ladeadresse, das an beliebiger Adresse geladen und mit SYS oder RESET gestartet wird
 
;BLK nnn
 
;! nnn
 
:  eine Datei OHNE Ladeadresse, die an beliebiger Adresse geladen und mit SYS oder RESET gestartet wird
 
:  es kann entweder 'BLK' oder '!' verwendet werden, das Ergebnis ist das selbe.
 
die Datei wird an die angegebene Adresse 'nnn' geladen. Die Adresse kann dezimal, hexadezimal (beginnt mit '$' oder '0x') oder Oktal (beginnt mit '0') angegeben werden
 
;8KB
 
: das Programm wird als 8KB Modul gestartet
 
;16KB'''
 
: das Programm wird als 16KB Modul gestartet
 
;UltiMax
 
:  das Programm wird als Ultimax Modul gestartet
 
;CRT
 
:  der Modul Typ wird selbsttätig erkannt, - nur bei CRT Dateien
 
;"---"
 
: Sonderfall für die Verwendung des internen UC-FB, wenn der '''Programm Name''' exakt 'F1' ist
 
  
 +
Selbst wenn es einem Benutzer Programm gelingt, die Page 1023 einzublenden und so Zugriff auf den Adressen Bereich 1FFF00 bis 1FFF7F zu erlangen, kann das Programm die MMU nicht zugreifen (MMU ist unsichtbar).
  
<b><u>Spalte 3 -- Dateiname</u>:</b>
+
Die MMU Hardware ist wasserdicht, der Speicher ist perfekt geschützt. Nur wenn das OS einen Zugriff erlaubt, hat das Benutzerprogramm einen Zugriff. Die Schwachstelle ist also immer das OS, eine Schadsoftware könnte aber theoretisch Fehler im Systemcode nutzen. Im Normalfall läuft der Benutzer Code in einer sichern Blase, quasi eine virtuelle Umgebung. Es läuft in seiner virtuellen Speicher Welt, die das OS eingestellt hat, und kommt nicht heraus.
  
Der Dateiname am PC, damit der UC-Builder die Datei lesen und in die Image Datei einbinden kann. Es sind alle Arten von Pfade erlaubt, die dem OS bekannt sind (Unterverzeichnisse, andere Laufwerke, absolute Pfade, Netzlaufwerke, Pfad Aliase ...). Dateien werden einfach als Byte Stream gesehen. Es gibt aber Ausnahmen, Dateien die inhaltlich interpretiert werden: P00 und CRT
+
Das Konzept mit der MMU geht schon in die Richtung, die beim PC erst seit dem Intel 386 funktionieren. Der Intel Prozessor ist natürlich 16/32 Bit breit, und hat das ganze Paging voll integriert in der CPU. Aber im Grunde gab es das schon Jahre vorher.
  
; P00
 
: Diese Dateien werden besonders behandelt, der P00 Header wird überlesen und ab Byte [0x1A] wird als Inhalt verwendet
 
  
; CRT
+
<br />
: Diese Dateien sind 'Modul Dateien' für den Emulator. Sofern es CRT Dateien vom Typ 0 (8K, 16K, Ultimax) sind, werden sie vom UC Builder und vom UC-FB richtig interpretiert.
 
  
 +
=== Inbetriebnahme ===
  
<b><u>Spalte 4 -- Start Optionen</u>:</b> (optional, ab v1.05)
+
Voraussetzung ist ein sauber funktionierendes Byte Machine mit 12MHz Quarz (bei einer 3MHz CPU - 68C09P).
 +
Die Funktion des Mainboard kann man mit jedem CPU Board testen (Knight Rider Test Code).
  
Die Spalte 4 kann normalerweise einfach weg gelassen werden. Man kann hier eine bestimmte Startoption erzwingen. Wenn die Spalte weg gelassen wird, startet der UC-Loader alle PRG mit einem 'RUN' Befehl, alle Modul Dateien mit einem Soft RESET und alles andere gar nicht (springt nach dem LOAD ins BASIC).
 
  
Wenn man eine Startoption definiert, dann führt sie der UC-Loader nach dem LOAD aus, unabhängig davon ob es Sinn macht oder nicht.
+
<br />
 +
==== Inbetriebnahme MMU 6829 ====
  
 +
Das OS9 Board mit [[MMU-6829]] wird bestückt. Das GAL 22v10 muss mit dem korrekten JEDEC beschrieben werden (zB. mit einem TL866 Programmer). Bei 12MHz Systemtakt sollte die CPU ein C Typ sein (63C09P), für andere CPU Typen (1, 1.5 und 2 MHz) muss die Frequenz des Quarz entsprechend angepasst werden.
  
;Folgende Startoptionen sind erlaubt
 
  
; RESET
+
Das Board kann zunächst ohne MMU getestet werden, dazu bastelt man sich einen kleinen Adapter aus einem Sockel mit sieben Drähten (siehe Fotos). Der Adapter verdrahtet eine fixe Memory MAP, die kompatibel ist zu den einfachen CPU Boards. Damit wird der Standard Test Code an der EPROM Adresse $5FD00 (physikalische Adresse $1FFC00) ausgeführt. Wenn der GAL richtig programmiert wurde, dann sollte die Knight Rider Animation laufen (genau wie bei den einfachen CPU Boards).
: Nach dem laden des Programmes wird ein Soft RESET ausgeführt.<br />
 
: (Das ist Standard bei Programm Typ 8KB, 16KB, UltiMax und CRT)
 
  
; SYS nnn
+
Mit MMU braucht man dann ein anderes EPROM auf dem Byte Machine Mainboard. Der Standard Byte Machine ROM wird ersetzt durch einen eigenen OS9 EPROM. Die MMU schaltet nach einem Reset alle Adressleitungen auf high, wodurch nur noch die oberste Page sichtbar ist (physikalische Adresse $1FFF800-$1FFFFFF). Deswegen muss der Reset Code ganz am oberen Ende des EPROM liegen (EPROM Adresse $7F800-$7FFFF). Die Reset Routine muss zu aller erst die MMU konfigurieren, damit RAM und IO sichtbar werden im Adressraum der CPU.
: Nach dem laden des Programmes wird ein SYS ausgeführt auf die Adresse 'nnn'. Die Start Adresse kann dezimal, hexadezimal (beginnt mit '$' oder '0x') oder Oktal (beginnt mit '0') angegeben werden.
 
  
; RUN
 
: Nach dem laden des Programmes wird ein RUN ausgeführt. Sofern es sich bei dem Programm um ein BASIC Programm handelt, wird es automatisch nach dem LOAD ausgeführt.<br />
 
: (Das ist Standard bei Programm Typ PRG)
 
  
; READY
+
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
: Nach dem laden des Programmes wird '''nichts''' gemacht. Der UC-Loader springt direkt nach dem LOAD in den Direktmodus des BASIC (Interpreter Loop).<br />
+
Image:6309-OS9-FO.GIF
: (Das ist Standard bei Programm Typ BIN und BLK)
+
Image:MMU-Replacement.png
 +
Image:6309-OS9-MMU-01.jpg
 +
Image:6309-OS9-MMU-02.jpg
 +
Image:6309-OS9-MMU-03.jpg
 +
</gallery>
  
; ROM
 
: Das Programm wird direkt im ROM (EPROM/FLASH) ausgeführt, ohne zuerst ins RAM geladen zu werden. Der UC Loader selektiert die richtige Speicher Bank und startet dann per Reset. Module vom Typ  8K und 16K werden direkt an der unteren Grenze einer 16K Bank angeordnet. Ultimax Module mit 8K werden automatisch in dem oberen 8K Block einer Bank angeordnet, das ist Standard für Ultimax Module wegen dem Reset Vektor.
 
: Diese Methode hat den Nachteil, dass ein Programm genau an den Block Grenzen einer Bank angeordnet werden muss, dadurch entstehen u.U. Lücken zu dem Programm vorher und der Speicher kann nicht mehr vollständig benutzt werden. Aber es eignet sich gut, wenn hauptsächlich Modul Programme (CRT Dateien) mit 8K und 16K Größe benutzt werden (zB. das Multi-MAX Modul). Im Falle von vielen 8K Modulen wird der Speicher ideal genutzt, wenn sich eine 8K und eine Ultimax immer abwechseln.
 
  
 
<br />
 
<br />
  
=== Der File Browser (UC-FB) ===
+
==== Inbetriebnahme MMU-16 ====
  
Der UC File Browser wird vom UC-Menü gestartet mit der Taste <F1>. Der UC File Browser ist nur verfügbar, wenn im CSV File ein Dummy Eintrag gemacht wird. Der Menütext (erste Spalte) muss 'F1' lauten und die zweite Spalte enthält drei Bindestriche ('---'). Die dritte Spalte wird nicht ausgewertet. Optional kann man statt des internen UC-FB auch einen eigenen Browser einbinden, dazu muss nur die erste Spalte exakt 'F1' enthalten.
+
Das OS9 Board mit [[MMU-16]] wird bestückt. Die beiden Atmel CPLD's ATF-1504 werden über JTAG mit der aktuellen Firmware programmiert. Bei 12MHz Systemtakt sollte die CPU ein C Typ sein (63C09EP), für andere CPU Typen (1, 1.5 und 2 MHz) muss die Frequenz des Quarz entsprechend angepasst werden.
  
Der UC-FB läuft als 8KB ROM und ist sonst wie der normale FB v2. Er startet Programme, wechselt in Verzeichnisse oder Disk Image Dateien und verlässt diese auch wieder. So kann man sehr komfortabel auf einem SD basierten Laufwerk (wie das SD2IEC) navigieren.
 
  
Der UC-FB kann auch CRT Dateien vom Typ 0 starten. Es wird automatisch der Modul Typ (8K, 16K oder Ultimax) aus dem CRT File gelesen und entsprechend in den UC RAM geladen. Der Start erfolgt über einen Soft Reset.
+
Der Standard Test Code wird an der EPROM Adresse $5FD00 (physikalische Adresse $1FFC00) ausgeführt. Wenn die beiden CPLD richtig programmiert wurden, dann sollte die Knight Rider Animation laufen (genau wie bei den einfachen CPU Boards).
 +
 
 +
Für den Einsatz von OS9 braucht man dann ein eigenes EPROM. Die obersten 8KB des EPROM enthalten den NitrOS9 Startcode (REL + KERNAL). Die MMU schaltet nach einem Reset alle Adressleitungen auf high, wodurch nur noch die oberste Page sichtbar ist (physikalische Adresse $1FFF800-$1FFFFFF). Deswegen muss der Reset Code ganz am oberen Ende des EPROM liegen (EPROM Adresse $7F800-$7FFFF). Die Reset Routine muss zu aller erst die MMU konfigurieren, damit RAM und IO sichtbar werden im Adressraum der CPU. Danach wird der NitrOS Startcode kopiert in den RAM an der logischen Adress2 $2800. Dann wird REL gestartet an der Adresse $2802.
 +
 
  
 
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
 
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
Image:UC1-FB-01.png
+
Image:MMU-16-FO.GIF
 +
Image:6309-OS9-MMU16-01.jpg
 
</gallery>
 
</gallery>
 +
  
 
<br />
 
<br />
=== MAX Machine ===
 
  
Die UC Module sind dafür konzipiert, in einem C64 Computer zu arbeiten. Neuere UC Module können aber auch in einer Commodore MAX Machine laufen. Mie Module UC-1 und UC-1.5 haben dazu einen optionalen Jumper, mit dem sie in den MAX Machine Modus geschaltet werden können. Das UC-2 Modul kann per Software Einstellung in den MAX Machine Modus wechseln.
+
== Das Betriebssystem ==
 +
 
 +
Das einzige Betriebssystem, das eine MMU unterstützt, ist OS9 ab Level 2.
 +
Daher habe ich NitrOS9 Level 2 angepasst für mein [[NitrOS9-Board|NitrOS9 Board]] mit MMU-16.
 +
Die Basis dafür ist der Quellcode des NitrOS9 für den großartigen [https://www.roug.org/retrocomputing/os/os9/p9000 Positron 9000 Computer].  
 +
 
 +
 
 +
<br />
 +
=== Reset Modus ===
 +
 
 +
Durch einen Hardware Reset wird in der MMU das Reset Bit gesetzt. Die MMU ist dann in einem speziellen Modus: Reset Modus
 +
 
 +
Das Reset Bit ist notwendig, weil das Mapping RAM nach dem einschalten einen nicht definierten Inhalt hat. Dadurch wäre das ganze System in einem undefinierten Zustand und könnte nicht richtig gestartet werden.
 +
 
 +
 
 +
Zusammenfassung Reset Bit:
  
Ein UC Modul im Max Machine Modus läuft auch in einem C64.
+
* das Reset Signal setzt das Reset Bit, die MMU ist im Reset Modus
  
 +
* im Reset Modus ist das Mapping RAM inaktiv, alle physikalischen Adressleitungen sind high
  
Der MAX Machine Modus unterliegt den Beschränkungen dieser Ziel Plattform:
+
* im Reset Modus kann das Mapping RAM beschrieben werden, wie im SU Modus
* es funktioniert nur noch der Ultimax Modus
 
* der UC Loader funktioniert in diesem Modus nicht
 
* ein C64 hat nur noch 4K RAM
 
* an einer MAX Machine sind 2K RAM (intern) und 2K extern (UC-RAM) von $0800 bis $0x0FFF
 
* das Signal IO-1 ist direkt mit /EXRAM verbunden
 
* das Signal IO-2 ist direkt mit /EXROM verbunden
 
* die UC Register sind in einer MAX Machine in dem 2K Adressraum $0800-$0FFF ansprechbar (statt wie gewohnt ab $DExx)
 
* an einem C64 hat man 256 Byte UC RAM im IO-2 Bereich ($DFxx)
 
  
 +
* das Reset Bit wird zurück gesetzt, sobald man da OP-Key Register beschreibt
  
Da der UC Loader nicht funktioniert im Max Machine Modus funktionieren da auch keine UC Images mehr. Es braucht eine Software die spezielle für diesen Modus entwickelt wurde, zum Beispiel die MultiMax Software für das UC Modul.
 
  
  
 
<br />
 
<br />
== Modul Gehäuse selbst gedruckt ==
+
=== System Modus ===
 +
 
 +
Durch einen Interrupt (Hardware oder Software Interrupt) wird in der MMU das System Bit gesetzt. Die MMU wechselt dadurch automatisch in den System Modus (oder auch Super User Modus). Solange das System Bit gesetzt ist, ist die MMU immer Task# 0 (System Task). Die Memory Map ist die System Map und die MMU Register sind im Zugriff. Normalerweise wird nun Betriebssystem Code ausgeführt. Das System Bit wird zurückgesetzt, indem man einen Task Wechsel zu einem Benutzer Task durchführt.
 +
 
  
Vielen Dank an [https://www.forum64.de/wcf/index.php?user/27832-goodwell/ '''Goodwell''' vom Forum-64], er hat wunderschöne Gehäuse konstruiert für das UC-2 und das UC-1.5 ([https://www.forum64.de/index.php?thread/118061-uc1-universal-cartridge-1-universell-verwendbares-c64-modul/&postID=1819848#post1819848 siehe F64 Beitrag]). Mit seiner Erlaubnis verlinke ich die STL Dateien im 'Links' Bereich.
+
Zusammenfassung System Bit:
  
 +
* ein Interrupt setzt das System Bit, die MMU wechselt in den System Modus
  
 +
* im System Modus ist immer der Task# 0 (System Task) aktiv
  
<gallery mode="traditional" widths=90px heights=90px perrow=9 caption="">
+
* im System Modus ist die System Memory Map aktiv
Image:UC-Cover-01.jpg
+
 
Image:UC-Cover-02.jpg
+
* im System Modus ist hat man Zugriff auf die MMU Register und das Mapping RAM
Image:UC-Cover-03.jpg
 
</gallery>
 
  
 +
* das System Bit wird zurück gesetzt, sobald man das FUSE Register beschreibt und der FUSE Counter null erreicht
  
  
 
<br />
 
<br />
 +
=== Benutzer Modus ===
  
== News ==
+
Der Benutzermodus ist quasi der 'Normalbetrieb'. Die CPU führt einen Benutzer Task aus und ist auf die eingestellte Memory MAP beschränkt. Die MMU Register und das Mapping RAM sind nicht im Zugriff, ja sogar vollkommen unsichtbar. Der MMU Speicherbereich ist komplett nutzbar durch die eingestellte Page.
 +
 
 +
Im Benutzermodus kann das OS aufgerufen werden durch einen Software Interrupt (SWI Befehl).
 +
 
 +
Hardware Interrupts werden durch das OS bedient. Es funktioniert im Prinzip genau wie ein Taskwechsel.
  
* 11.06.2021 -- Prototyp der UC1
+
DMA Zugriffe funktionieren auch ohne Hilfe des OS. Während eines DMA Zugriff wechselt die MMU automatisch in den Task# 1. Die externe Hardware 'sieht' die Memory MAP der Task# 1 die durch das OS konfiguriert wurde.
* 14.07.2021 -- Release der UC1
 
* 20.09.2021 -- UC-2 voll funktionsfähig
 
* 23.09.2021 -- UC-1.1 Prototyp
 
* 01.10.2021 -- Release UC-Builder v1.07
 
* 08.10.2021 -- Release der UC2
 
* 29.10.2021 -- Release UC-Builder v1.10
 
* 13.01.2022 -- Release UC-Builder v1.11
 
  
 
<br />
 
<br />
  
== Downloads ==
+
=== Start Sequenz ===
 +
 
 +
Nach einem Reset fetched die CPU den RESET Vektor von der logischen Adresse $FFFE und führt den Code aus. Die MMU ist nach einem System RESET im [[MMU#Reset_Modus|Reset Modus]]. Die Adressleitungen PA11 bis PA23 sind high, daher wird der Reset Vektor gelesen von der physischen Adresse $FFFFFE in der obersten Page (Page 8191). Es läuft privilegierter Code, die MMU Konfig Register sind sichtbar an der Adresse $FF00 bis $FF7F.
 +
 
 +
Das erste was die CPU nun zu tun hat, ist die Konfiguration der MMU. Sonst hat man keinen Zugriff außerhalb der Page 8191. Die MMU bekommt nun die Konfiguration unter der NitrOS9 laufen kann. Dann wird der Kern Code gestartet. Je nach Art des NitrOS9 ist entweder das gesamte OS im ROM (20K) oder nur der Kern (4K).
 +
 
 +
 
 +
Konfiguration der MMU nach einem Reset:
 +
 
 +
* der Access Key ($FF4A) wird auf Task# 0 gestellt
 +
 
 +
* das Mapping RAM für Task# 0 wird beschrieben ($FF00 bis $FF3F)
  
* [https://www.dropbox.com/s/6c3nfel83yqz5zo/UC-Image-v1_06.zip?dl=1 UC-Builder v1.06 mit Beispiel Images und den Menü Sourcen]
+
* das Key Value Register KV-0 ($FF40) wird beschrieben, das beende den Reset Modus und aktiviert das Mapping
* [[Media:UC-Builder.zip|Aktuelle Version des UC-Builder: v1.11]]
 
* [[Media:UC-Builder-n.zip|Bugfix Version des UC-Builder: RC1.12]]
 
  
* [[Media:Multimax-UC2-UC1.5.zip|MultiMax Image für die UC-1.5 und UC-2]]
+
* nun kann die Kontrolle dem OS übergeben werden
* [[Media:Pop512.zip|'Prince of Persia' Image für UC2 (dazu benötigt wird das EF Jedec)]]
 
  
 
<br />
 
<br />
  
== Links ==
+
== News ==
 +
 
 +
* 12.11.2022 -- NitrOS9 Level 1 läuft
 +
* 10.08.2022 -- CUBIX läuft
 +
* 08.09.2022 -- FLEX läuft
 +
* 19.07.2022 -- OS9 Board mit MMU-16 läuft
 +
* 23.05.2022 -- OS9 Board mit MMU 6829 läuft
 +
* 19.05.2022 -- Teil-Inbetriebnahme OS9 Board (ohne MMU)
 +
* 29.04.2022 -- Layout des OS9 Board
 +
* 13.03.2022 -- Aufbau und erste Versuche mit der ByteMachine
 +
 
 +
<br />
 +
 
 +
== Downloads ==
 +
 
 +
* [[Media:ByteMachine-Gerber-6309-P.zip|Gerber für das Basic CPU Board - 6309P]]
 +
* [[Media:ByteMachine-Gerber-6309EP.zip|Gerber für das Basic CPU Board - 6309EP]]
 +
* [[Media:ByteMachine-Gerber-6309P-EP.zip|Gerber für das 6309 universal CPU Board (6309P oder 6309EP)]]
  
* [[Universal_Cartridge_1|Handbuch zur UC-1]]
 
* [[Universal_Cartridge_1.5|Handbuch zur UC-1.5]]
 
* [[Universal_Cartridge_2|Handbuch zur UC-2]]
 
  
* [https://www.youtube.com/watch?v=qGbBArzOOa4 erstes YouTube Video zur UC-2 von '''RetroStuffRocks''']
 
* [https://www.youtube.com/watch?v=FORub4gcVZk zweites YouTube Video zum neuen Windows GUI '''RetroStuffRocks''']
 
  
* [https://www.kanda.com/products/Kanda/PLD-BOARD.html Kanda PLD Training Board - GAL16v8]
+
<br />
* [https://www.microchip.com/en-us/development-tool/ATF15XX-DK3-U Microchip DK3 Dev Board (für ATF-1504)]
 
* [https://www.microchip.com/en-us/development-tool/ATDH1150USB Microchip USB Programmer (für ATF-1504)]
 
* [[ATF150x|die Programmierung des ATF-1504]]
 
* [http://www.harries.dk/files/C64MemoryMaps.pdf C64 Banking (PDF)]
 
* [https://www.c64-wiki.de/wiki/Max_Machine Commodore MAX Machine]
 
* [https://www.c64-wiki.de/wiki/Expansionsport C64 Cartridge Port]
 
* [https://www.c64-wiki.de/wiki/Expansionsport_(Max_Machine) Max Machine Cartridge Port]
 
* [http://www.multimax.co/ MultiMAX Cartridge]
 
  
* [https://vice-emu.sourceforge.io/vice_15.html VICE Doku zu CARTCONV]
+
== Links ==
* [http://unusedino.de/ec64/technical/formats/crt.html Doku zu CRT Datei Format (EC64)]
 
* [https://fossies.org/linux/vice/src/cartridge.h Liste der CRT CartTypes]
 
* [https://codebase64.org/doku.php?id=base:crt_file_format Doku zu CRT Datei Format (Codebase)]
 
* [https://skoe.de/easyflash/files/devdocs/EasyFlash-ProgRef.pdf EasyFlash Entwickler Doku]
 
* [https://codebase64.org/doku.php?id=base:code_sample EasyFlash Sample Code]
 
* [https://github.com/msolajic/c64-magic-desk-1024k 1MB Magic-Desk Doku]
 
  
* [https://www.printables.com/de/model/168706-universal-cartridge-15-rev5 STL Datei - UC-1.5 Rev.5 (Danke an Goodwell vom F64)]
+
* [https://github.com/c0pperdragon/ByteMachine Die ByteMachine (GITHUB Repository)]
* [https://www.printables.com/de/model/168127-universal-cartridge-2-rev4 STL Datei - UC-2 Rev.4 (Danke an Goodwell vom F64)]
+
* [[MMU|MMU (Memory Management Unit)]]
 +
* [http://www.nitros9.org/documents.html NitrOS9 Doku]
 +
* [https://github.com/n6il/nitros9 NitrOS9 on GIThub]
 +
* [https://sourceforge.net/projects/nitros9/ NitrOS9 on SourceForge]

Aktuelle Version vom 20. Januar 2023, 15:43 Uhr

OS9 Board


Mikro Computer Board

Das Ziel ist ein vollständiges Computer System auf Basis einer MC6809 bzw. einer HD6309 CPU mit NitrOS9 als Betriebssystem.



Das ByteMachine Board

Aller Anfang ist schwer, deswegen habe ich das CPU Board nicht von Grund auf selbst entwickelt. Statt dessen habe ich meine ersten Schritte mit dem Nachbau eines funktionierenden CPU Boards gemacht: die ByteMachine

Im GITHUB gibt es das Projekt die ByteMachine von dem GIT User c0pperdragon. Die ByteMachine besticht durch ihre grandiose Einfachheit kombiniert mit enorm großer Flexibilität.


Die ByteMachine besteht aus drei Komponenten:

  • CPU Board
  • Mainboard: SRAM, EEPROM, Taktgenerator, Reset Signal, 8 LED und 8 digitale Eingänge
  • optionales IO Board: serielle Schnittstelle und SD Karte


Jede 8 Bit CPU benötigt dieselben Komponenten für ein lauffähiges System. Daher macht es Sinn, die gemeinsamen Komponenten auf ein eigenes Board zu legen. Das CPU Board macht nur die Anpassung für das Mainboard der ByteMachine. Das IO Board ist optional und wird ggf. auf das Mainboard gesteckt.


Das Mainboard der ByteMachine hat zwei Schnittstellen, eine zum CPU Board und eine zum IO Board. Das CPU Board sowie das optionale IO Board werden einfach auf das Mainboard aufgesteckt. Man kann die CPU aber auch einfach in ein Steckbrett setzen und die Verbindung zum Mainboard über Steckdrähte herstellen.


Die Schnittstelle zwischen CPU Board und Mainboard ist eine Stiftleiste mit 34 Pins. Über die Schnittstelle wird das CPU Board versorgt mit Strom, Takt und Reset. Das CPU Board kontrolliert die restlichen Komponenten über die Schnittstelle. Jede CPU benötigt eine minimale Anpassung um Kompatibilität zur Mainboard Schnittstelle herzustellen.


Das IO Board ist optional. Es bietet eine serielle Schnittstelle und den Anschluss einer SD Karte. Allerdings hat das IO Board keinerlei 'Intelligenz': Sowohl die serielle Schnittstelle als auch die SD Karte werden nur über digitale IO getrieben (Soft UART und SD-Card Bit-Bang). Das IO Board wird einfach auf das Mainboard aufgesteckt, dazu dienen sie Stiftleisten auf der rechten Seite: 8 digitale Ausgänge, 8 digitale Eingänge und Stromversorgung.


Für die ByteMachine existieren 4 CPU Boards im GITHUB:

  • W65C02 mit 10 bis 16 MHz
  • W65C816 mit 10 bis 16 MHz
  • Z84C00
  • i8088


Für die ByteMachine habe ich 4 weitere CPU Boards entwickelt:

  • Motorola 6809P mit 1 bis 3 MHz
  • Motorola 6809EP mit 1 bis 3 MHz
  • Motorola 63C09P mit MMU 6829
  • Motorola 63C09EP mit MMU-16


Es existieren Schaltbilder, Doku und Platinen Layout für jedes CPU Board. Außerdem gibt es im ROM des Mainboard für jede CPU ein Testprogramm. Das Testprogramm zeigt über die LED des Mainboard an, dass die Hardware richtig funktioniert. Es braucht nur ein EPROM am Mainboard, denn jede CPU hat ihren eigenen Speicherbereich in dem 512K großen EPROM Speicher.

Wenn man eine neue CPU an das Mainboard der Bytemachine anschließen möchte, dann genügen ein Steckbrett und ein paar Verbindungsdrähte. Das macht dieses Konzept so wunderbar flexibel.


OS9 CPU Boards

Auf dem NitrOS9 Board läuft eine Motorola CPU 6809 mit 3MHz. Alternativ kann auch eine Hitachi 6309 verwendet werden, diese CPU ist PIN kompatibel und Binärcode kompatibel. Hitachi hat aber viele Verbesserungen im Design der 6309 einfließen lassen. Die 6309 ist schneller, hat mehr Register, kann 32 Bit Operationen ausführen und hat zusätzliche Befehle.

Die 6309 gibt es in verschiedenen Versionen. Je nach 'Speed-Grade' der CPU ist die maximale (interne) Taktfrequenz 1, 1.5, 2 oder 3 MHz. Zudem gibt die Typen P und EP, der Unterschied ist die Taktsteuerung. Die P Typen erzeugen den Takt intern aus einem 4 fachen Grundtakt (12MHz für eine 3MHz 6309P). Die EP Typen brauchen einen externen Takt, den man mit externer Elektronik bilden muss. Bei beiden Typen steuert die CPU die äußere Beschaltung mit zwei Taktleitungen: E und Q. Die Takte E und Q sind 90° phasenverschoben. Das E Signal ist ähnlich dem PHI2 bei der 6502 CPU, man erkennt aus dem Signal die Gültigkeit der Daten am Adressbus.


Basierend auf der Doku des W65C02 Board für die ByteMachine, habe ich drei CPU Boards entwickelt. Eines für die 6309P, eines für die 6309EP und eines wo man beide CPU Typen (P und EP) verwenden kann:



Die CPU Boards laufen extrem stabil. Die Taktfrequenz ist sehr flexibel, die 63C09P läuft stabil mit 1, 2, oder 3 MHz. Versuche die CPU zu übertakten sind erfolgreich, bei 4 MHz ist keine Erwärmung feststellbar und es läuft seit einigen Tagen fehlerfrei durch. Eine 63B09EP läuft tadellos mit 2,5 MHz.


IO Boards

Das Mainboard der Byte Machine stellt 8 digitale Ausgänge und 8 digitale Eingänge zur Verfügung. Im GitHub existiert zudem ein aufsteckbares IO Board, das eine serielle Schnittstelle sowie den eine SD Karte bietet (IOexpander).

Leider ist sowohl die serielle Schnittstelle als auch die SD Karte nur an den digitalen IO des Mainboard angeschlossen. Es gibt keinerlei Hardware Unterstützung. Die serielle Schnittstelle ist eine reine Software basierte Lösung (Soft-UART). Die SD Karte wird ebenso per Bit-Bang bedient, was es extrem langsam macht und die Software ist sehr aufwendig.


Deswegen habe ich eigene IO Boards entwickelt:

  • IO Test Board mit 15 LED (zum Test des IO Port und Software Entwicklung)
  • UART Board auf Basis eines TL16C550 (serielle Kommunikation bis 115200Bd)
  • Nano IO Board mit UART und SD Card auf Basis eines Arduino Nano



Alle diese IO Boards verwenden einen IO Port zum Anschluss auf einem CPU Board. Es braucht dazu spezielle, erweiterte CPU Boards, die Standard CPU Boards der Byte Machine haben keinen IO Port. Die IO Ports werden einfach auf den neuen CPU Boards aufgesteckt, quasi als dritte Ebene.


Das IO Test Board hat 15 LED, mit einem geeigneten Test Programm kann damit die korrekte Funktion des IO Port überprüfen.

Die LED-0 bis 7 zeigen den Zustand der Datenleitungen D0 bis D7 bei einem Schreibzugriff auf einen IO Bereich IO-0.

Die LED IO-0 bis IO-6 zeigen den letzten Zugriff auf den zugehörigen IO-Bereich. Bei einem Lesezugriff wird die LED ausgeschaltet und bei einem Schreibzugriff eingeschaltet.



Erweiterte CPU Boards

Die erweiterten CPU Boards stecken auf dem Byte Machine Mainboard, genau wie die Basis CPU Boards. Aber sie bieten erweiterte Funktionalität die über eine reine CPU Funktion hinaus geht:

  • IO Port zum Anschluss von bis zu 8 IO Boards
  • optional: Banking Funktion um den ganzen Mainboard Speicher zugreifen zu können
  • optional: Speicher Management (MMU) um den Adressraum über einem MB verwalten zu können
  • optional: Interrupt Managment
  • optional: DMA Funktionalität


Es sind folgende CPU Boards in Entwicklung:

  • W65C02 mit 16MHz und Banking (4 x 16K in einem MB)
  • 6309 CPU mit MMU 6829 (32 x 2K in zwei MB)
  • 6309 CPU mit MMU-16 (32 x 2K in 16 MB)



Auf diese erweiterten CPU Boards können die IO Boards aufgesteckt werden. Damit hat man eine schnelle serielle Kommunikation und einen effizienten Zugriff auf eine SD Karte.

Das 6309 Board mit der MMU hat eine hoch effiziente Speicher Verwaltung, einen Adressraum von 2 MB und separate IO Bereiche. Zusammen mit dem Nano IO Board hat man eine Verbindung zur Außenwelt (Terminal) und einen 'Massenspeicher'. Damit ist es schon eine gute Basis, auf der man problemlos ein NitrOS9 Level II implementieren kann.


Die Hardware

Die Hardware ist wie im vorhergehenden Kapitel beschrieben:

  • ein Byte Machine Mainboard mit 512K SRAM und 512K FLASH
  • ein erweitertes CPU Board (6309 + MMU)
  • ein Nano IO Board mit serieller COM und SD Karte
  • optional SRAM Boards 512K bis 15MB RAM


Eventuell wird es auch eine SBC (Single Board Computer) Version davon geben (NitrOS9 SBC), wo alles auf einer Platine vereint ist.



Memory MAP

Der physikalische Adressraum hat eine Größe von einem oder mehreren Megabytes. Dem gegenüber steht eine CPU die nur 64K adressieren kann (logischer Adressraum). Diese Diskrepanz wird gelöst durch den Einsatz einer MMU (Memory Management Unit).


Bei der MMU von Motorola (MC6829) hat der physikalische Adressraum eine Größe von 2MB und ist in 1024 Seiten (Pages) zu je 2K (Page $000 bis $3FF) unterteilt.

Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.

Bei der MMU-16 hat der physikalische Adressraum eine Größe von 16MB und ist in 8192 Seiten (Pages) zu je 2K (Page $000 bis $1FFF) unterteilt.


Beide MMU splitten den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.


Es sind 32 Blöcke die einer Page zugeordnet werden. Dazu gibt es 32 Zeiger zu je 10 Bit (MMU 6829) bzw. 16 Bit (MMU-16). Es sind also zwei Bytes pro Page (insgesamt 64 Bytes), die eine ganze Speicherbelegung (Memory Map) beschreiben.

Die Memory MAP ist also ein komplette 'Sicht' auf den logischen Adressraum von 64K. Das ermöglicht einen sehr flexiblen Zugriff auf den gesamten physikalischen Adressraum. Zudem kann das Block Mapping dynamisch verändert werden, sodass die CPU stets die gerade wichtigen Teile des physikalischen Adressraum im Zugriff hat.


Memory MAP bei der MMU 6829


Memory MAP bei der MMU-16


Speicher Management (MMU)

Das NitrOS9 Level 2 hat bestimmte Anforderungen an die Hardware. Neben den Mindestanforderungen von 128K RAM sollte auch das Banking bestimmten Anforderungen entsprechen. Der Grund ist die Multitasking Fähigkeit von NitrOS9, das erfordert eine blitzschnelle Umschaltung zwischen verschiedenen Speicherbelegungen (Memory Maps).

In einem NitrOS9 System gibt es mehr als eine Memory MAP. Es ist sinnvoll, dass das OS andere Teile des physikalischen Adressraum sieht als ein Benutzer Programm. Zudem ist NitrOS9 in der Lage mehrere Benutzer Programme quasi gleichzeitig laufen zu lassen (Multi Tasking). Es gibt also mehrere Memory MAPs für das OS, für Treiber und für mehrere Benutzer Programme. Deshalb wird eine bestimmte Memory MAP als 'Task' bezeichnet.

Jeder Task beschreibt also eine ganze Memory MAP. Eine Memory MAP besteht technisch gesehen aus x Zeiger in den physikalischen Adressraum (für jeden Block ein Zeiger). Jeder Zeiger enthält die Nummer der zugeordneten Page, also eine Zahl zwischen 0 und 1023 (10 Bit bei der MMU 6829) bzw. zwischen 0 und 8191 (13 +3 Bit bei der MMU-16). Die Zeiger sind dynamisch änderbar, also quasi ein RAM Speicher aus Sicht der CPU. Die MMU benötigt also 64 Byte RAM Speicher pro Task.

Das Multitasking ist natürlich nicht wirklich eine 'gleichzeitige' Ausführung von Programmen. Selbstverständlich wird immer nur ein Programm nach dem anderen ausgeführt. Um das Gefühl von gleichzeitig zu bekommen, wechselt die Ausführung der verschiedenen Tasks relativ häufig (zig mal pro Sekunde). Nun hat jeder Task seine eigene Memory MAP bestehend aus 64 Zeiger in den physikalischen Adressraum. Dank MMU muss das OS aber nur einen Schreibzugriff ausführen, um einen Task Wechsel zu veranlassen. Dazu stellt die MMU ein TASK-Register zur Verfügung.

Unter NitrOS9 werden alle Interrupts der CPU vom OS ausgeführt. Das bedeutet einen Task Wechsel in der MMU für jeden einzelnen Interrupt. Und natürlich einen Taskwechsel zurück zum Task der vorher eingestellt war. Das NitrOS9 läuft dabei immer auf Task #0.



MMU Motorola 6829

Die MMU-6829 verwaltet einen physikalische Adressraum mit einer Größe von 2MB. Der physikalische Adressraum ist in 1024 Seiten (Pages) zu je 2K (Page $000 bis $3FF) unterteilt.

Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.

Es sind 32 Blöcke die einem der 1024 Pages zugeordnet werden. Dazu gibt es 32 Zeiger zu je 10 Bit (zwei Bytes), also insgesamt 64 Bytes, die eine ganze Speicherbelegung (Memory Map) beschreiben. Die MMU-6829 stellt vier Tasks (vier MAPs) zur Verfügung. Das Mapping RAM hat also eine Größe von insgesamt 256 Bytes (64 mal 4).


Näheres zu dieser MMU findet man hier.



Die MMU-16

Die Motorola MMU 6829 ist heutzutage kaum noch zu bekommen. Aus diesem Grund wurde die MMU-16 entwickelt. Die Arbeitsweise und die Register der MMU-16 sind kompatibel zur Motorola 6829. Alle Bauteile sind auch heutzutage noch gut erhältlich.


Die MMU-16 verwaltet einen physikalische Adressraum mit einer Größe von 16MB. Der physikalische Adressraum ist in 8192 Seiten (Pages) zu je 2K (Page $0000 bis $1FFF) unterteilt.

Diese MMU splittet den logischen Adressraum (64K) auf in 32 Blöcke zu je 2K. Jeder dieser 2K großen Blöcke kann nun irgendwo im physikalischen Adressraum liegen (in 2K Schritten). Es erfolgt also eine Zuordnung von Block zu Page.

Es sind 32 Blöcke die einem der 8192 Pages zugeordnet werden. Dazu gibt es 32 Zeiger zu je 13 Bit (zwei Bytes), also insgesamt 64 Bytes, die eine ganze Speicherbelegung (Memory Map) beschreiben. Die MMU-16 stellt 256 Tasks (256 MAPs) zur Verfügung. Das Mapping RAM hat also eine Größe von 2 mal 8KB (64 mal 256).


Näheres zu dieser MMU findet man hier.



Speicher Schutz

Wenn nur ein Programm läuft, dann braucht man keinen besonderen Schutz des Speicherraum. Ganz anders ist es, wenn man mehrere Programme gleichzeitig laufen lässt (Multitasking). Es erhöht die Stabilität des System ungemein, wenn jedes Programm nur 'seinen eigenen Speicher' im Zugriff hat.

Das gilt insbesondere auch für den Speicher des Betriebssystem selbst. Wenn Benutzerprogramm in den Speicherbereich des NitrOS9 schreiben können, dann kann es zu Problemen und Abstürze kommen.

All Ressourcen im System (Bildschirm, IO, Massenspeicher, Kommunikation ...) können bei einer Motorola CPU nur als quasi 'Speicher' zugegriffen werden. Daher ist eine Speicherschutz auch glz. ein Schutz aller Ressourcen im System. Zum Beispiel der Bildschirm RAM, wenn da zwei Programme glz. hinein schreiben, dann wird es wahrscheinlich chaotisch aussehen am Bildschirm den Benutzer.


Nun kann die CPU ja nur ihren logischen Adressraum zugreifen. Daraus folgt, die CPU kann im physikalischen Adressraum nur zugeordnete Pages verändern. Letztlich muss also nur der Zugriff auf die MMU selbst beschränkt werden, um einen Speicherschutz zu erreichen.

Bei der MMU 6829 ist der Zugriff auf die MMU nur im Task #0 möglich. Task #0 ist also der System Task, der die alleinige Kontrolle über das Page Mapping hat. Der Speicherschutz ist folglich alleinige Aufgabe des OS. Das NitrOS9 kann sensible Speicherbereiche einem Programm zuordnen oder eben nicht.


Maximale Speicher Nutzung

Unter NitrOS9 Level 1 hatte man nie den vollen logischen Adressraum zur Verfügung. In jedem Fall musste stets ein ROM im obersten Ende des Speicher sein, weil da die Vektoren für Interrupts und SWI stehen und auch der Code dafür musste stets im Zugriff stehen.

Dank MMU und NitrOS9 Level 2 kann nun jeder Task die gesamten 64K voll RAM haben. Es wird kein einziges Byte verschwendet für ROM oder IO.


Möglich wird das durch eine besondere Fähigkeit der MMU, die selbstständig beim Aufruf einen OS9 Service (SWI) oder eines Interrupts automatisch in den System Task #0 schalten kann. Dazu stellt die CPU eigene Signale zur Verfügung, die ermöglichen der MMU die Erkennung, was die CPU gerade so macht. Im Falle eines Interrupt werden die Register auf den User Stack geschrieben, dann schaltet die MMU automatisch auf den Task #0, wodurch das System ROM sichtbar wird. Die CPU lädt den Interrupt Vektor aus dem System ROM und führt den Code aus.


Jeder Benutzer Task kann zusätzlichen RAM anfordern vom OS. Über einen Banking Bereich kann man so auch mehr als 64K Speicher zur Verfügung haben. Man kann RAM teilen mit mit anderen Tasks (gemeinsame RAM Bereiche). Es braucht keinen Platz für IO und keinen ROM Bereich in der Memory MAP eines Benutzer Task, es ist aber optional trotzdem noch möglich.

Der Benutzer Speicher ist geschützt vor Zugriffe eines anderen Benutzer Task. Alles Speicherbereiche des OS und die IO Bereiche sind geschützt vor den Benutzer Tasks.


Spezielle Funktionen der MMU

Durch spezielle Steuersignale von der CPU erkennt die MMU automatisch einen Reset, einen Interrupt (IRQ) oder einen SWI Befehl. Der Task Wechsel ist ein sensibler und komplexer Vorgang. Durch die Änderung der Speicher MAP ändert sich ja unter Umständen gänzlich alles, auch der Stack und User Stack liegt plötzlich an einer ganz anderen physikalischen Adresse. Die MMU zählt CPU Takte, damit die Umschaltung der Speicher MAP immer an dem exakt definierten Zeitpunkt statt findet.

Der Wechsel zum System Task #0 erfolgt voll automatisch. Die CPU sichert die Register noch in der User MAP und fetched die Vektoren bereits in der System MAP. Dann wird der Code des OS bzw. einer Modul (Hardware Treiber) ausgeführt. Die Rückkehr zum User Task erfolgt in der Regel durch ein RTI. Da muss der RTI Befehl noch aus der System MAP gelesen werden, die Rücksicherung der Register muss aber bereits vom Stack des Benutzer Task erfolgen. Der Zeitpunkt des Task Wechsel in der MMU ist sehr sensibel. Zum Glück übernimmt das NitrOS9 diese Aufgabe.


Der Schutz des OS vor Benutzer Code und der Schutz des Benutzer Code vor anderem Benutzer Code erfolgt nur durch das Paging. Der Schlüssel dazu ist die Konfiguration der MMU. Deshalb kann die MMU Konfiguration nur verändert werden durch "privilegierten Code". Die MMU Register sowie der Paging RAM können nur verändert werden, wenn der Task #0 aktiv ist. Mit anderen Worten, für DMA und Benutzerprogramme ist die MMU unsichtbar.

Nach einem Reset ist die MMU in einem speziellen Modus. Die Adressleitungen PA11 bis PA20 sind high, daher muss das Start ROM im oberen Ende des physikalischen Adressraum liegen. Da liegen auch die MMU Register und der MMU RAM. Bei der NitrOS9 Platine liegt die MMU an der Adresse 1FFF00 bis 1FFF7F (128 Bytes). Es ist egal ob die MMU Register sichtbar sind oder nicht, in diesem Adressbereich ist das ROM immer ausgeblendet.

Selbst wenn es einem Benutzer Programm gelingt, die Page 1023 einzublenden und so Zugriff auf den Adressen Bereich 1FFF00 bis 1FFF7F zu erlangen, kann das Programm die MMU nicht zugreifen (MMU ist unsichtbar).

Die MMU Hardware ist wasserdicht, der Speicher ist perfekt geschützt. Nur wenn das OS einen Zugriff erlaubt, hat das Benutzerprogramm einen Zugriff. Die Schwachstelle ist also immer das OS, eine Schadsoftware könnte aber theoretisch Fehler im Systemcode nutzen. Im Normalfall läuft der Benutzer Code in einer sichern Blase, quasi eine virtuelle Umgebung. Es läuft in seiner virtuellen Speicher Welt, die das OS eingestellt hat, und kommt nicht heraus.

Das Konzept mit der MMU geht schon in die Richtung, die beim PC erst seit dem Intel 386 funktionieren. Der Intel Prozessor ist natürlich 16/32 Bit breit, und hat das ganze Paging voll integriert in der CPU. Aber im Grunde gab es das schon Jahre vorher.



Inbetriebnahme

Voraussetzung ist ein sauber funktionierendes Byte Machine mit 12MHz Quarz (bei einer 3MHz CPU - 68C09P). Die Funktion des Mainboard kann man mit jedem CPU Board testen (Knight Rider Test Code).



Inbetriebnahme MMU 6829

Das OS9 Board mit MMU-6829 wird bestückt. Das GAL 22v10 muss mit dem korrekten JEDEC beschrieben werden (zB. mit einem TL866 Programmer). Bei 12MHz Systemtakt sollte die CPU ein C Typ sein (63C09P), für andere CPU Typen (1, 1.5 und 2 MHz) muss die Frequenz des Quarz entsprechend angepasst werden.


Das Board kann zunächst ohne MMU getestet werden, dazu bastelt man sich einen kleinen Adapter aus einem Sockel mit sieben Drähten (siehe Fotos). Der Adapter verdrahtet eine fixe Memory MAP, die kompatibel ist zu den einfachen CPU Boards. Damit wird der Standard Test Code an der EPROM Adresse $5FD00 (physikalische Adresse $1FFC00) ausgeführt. Wenn der GAL richtig programmiert wurde, dann sollte die Knight Rider Animation laufen (genau wie bei den einfachen CPU Boards).

Mit MMU braucht man dann ein anderes EPROM auf dem Byte Machine Mainboard. Der Standard Byte Machine ROM wird ersetzt durch einen eigenen OS9 EPROM. Die MMU schaltet nach einem Reset alle Adressleitungen auf high, wodurch nur noch die oberste Page sichtbar ist (physikalische Adresse $1FFF800-$1FFFFFF). Deswegen muss der Reset Code ganz am oberen Ende des EPROM liegen (EPROM Adresse $7F800-$7FFFF). Die Reset Routine muss zu aller erst die MMU konfigurieren, damit RAM und IO sichtbar werden im Adressraum der CPU.




Inbetriebnahme MMU-16

Das OS9 Board mit MMU-16 wird bestückt. Die beiden Atmel CPLD's ATF-1504 werden über JTAG mit der aktuellen Firmware programmiert. Bei 12MHz Systemtakt sollte die CPU ein C Typ sein (63C09EP), für andere CPU Typen (1, 1.5 und 2 MHz) muss die Frequenz des Quarz entsprechend angepasst werden.


Der Standard Test Code wird an der EPROM Adresse $5FD00 (physikalische Adresse $1FFC00) ausgeführt. Wenn die beiden CPLD richtig programmiert wurden, dann sollte die Knight Rider Animation laufen (genau wie bei den einfachen CPU Boards).

Für den Einsatz von OS9 braucht man dann ein eigenes EPROM. Die obersten 8KB des EPROM enthalten den NitrOS9 Startcode (REL + KERNAL). Die MMU schaltet nach einem Reset alle Adressleitungen auf high, wodurch nur noch die oberste Page sichtbar ist (physikalische Adresse $1FFF800-$1FFFFFF). Deswegen muss der Reset Code ganz am oberen Ende des EPROM liegen (EPROM Adresse $7F800-$7FFFF). Die Reset Routine muss zu aller erst die MMU konfigurieren, damit RAM und IO sichtbar werden im Adressraum der CPU. Danach wird der NitrOS Startcode kopiert in den RAM an der logischen Adress2 $2800. Dann wird REL gestartet an der Adresse $2802.




Das Betriebssystem

Das einzige Betriebssystem, das eine MMU unterstützt, ist OS9 ab Level 2. Daher habe ich NitrOS9 Level 2 angepasst für mein NitrOS9 Board mit MMU-16. Die Basis dafür ist der Quellcode des NitrOS9 für den großartigen Positron 9000 Computer.



Reset Modus

Durch einen Hardware Reset wird in der MMU das Reset Bit gesetzt. Die MMU ist dann in einem speziellen Modus: Reset Modus

Das Reset Bit ist notwendig, weil das Mapping RAM nach dem einschalten einen nicht definierten Inhalt hat. Dadurch wäre das ganze System in einem undefinierten Zustand und könnte nicht richtig gestartet werden.


Zusammenfassung Reset Bit:

  • das Reset Signal setzt das Reset Bit, die MMU ist im Reset Modus
  • im Reset Modus ist das Mapping RAM inaktiv, alle physikalischen Adressleitungen sind high
  • im Reset Modus kann das Mapping RAM beschrieben werden, wie im SU Modus
  • das Reset Bit wird zurück gesetzt, sobald man da OP-Key Register beschreibt



System Modus

Durch einen Interrupt (Hardware oder Software Interrupt) wird in der MMU das System Bit gesetzt. Die MMU wechselt dadurch automatisch in den System Modus (oder auch Super User Modus). Solange das System Bit gesetzt ist, ist die MMU immer Task# 0 (System Task). Die Memory Map ist die System Map und die MMU Register sind im Zugriff. Normalerweise wird nun Betriebssystem Code ausgeführt. Das System Bit wird zurückgesetzt, indem man einen Task Wechsel zu einem Benutzer Task durchführt.


Zusammenfassung System Bit:

  • ein Interrupt setzt das System Bit, die MMU wechselt in den System Modus
  • im System Modus ist immer der Task# 0 (System Task) aktiv
  • im System Modus ist die System Memory Map aktiv
  • im System Modus ist hat man Zugriff auf die MMU Register und das Mapping RAM
  • das System Bit wird zurück gesetzt, sobald man das FUSE Register beschreibt und der FUSE Counter null erreicht



Benutzer Modus

Der Benutzermodus ist quasi der 'Normalbetrieb'. Die CPU führt einen Benutzer Task aus und ist auf die eingestellte Memory MAP beschränkt. Die MMU Register und das Mapping RAM sind nicht im Zugriff, ja sogar vollkommen unsichtbar. Der MMU Speicherbereich ist komplett nutzbar durch die eingestellte Page.

Im Benutzermodus kann das OS aufgerufen werden durch einen Software Interrupt (SWI Befehl).

Hardware Interrupts werden durch das OS bedient. Es funktioniert im Prinzip genau wie ein Taskwechsel.

DMA Zugriffe funktionieren auch ohne Hilfe des OS. Während eines DMA Zugriff wechselt die MMU automatisch in den Task# 1. Die externe Hardware 'sieht' die Memory MAP der Task# 1 die durch das OS konfiguriert wurde.


Start Sequenz

Nach einem Reset fetched die CPU den RESET Vektor von der logischen Adresse $FFFE und führt den Code aus. Die MMU ist nach einem System RESET im Reset Modus. Die Adressleitungen PA11 bis PA23 sind high, daher wird der Reset Vektor gelesen von der physischen Adresse $FFFFFE in der obersten Page (Page 8191). Es läuft privilegierter Code, die MMU Konfig Register sind sichtbar an der Adresse $FF00 bis $FF7F.

Das erste was die CPU nun zu tun hat, ist die Konfiguration der MMU. Sonst hat man keinen Zugriff außerhalb der Page 8191. Die MMU bekommt nun die Konfiguration unter der NitrOS9 laufen kann. Dann wird der Kern Code gestartet. Je nach Art des NitrOS9 ist entweder das gesamte OS im ROM (20K) oder nur der Kern (4K).


Konfiguration der MMU nach einem Reset:

  • der Access Key ($FF4A) wird auf Task# 0 gestellt
  • das Mapping RAM für Task# 0 wird beschrieben ($FF00 bis $FF3F)
  • das Key Value Register KV-0 ($FF40) wird beschrieben, das beende den Reset Modus und aktiviert das Mapping
  • nun kann die Kontrolle dem OS übergeben werden


News

  • 12.11.2022 -- NitrOS9 Level 1 läuft
  • 10.08.2022 -- CUBIX läuft
  • 08.09.2022 -- FLEX läuft
  • 19.07.2022 -- OS9 Board mit MMU-16 läuft
  • 23.05.2022 -- OS9 Board mit MMU 6829 läuft
  • 19.05.2022 -- Teil-Inbetriebnahme OS9 Board (ohne MMU)
  • 29.04.2022 -- Layout des OS9 Board
  • 13.03.2022 -- Aufbau und erste Versuche mit der ByteMachine


Downloads



Links