Wiederbelebung Sage II


  • Danke! :)

    »It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.« (Edsger W. Dijkstra)


    Homespage| Computerarchäologie | Blog | Forschung

    • Offizieller Beitrag

    Heute mal das Netzteil überarbeitet. Besonders die Kontakte sehen schlimm aus, auch die Kontakthülsen in den Molexsteckern sind stark oxidiert. Werde mal versuchen, mit Interdentalbürsten und Kontakt WL diese blank zu bekommen. Der Hauptschalter hatte 4 Ohm Übergangswiderstand wegen der oxidierten Kontakte. Im Inneren des Schalters ist ein Fett! Kennt jemand sowas oder hat sich da jemand einen Scherz erlaubt? Die Elkos waren alle noch in Ordnung, hab sie trotzdem ausgewechselt. Der Rechner ist von 1982 und die Elkos waren alle top (C/ESR). So langsam glaube ich, es ist ein Märchen, daß Elkos in NTs schnell degradieren.

  • Einspruch - Schalter ohne Fett sind normal.
    Ich habe noch in keinem anderen Gerät als einem C64 einen mit Fett gefüllten Schalter gesehen.


    ... jetzt ja ... den von Toshi ... ;) !


    Ich bin bei meiner Antwort davon ausgegangen, das in seinem Schalter Fett hingehört ... wie halt beim C64. Der ist ja nur extrem wenig gefettet!

    • Offizieller Beitrag

    Mein Sage quält mich weiter. Ich habe nun alle (alle!) ICs des Sage-II Boards ausgetauscht. Ich habe nun als einzigen Effekt eine etwas besser bestückte Sammlung von 74LSxxx ICS. Leider ist das Fehlerbild gleich geblieben, die Maschine bootet nicht durch, sondern bleibt nach ca. 50% der Zeit des Bootvorgangs mit roter LED hängen.
    Hat irgendwer einen Tip, woran es jetzt noch liegen kann?
    Muß ich jetzt nach und nach die IC Sockel tauschen, in der Hoffnung, daß es daran liegt?


    Oder gibt es einen etwas weniger stumpfsinnigen Weg der Fehlersuche? Irgendwas (mit dem LA) messen?


    Noch nicht geprüft sind die Kondensatoren, Widerstände und Widerstandsarrays (blaue Käfer) sowie der Quarzoszillator.

    • Offizieller Beitrag

    Muß ich jetzt nach und nach die IC Sockel tauschen, in der Hoffnung, daß es daran liegt?


    Das wäre digging in the dust.

    Oder gibt es einen etwas weniger stumpfsinnigen Weg der Fehlersuche? Irgendwas (mit dem LA) messen?


    Deutlich besser. Aber was messen? Das lässt sich auch nicht in 3 Zeilen klären.
    Hast du einen LA?


    Ich hab auch etwas den Überblick verloren.
    Ein Board funktioniert, das andere nicht? Gleiches OS?
    Kannste den Sachverhalt nochmal kurz erklären?


    Nachtrag: Was ist den mit dem Parity Error geworden?


    Viel Erfolg.

  • Hat irgendwer einen Tip, woran es jetzt noch liegen kann?



    Ja. Ich hatte mal einen Fall ... eine alte VC1541 ... die ich gereinigt, geprüft & mit meinen Möglichkeiten repariert habe. Die lief einwandfrei und ist/war technisch einwandfrei. 100%! Von einem Tag auf den anderen war sie im Dauerlauf. 1 IC saß eine Spur zu locker im Sockel ... die Beinchen hatten wohl an 1 oder mehreren Pins keinen Kontakt.


    Optisch sieht man da gar nichts ... ich habe die IC-Beinchen etwas "strammer" gebogen ... und siehe da ... es lief alles wieder einwandfrei.


    Du kannst im Prinzip nur die IC-Sockel der Reihe nach mal durchchecken ... ich weiß, Sauarbeit ... und schauen, wo vielleicht ein IC "zu locker" drin sitzt.


    Danach fällt mir auch nichts mehr ein. Dann geht es ja schon fast an die Leiterbahnen und die Platinen.


    Du könntest dann höchstens nochmal eine Ladung Kältespray über das Board ziehen ... ansonsten bin ich erstmal ratlos.

  • ... und vielleicht noch etwas aus meiner Reperatur-Erfahrung mit ICs (C64) ... bei ICs gibt es nicht schwarz-weiß "GOOD" or "BAD" ... da gibt es eine Grauzone ... sagen wir mal 80% "GOOD" ... oder langsam "sterbende" ICs ... Stichwort: Höhenstrahlung ... IC-Killer Nr. 1!

  • ... allerletzte Idee, die ich habe. Du bräuchtest quasi einen Sage II als "Testrechner", der 100% läuft, wo du deine ICs (die du anderweitig in keinem anderen Computer testen kannst) testen kannst.

  • Schwach werdende Roms... mal mit verschiedenen Spannungen auslesen - sollten zwischen 4,5 und 5,5V Unterschiede sein, ist das Rom vmtl. grenzwertig.


    Dann hilft evtl. das Auslesen mit verminderter Spannung - bis runter zu 4V sollte funktionieren - um an ein fehlerfreies Abbild zu kommen.

  • Ich bin ja überhaupt kein Freund dieser Tauschorgien "auf gut Glück". Meine Strategie ist allerdings auch etwas "mühsam", und Erfahrung habe ich damit hauptsächlich bei meinen Maschinen ohne Mikroprozessor. Ob das bei 68K eine sinnvolle Methode ist kann ich also nicht sagen. Ich möchte sie dennoch als Variante vorschlagen.


    Voraussetzung ist, dass die Maschine halbwegs gut dokumentiert ist (Schaltbild sollte vorhanden sein) und der Fehler bei der Abarbeitung der Firmware, d.h. vor dem Laden und Ausführen des OS auftritt. Soweit ich das verstanden habe, ist beides hier der Fall.


    Weiterhin braucht man ein ROM-Listing - da reicht aber normalerweise auch ein Disassemblerlisting der ROM-Inhalte.


    Ich prüfe dann mit dem LA den Weg, den der Prozessor durch die Firmware nimmt. Irgendwo weicht er vom Soll-Pfad ab - das gilt es zu finden und dann die Ursache zu ergründen. Wenn er z.B. in einer Schleife läuft, die er nie verlässt, ist anhand des Rom-Listings zu prüfen, an welchen Stellen die Schleife verlassen werden müsste, und welche Bedingungen dafür gelten. Mit Hilfe des Schaltplans kann man dann die relevanten Signale identifizieren und gezielt untersuchen.


    Ist zugegebenermaßen auch nicht trivial, aber meiner Meinung nach besser als dieses Stochern im Nebel.


    Bei Mikroprozessoren kommen hier natürlich eine ganze Menge Störungen hinzu: ROM- und I/O-Adressen gemischt auf dem Adressbus, mehrere OP-Codes-Fetches pro Befehl, Interrupts, DMA, Refreshzyklen usw. - das wäre zu prüfen, inwieweit man da mit meiner Methode voran kommt. Beim Z80 habe ich das mal gemacht - wenn man ein paar weitere Signale dazunimmt (beim Z80 afair das M1-Signal) geht das aber einigermaßen.


    Ach ja : Die ROMs sollten schon zuverlässig sein. Also gerne die Tipps von Dosenware beherzigen, und/oder mit einen sauberen Image neue EPROMs brennen.

    • Offizieller Beitrag


    Ich hab auch etwas den Überblick verloren.
    Ein Board funktioniert, das andere nicht? Gleiches OS?
    Kannste den Sachverhalt nochmal kurz erklären?


    Grade funktionieren beide nicht. Ich habe mich nun erst mal um das Board gekümmern, was noch nie lief, aber alle ICs gesockelt sind. Deshalb habe ich neue beschafft und einfach alle getauscht in der Hoffnung, so einfach das Ding wieder zum laufen zu bekommen.
    Hat leider nicht funktioniert.
    Ich habe eben am besagten, voll-gesockelten Board den CPU Takt mit dem Oszi gemessen. Es sind 8Mhz, aber der Signalverlauf ist kein schönes Rechteck. Und wenn ich messe, läuft der Rechner nicht. Wahrscheinlich frißt die Messung einen Teil der Amplitude, und dann reicht es nicht mehr für die CPU? 5V Peak to Peak sollte aber i.o sein, oder?

    • Offizieller Beitrag

    Ich bin ja überhaupt kein Freund dieser Tauschorgien "auf gut Glück".


    Nun, ich stimme Dir zu. Aber ich bewege mich hier im Rahmen meiner Möglichkeiten. Über die Kenntnisse, welches Du hier skizzierst, verfüge ich noch nicht. Aber möglicherweise wäre dieses Problem der richtige Zeitpunkt, zu versuchen sie sich anzueignen.


    Weiterhin habe ich in der Doku für die SAGE gefunden, daß es einen ROM - Monitor gibt. Damit kann man sich Speicherbereiche und die Registerinhalte ansehen usf. Könnte das hier helfen? Der Monitor läßt sich bedienen. Problematisch wird es nur beim Booten von Floppy.

  • Grade funktionieren beide nicht.
    ...
    Ich habe eben am besagten, voll-gesockelten Board den CPU Takt mit dem Oszi gemessen. Es sind 8Mhz, aber der Signalverlauf ist kein schönes Rechteck. Und wenn ich messe, läuft der Rechner nicht.


    Ich glaube, wir sollten mal den Begriff "laufen" klären ;)
    Beide funktionieren nicht, aber ... wenn Du misst, läuft der Rechner nicht. Hört sich für mich an, als ob er ohne Messung läuft. Aber er funktioniert nicht. ?(
    Woanders schreibst Du, dass der ROM-Monitor läuft.
    Muss ich das so verstehen, dass der Rechner "läuft" im Sinne von "Startmeldung kommt, Monitor kann aufgerufen werden und funktioniert, aber das Booten des OS klappt nicht"?
    Das wäre einiges mehr als ich erwartet hätte.
    Mit dem Monitor kannst Du z.B. das RAM testen. Wobei das der Selbsttest sicher besser macht. Vielleicht kannst Du auch einfache Diskzugriffe testen. Auf diese Weise könnte man wieder etwas gezielter nach dem Fehler suchen.


    Der Hinweis mit dem Interruptbetrieb ist dann auch ganz wichtig. Vielleicht gibt ss dort ein Problem jenseits des Controllers. Das ist allerdings auch schwer zu testen oder nachzuvollziehen...


    Die Sache mit dem Takt kann mehrere Erklärungen haben. Nicht jedes Oszilloskop kann ein 8MHz-Rechteck als Rechteck darstellen. Mein olles 20MHz zeigt auch oft einen Sinus, wo das gute Tek ein Rechteck zeigt. Zu niedrige Eingangsimpedanz, schlechte Tastköpfe - das könnte auch den Einfluss auf den Rechner erklären. Wobei Dein Oskar sooo schlecht nicht aussieht, solche Einflüsse würde ich nicht erwarten. Vielleicht gibt es da auch schon Probleme ...

    • Offizieller Beitrag


    Ich glaube, wir sollten mal den Begriff "laufen" klären ;)
    Beide funktionieren nicht, aber ... wenn Du misst, läuft der Rechner nicht. Hört sich für mich an, als ob er ohne Messung läuft. Aber er funktioniert nicht.


    Hallo Georg,


    danke für die Erläuterungen!
    Ich bitte die unpräzise Formulierung zu entschuldigen. Der Rechner stoppt/nimmt keine Tastaturmeldungen mehr entgegen, wenn der Tastkopf am CLK Pin der CPU liegt. Er zeigt auch keine Startmeldung, wenn man den Tastkopf am CPU-CLK Pin eingeklipst läßt und den Rechner startet oder resettet. Ja, Du hast richtig verstanden, er bootet bis zu einem bestimmten Punkt (CP/M-68k oder P-System) und stoppt dann. RAM Test und Monitor funktioniert. Mit dem Monitor kann man Diskettenzugriffe durchführen.
    Das Oszi ist ein 40Mhz-Gerät von Hameg ohne Speicher. Sowas was früher in Schulen verwendet wurde. Beim C64 ist der Takt ein ziemlich gutes Rechteck. Aber das ist nur ein Achtel der Frequenz.

  • Stephan, kein Problem, nur gut zu wissen, was geht und was nicht.
    Um die Fragestunde vollständig zu machen: wir reden von dem gesockelten?
    Wie sieht das bei dem anderen aus? Genauso, oder ein anderes Fehlerbild?


    Was den Takt angeht würde ich übrigens erwarten, dass ein 40MHz-Hameg das besser hinbekommen sollte, und nicht so gravierende Einflüsse auf den Rechner haben sollte.


    Ersteres kannst Du ja mal an einem Frequenzgenerator oder alternativ an jedem anderen Rechner mit 8-10 MHz testen. Z.B. auch an der ungesockelten Sage. Wie gesagt, da würde ich bessere Bilder erwarten.


    Du warst aber am echten Taktsignal, und nicht einfach am Quarz? Entschuldige, falls die Frage zu blöd war :S


    Wobei ich mir nicht vorstellen kann, dass Probleme an dieser Stelle zu dem beschriebenen Fehler führen...

    • Offizieller Beitrag

    Stephan, kein Problem, nur gut zu wissen, was geht und was nicht.
    Um die Fragestunde vollständig zu machen...


    Hallo Georg,
    ja, genau, das gesockelte Board liegt gerade auf dem Tisch. Ich werde morgen mal bei einem Amiga 500 messen, der hat ja eine ähnliche Taktfrequenz. Gemessen habe ich mit GND des Tastkopfes am Netzteil-Ausgang und mit der Tastkopfspitze am Pin 14 der CPU (CLK).


    Wenn der Rechner nach dem boot-Versuch stoppt, ist totenstille auf dem Bus, alle Daten- und Adreßleitungen auf Low. Der DRAM-Refresh ist noch da mit 64kHz und auf der Enable Leitung der CPU ist ein sauberes Rechteck mit 1.7 Mhz.


    Ich habe leider einen NF Generator bis 2Mhz hier.

  • 8MHz sollten zu finden sein. Dein Arduino hat 16. Wäre auch was zum Vergleichen. Sagt nur leider nichts aus, wenn der Oskar das nicht schafft - nur umgekehrt würde es etwas beweisen ...
    Ansonsten die andere Sage oder auch Amiga. Hast Du keine Wang 2200? Die haben 10MHz :D


    Die restliche Beschreibung bezieht sich auf das "normale" Bootproblem, d.h. ohne Oskar? Ist interessant, aber zur Interpretation müsste man jetzt was vom 68K oder der Sage wissen. Komplett tote Busleitungen heißen entweder, er wurde angehalten (gibt es sowas wie einen Halt Befehl? Oder einen Trap o.ä. bei irgendwelchen ungültigen Opcodes, Adressen o.ä., die ihn anhalten?), oder auch, ganz bescheuert (ich komme drauf, weil in einem der zuletzt diskutierten Z80-Designs genau so was gemacht wurde): ein Dauer-Reset?


    Das wäre übrigens ein Ansatz für meinen Lösungsweg: Die Busleitungen mit dem LA abhorchen, Trigger auf z.B. 10 Takte mit "totem" Adressbus, und die Aktivitäten genau davor analysieren.


    Und dann ist noch interessant zu wissen, was auf den Leitungen los ist, wenn der Oskar den Takt "klaut"...


    Georg

  • Also, als das zweite Board noch lief, liefen beide ROM Sätze im "guten Board" und kein ROM Satz im "schlechten Board". Meinst Du ein Auslesen im Eprom Brenner und erneutes Schreiben auf frisch gelöschte Eproms kann eine Verbesserung bringen?


    Wenn ein Kreuztausch der Roms funktioniert, ist das Rom höchstwarscheinlich unschuldig - bei den später erwähnten Problemen (Romteil läuft sauber, Booten von Diskette nicht) ist der Rom ebenfalls höchstwahrscheinlich unschuldig.


    Was das Auslesen betrifft: mit manchen EPrommern (z.b. dem TL866CS) kann man die Spannung beim Auslesen einstellen:
    - Erhöht man die Spannung kippen schwache Zellen beim Auslesen auf 1 (gut für den Verify nach dem Brennen)
    - Verringert man die Spannung werden auch schwache Zellen mit höherer Wahrscheinlichkeit korrekt (also mit 0) ausgelesen


    Das klappt jedoch nur in einem gewissen Rahmen, eine zu hohe Spannung ist schädlich und bei einer zu niedrigen Spannung funktioniert der Logikteil des Eproms nicht mehr korrekt und du bekommst massig Fehler.
    Wenn man dann ein sauberes Image hat, kann man es einfach rüberbrennen - es werden eh nur 0bits geschrieben und da die schwachen Zellen auf 1 gewechselt sind passt das. (und du ersparst den Roms das löschen)


    Zitat

    Ja, Du hast richtig verstanden, er bootet bis zu einem bestimmten Punkt (CP/M-68k oder P-System) und stoppt dann.


    Nur zur Sicherheit: Lief das am anderen Sage schoneinmal? Oder hatte der das Gleiche Problem?
    Andere Diskette/anderes Diskettenlaufwerk probiert? (nicht das der Sage wegen eines schnöden Lesefehlers Probleme macht)

    • Offizieller Beitrag

    Gemessen habe ich mit GND des Tastkopfes am Netzteil-Ausgang und mit der Tastkopfspitze am Pin 14 der CPU (CLK).


    Das reicht fuer dein "unsauberes" Clock Signal. Du musst den GND in der naehe desTastkopfes nehmen, nicht laenger als die GND Strippe am Tastkopf.


    Wenn der Rechner nach dem boot-Versuch stoppt, ist totenstille auf dem Bus, alle Daten- und Adreßleitungen auf Low. Der DRAM-Refresh ist noch da mit 64kHz und auf der Enable Leitung der CPU ist ein sauberes Rechteck mit 1.7 Mhz.


    Ich hab mich gestern mal in die 68000 eingelesen. Nach einem Double Bus Fault stellt die CPU den Betrieb ein und aktiviert das /HALT Signal (also /HALT = 0). Dieser Fault entsteht, wenn ein Bus Error (/BERR = 0) auftritt, waehrend eine Bus Error Exception bearbeitet wird, also eben ein doppelter Bus Error.
    Das waere auf jeden Fall eine gute Triggerbedingung zum messen, am besten mit dem LA.


    Mit dem Enable Signal meinst du das E vom Prozessor? Das ist ein Takt fuer aeltere 6800 Peripheriebausteine.


    Toshi, wenn du willst, komm nochmal vorbei und wir messen das Board durch (Urlaubsbedingt dann erst im September) oder ich bring den LA zur CC mit.

    • Offizieller Beitrag

    Heute mal das Netzteil überarbeitet.


    Das überarbeitete Netzteil lebte genau 5 Minuten. Jetzt ist 5V Schiene tot. Alle Dioden, Z-Dioden und Transistoren ausgelötet geprüft und I.O.
    Alle Elkos gewechselt. Primärseite und 12, -12V in Ordnung. Optokoppler getauscht.


    So langsam macht mich diese diabolische Sage mürbe.

    • Offizieller Beitrag

    Liegt vielleicht irgendwo ein Kabelbruch/-wackler/-abriss etc. vor, den man nicht sieht?


    Ne. Hab jetzt auch alle Widerstände geprüft. Zumindest im eingebauten Zustand mit Multimeter gibt es keinen, der "unendlichen" Widerstand hat. Reicht das aus? Eigentlich sind Widerstände doch immer ok oder extrem hochohmig, oder?