Unbekanntes C64-Modul "KEX" mit RAM und Pufferbatterie. Was ist es?

Durch die Batterie würde ich auf eine Clock tippen, aber die DIPs irretieren mich dabei.

Wenn Du die Platine aus dem Gehäuse nimmst, steht da nichts weiter drauf?

Sicher, dass es KEX heißt und nicht REX?

Jo... KEX steht auf der Platine und auf dem IC.

Vielleicht für KernalEXtension? Oder doch von Bahlsen?

Wundert mich, dass man so gar nichts dazu findet... also ich jedenfalls nicht.

Das ist ein 8 kB SRAM und ein PAL (programmierbarer Logikbaustein).

Ich würde mal raten, damit kann man ein CBM80-Modul (und wahrscheinlich noch andere, daher die DIP-Schalter) emulieren - zuerst schaltet man das Ding auf IO1 oder IO2, lädt das Modul rein und schaltet dann um auf ROM. Die Batterie ist dazu da, dass das RAM auch nach dem Ausschalten den Modulinhalt noch beibehält, man es also nicht jedes Mal neu beladen muss,

Das PAL macht die ganze Logik für die Umschaltung, Adressierung, usw.

So eine ganz frühe Form eines "Easy Flash für Arme".

[EDIT]

Ach ja, richtig, wie oben geschrieben, "KEX" könnte auch "Kernal Expansion" oder so was heißen. Das Prinzip bleibt aber gleich.

[/EDIT]

Zitat von kinzi

Ich würde mal raten, damit kann man ein CBM80-Modul (und wahrscheinlich noch andere, daher die DIP-Schalter) emulieren - zuerst schaltet man das Ding auf IO1 oder IO2, lädt das Modul rein und schaltet dann um auf ROM. Die Batterie ist dazu da, dass das RAM auch nach dem Ausschalten den Modulinhalt noch beibehält, man es also nicht jedes Mal neu beladen muss,

Das PAL macht die ganze Logik für die Umschaltung, Adressierung, usw.

So eine ganz frühe Form eines "Easy Flash für Arme".

Ich würde anhand dieser Beschreibung eher sagen, es handelt sich um eine Art Entwickler-Kit für jemanden, der Module entwickeln und testen will.

Vielleicht ein Kernal-Ersatz, etwa wie es in skoe.de/kernal/kernal-cartridge.pdf beschrieben ist? Oder auch einfacher gestrickt, wobei die /HIRAM-Detektion nicht umgesetzt wird (also das RAM via Port $01 nicht mehr von der CPU gelesen werden kann - dafür bräuchte man ja noch mal 8 KByte Spiegel-RAM für das RAM unterhalb des Kernals, wenn ich da richtig gelesen habe).

Für ein einfaches "CBM80"-Modul ist da ein PAL für die Logic doch "überdimensioniert", oder? Vielleicht ist das wegen den entsprechenden Konfigurationsmöglichkeiten durch die Dip-Switches, wo eventuell sonst diverse TTL-Gatter anfallen?

Gut, man soll vielleicht bei "KEX" nicht zu viel hineininterpretieren, das "K" muss ja nicht zwangsläufig etwas mit Kernal zu tun haben. Kann ja auch sonst irgend ein Name des Herstellers sein ...

Ist das Modul schon real getestet worden?

Zitat von JeeK

Für ein einfaches "CBM80"-Modul ist da ein PAL für die Logic doch "überdimensioniert", oder? Vielleicht ist das wegen den entsprechenden Konfigurationsmöglichkeiten durch die Dip-Switches, wo eventuell sonst diverse TTL-Gatter anfallen?

Nein, denn irgendwie musst du das Ding ja beschreiben können. Schreibzugriffe auf ROML und ROMH landen aber immer im RAM "darunter", weil die C64-Designer davon ausgingen bzw. festgelegt haben, dass ausschließlich (EP)ROM an ROML und ROMH vorkommen.

Und ein SRAM. das man nicht beschreiben kann macht arg wenig Spaß in diesem Modul.

Deshalb vermute ich, dass man es per IO1 und/oder IO2 beschreiben kann; daher das PAL, es muss z. B. die Adresslogik bereitstellen beim Schreiben, da 8 Adress-Bits zu wenig sind sind für 8 kB. Und weil das ein TTL-Grab würde, hat man eben ein PAL genommen.

Zitat von kinzi

Nein, denn irgendwie musst du das Ding ja beschreiben können. Schreibzugriffe auf ROML und ROMH landen aber immer im RAM "darunter", weil die C64-Designer davon ausgingen bzw. festgelegt haben, dass ausschließlich (EP)ROM an ROML und ROMH vorkommen.

Und ein SRAM. das man nicht beschreiben kann macht arg wenig Spaß in diesem Modul.

Aber wie im PDF beschrieben, die Schreibaktion ins RAM kann man ja im SRAM "mitschreiben" (wenn der richtige Dip-Switch umgelegt ist). Leseaktionen auf den Kernal-Bereich wird dann immer aus dem SRAM geliefert (ev. auch per Dip-Switch deaktivierbar). Das Umschalten per $01 sei einmal vernachlässigt (was ja die recht aufwändige /HIRAM-Logik wie im PDF beschrieben erforderte. Aber auch für das würde man einiges an Dekodierlogik brauchen, die man gerne in einem PAL zusammengefasst hat, oder?

Zitat von kinzi

Deshalb vermute ich, dass man es per IO1 und/oder IO2 beschreiben kann; daher das PAL, es muss z. B. die Adresslogik bereitstellen beim Schreiben, da 8 Adress-Bits zu wenig sind sind für 8 kB. Und weil das ein TTL-Grab würde, hat man eben ein PAL genommen.

Glaub ich eh auch, dass zu der Zeit das eher so etwas war. Mir geht ging es oben eher um das Gedankenspiel, nämlich ob es theoretisch nicht auch so etwas hätte sein können.

Aber um auf IO1/2 zurückzukommen. Wenn ich da quasi Register für die Adressierung von Speicherstellen im SRAM bilde (die mir das PAL dekodiert), brauch ich da nicht ein Latch, das mir dann z.B. die höherwertigen Bits speichert? Reicht da ein PAL überhaupt?

Zitat von JeeK

Wenn ich da quasi Register für die Adressierung von Speicherstellen im SRAM bilde (die mir das PAL dekodiert), brauch ich da nicht ein Latch, das mir dann z.B. die höherwertigen Bits speichert? Reicht da ein PAL überhaupt?

Ich habe mich zuletzt vor 30 Jahren mit PALs beschäftigt und kann mich nicht mehr erinnern, aber ich denke, ein Latch bekommt man damit hin. Sind ja auch nur Gatter, im Prinzip. Vielleicht kann uns da jemand "erhellen".

Es ist ungewöhnlich und "kurios"

Also perfekt für meine Sammlung.

Zitat von kinzi

Ich habe mich zuletzt vor 30 Jahren mit PALs beschäftigt und kann mich nicht mehr erinnern, aber ich denke, ein Latch bekommt man damit hin. Sind ja auch nur Gatter, im Prinzip. Vielleicht kann uns da jemand "erhellen".

Bei mir ist es nicht so lange her, würde mich bei weitem nicht als PAL-Spezialisten sehen, aber da müsste bei einem PAL 16L8 dann 5 der 8 Ausgabeleitungen den 5 Adressleitungen spendieren (natürlich auch 5 Eingabeleitungen der 16). Ob man dann den Rest der notwendigen Logik mit den verbleibenden Leitungen zusammenbringt, übersteigt allerdings meine Einschätzung (wenn nicht sowieso schon am Holzpfad war).

Vielleicht bräuchte man dann da eher schon ein CPLD, oder so ...

Zitat von JeeK

da müsste bei einem PAL 16L8 dann 5 der 8 Ausgabeleitungen den 5 Adressleitungen spendieren (natürlich auch 5 Eingabeleitungen der 16). Ob man dann den Rest der notwendigen Logik mit den verbleibenden Leitungen zusammenbringt, übersteigt allerdings meine Einschätzung

Naja, sonst braucht es ja nicht allzu viel. Als CBM80-Cartridge praktisch nix, das hat ja sonst normalerweise auch keine Gatter. Und Bankswitching gibt es bei einem 8 kB-RAM auch keines. Höchstens die Umschaltung ROML/ROMH auf /CS des RAM wäre noch zu erledigen, kann aber auch per DIP erfolgen.

Aber ja, ein Schaltplan wäre toll.