Schneider Euro PC: Keyboard Controller startet nicht

Ich versuche gerade, ein Euro-PC-Mainboard mit Laugenschaden wiederzubeleben. Das erste Problem, was sich stellt, ist dass die Kiste (meistens) gar nicht aus dem Reset-Zustand kommt. Wenn ich die Schaltung im Euro PC richtig verstanden habe, wir über einen Widerstand in RN3 die Basis von T3 mit Strom versorgt, wodurch T3 über R32 die low-aktive Reset-Leitung des FE2010A aktiviert. Damit bleibt der gesamte PC im Reset, bis der Keyboard-Controller PB4 (Pin 29) low zieht, und damit T3 den Basisstrom wegnimmt.

Bei meinem Euro-PC passiert das aber nicht. Ich habe an den Beinen des Keyboard-Controllers gemessen, und zunächst keinen offensichtlichen Fehler gefunden (alle Aussagen gemessen, nicht nur aus dem Schaltplan vorgelesen):

• +5V/Masse liegt an
• Reset geht (wohl über einen im Controller integrierten Pullup, der C302 auflädt) langsam hoch bis 3,5 oder etwas mehr Volt, was nach TTL-Interpretation ein klares "high" ist, und den Controller freigeben sollte.
• KBCLK ist (bis auf einen kurzen Glitch beim Einschalten des Hauptschalters) permanent low(!), der 4,7k-Pullup scheint aber funktionsfähig zu sein: Mit dem Multimeter im Widerstandsbereich messe ich 4,38kOhm von KBCLK nach +5V, solange der PC aus ist.
• EXTAL hat einen sauberen Takt mit 5V Pegel
• Timer ist high, die 2,2kOhm Pullup sind ohmsch nachmessbar
• XTAL ist mit Masse verbunden
• NUM ist über JS11A mit Masse verbunden (ich habe explizit geprüft, dass JS11A nicht durchgefressen ist)
• PA0-PA7 haben im Betrieb etwa 2,5V DC
• PD0-PD7 haben jeweils 100k Pullup, und im Betrieb +5V
• PC7 liegt auf Masse
• PC0-PC6 haben jeweils 10k Pullup, und im Betrieb +5V
• PB0-PB7 verhalten sich messtechnisch wie gemäß Aussenbeschaltung im Schaltplan zu erwarten

Interessant ist aber, dass im Moment (ich meine, das Verhalten hat sich während der Messungen geändert), gefühlt eine halbe Sekunde nach dem Einschalten auf PB0-PB7 offenbar hochfrequent etwas ausgegeben wird. Die Pegel an PB0-PB7 springen zwischen dem, was die Schaltung bei offenem PB-Pin hergibt und 0V hin und her. Da ich gerade nur ein 1-Kanal-Oszilloskop habe, kann ich nicht sagen, ob PB0-PB7 exakt das gleiche Muster haben, aber es wirkt auf den ersten Blick so. PB5-PB7 springen also zwischen +5 über den Pullup und Masse, wogegen PB4 nur zwischen 0,7V (der Basisspannung von T3) und Masse springt.

Ohne einen klaren stabilen Massepegel an PB4 gibt das Teil natürlich keine Lebenszeichen von sich. Wenn ich den Pin extern auf Masse ziehe, dann kommt es zum üblichen "lang-kurz"-Fehlerpiep. Nur einmal, also vermutlich ein Fehler in oder um JIM. Bei dem weniger zerfressenen Euro-PC-Board, was ich vor ein paar Tagen in der Hand hatte, war die A6-Lötstelle an JIM kaputt, was dieses Verhalten erzeugt hat. Den JIM-Fehler habe ich wegen des Reset-Problems zunächst zurückgestellt.

Meine aktuelle Vermutung ist, dass der Keyboard-Controller in seiner Initialisierung auf einen Fehler läuft, und möglicherweise das Muster auf PB einen POST-Code des KBC darstellt.

Kennt jemand diese Situation, und kann mir Tipps geben, was ich messen kann? Wie wahrscheinlich ist ein ausgefallener Keyboard-Controller? Ist das Symptom vielleicht sogar schon bekannt?

Kurze Ergänzung: Das Signal auf Port B ("etwas hochfrequentes") ändert sich alle paar Maschinentakte (d.h. auf einem 250ns-Raster) des Keyboard-Controllers. Der Takt für den Keyboard-Controller liegt im Rahmen der Ablesegenauigkeit auf meinem Oszilloskop bei den gewünschten 4MHz.

Und besonders irritierend: Alles deutet darauf hin, dass der Keyboard-Controller wenn überhaupt nur sehr schwache Pullups hat, und dessen Ausgänge somit Open Collector sind. Trotzdem zeigt mein Multimeter, wenn ich PB4 nach Masse ziehe Ströme zwischen 3 und 4 mA an. Dank 5V Betriebsspannung und 4,7k Pullup sollte eigentlich nicht mehr als 1,1mA drin sein. T3 wirkt auf den ersten Blick aber messtechnisch in Ordnung, er hat auf jeden Fall keinen Collector->Basis-Schluss, so dass auf die Basis von T3 nichts aus der Kollektorseite kommen sollte.

Habe inzwischen das Datenblatt vom MC6805U2 gefunden, der das laut Schaltplan sein soll. Port B hat ausreichend Ausgangsstrom im High-Zustand, der die 3 bis 4 mA erklären kann.

Neuester Ergebnisse: Manchmal startet der Keyboard-Controller normal, meistens aber nicht. Man kann durch ein Reset des Keyboard-Controllers (Pins 1 & 2 kurzschließen) einen neuen Startversuch anstoßen. Das Verhalten, dass der Keyboard-Controller wild am Port B rumfuchtelt anstatt den Prozessor einzuschalten tritt zwar meistens auf, aber nicht immer. Weil ich sonst keine Ideen mehr hatte, warum der Keyboard-Controller manchmal funktioniert und manchmal nicht, habe ich über die Betriebsspannungspins (1 & 4) direkt einen 47nF-Kondensator, den ich noch rumliegen hatte, gelötet, für den Fall, dass die Betriebsspannung unter irgendeiner Spitze einbricht. Leider keine Änderung des Verhaltens. Außer defektem Controller fällt mir im Moment nichts ein, was diese Art von Problem noch verursachen kann.

Zitat von fanhistorie

ES würde noch die MÖGLICHKEIT bestehen, extern einen Selbsttest des Bausteines an sich durchzuführen, dazu sollte er aber gesockelt sein,

Odet tausche auf Verdacht die Diode und den Kondensator im Reset Bereich aus, ob sich dann eine Änderung sich ergibt

Wenn du sowieso noch ein anderes System hast, dann ggf im Kreuzvergleich überprüfen

Danke für Deine Ideen!

Leider ist der Keyboard-Controller im Euro PC nicht gesockelt. Da ich keinn Entlötkolben mit elektrischer Pumpe habe, und das alte Lötzinn insbesondere nach dem Laugenangriff nicht gut fließt, halte ich es für sehr schwierig, den DIP40-Chip auszulöten. Ich habe in dem Euro PC gerade den Prozessorsockel gewechselt, und das Auslöten war selbst nach dem zerschneiden des Sockels in mehrere Teile noch schwierig. Über einen Tausch mit dem guten System habe ich schon nachgedacht, aber das würde heißen, 2* DIP40 auszulöten, und das insbesondere auch an einem derzeit funktionierenden System. Deshalb habe ich die Idee verworfen.

Die Reset-Schaltung zu tauschen wäre zwar möglich, aber da ich auf dem Oszilloskop bereits ein sauberes Signal gesehen habe, und der Chip einige Volt Hysterese auf dem Reset-Signal hat, kann ich eine Störung durch ein unsauberes Reset-Signal eigentlich ausschließen.

fanhistorie  Toshi

vielen Dank für eure Tips. Das Projekt Euro PC mit defektem Controller lege ich dann ein paar Tage ode Wochen zur Seite, und kümmere mich weiter drum, wenn ich passendes Werkzeug (u.A. Entlötlitze und Heißluft) zur Hand habe. In der Zwischenzeit habe ich schon mal zwei MC68705R3 (gebraucht, ungetestet) bestellt, und will mir einen Adapter für meinen ALL-03 bauen, um Ersatzcontroller programmieren zu können. Sollte alles ohne Verluste funktionieren, kann ich den zweiten überschüssigen selbstprogrammierten Controller auch gerne hier im Marktplatz anbieten.

Das Programm für den Controller werde ich selbst entwickeln, da es sich aber nur um das Scannen der Keyboard-Matrix, Erzeugung der Scan-Codes und Erzeugung des Reset-Signals bei Ctrl-Alt-BkSp handelt, sollte das Programm einigermaßen trivial sein.

Zitat von fanhistorie

Darf man vorab interessehalber nachfragen, mit welchem System, mit welcher Software du dann das Programm schreiben willst oder kannst,

Ehrlich gesagt weiß ich das noch nicht, da ich noch keinen Kontakt mit der 68xx-Architektur hatte, eine Recherche an Möglichkeiten steht noch aus. Aber ich gehe davon aus, einen 6805-Assembler im Internet zu finden, und wenn nicht, dann schreibt man sich "mal eben" halt selbst einen in Python, oder bastelt sich eine Opcode-Tabelle für einen generischen Assembler. Die Prozessorarchitektur ist im Datenblatt, was ich zurzeit vorliegen habe, ausreichend gut beschrieben.

Bei der Suche nach 6805-Tools bin ich auf einen interessanten Hinweis gestoßen:

Die Hinweise verdichten sich, dass in der Tat der Keyboard-Controller defekt ist, und zwar mit einem durchgefressenen Bond-Draht auf dem Pin "NUM" (non-user mode). Im Datenblatt des MC6805R2 steht, dass dieser Pin fest auf Masse liegen muss. Auf dem Euro-PC ist das auch der Fall, via JS11A, der auf der Platine schon permanent gesetzt ist.

Sollte dieser Pin allerdings nicht auf Masse liegen, wird der "Non-User mode" aktiviert, bei dem offenbar statt des internen "user" ROM ein externes ROM verwendet werden kann: http://matthieu.benoit.free.fr/6805.htm (siehe Abschnitt "NUM mode readout"). Dabei sind Port B und die unteren drei Bits von Port C (oops, habe ich das beim Messen am Anfang übersehen, das auf denen auch was passiert?) 11 Addressbits, die das externe ROM addressieren, und die Daten des externen ROM werden über Port A eingelesen. Dieser Betriebsmodus passt zu meiner Beobachtung: "Sobald der Controller aus dem Reset geht, wackeln die Port-B-Bits synchron zum Takt des Controllers".

Als besonders hilfreich kann sich herausstellen, dass auf Port B außer den Adressbits zum Einlesen eines externen Bytes immer dazwischen auch der Inhalt des internen ROMs an genau dieser Adresse ausgibt. Möglicherweise ist das für einen in-circuit-Emulator gedacht, der in der Regel die Bytes des internen ROMs durchleitet (von Port B nach Port A), aber auf bestimmten Adressen Breakpoints setzen kann (indem ein anderer Opcode angelegt wird, der den Chip zur Pause zwingt).

Sollte diese Theorie stimmen, komme ich möglicherweise um die Entwicklung eines eigenen Keyboard-Controller-Programms herum, weil der Keyboard Controller immer dann, wenn er nicht "korrekt" startet, sein eigenes ROM auf Port B ausgibt, so dass man es einfach kopieren kann.

Ich werde also noch mal prüfen, ob es einen Wackler an NUM gibt, so dass der Pin nicht so low ist, wie er sein sollte. Sollte es doch an der externen Beschaltung des NUM-Pins liegen, erübrigt sich das Projekt "KBC tauschen", und ich muss einfach die Verbindung dieses Pins mit Masse wiederherstellen. Und falls NUM intern kaputt ist, kann ich wie gesagt einfach eine Kopie machen, wenn das Ding "spinnt". Damit ist das Projekt "Eigenentwicklung eines Controller-Programms für den Euro-PC" erst mal auf Eis gelegt. Auf jeden Fall kann ich aber versuchen, den Originalcontroller zu dumpen, und zum Erhalt des Euro-PC den ROM-Dump des Originalcontrollers zur Verfügung stellen.

Theorie bestätigt!

Der Prozessor läuft offenbar undefiniert mal im NUM, mal nicht im NUM, unabhängig vom Pegel an Pin 7, der bei einem originalen MC6805U2 den Modus festlegen soll. Ich glaube, keiner weiß bisher genau, ob der Chip im Euro PC mit dem Label "ZC68115" das gleiche Bonding-Schema hat der MC6805U2, oder ob möglicherweise der NUM-Pin gar nicht herausgeführt werden soll.

Bei wiederholten Power-Cycles habe ich inzwischen beobachten können, dass sich an den Pins PC0 bis PC2 tatsächlich gelegentlich ein Rechtecksignal mit etwa 1/2/4kHz einfindet, wenn man Port A mit NOP versorgt. Das passt genau zu dem Posting über das Auslesen eines 6805 im NUM, in dem berichtet wird, dass bei 1MHz Takt sich das komplette Muster alle 16384µs wiederholt: Im Euro-PC wird der Chip nicht mit 1MHz, sondern mit 4MHz betrieben, so dass die Wiederholrate auf 4096µs heruntergeht, also etwa 250Hz für einen Durchlauf des Adressraums. Da an PC0 bis PC2 nicht die höchsten Adressbits liegen, sondern A9 und A10 mit auf die Port-B-Pins gemultiplexed sind, wiederholt sich das Muster dort schon nach Durchlauf eines Viertels des Adressraums, also mit 1kHz (für A8). Die Bits A7 und A6 haben dann natürlich die Frequenzen 2kHz und 4kHz.

Meine Ausleseversuche (in-circuit) sind fehlgeschlagen. Ich bekomme ein Image, in dem offensichtlich einiges nicht stimmt, obwohl die Signale auf dem Logik-Analysator glitchfrei aussehen, auch unabhängig von der Schwellspannung. Notwendige Anpassungen zum Auslesen (z.B. Kurzschluss zwischen PB5/PB6/PB7 entfernen) habe ich durchgeführt, ebenso fehlende Pullups ergänzt, den Reset-Transistor ausgelötet, der sonst PB3 runterzieht, und den HF-Filterkondensator auf KBDATA musste ich auch entfernen. Außerdem habe ich an PAx das Bitmuster für NOP angelegt. Das Auslesen ist aber völlig unnötig, denn jemand anders hier im Forum hat das schon mal gemacht.

RE: PC's von Schneider und Amstrad

Vielen Dank lvr

Zitat von jonnyjo

wenn du willst, kannst du mir einen MC68705U3 zuschicken. Das Board zum Programmieren habe ich mir vor einiger Zeit mal selbst nachgebaut und das EEPROM aus dem anderen Thread verwendet. Funktioniert in der Tat einwandfrei.

Damit habe ich bisher 6 Euro PCs wieder zum Leben erweckt. Und wie du hier schon geschrieben hast, war es immer der Reset zum FE2010A, den der Controller nicht mehr freigegeben hat, bzw. nur noch ganz sporadisch freigegeben hat.

Das mit dem Reset ist ja klar: Sobald der Controller soweit defekt ist, dass er nicht mehr zuverlässig bootet, schaltet er PB4 nicht mehr auf output/low. Ein Totalausfall dieses Controllers führt also immer dazu, dass der Reset nicht mehr freigegeben wird. Das Angebot zum Programmieren nehme ich gerne an, das vereinbaren wir außerhalb dieses Threads. Dann kann ich mir sparen, ein eigenes Programmiergerät zu bauen, bis ich später vielleicht irgendwann mal auf die Idee komme, einen getweakten Keyboard-Prozessor haben zu wollen.

Ich habe jetzt von jonnyjo meine MC68705-Chips programmiert bekommen, und damit kommt der Euro-PC zuverlässig aus dem Reset. Die Ursache des Problems war also in der Tat ein defekter Tastatur-Prozessor. Sowas kommt beim Euro-PC wohl häufiger vor.