Wie RAM-Erweiterung über 64 kiB beim 16-Bit-Adressbus?

[aths]

Viele Systeme mit 8-Bit-CPUs und 16-Bit-Adressbus sind mit über 64 kiB RAM ausrüstbar. Wie wird das realisiert? Ja ich weiß, mit "Bank Switching". Ich hätte es gerne etwas genauer. Gibt es da eine Art separate MMU? Kann man den Speicher irgendwie linear adressierbar machen? Wie puzzelt sich ansonsten die Applikation zusammen, welche Bank gerade wo eingeblendet ist (und achtet dabei darauf, nicht ausversehen ihren eigenen Code auszublenden? Oder ihren Stack, ... oder, oder, oder.)

[Tyson]

Ich gehe mal davon aus, dass du von 8-Bit Mikrocontrollern redest (Atmel, PIC, 80Cxyz, etc). Die Kunst liegt darin, es so hinzubekommen, dass kein Zugriff auf eine ausgeblendete Bank geht. Hier muss sich halt der Programmierer um alles kümmern. Wenn es dafür ne extra MMU gäbe, dann hättest du ja nicht mehr 16 Bit Addresslines sondern mehr (zb. 24).

Ich glaube auch das ausführbahrer Code nicht in nem "geswitchten" Bereich liegt, sondern der erweiterte Bereich einfach zum Speichern gedacht ist (zB. Messwerte).

Ne andere Möglichkeit wäre auch die Addresse aus 2x 16 Bit bestehen zu lassen. Dann dauert das Ansprechen auch doppelt so lange, aber dann kannst du 32 Bit ansprechen. Hängt dann aber davon ab, ob die CPU/Mikrocontroller das unterstützt.

Gruß Tyson

[ShadowXX]

Viele Systeme mit 8-Bit-CPUs und 16-Bit-Adressbus sind mit über 64 kiB RAM ausrüstbar. Wie wird das realisiert? Ja ich weiß, mit "Bank Switching". Ich hätte es gerne etwas genauer. Gibt es da eine Art separate MMU? Kann man den Speicher irgendwie linear adressierbar machen? Wie puzzelt sich ansonsten die Applikation zusammen, welche Bank gerade wo eingeblendet ist (und achtet dabei darauf, nicht ausversehen ihren eigenen Code auszublenden? Oder ihren Stack, ... oder, oder, oder.)
Guck mal du Informationen zum Commodore C128 bekommen kannst (sollte es im I-Net genug geben).

Da dürfte dann auch die Lösung des Problems dabei sein. Ich hatte mal eine Seite, wo genau diese beschreiben war, hab aber keine Ahnung mehr wie die Heisst.
AFAIR muss aber tatsächlich der Programmierer alles per Hand erledigen (also sorge dafür tragen, das die von dir erwähnten Probleme nicht auftauchen).

[ilPatrino]

um die segmentierung deines speichers mußt du dich imho selber kümmern.es gibt nur die schutzmechanismen, die du selber implementierst...

[DerRob]

Viele Systeme mit 8-Bit-CPUs und 16-Bit-Adressbus sind mit über 64 kiB RAM ausrüstbar. Wie wird das realisiert? Ja ich weiß, mit "Bank Switching". Ich hätte es gerne etwas genauer. Gibt es da eine Art separate MMU? Kann man den Speicher irgendwie linear adressierbar machen? Wie puzzelt sich ansonsten die Applikation zusammen, welche Bank gerade wo eingeblendet ist (und achtet dabei darauf, nicht ausversehen ihren eigenen Code auszublenden? Oder ihren Stack, ... oder, oder, oder.)
eine separate mmu gab es soweit ich weiß beim c128. der c64 hat die speicherbereiche (z.b. umschaltung zwischen rom und ram) dadurch gewechselt, daß man ein paar bits in adresse 0001 verändert hat (siehe z.b. hier (http://www.infinite-loop.at/Power64/Documentation/Power64-LiesMich/AD-Spezialbausteine.html) ganz unten)
schutzmechanismen gabs da aber keine. wenn der c64 also gerade ein paar befehle aus dem rom ausgeführt hat, und man schaltete den bereich auf ram um, hat sich der c64 ganz einfach aufgehängt :rolleyes:

[elianda]

Beim C128 geht das mit der MMU so, dass man 2x 64kB hat. Beim umschalten zwischen den Speicherbereichen muss sich das Programm in dem andren Speicherbereich fortsetzen. Im einfachsten Fall eine Kopie. Das ist zB fuer die Interruptbehandlung ein Muss, da bei einem Interrupt eine beliebige Speicherkonfiguration gerade aktiv sein kann.
Desweiteren gibt es im 8502 Modus im vorderen Speicherbereich eine Common Area, die fest in den ersten 64 kB liegt. Das heisst, wenn man auf die zweiten 64 kB umschaltet, bleiben die ersten paar kB gleich.
Die Dekodierung des Zugriffsmusters (zu welchem Chip ein Lese/Schreibzugriff geht) erfolgt direkt ueber die Adresse. Die Profile dafuer gibt die MMU vor. (Beim C64 die PLA).

Die REU nutzt eine andre Moeglichkeit. Dabei hat man 3 Counter, einen fuer den Speicher im Rechner und einen fuer den Speicher im RAM der REU. Der dritte Counter zaehlt die Bytes. Zusaetzlich hat man noch Steuerbits um einen der counter zu blocken. Damit kann man zB. einen Speicherbereich aus der REU in eine Speicherstelle im Rechner kopieren mit 1 Byte / Takt. Der Transfer erfolgt ueber DMA. Da man im RechnerRAM jede Speicherstelle beschreiben koennte, gibt es die Moeglichkeit den Transfer ueber einen gelatchten Schreibzugriff an Adresse $FF00 zu starten. Mit etwas mehr Logik kann man dann nicht nur aus der REU heraus und rein kopieren, sondern auch die Speicherbereiche austauschen.

Die GeoRAM nutzt die 2 verfuegbaren I/O Bereiche fuer externe Peripherie. In den einen I/O Bereich wird eine Seite a 256 Byte RAM aus dem Speicherpool der GeoRAM eingeblendet. Im andren I/O Bereich werden Bits dekodiert, die die Seitennummer vorgeben die gerade eingblendet wird. Der Nachteil ist, man verstopft sich so gleich beide I/O Bereiche die fuer externe Hardware vorgesehen sind.

Ansonsten gibt es natuerlich noch viele andre Moeglichkeiten, man kann ueber jeden Digital I/O Ausgang etwas dekodieren, das dann Speicher ROM/RAM in den vorgesehenen Bereichen einblendet. (/EXROM /GAME) usw.

[aths]

Meine konkreten Gedanken waren: Angenommen man hätte einen Homecomputer mit 16-Bit-Adressraum. Die 64 kiB Speicher wären so aufgeteilt: 16 kiB ROM, 16 kiB RAM für Bildschirmspeicher, 2x 16 kiB für freie Verwendung.

(Der Bildschirmspeicher ist auf 32 kiB umschaltbar so dass man nur 16 kiB für freie Verwendung hat. Im Textmodus wiederum ist der Bildschirmspeicher kleiner, so dass man mehr als 32 kiB frei hat.) (Gerade wenn der Homecomputer auch einen Modulschacht hat, wäre das brauchbar, da der Programmcode dann von einem ROM käme.)

Will man nun eine Speichererweiterung unterstützen, wäre die Frage, wie man das machen könnte.

[Gast]

als man seinerzeit auf der x86-Plattform mit der 16bit-Grenze zu kämpfen hatte, hat man sich doch mit dieser Geschichte mit den Segmenten beholfen, die man auch heute noch in Assembler-Code sieht. Warum macht man das nicht auch bei anderen 16bit-Plattformen?

[StefanV]

Wobei die x86er damals schon 20bit Adressraum hatten (reicht für 16MB RAM), z.B. der 80286...

[Legolas]

Wobei die x86er damals schon 20bit Adressraum hatten (reicht für 16MB RAM), z.B. der 80286... Der 8086 hatte einen 20Bit breiten Adressbus, mit dem er 1MB RAM adressieren kann. Der 286er hatte 24 Adressleitungen, mit dem er 16MB adressieren kann.

[elianda]

Trotzdem ist die Segmentierung eher eine Kruecke und blaest den Code auf. Fuer ein einfaches System reicht es sicher einfach die hinteren 8 / 16 / 32 KB zu mappen mit beliebigen ROM / RAM. Man kann sich sogar ueberlegen das mit R/W zu trennen, dass man fuer schreiben einen andren Bereich vorgibt als fuer lesen. Das macht zB Sinn wenn man in einen der mapbaren Bereiche den Videospeicher hat, dann kann man beim lesen ROM beim schreiben Video-RAM machen.
Wenn man keinen schnellen System zu Video RAM Transfer benoetigt, kann man sich auch ueberlegen den Video RAM extern zu machen und ueber I/O zu transferieren. Oder man macht ich etwas mehr Aufwand und implementiert sowas wie einen System zu Video RAM DMA. Das ist aber komplexer als es aussieht, da typischerweise der Display Controller zu beliebigen Zeiten einen Video DMA benoetigen koennte. (Typischerweise jede x-te Rasterzeile)