Hallo,
seit einiger Zeit bereitet mir mein alter PPG Waveterm Musikcomputer,
indem ein ELTEC EUROCOM II V7 Board eingebaut ist, Probleme.
Hier ein Bild vom Board:
http://www.fluide.de/download/wavterm_motherboard_oben.jpg
Das ELTEC EUROCOM II V7 Board basiert übrigens auf einer Motorola 6809
CPU.
Das Problem: der Computer bootet nicht mehr von Floppy und zeigt
kryptische Zeichen auf dem Monitor. Hier ein Bild von der
Monitorausgabe:
http://www.fluide.de/download/monitor.jpg
Serviceunterlagen gibt es übrigens hier als PDF:
http://www.seib.synth.net/documents/wt_b_serv.pdfhttp://seib.synth.net/documents/EurocomIIHW.pdf
Ich hatte bereits einige ICs ausgetauscht: den Floppy-Controller, CPU,
RAMs und EPROM. Leider keine Besserung. Habe jetzt wieder das
Original-EPROM und die alten RAMs eingebaut.
Nun liegt folgende Vermutung nahe:
Könnte auch sein, das die CPU den Adressbereich gar nicht anspricht,
weil sie vorher abstürzt.
Die unterschiedlichen Muster bei Ramtausch (auf dem Monitor) lassen das
nicht ganz unplausibel erscheinen.
Evtl. ist auch da was defekt:
CPU läuft los, alles prima.... CPU will was vom RAM, das liefert aber
nur Unsinn zurück... CPU stürzt ab oder rennt wirr durch den Code.
Da ich die Bootreihenfolge des Systems nicht kenne, weiß ich auch nicht
wie man da jetzt weiter schlaue Messungen austüfteln kann...
(So nach dem Motto: er kommt bis zum EPROM (klar, sonst passierte nix),
er kommt bis zum RAM, er kommt bis zum Floppy Controller, er schmiert
ab...)
Das Bild sieht zumindest so aus als ob die Grafik nicht korrekt
initialisiert wird.
Der Computer bootet normalerweise von Floppy, daher es sind zwei Floppys
eingebaut: eines zum Bootet und ein zweites, um Daten zu
speichern/laden.
Ich würde mich riesig freuen, wenn ich hier einige Tipps zur Fehlersuche
bekommen könnte.
LG aus Hamburg,
Cornel.
Ich fürchte ohne Logikanalysator und profunden Einblick in die 6809-CPU
wird das schwierig. Denn darauf dürfte es rauslaufen: den Bus der ab
Reset zu tracken und sehen wie weit sie kommt / wo sie aus dem Ruder
läuft.
Das Ding ist eine echte Sehenswürdigkeit, der Eurocom war ein feines
Teil - vor einem viertel Jahrhundert.
Du schreibst, daß Du das EPROM ausgetauscht hast.
Wo hast Du die Daten für das Ersatz-EPROM her? Hast Du dazu das
Original-EPROM ausgelesen?
Ist denn sicher, daß das EPROM noch den korrekten Code enthält? Auch
EPROMs haben keine ewig garantierte Datenhaltbarkeit, die Hersteller
haben Zeiten von etwa 10 Jahren garantiert ... und ein 6809-System ist
ja nun ein kleines bisschen älter.
Je nachdem, wie gut das EPROM programmiert wurde (Das Nichteinhalten der
vom Hersteller spezifizierten Programmieralgorithmen war ein beliebter
Sport auch bei Herstellern von Programmiergeräten) können die Daten mit
der Zeit flau werden.
Aus der Tatsache, daß ein Videosignal erzeugt wird, kannst Du nicht
ableiten, daß CPU und EPROM überhaupt was sinnvolles machen, denn -so
wie im Handbuch beschrieben- die Videologik ist "diskret" in TTL-Logik
aufgebaut und verwendet nicht einen programmierbaren Videogenerator wie
den 6845. Der würde erst nach erfolgreicher Initialisierung ein
korrektes Videotiming erzeugen, so daß man aus dem Vorhandensein des
Timings auf die korrekte Initialisierung schließen könnte ...
"Dank" des "diskreten" Aufbaus aber funktioniert die Videologik
vollkommen unabhängig von der CPU.
Ich würde auch zunächst den EPROM-Inhalt überprüfen. Einige Geräte
kommen nach 10-15 Jahren zurück, weil das EPROM seine Information
verloren hat, teilweise auch komplett.
Rufus t. Firefly wrote:
> Du schreibst, daß Du das EPROM ausgetauscht hast.> Wo hast Du die Daten für das Ersatz-EPROM her? Hast Du dazu das> Original-EPROM ausgelesen?
Ich habe glücklicherweise das Original-Image zur Hand und mir damit neue
EPROMs brennen lassen. Hier das Image-File:
http://www.fluide.de/download/rom.bin
Läßt sich daraus erkennen, ob es fehlerhaft ist?
Ich habe das Imagefile zusammen mit den EPROMs zu Batronix Elektronik
geschickt, die einen Brennservice anbieten.
Aber es ist egal ob ich den Alten oder die neuen EPROMs einsetze: das
Monitorbild ändert sich nicht.
Was auch unklar ist:
http://www.fluide.de/download/pal1.gif
Grün: anliegender Puls
Gelb: messbare Spannung
Rot: keine Spannung/Signal (PS (per IS9.4) Dauer-Low ist ok)
Wie man sieht fehlt hier /GAP am Ausgang und kann darum nicht zum PAL2
gelangen. /GAP sollte die Devicelücke für den Floppydisc-Controller
erzeugen.
Schaut doch nach einem defekten PAL aus, oder irre ich mich?
Gruss,
Cornel
Gut, wenn das Original-Image vorhanden ist, dann sollte das EPROM schon
in Ordnung sein.
Am Image selber kann man nicht erkennen, ob es in Ordnung ist; man
müsste es durch einen 6809-Disassembler schicken und dann das
Disassemblat analysieren.
Da die Hardware des Systems recht gut dokumentiert zu sein scheint,
könnte man nun mit selbstgeschriebener Testsoftware anstelle des
EPROM-Inhaltes weiter vorgehen.
Es gibt einen undokumentierten* Opcode für den 6809, mit dem der zu
einem Adresszähler mutiert; es werden aufeinanderfolgend alle Adressen
von $0000 bis $FFFF auf den Bus gelegt und ein Lesezyklus durchgeführt.
Mit einem Oszilloskop bzw. eher einem Logikanalysator könnte man so
zunächst die Adressdecodierung überprüfen.
In diesem Zusammenhang ein großes Lob an die Firma Eltec, die im
Handbuch sogar die PAL-Logikgleichungen veröffentlicht hat, ohne die die
Platine kaum reparierbar wäre.
Ein weiterer Test bestünde darin, ein Programm zu schreiben, das ohne
RAM auskommt und über die serielle Schnittstelle Zeichen ausgibt. Darauf
aufbauend ließe sich ein RAM-Test programmieren, der das RAM mit
definierten Bitmustern füllt. Die sollten dann spätestens auch auf dem
angeschlossenen Monitor zu sehen sein.
Naja, und bei all diesen Dingen kann man sehr schön mit einem
Oszilloskop/Logikanalysator dem 6809 auf die Beinchen gucken.
*) http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
Rufus t. Firefly wrote:
> Am Image selber kann man nicht erkennen, ob es in Ordnung ist; man> müsste es durch einen 6809-Disassembler schicken und dann das> Disassemblat analysieren.> Es gibt einen undokumentierten* Opcode für den 6809, mit dem der zu> einem Adresszähler mutiert; es werden aufeinanderfolgend alle Adressen> von $0000 bis $FFFF auf den Bus gelegt und ein Lesezyklus durchgeführt.> Mit einem Oszilloskop bzw. eher einem Logikanalysator könnte man so> zunächst die Adressdecodierung überprüfen.> Ein weiterer Test bestünde darin, ein Programm zu schreiben, das ohne> RAM auskommt und über die serielle Schnittstelle Zeichen ausgibt. Darauf> aufbauend ließe sich ein RAM-Test programmieren, der das RAM mit> definierten Bitmustern füllt. Die sollten dann spätestens auch auf dem> angeschlossenen Monitor zu sehen sein.>
Einen ähnlichen Tipp hatte ich auch schonmal erhalten. Leider verfüge
ich über keinerlei Erfahrungen im Schreiben von Programmen und ich würde
mich riesig freuen, wenn sich jemand hier im Forum finden ließe, der mir
diese Testroutinen schreiben könnte. Sollte auch nicht umsonst sein.
LG
Cornel
'Blöde' Frage zwischendurch: wie sieht es denn mit dem Netzteil aus?
Sind die Spannungen während des versuchten Bootvorgangs stabil oder
sackt da evtl sogar etwas ein...?
Gruss, Ingo.
Das mit den Spannungen ist eine gute Frage: kann ich mom nicht
beantworten, muss ich nachmessen.
Könnte ein alter Siebelko auch für Spannunsgeinbrüche sorgen?
Gruss,
Cornel
Ja, sicher. Ein alter Siebelko im Netzteil kann dafür sorgen, daß
ordentlich "Brumm" der Versorgungsspannung überlagert wird. Wenn denn
ein Trafonetzteil mit Brückengleichrichter verwendet wird ...
Rufus t. Firefly wrote:
> Ja, sicher. Ein alter Siebelko im Netzteil kann dafür sorgen, daß> ordentlich "Brumm" der Versorgungsspannung überlagert wird. Wenn denn> ein Trafonetzteil mit Brückengleichrichter verwendet wird ...
Ich hatte die Versorgungsspannungen auch mit dem Oszi überprüft: die
sind schon etwas wellig.
Aber da ich die Becherelkos sowieso austauschen wollte (hab sie auch
schon da, sollte ich dieses mal auch in Betracht ziehen.
Gruss,
Cornel
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Thread beobachten
Seitenaufteilung abschalten
