c128 - 256 KB // MMU Nachbau

Es gibt 64 Antworten in diesem Thema, welches 7.384 mal aufgerufen wurde. Der letzte Beitrag (12. Februar 2024 um 17:59) ist von Diddl.

  • Alles was den 128er aufwertet und dazu noch für jedermann der möchte schnörkellos realisierbar ist, gefällt mir.

    Vielleicht eine dumme Frage aber ich stelle sie trotzdem. Währe das ganze dann auch abwärtskompatibel oder kommt da dann ein weit abgewandeltes System raus womit vorhandene Software/ Hardware Probleme bekommt und Anpassungen notwendig würden?

    Solange man am Rom nichts ändert, wird alles kompatibel sein.

    Dann kommt es darauf an, was man ändert und wie.

    Mein Vorschlag: Das Basic in eine andere Bank verlegen, da der Zugriff zum Basicram immer nur über die Zerropage erfolgt, muß man nur die Bankadresse ändern. Zusätzlich kann man dann auch den Basicstart von $1C01 nach $0401 verlegen. Das wären 2kb mehr.

    Mann kann auch den Tastaturpuffer verlegen, da hier der Zugriff immer mit Config $00 auf $FF00 erfolgt, reicht es aus, wenn dieser unterhalb von $4000 liegt. Diesen könnte man dann auch auf 3 Zeilen erweitern, also von 160 Byte auf 240 Byte. Damit bekäme man zusätzlich 160 Byte in der Zerropage frei.

    Mit diesen Änderungen bleibt der C128 kompatibel, solange man nicht den zusätzlich gewonnenen Basic Speicher nutzt.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Es wäre zu schade, das zu verschenken.

    Da hast du vollkommen recht, irgendwie sollte man das zugreifbar machen.

    Die Frage ist nur wie, bzw. wie damit es auch real nutzbar ist.

    Der c128 "versteht" mit der aktuellen MMU ja Bank 0,1,2,3.

    Nun gäbe es dazu noch Bank 4,5,6,7.

    Vielleicht 4 Bit.

    Bit 0 schaltet Bank 0 / 4.

    Bit 1 schaltet Bank 1 / 5.

    Bit 2 schaltet Bank 2 / 6.

    Bit 3 schaltet Bank 3 / 7.

    Dann wäre man halbwegs flexibel?

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Solange man am Rom nichts ändert, wird alles kompatibel sein.

    Dann kommt es darauf an, was man ändert und wie.

    Hmmm, soweit habe ich jetzt gar nicht gedacht.

    Möchte ich zum jetzigen Zeitpunkt auch gar nicht ausarbeiten.


    Aber wenn BASIC 7 erweitern, dann würde ich gerne STRING Space auslagern.

    Zur Zeit ist es doch so, dass Bank 0 BASIC Code hat und Bank 1 Variable?

    Das finde ich sehr sinnvoll.

    Variable wachsen ja von "unten" nach "oben".

    Strings wachsen dynamisch von "oben" nach "unten".

    Das könnte man sicher sinnvoll trennen.

    Strings in Bank 2 verlegen.


    Theoretisch könnte man BASIC 7 Subroutinen in Bank 3 verlegen.

    Der GOSUB Befehl wechselt also die Code Bank auf 3.

    Der RETRUN Befehl wechselt ggf. zurück nach Bank 0.

    Oder man lagert den BASIC Stack aus.

    Wobei 64K etwas üppig sind ...

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Vor allem wäre das kompatibel.

    "Ausgangszustand" ist, alle Bits in Richtung 0/1/2/3.

  • $D500:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bit 7 dient als A17 (Bank 2/3).

    $D505:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Zwei Bits wären noch frei. Die waren zwar für zusätzliche Portbits vorgesehen, aber ich glaube nicht, dass da noch was von Commodore kommt ... :biggrin:

    $D506:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bit 7 ist die A17-Erweiteung für den VIC.

    Bit 5 und 4 wären frei für Erweiterungen, z. B. Bit 5 = VIC-A18 (512kB) und Bit 4 = RAMBANK4..7 (A18).

    Page Pointers:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ebenfalls erweiterbar.

    $D50B:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Zeigt im oberen Nibble an,wie viele 16 kB-Blocks an RAM verfügbar sind. Max. ist 1 MB (wenn das Nibble 0 ist.

    Also es wäre Platz im vorhandenen Registerset.

  • Nun gäbe es dazu noch Bank 4,5,6,7.

    Da könnts dann Probleme geben, der Begriff BANK wird vom Basic 7 nämlich generell verwendet, um unterschiedliche RAM/ROM Kombinationen festzulegen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Meiner Meinung nach sind Bank 2 und 3 die beste Möglichkeit, um zusätzlichen RAM einzubinden.

    Könnte man evtl durch Banking festlegen, welcher Bereich der zusätzlichen 256/512 kB als Bank 2 und 3 eingebunden werden soll?

    Also 0-128, 128-256, 256-384, 384-512.

    Änderungen am Basic-ROM machen klingt mMn nach "und so nahm das Unheil seinen Lauf" :biggrin:

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • ich könnte mir vorstellen, das Zusatz-RAM für ladbare ROMs, Kernal etc. zu verwenden.

    In der einen oder anderen Zusatzliteratur sind die vorsichtig als Expansion bezeichneten Bits schon klarer bezeichnet. Da war Commodore wohl voreilig beim Rausgeben von Doku.

    Z.B. im Programmer's Reference Manual steht wörtlich von einer 1MB Erweiterung.

    Auch bei den Page Pointern sind tw. 4 Bit vorgesehen im Highbyte, also auch 1MB.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • In der einen oder anderen Zusatzliteratur sind die vorsichtig als Expansion bezeichneten Bits schon klarer bezeichnet. Da war Commodore wohl voreilig beim Rausgeben von Doku.

    Kannst du die mal auszugsweise hier posten / pasten?

    Dann wäre alles an einem Ort.

  • In der einen oder anderen Zusatzliteratur sind die vorsichtig als Expansion bezeichneten Bits schon klarer bezeichnet. Da war Commodore wohl voreilig beim Rausgeben von Doku.

    Kannst du die mal auszugsweise hier posten / pasten?

    Dann wäre alles an einem Ort.

    Nicht so einfach, wegen Dateigröße.

    Im Data Becker - C128 Intern steht es aber ganz deutlich und ausführlich, auf Deutsch. Ab Seite 147:

    Bitte melde dich an, um diesen Link zu sehen.

    Details wie das mit der 1MB Erweiterung mal gedacht war, bleiben da aber auch offen, da manche Register eben nur 256kB addressieren können. Es steht aber drin, dass der Speicher in 256kB Blöcken umschaltbar ist.

    - Offenbar können aber die Page Pointer direkt 1MB addressieren

    - Ob die Common Areas dann für den ganzen 1MB Bereich common sind, steht da auch nicht drin.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • OK, da steht auch nur das drin,was im Service Manual unter Punkt "MMU" zu finden ist.

    Das mit den Bits 4 und 5 des RCR scheint eine "Interpretation" zu sein, weil der Maximalausbau von 1 MB beim Version Register im Service Manual genannt wird.

    Wenn das so ist, war für den VIC nur RAMBANK0 und 1 vorgesehen. Reicht ja im Prinzip auch, sind acht Bänke pro 256 kByte; also 32 mit Umschaltung der 256 k-Bänke via RCR:

    Das Problem ist nun, dass die Bits, die mit "EXPANSION" bezeichnet sind, einen fixen Wert beim Lesen zurückgeben. Nur mit "Parallelschalten" einer GAL-MMU ist es also nicht getan.

    Der Minimalansatz ist 256 kByte. Das geht relativ leicht, wenn man die CASRAM-Leitungen 0 und 1 durch das GAL führt, und entspricht dem, was Marko Mäkelä mit einer zweiten MMU gemacht hat.

    Der 1 MB-Ansatz ist komplexer, da wird es nur mit "Parallelschaltung" nicht gehen. Wird eher auf einen MMU-Austausch hinlaufen müssen.

  • Hier noch die Seite aus dem C128 PRG, was ich dann schon als offiziell zählen würde. Klar dass die anderen hier abschreiben.

    Ist auch auf archive.org: Bitte melde dich an, um diesen Link zu sehen.


    Bitte melde dich an, um diesen Anhang zu sehen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • In dem Zusammenhang wäre auch die hier erwähnte Doku zum MOS 8725 von extrazom interessant:

    Bitte melde dich an, um diesen Link zu sehen.

    Gibts hier schon was neues?

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Weil mir der Buchauszug von x1541 sehr bekannt vorkam...

    Bitte melde dich an, um diesen Anhang zu sehen.

    ... findet sich 1:1 im C128 Buch von Sybex.

    Nur halt auf D. ^^

  • Das Sybex Buch habe ich sogar, aber weder gerade gefunden noch ist mir der Verlag eingefallen.

    Darin habe ich dann das original auf englisch bemüht ;)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Im Intern C128, wird ab Seite 153 das Register $D506 beschrieben. Die Bits 6,7 bestimmen aus welcher Rambank der VIC zugreift. Die ROM Routen sind allerdings auf Bank 0 fixiert, diese müßten dann angepasst werden.

    Die Bits sind für die 1mb Version

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Hallo,

    leider lassen die eigenen Anschlüsse der MMU keine Ansteuerung von 4 Banken zu.

    Ca 1997 stand ich vor dem gleicen Problom.

    Es gab ein Angebot von Conrad mit der C128 MMU.

    Ich habe mir 4 Stück bestellt, da ich die orginalen nicht einsetzen wollte.

    Ich habe also mir eine Verdratung mit 2 MMU entwickelt.

    Diverse bidirektionale Schalter (CMOS)4066 ein 74ALS30 und noch einige + Negator kommen zum Einsatz.

    Auf der C128-Platine müssen die die 16 (bzw 4 im C128DCR) RAM Bausteine (CAS separieren) + ein 74X32 hukepack aufgelötet.

    die eine MMU steuert gerade und ungerade Bank (0/1 oder 2/3).

    die 2. MMU steuert ob (Bank 0/1 oder 2/3).

    Bei den 74x32 müssen 2 Anschlüsse auf einen Stecker separieren.

    Die Neue MMU benötigt so 2 zusätzliche Anschlüsse zu genau diesen.

    In der MMU können die Orgrinalausgänge nicht direkt verwendet werden. Die Ausgänge beider MMU müssen über einen 74x32 auf 4 CAS-Signale dekodiert werden.

    Ich selber habe 2 dieser Super-MMU hergestellt und die C128D + einen Nachbau aus Ersatzteilen umgebaut.

    Der Nachbau hatte noch keine Änderung im Versionsregister der MMU, das hatte ich dann in der 2. Variante naachgerüstet.

    Im Anschluß habe ich das CPM3.0+ angepasst.

    In diesem CPM giebt es auch Änderungen um mit FD2000 + FD4000 (CMD) mit mehren 81 (nicht C81) Partionen benutzen zu können.

    Ein entsprechendes Formatprogramm ist vorhanden. Eine REU(mit 4MB) kann auch benutzt werden.

    Ich hoffe das hilft bei weiteren Überlegungen.

  • Mir ist diese Lösung bekannt.

    Der Nachteil ist, man braucht 2 Stück MMU.


    Ein Microchip CPLD oder zwei GAL werden heute noch produziert und sind daher einfacher zu kriegen. :)

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.