Beiträge von MKarcher

    Ja, die großen blauen Bauteile sind richtig fette Kondensatoren, in denen eine große Menge Energie gespeichert werden kann. Es sind die 10.000µF / 17.000µF-Kondensatoren auf der letzten Seite im Schaltplan. Zu Deinem Glück: Die Dinger werden auf nicht mehr als 30V aufgeladen. Solange Du nicht mit pitschnassen Händen das ganze sehr ungünstig anpackst, kann dich die elektrische Energie da drin nicht umbringen. Das ist ganz anders als bei neuen Netzteilen, die erst mal die Netzspannung gleichrichten, da hast Du mehr als die zehnfache Spannung, und das kann richtig gefährlich werden. Dass die Spannung nicht reicht, dich ernsthaft zu verletzen, heißt aber nicht, dass es nicht gehörig knallen kann, wenn Du die Kondensatoren direkt nach dem Ausschalten kurzschließt. Und dadurch besteht die Gefahr, dass Du Dich aufgrund des Schrecks verletzt.


    Was man im Netzteil sieht: Da ist offenbar irgendwo so lange zu viel Strom geflossen (und damit wirds heiß), bis eine Sicherung wegen zu viel Strom durchgebrannt ist. Der Fehler muss nicht unbedingt im Netzteil liegen, sondern das Netzteil überhitzt auch wenn die Diskettenlaufwerke einen Kurzschluss haben, und zu viel Strom verbrauchen. Da es so aussieht, als ob das eine normal +5V/+12V-Versorgung ist, kannst Du ersatzweise probieren, das Gerät mit einem AT-Netzteil zu versorgen. Am besten kein zu leistungsfähiges, damit es im Kurzschlussfall früher abschaltet. Das Netzteil selbst braucht vermutlich keine Mindeslast (bzw. diese wird hoffentlich bereits durch die Spannungsteiler am Spannungsregler erzeugt), so dass man nach dem Ersetzen der Sicherung das Netzteil in Isolation testen kann (Voltmeter: Muss +5 und +12 rauskommen).

    ISA-Zyklen orientieren sich (fast) nicht am Bus-Takt. Die Timing-Beziehungen auf dem ISA-Bus gehen darauf, wann die Kommando-Pins wie /MEMR, /MEMW, /IOR oder /IOW aktiviert und deaktiviert werden, und lassen den Takt außen vor. Der Bustakt spielt nur im Zusammenhang mit 0WS (haben echte 8-bit-Karten eh nicht, da diese Funktion erst im AT eingeführt wurde) und als Sampling-Rate für IOCHRDY eine Rolle. Ein 8088-System lässt den ISA-Bus in der Regel direkt auf dem Prozessortakt laufen, so dass ein 8-Bit-Speicher-Zyklus 4 Prozessortakte dauert, das sins 838ns. Ein Zyklus kann verlängert werden, wenn die Karte IOCHRDY auf low zieht, was EGA-Karten häufig auch tun.


    In AT-Computern werden 8-Bit-Zyklen in der Regel so viele Wait States hinzugefügt, dass sie etwa die Geschwindigkeit von 8-Bit-Zyklen im IBM-PC bei 4,77MHz haben. Karten, die schnellere Zugriffe erlauben (der 286 kann Speicher- und I/O-Zugriffe in 2 Prozessortakten abwickeln) müssen sich als 16-Bit-Karten zu erkennen geben, und dann auch 16 Bit Busbreite unterstützen (Standard auf den meisten AT-Mainboards ist dann 1WS), oder durch früheres Bedienen der 0WS-Leitung den Waitstate-Generator auf dem Mainboard überstimmen.


    Das Ergebnis ist, dass 8-Bit-Zyklen in einem 8MHz-AT möglicherweise deutlich langsamer sind (durch mehr Wait-States) als in einem 7,16MHz-PC/XT. Es scheint, dass die EGA-Karte in diesem Thread mit dem verkürzten ISA-Timing bei 7,16MHz nicht klar kommt.


    Mein 10-MHz-Turbo-XT-Mainboard fügt bei 10MHz zu Speicherzyklen auf dem ISA-Bus (nicht aber im konventionellen Arbeitsspeicher) immerhin einen Waitstate hinzu, so dass die Zykluszeit von 838ns im Standard-Modus nicht auf 400ns sinkt, sondern immerhin 500ns übrig bleiben. Meine Genoa-basierte Super-EGA (kann bis zu 800x600) kommt mit dem 10MHz-Timing auf dem Board problemlos klar. Das Testen einer anderen EGA-Karte auf Kompatibilität mit dem 7,16MHz-Bustimings des Boards ist meiner Ansicht nach vielversprechend.

    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.

    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

    Die CheckIt-Werte sind mit an Sicherheit grenzender Wahrscheinlichkeit korrekt. 9.54 MHz ist genau das doppelte der 4,77 MHz des originalen IBM-PC, und war bei Turbo-XTs ein sehr verbreiteter Takt (andere übliche Takte waren 10MHz, 8MHz, oder 7,15MHz). Die Performance eines 8088-Systems hängt nicht nur davon ab, wie schnell der Prozessor Befehle verarbeiten kann, sondern je nach Anwendung mehr oder weniger auch davon, wie schnell er auf Daten und Befehle zugreifen kann. Das 8086/8088-Busprotokoll benötigt 4 Takte für einen Buszyklus, der bei einem 8088 gerade mal ein einzigen Byte übertragen werden kann. Für einen Befehl, der zwei Byte groß ist (wie zum Beispiel "MOV AX,BX") benötigt der 8088 also schon 8 Taktzyklen, um ihn aus dem Speicher in den Prozessor zu laden. Da hilft es dann nur noch wenig, dass der Prozessor diesen Befehl innerhalb von 2 Takten ausführen kann.


    Dein Board hat 5 Speicherchips zu je 262144 Einträgen mit 4 Bit (256k x 4). Da die Anzahl ungerade ist, können die Chips offenbar nicht paarweise als 8-Bit-Speicher verwendet werden. Ich vermute sehr stark, dass diese Spar-XT-Boards den Speicher als 1280 Kibi-Einträge zu je 4 Bit ansprechen, wobei bei jedem Prozessorzugriff zwei Zugriffe auf den Speicher durchgeführt werden, so dass virtuelle 640 Kibi-Einträge zu je 8 Bit entstehen. Dieses Zugriffsmuster kostet aber Zeit, die der Prozessor mit Wartezyklen ("wait states") verbringen muss, solange er das Ergebnis sofort braucht. Ein originaler IBM-PC hat bei 4,77MHz keine Waitstates im konventionellen Arbeitsspeicher (es sei denn, der Speicherbereich ist auf einer RAM-Karte, die von sich aus Waitstates fordert). Dein Board wird, zumindest bei 9,54MHz, Waitstates einlegen. Und diese Waitstates drücken auf die CPU-Performance.


    Theoretisch sollte ein V20 aber auch durch Waitstates nicht unter das 8088-Niveau gebremst werden können. Es ist aber durchaus möglich, dass das Befehlsmuster, was Landmark zur Messung der Taktfrequenz verwendet, nicht repräsentativ für normale PC-Nutzung ist, und tatsächlich vom V20 langsamer abgearbeitet wird als vom 8088.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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?