NKC Forum
Registrieren | FAQ | Suche | Wer ist online? | Mitgliederliste | Heutige Beiträge | Kalender | Einloggen



Autor Thema: 8/16 bit MMU - mal so rumgesponnen
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 19. Dezember 2020 20:34 (#1)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,

das ist kein konkretes Projekt, sondern nur so eine Idee, wie man eine zum NKC passende MMU für CP/M 3, MP/M und Fuzix bauen könnte.

Einführung

Der Adressraum von 8/16 Bit CPUs ist oft zu klein, so dass er extern
erweitert wird, um mehr als 64 KByte Speicher benutzen zu können.
Diese Erweiterung kann auf verschiedene Weise erfolgen.

Erweiterung mit Bänken

Das älteste Konzept ist ROM in der Startbank, um zu booten und später
in einer anderen Bank den vollen Adressbereich mit RAM benutzen zu können.

Eng damit verwandt ist die reine Erweiterung des Adressbusses um
zusätzliche Bits. Falls ein gemeinsamer Teil in allen Bänken benötigt
wird, werden die zusätzlichen Bits in Abhängigkeit der unteren Bits
gesetzt. Dabei ist die Steuerung der Bankadressen durch die 16 bit
Adressen und damit die Adresslage des festen Bereichs in der Hardware
verankert (statische Adressübersetzung). Es ist schwierig, das gesamte
vorhandene RAM zu benutzen, wenn der umschaltbare Bankbereich nicht die
Größe einer Zweierpotenz hat.

Das Design der BANKBOOT

Die BANKBOOT Karte teilt den Adressraum in zwei Teile auf: Der
Bootspeicher (32k) und banked Speicher (1 MB). Die Busleitung BANKEN
schaltet zwischen diesen Bereichen um (Banking enable). Es gibt keinen
gemeinsamen Speicher, sondern man kann in die untere Hälfte jeder Bank
den Bootspeicher einblenden. Aus dem Grund muss in der oberen Hälfte
jeder Bank etwas Speicher für den Interbanktransport reserviert werden, so
dass die Bänke nicht durchgehend benutzt werden können. Weiterhin müssen
Daten zwischen Bänken immer über einen Zwischenpuffer kopiert werden.

Da CP/M 3 gemeinsames RAM benötigt, wird eine Schaltungsänderung der
BANKBOOT oder der Speicherkarte selbst benötigt, durch die RAM verloren
geht, weil der nicht gemeinsame Speicherbereich keine Zweierpotenz als
Größe hat. Bei anderen Betriebssystemen gibt es die gleichen Probleme,
allerdings liegt der gemeinsame Bereich je nach Architektur an einer
anderen Stelle.

Erweiterung mit virtuellem Speicher

Das jüngere Verfahren ist die dynamische Adressübersetzung mit einer MMU
zwischen der CPU und dem Rest des Systems, die den Adressraum in Seiten
aufteilt, die beliebig abgebildet werden können. Ein gemeinsamer Bereich
an beliebiger Stelle ist durch entsprechende Adressübersetzung ebenso
möglich wie Teile von Bänken einzublenden, um Daten ohne Zwischenspeicher
zu kopieren.

Eine zentrale Frage ist die Größe der Speicherseiten. Je größer die
Seiten sind, um so mehr Speicher wird bei Prozessen verschwendet, die
nicht den gesamten Adressraum brauchen. Je kleiner die Seiten sind,
um so mehr Seiteneinträge müssen neu konfiguriert werden, um z.B.
einen Interrupt zu bearbeiten oder den Prozesskontext zu wechseln.
Die 6829 MMU benutzt 2 KByte Seiten und bietet Platz für 4 Seitentabellen.
Die 74LS612 MMU benutzt 4 KByte Seiten, d.h. ein voller Kontextwechsel
muss 16 Register neu beschreiben. Die PDP-11 benutzt 8 KByte Seiten
und kommt darum mit 8 Registern aus.

Moderne MMUs laden Seitentabellen bei Bedarf selbständig aus dem
Hauptspeicher und die Einträge haben oft ein Identifikationsfeld für
den Prozess, so dass bei einem Kontextwechsel nicht alles neu geladen
werden muss.

Die MMU16 als Ersatz

Um den Bauteilaufwand gering zu halten, bietet sich die Unterteilung in
16 K Pages an, wie sie bei vielen CP/M 3 Systemen üblich war. Mit vier
Registern zu je 8 Bit, die durch A14 und A15 selektiert werden, werden
A14-A21 generiert.

Es ist naheliegend, die BANKBOOT Karte durch eine MMU Karte mit einer
Adressübersetzungseinheit sowie eine modifizierte ROA zu ersetzen.
Die CPU Karte würde dann neben die MMU Karte gesteckt, wobei die
höherwertigen Adressleitungen von der CPU zur MMU verbunden werden,
die diese ihrerseits die abgebildeten Adressleitungen auf den Bus legt.

Bei der CPU68020 zeigte sich bereits der Bedarf nach mehr Adressleitungen
als A16-A19 der BANKBOOT und nicht benutzte Signale wurden identifiziert:
/M1 = A20
/REFRESH = A21
PI = A22
PO = A23

A22 und A23 wuerden mehr als 8 bit und damit mehr Zugriffe zum
Seitenwechsel brauchen. Bei einer gemeinsamen Seite erfordert
ein Kontextwechsel so nur drei OUT Zugriffe.

Alternativ wird BANKEN durch A20 gesteuert und A21 nicht benutzt, was
den Vorteil hat, dass die vorhandenen Speicherkarten nicht modifiziert
werden müssen und nur in der oberen Hälfte des Adressraums angesprochen
werden.

Noch eine Alternative wäre die Integration von MMU und Speicher auf
einer Karte, was aber vom Platz her sehr knapp wäre.

Design

Zwei 74HCT670 Register File ICs bilden A14-A17 und A18-A21. Die
Leseadressen werden mit dem virtuellen Adressbus der CPU angesteuert und
die Datenausgänge steuern den physischen Adressbus auf der anderen Seite
der MMU. Die Schreibadresse und die Schreibdatenleitungen werden als
IO Port angesprochen.

Das Resetsignal löscht ein Flipflop, welches die Adressübersetzer
deaktiviert und einen Bustreiber aktiviert, der A14 und A15 transparent
durchleitet und die höheren Adressen auf fest einstellbare Bits setzt.
Der erste Lesezugriff auf die Adressübersetzer setzt das Flipflop.

2x 670 Seitentabelle
1x 74 MMU Enable Flipflop
1x 245 Transparenz
1x 245 Adressbustreiber fuer Seitentabelle
1x 688 Dekodierung
1x 138 Dekodierung

Code von BANKBOOT fuer MMU umschreiben

bank[7]: 0 = Banking disabled: Untere Hälfte BANKBOOT, obere Hälfte
durch Banking bestimmt. (LED leuchtet)
1 = Banking enabled: Der gesamte Adressraum wird durch die Bank
bestimmt. (LED leuchtet nicht)

bank[3:0]: A16-A19 der Bank

Untere Hälfte BOOT-ROM einblenden:

OUT (0xc8),0x80

OUT (frame0),0
OUT (frame1),1

Untere Haelfte auch RAM einblenden:

OUT (0xc8),0

OUT (frame0),4
OUT (frame1),5

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: nicht gespeichert



| https://hschuetz.selfhost.eu | Boardregeln | Datenschutzerklärung


Tritanium Bulletin Board 1.8
© 2010–2021 Tritanium Scripts


Seite in 0,026585 Sekunden erstellt
15 Dateien verarbeitet
gzip Komprimierung eingeschaltet
1987,73 KiB Speichernutzung