Restaurierung Elektor EC65K

Nachdem der EC65 wieder läuft (Bilder und Details kommen später), habe ich mich an einen EC65K gemacht. Das ist der Nachfolger mit 65816 Prozessor. Und das Dingen macht echt graue Haare. Im 6502-Modus mit 64K RAM läuft er tadellos. Sobald ich ihm aber die 256K RAM Karte gebe, wird die IO des Floppy-Controllers von RAM-Zellen überlagert.

Und da ist nichts mehr mit "ha, das ist einfach". Ich weiß, was passiert. Aber ich weiß nicht, warum.

Der 65816 multiplext auf dem Datenbus auch A16-A23. Bei steigender Flanke von Phi1 sind die Adressen stabil, bei fallender Flanke die Daten. Bei der 256K RAM Karte liegen immer wieder falsche A16 und/oder A17 bei der Flanke an, weswegen die von RAM ausgeht (z.B. 1E000 anstelle 0E000), obwohl sie es nicht sollte. Es sieht so aus, als ob da ein Datenbustreiber immer noch oder zu früh aktiv ist. Immer wenn ich denke, ich habe den Verursacher gefunden und nochmal mit anderem Testprogramm Testmuster erzeuge, kann ich keinen Fehler mehr messen. Aber er ist noch da.

Ich glaube, ich muß doch mal in einen 64-Kanal Logikanalysator investieren (scheint ja gerade in Mode zu sein).

Falls jemand schlaue Ideen hat, her damit.

Hatte jetzt kein Handy mit im Arbeitszimmer. Aber ein Verursacher ist gefunden: Ein 74LS245 machte Ärger. Ausgetauscht und ich bin einen Schritt weiter. FCU kann jetzt angesprochen werden. Aber er startet nicht von Disk. Mit 64K RAM-Karte geht es. Ein paar Diagramme am Oszilloskop sehen nach parasitären Kapazitäten aus. Die könnten bei dem engen Timing vielleicht den Ausschlag geben. Muß eventuell die Busplatine mal durchmessen.

Eigentlich ist das auch kein SBC mehr: CPU, PSIO, VDU, FCU, RAM sind schon 5 Platinen.

So, hier ein paar Bilder. Die Minimalausstattung des EC65K, wenn man kein spezielles EPROM hatte, war die CPU-Karte:

eine PSIO mit RTC (die ich noch reparieren muß, zum Glück war keine Batterie eingelötet):

Ein Floppy-Controller FCU:

eine Videokarte VDU:

Und eine RAM-Karte. Hier die spezielle SRAM-Karte für den EC65K mit 256K. Man konnte aber auch die 64K DRAM oder 64K SRAM vom Samson 65/Octopus 65/EC65/Junior verwenden. Diese Karte aber (eigentlich) nur mit dem EC65K.

Als Gesamtsystem, bei mir auf dem Arbeitstisch, sieht das dann so aus (die vorhandenen Floppies habe ich soweit möglich auf ein Gotek gezogen):

Das ist also eigentlich kein Einplatinen-Computer mehr.

Was mir graue Haare beschert hat waren, neben ein paar fehlerhaften TTL Chips, drei Dinge: Kapazitäten auf der Busplatine, die interessanterweise mit Alkohol soweit nötig weggingen, nicht durchgeführte notwendige Änderungen und ein Umbau an der Speicherkarte, der mir nicht auffiel.

Dazu muß man wissen, daß die Qualitätskontrolle bei Elektor nicht so ganz optimal war. Es gab da so die Regel: Keine Computerplatine ohne mindestens eine Änderung. Da einige Karten schon für die Vorgänger Junior und Samson aka EC65 aka Octopus herausgekommen waren, brauchten die für den EC65K ein paar Änderungen zusätzlich zu den sowieso schon nötigen Änderungen, die der Vorbesitzer nicht vollständig/richtig durchgeführt hatte. Die musste ich mir erstmal zusammensuchen und durchführen. Dabei feststellen, daß die angegebenen Änderungen teilweise falsch waren und erstmal die richtigen raussuchen. Eine Änderung betraf eine Neubelegung des Busses (vorher Masse, jetzt Bankselect), die ich an der VDU nur mit abknipsen eines Pins im Stecker durchführen konnte (oder ich hätte den ganzen Verbinder auslöten, darunter liegende Leiterbahnen durchtrennen und wieder einlöten müssen). Manchmal hat Elektor damals so komische Änderungen wie bei der VDU zu sehen, vorgeschlagen. Das habe nicht ich gemacht! Pins hochbiegen und mit Draht verlöten ist nicht so meines. Ich hätte da eine Adapterplatine draufgesetzt. Aber ok. Das werde ich eventuell mal ändern.

Nun zu dem echten Hit. Die 256K SRAM-Karte ist für den EC65K ausgelegt. Die läuft nicht wirklich im Vorläufer, denn sie benötigt zusätzliche Adressleitungen, die es vorher noch nicht gab. Den Vorbesitzer hat das aber wohl nicht gestört. Er hat, unter dem Sockel des Adresskomparators, das Ausgangssignal direkt zu Masse geführt und den Chip wieder eingesteckt. Ganz böses Foul. Das muß man erstmal finden. Denn in dem Modus entscheidet die Geschwindigkeit der anderen Adresskomparatoren, ob das RAM ausgeblendet wird oder nicht. Deswegen auch dieser wandernde Fehler. Immer wenn ich die RAM Karte "weiter weg" (also an den Bus-Extender fürs Messen) packte, dann waren die IO-Karten schneller und es ging teilweise. Tauschte ich die Karten um z.B. an der FCU zu messen, war die zu weit weg und die RAM Karte war schneller. Absolute Gemeinheit sowas.

Aber jetzt läuft er soweit. Wie gesagt, die RTC funktioniert noch nicht und bei der VDU-Karte "pumpt" das Bild. Jetzt geht es aber erstmal an die weiteren Karten des Computers und dann muß das alles auch noch in das Gehäuse.

Original war der in einem „PC“ Gehäuse von Feltron, in dem ein Käfig für die Einschubkarten war. Das Gehäuse, in dem ich den bekommen habe, war aber nur noch Schrott. Der Käfig unvollständig, Deckel fehlt, Halterungen abgebrochen. Suche erstmal weiter nach einem Originalgehäuse. Oder hast Du ein Pultgehäuse mit BGT?

So, die nächste Platine läuft wieder: Die CP/M-Karte. funkenzupfer hat massiv geholfen, den Fehler zu suchen. Dabei auch einen Schaltungsfehler behoben, der bei EPROMs größer 2732 wirkt. Was es genau war, wissen wir aber am Ende nicht. Ich hatte rein vorsorglich alle Kondensatoren ausgetauscht. Prozessor lief auch an, aber die Software machte irgendwie nicht nachvollziehbare Fehler. Da die Software von jemand anderem kam, der sich nicht sicher war, ob das EPROM noch alle Werte richtig hatte, gab es ja auch die Möglichkeit von Bitfehlern. Am Ende und nach sehr viele Stunden mit Testprogrammen, Messungen und Kopf kratzen, wollte ich dann nochmal die Abblockkondensatoren austauschen und hatte dann einfach mal, als alle ausgelötet waren, vier 1µ Tantal eingebaut. Und siehe da: Die Karte läuft. Die anderen vier Abblockkondensatoren wieder rein und es geht immer noch alles. Werde ich jetzt auch so lassen.

Im Gesamtsystem ist jetzt das Problem, daß mit der EC65K CPU-Karte und VDU das Bild massive Störungen hat, weil die Schreibzugriffe aufs Video-RAM nicht synchronisiert sind. Bei der normalen EC65 CPU tritt das nicht auf, aber für die Kombi habe ich keine Software. Der Bootloader hängt bei der EC65 CPU. Also werde ich wohl jetzt etwas machen müssen, was ich vor 35 Jahren, wegen Wechsel zu IBM AT, nicht mehr gemacht habe: Die Kolorator-Karte aufbauen. Denn die Platinen liegen so lange schon hier rum.