16k bzw. 24k Kernal

Schreibzugriff auf $d100 oder sowas ? So wird das z.B. im DTV gelöst ...

DTV_Programming

Ich würde eine Logik einbauen, die abhängig von einem Lesezugriff auf eine bestimmte ROM-Adresse, die normalerweise nicht angesprungen wird (den "RRBY"-String z. B.), die Bank umschaltet. Natürlich nur, wenn per $01 auch ROM eingeblendet ist. Eventuell auch zwei oder drei oder vier Lesezugriffe hintereinander in einem bestimmten Muster (erst "B" lesen, dann ein "R", dann das "Y").

Das dürfte in der Praxis nie vorkommen und sollte transparent sein.

Zitat

Das dürfte in der Praxis nie vorkommen und sollte transparent sein.

Hatte ich auch erst mal drüber nachgedacht. Funktioniert bloss nicht, wenn ein Programm das komplette ROM von $e000-$ffff oder von $a000-$bfff in das darunter liegende RAM kopiert, um es zu modifizieren.

peiselulli

Doch, deshalb das bestimmte Muster "out of order", lies bitte nochmals genau meinen Vorschlag.

Drei LDAs sind außerdem gleich schnell wie ein LDA, ORA, STA fûr irgendein Portbit.

Zitat von markusC64

dass bei den Lesevorgängen zwischendurch die CPU aus dem ROM den nächsten Befehl mit Parametern holen muss

Stimmt. Dann könnte man stattdessen Schreibzugriffe nehmen. Sollte auch nicht vorkommen und man kann es mit R/W verknüpfen.

Z. B.:

FFF6 52 52 42 59 R R B Y

STA $FFF8

STA $FFF6

STA $FFF9

STA $FFF7

Sollte in der Praxis nicht vorkommen.

Zitat von markusC64

Halte ich für eine gefährliche Idee - der Kernal ändert dadurch das darunterliegende RAM ab.

Auch richtig. dann Lesezugriffe und die Opcode-Fetches werden ignoriert, die haben dann ja, weil es lauter LDAs sind, eine feste Breite, wenn ich nicht irre.

Zitat von markusC64

Erkennt man die irgendworan - wenn man nur die Leitungen des Expansionsportes beobachten kann?

Ich bin jetzt kien 6502-Spezialist, aber die sollten als ganz normale Lesezugirffe daher kommen (R=1). Die CPU holt den Opcode und macht für die Dauer der Verarbeitung in jedem Takt den gleichen Zugriff wieder. Es gubt Überlappungen, wenn der Befehl nur noch intern abgearbeitet wird und kein Buszugriff mehr benötigt wird, wie beim LDA, dann wird schon der nächste Opcode geholt.

Ungefähr so (genau wird es nicht stimmen, da muss ein Experte ran):

CPU holt nächstenb Opcode (hier für LDA $xxyy, LDA $xxxx braucht 4 Takte)

CPU holt LSB (xx)

CPU holt MSB (yy)

CPU holt Wert von $xxyy ; den hier brauchen wir!, der erste

CPU holt nächsten Opcode (hier für LDA $xxyy, LDA $xxxx braucht 4 Takte)

CPU holt LSB (xx)

CPU holt MSB (yy)

CPU holt Wert von $xxyy ; den hier brauchen wir, der zweute

CPU holt nächsten Opcode (hier für LDA $xxyy, LDA $xxxx braucht 4 Takte)

CPU holt LSB (xx)

CPU holt MSB (yy)

CPU holt Wert von $xxyy ; den hier brauchen wir, der dritte

CPU holt nächsten Opcode (hier für LDA $xxyy, LDA $xxxx braucht 4 Takte)

CPU holt LSB (xx)

CPU holt MSB (yy)

CPU holt Wert von $xxyy ; den hier brauchen wir, der vierte

Zitat

Weder RONL, ROMH, IO1, IO2, ... signalisieren uns, dass auf $d1xx zugegriffen wird, uns fehlt also technisch gesprochen das /CS Signal.

Es liegt doch der komplette Adress-Bus an, dann kann man sich das CS selbst "ausrechnen".

Wenn man den 6510 durch einen 6502 ersetzt und den Prozessorport extern implementiert, stehen 2 zusätzliche Bits am Port zur Verfügung. Da die Manipulation dieser Bits die Font des Commodore 128 verändert, ist Software generel bereits so geschrieben, dass sie diese Bits nicht berührt, so dass die Folgen für die Kompatibilität begrenzt sind. In Kombination mit den bestehenden Konfigurationslinien LORAM, HIRAM und CHAREN kann die Anzahl der möglichen Konfigurationen des C64 von 8 auf 32 erhöht werden, genug, um einige KERNAL-Banken zu implementieren. Darüber hinaus sind alle Speicherkonfigurationsbits auf demselben Register besonders elegant.

Für die Ultimate64 und möglicherweise andere neue C64-Boards ist die obige Idee realisbaar. Nicht für den 1541U2, weil er in einem Original-C64 funktionieren muss. Also eine Idee, die mit dieser möglich ist. Der 1541U2 wendet bereits über seinen "alternate KERNAL" den Trick an, den Wert von HIRAM herauszufinden. So weiß der 1541U2, ob die Adresse auf dem Adressbus aus ROM oder RAM gelesen wird. Man könnten eine magische Adresse implementieren, die den Bankswitch auslöst.

Zum beispiel:

lda $f200 ; switch to KERNAL bank 0

lda $f201 ; switch to KERNAL bank 1

lda $f202 ; switch to KERNAL bank 2

lda $f203 ; switch to KERNAL bank 3

Um es sicherer zu machen und es vor versehentlich aus dem ROM lesender C64-Software zu schützen, konnte der 1541U2 testen, ob der vorherige Speicherzugriff (das Lesen des Befehls durch die CPU) ebenfalls vom KERNAL kam.

Vom architektonischen Standpunkt aus gesehen ist dies ein viel unschönerer Hack als der vorherige, aber wahrscheinlich sehr effektiv.

Zitat von peiselulli

Es liegt doch der komplette Adress-Bus an, dann kann man sich das CS selbst "ausrechnen".

Aber nicht die Info, ob mit $D100 RAM, Char-ROM oder I/O gemeint ist.

Zitat von dmantione

Man könnten eine magische Adresse implementieren, die den Bankswitch auslöst.

Zum beispiel:

lda $f200 ; switch to KERNAL bank 0

lda $f201 ; switch to KERNAL bank 1

lda $f202 ; switch to KERNAL bank 2

lda $f203 ; switch to KERNAL bank 3

Alles anzeigen

Ein einzelner Read ist ganz schlecht, weil wenn die ROM-Routine, die um $F200 herumliegt abgearbeitet wird knallt's, wenn auch nur der Opcode von der CPU geholt wird, der an $F20x liegt.

Die Lösung sollte auch ohne Umbau des C64 auskommen. Die oben skizzierte Methode steht prinzipiell auch am ROM-Sockel zur Verfügung. Man muss also lediglich das Kernal durch das neue "ROM" inkl. der notwendigen Logik ersetzen.