Die Zugriffe der anderen Rambanken unterscheiden sich eigentlich nur von Rambank 0. Das könnte man doch nutzen, indem man Bank 1 Aufsplittet und daraus die Banken 1,2 und 3 macht.
c128 - 256 KB // MMU Nachbau
-
Diddl -
20. Januar 2024 um 10:29 -
Erledigt
Es gibt 64 Antworten in diesem Thema, welches 7.385 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Korrigiert mich, wenn ich daneben liege ...
Bit 7 im Control Register wäre prinzipiell vorgesehen, um Bank 0/1 umzuschalten auf Bank 2/3, ja?Es gibt auch noch ein entsprechendes Bit für die VIC-Buszyklen, und dann noch jeweils eins in den Pagepointer-Registern für Zeropage und Stack.
-
Was meint ihr dazu?
Machbar, nicht machbar?
Sinnvoll, nicht sinnvoll?
In der Theorie hab ich auch schon mit dem Gedanken gespielt, abgesehen davon dass mir Wissen und Zeit fehlen um das real umzusetzen und ich momentan keinen C128 zum zerbasteln habe

Wenn schon dann gleich 512K , juckt mich immer in den Fingern wenn ich die 5V DIP32 512Kb RAM Chips sehe (z.B. Reichelt 628512-55) die mal in einem Projekt einzusetzen.
Plus, 512K sind vermutlich kein nennenswerter Mehraufwand gegenüber 256K.
Natürlich gibts keine nennenswerte bestehende Software die das unterstützt, notfalls halt wie immer erstmal ne RAM-Disk ...
Für entsprechend angepasste Software hätte das den Charme dass man "instant" Speicher einblenden kann -> optimale Geschwindigkeit. Und mit VIC+VDC+gescheiter Tastatur+2Mhz+Z80 bietet der C128 auch mehr Möglichkeiten um damit was anzufangen als z.B. der C64.
Punkte die mir da noch als optionale Ergänzungen durch den Kopf gegangen sind:
-Verfügbar auch aus dem CP/M Modus?
-Evtl. getrennte Bank für VIC einstellbar?
-Ersetzen der ROMs durch ein 512 KB Flash der auch bankswitchbar ist (so dass man softwareseitig auf einen alternativen Kernel umswitchen könnte, ggf. sogar auf ein alternatives System das mehrere Bänke groß ist)
-
Wenn schon dann gleich 512K , juckt mich immer in den Fingern wenn ich die 5V DIP32 512Kb RAM Chips sehe (z.B. Reichelt 628512-55) die mal in einem Projekt einzusetzen.
Plus, 512K sind vermutlich kein nennenswerter Mehraufwand gegenüber 256K.
Das ist richtig.
Ich würde auch ein 512K SRAM verwenden, weil die kriegt man einfacher wie 256K und relativ gesehen günstiger.
Es ist nur so, dass 256 KB im c128 schon dokumentiert sind und quasi "vorbereitet".
In der MMU gibt es schon ein entsprechendes Bit dafür.
Bei 512 KB müsste man sich selbst was überlegen, das ist so nicht vorgesehen worden von Commodore.
-Verfügbar auch aus dem CP/M Modus?
Ja klar, der kann wohl auch die MMU steuern.
-Evtl. getrennte Bank für VIC einstellbar?
Das geht ja jetzt auch nicht?
Wie sollte man das machen ohne das ganze Konzept in Frage zu stellen?
-Ersetzen der ROMs durch ein 512 KB Flash der auch bankswitchbar ist (so dass man softwareseitig auf einen alternativen Kernel umswitchen könnte, ggf. sogar auf ein alternatives System das mehrere Bänke groß ist)
Natürlich könnte man die bestehenden ROM zusammenfassen.
Aber das ist keine besonders schwierige Aufgabe.
Wäre für mich nur sinnvoll im Zuge eines neuen Motherboard, wie das NEO Dingens.
Banking geht eh jetzt schon beim Function ROM (U36) in Form des MegaBit 128.

-
Es ist nur so, dass 256 KB im c128 schon dokumentiert sind und quasi "vorbereitet".
In der MMU gibt es schon ein entsprechendes Bit dafür.
Bei 512 KB müsste man sich selbst was überlegen, das ist so nicht vorgesehen worden von Commodore.
Ohne zusätzliche Register wird es nicht gehen.
-Verfügbar auch aus dem CP/M Modus?
Ja klar, der kann wohl auch die MMU steuern.
Es gibt einen "Z80-Modus". In diesem ist das Verhalten anders. Wird dort auf Bankl 2 und 3 zugegriffen, landen die Zugriffe auf Bank 0 und 1. Details habe ich wieder vergessen, aber für den C128 Dead Test waren sie wichtig.
-Evtl. getrennte Bank für VIC einstellbar?
Das geht ja jetzt auch nicht?
Wie sollte man das machen ohne das ganze Konzept in Frage zu stellen?
Das ist ja jetzt schon vorgesehen, dass man die VIC-Bank einstellen kann. Sogar für Bank 2 und 3 gibt es Register-Bits, WIMRE:
-
-
Ich liebäugle mit folgender Hardware Lösung:
- SRAM statt der internen DRAM
- die MMU wird weiter verwendet
- zwei GAL 22v10
Die GAL spiegeln ein paar MMU Bits:
- das MMU Controlregister Bit 7 (Bank 2/3 statt Bank 0/1 - also A17 des SRAM)
- das MMU Controlregister Bit 0 (IO enable)
- das PCRA Bit 7
- das PCRB Bit 7
- das PCRC Bit 7
- das PCRD Bit 7
Die GAL kann jedrmann selbst programmieren, ein TL866 genügt zB.
Der Hardware Aufwand ist gering.
Man kann das Ding leicht testen mit einem Multimeter und ein paar POKE Befehle.
-
-Evtl. getrennte Bank für VIC einstellbar?
Das geht ja jetzt auch nicht?
Wie sollte man das machen ohne das ganze Konzept in Frage zu stellen?
Natürlich geht das. Die RAM-Banks für CPU und VIC sind auch jetzt schon getrennt einstellbar.
-
Natürlich geht das. Die RAM-Banks für CPU und VIC sind auch jetzt schon getrennt einstellbar.
Nun ja, das geht dann ja auch weiterhin.

-
Natürlich geht das. Die RAM-Banks für CPU und VIC sind auch jetzt schon getrennt einstellbar.
Nun ja, das geht dann ja auch weiterhin.

Es sollte aber auch für RAMBANK 2 und 3 gehen. Daher muss dieses Regsiterbit berücksichtigt werden.
-
Es sollte aber auch für RAMBANK 2 und 3 gehen. Daher muss dieses Regsiterbit berücksichtigt werden.
Mir ist lieber eine einfache Lösung mit GAL als eine komplexere mit CPLD.
Die GAL Lösung kann jedermann nachbauen, die CPLD Lösungen sind meist Stiefkinder.
Ehrlich gesagt ist mir egal ob der VIC auf Bank 2 und 3 kommt oder nicht.
Der VIC kommt ja jetzt auch nur auf Bank 0 und 1.
Insofern ...
Es wäre doch ein Gewinn, wenn erst mal die CPU zusätzlich 128K schnellen RAM hat.
Wenn das funktioniert, dann kann man immer noch über bessere Lösungen nachdenken.
-
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?
-
Der Gewinn für den VIC ist überschaubar, ja.
Es wäre halt eine Einschränkung gegenüber dem ursprünglichen Konzept.
Aber, wie gesagt, die originale MMU generiert - zumindest im Z89-Mode - ein /CS für RAMBANK0, wenn auf RAMBANK2 zugegriffen wird. Ein einfacher "Parallelbetrieb" der Zusatz-MMU wird dadurch sowieso nicht möglich sein.
Zumindest muss man die Chip Selects für RAMBANK0 und RAMBANK1 nochmals durch das GAL führen und gaten.
-
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?
Das ist KEINE dumme Frage.
Eigentlich gibts keine dumme Fragen, nur dumme Antworten.
Es wäre absolut abwärtskompatibel.
Im Grunde müsste alles funktionieren was jetzt funktioniert.
AUSSER:
Ein Programm nutzt zB. Bank 2.
Bei einem normalen c128 würde das Programm Bank 0 benutzen.
Bei einem 256K c128 wird aber dann Bank 2 benutzt.
Natürlich reagiert das dann anders.
Aber es wäre dann eher ein Exploit.
Wer benutzt eine Bank die es im Normalfall nicht gibt?
-
Zumindest muss man die Chip Selects für RAMBANK0 und RAMBANK1 nochmals durch das GAL führen und gaten.
Ja das ist richtig.
Guter Einwand.
Beide CS durch das GAL führen (2 In, 4 Out).
-
Blödsinn, wenn man ein SRAM hat ist es ja sowieso etwas anders.
Zwei mal CS In, A16 und A17 Out.
Schade dass man die oberen 256 K nicht nutzen kann ...
Ein zusätzliches Register ...
Na das sollte man noch behirnen.
Und wenn man es nur für den VIC benutzt.
256K nur für den VIC ...

-
256K nur für den VIC ...
UHD kommt dem 128er immer näher.

-
Es wäre absolut abwärtskompatibel.
Im Grunde müsste alles funktionieren was jetzt funktioniert.
Prima!
Alles anzeigenAUSSER:
Ein Programm nutzt zB. Bank 2.
Bei einem normalen c128 würde das Programm Bank 0 benutzen.
Bei einem 256K c128 wird aber dann Bank 2 benutzt.
Natürlich reagiert das dann anders.
Aber es wäre dann eher ein Exploit.
Wer benutzt eine Bank die es im Normalfall nicht gibt?
Klar, niemand!
Ich dachte da in Richtung CP/M (resp. Z80) aber das hat kinzi ja schon beantwortet!Wie gesagt, fänd ich Super Klasse!
-
Alles anzeigen
Es wäre absolut abwärtskompatibel.
Im Grunde müsste alles funktionieren was jetzt funktioniert.
Prima!
Alles anzeigenAUSSER:
Ein Programm nutzt zB. Bank 2.
Bei einem normalen c128 würde das Programm Bank 0 benutzen.
Bei einem 256K c128 wird aber dann Bank 2 benutzt.
Natürlich reagiert das dann anders.
Aber es wäre dann eher ein Exploit.
Wer benutzt eine Bank die es im Normalfall nicht gibt?
Klar, niemand!
Ich dachte da in Richtung CP/M (resp. Z80) aber das hat kinzi ja schon beantwortet!Ich bin mir jetzt nicht sicher, ob das mit RAMBANK2 -> RAMBANK0 nur im Z80-Mode so ist, oder sonst auch.
Für die oberen 256 k würde ich einfach ein zusätzliches Register vorsehen. Es wäre zu schade, das zu verschenken.
-
Ich bin mir jetzt nicht sicher, ob das mit RAMBANK2 -> RAMBANK0 nur im Z80-Mode so ist, oder sonst auch.
Das kann man ja raus bekommen.
Für die oberen 256 k würde ich einfach ein zusätzliches Register vorsehen. Es wäre zu schade, das zu verschenken.
In der Tat! Sehe ich auch so! Wenn dan richtig!
-