ARNTE schrieb:
leider habe ich nur die hälfte verstanden
aber darum habe ich den JX8P ja auch aus der hand gegeben und hoffe, dass Black2545 da mehr mit anfangen kann...
das hoff ich auch, für ihn waren diese Details auch gedacht
zu den fragen:
ich habe den JX8P defekt bekommen. am anfang war der RAM aber intakt. d.h. ich konnte speichern und die sounds blieben auch drin. problem war eigentlich nur die tastatur und gelegentliches "abschmieren" des synths. er hat einfach versucht neu zu starten und ist dann beim runterzählen irgendwo hängen geblieben.
nach ein paar wochen waren dann die hyroglyphen im display und es ließ sich nichts mehr speichern.
Das mit dem Runterzählen irritiert mich schon die ganze Zeit. Ich kann mich nicht erinnern, daß mein JX sowas gemacht hat, muß aber auch nicht. Scheint sowas wie ein Selbsttest zu sein, da muß ich nochmal ins kommentierte Firmwarelisting schauen.
Das mit dem Abschmieren und neu starten klingt nach mehr als nur Speicherbatterie, sondern wirklich nach einem Chipdefekt irgendwo, kann auch gut der Speicherchip sein.
nochmal zum midi out: es kamen zwar noten über midi out allerdings mit einem enormen zeitverzug (ca. 30 - 45 sekunden). ich war mir damals nicht sicher ob das am midi interface hing oder am synth (ich hatte dazu ein extra midi interface an meinen mac gehangen, welches ich sonst nicht verwende). nach den erklärungen oben kann ich mir nun aber gut vorstellen, dass das tatsächlich am synth lag.
Interessant. Das würde für ein Kommunikationsproblem zwischen Hauptprozessor und dem Tastaturabfragechip sprechen. Dessen Taktgenerator und Resetleitung gehen aber, sonst würde der JX erst garnicht starten.
kann man diesen chip einfach tauschen? wo bekommt man den her? was kostet das?
Wenn man denn einen bekäme könnte man ihn tauschen, aber ich fürchte, daß ist nicht der Punkt, sondern der Fehler liegt an einer anderen Stelle.
Nachdem Chipversion und Firmware auch übereinstimmen wird Dein Kollege den Fehler genauer einkreisen müssen, und wie gesagt: ohne Oszi oder noch besser Logikanalyser wird er da nicht weiterkommen.
Nach dem Lesen Deines Beitrags hab ich so das Gefühl, daß entweder einer bzw beide RAM-Chips defekt sind (was ich ungewöhnlich finde) oder einer der Logikgatter, der die Kommunikation zwischen Tastaturchip und Hauptprozessor regelt (Adreßdekoder zB) einen Hau hat. Solchen Fehlern kommt man wirklich nur mit dem Oszi bei.
Was mir die ganze Zeit auch noch im Kopf rumschwirrt ist: ich kenne solche komischen Zickereien von Geräten, die einen Flüssigkeitsschaden abbekommen haben. Korrodierte Leiterbahnen und halb weggefressene Bauelemente werden da plötzlich zu Störquellen, die einem in den Wahnsinn treiben.
@Black2545: konntest Du im Gerät irgendwo Anzeichen eines Flüssigkeitsschadens entdecken? zB hinten im Bereich der Buchsen?
Was mir auch noch einfällt: im Servicemanual gibts eine Modifikation, die für sicheres Timing zwischen MCU und dem 63H149 sorgt. Wenn an dieser Stelle sich durch Bauteilealterung nochmal was verschoben hat, könnte das auch eine Ursache sein, aber das kann man nur mit dem Logikanalyser rausfinden.
Wie oben schon aus der Erinnerung geschrieben und durch die Anmerkungen bei Colin Fraser bestätigt, wird eine gedrückte Taste per Interrupt dem 6803 mitgeteilt, der dann in der Interruptroutine zuerst den Status des 63H149 abfragt (Interruptquelle) und dann die Daten der gedrückten Taste aus den Registern des Tastaturchips abholt.
Wenn die CPU an dieser Stelle die Daten nicht lesen kann, weil das Hardwaretiming zwischen den beiden Chips nicht stimmt, wäre das eine Erklärung für die enorme Zeitverzögerung. Ich muß mir die Firmware da mal genauer anschauen, kannst Du aber auch machen, den Link habe ich ja oben gepostet. Ist zwar vom JX-10, aber da dieser die identischen Komponenten und Abfragetechnik verwendet, kann man das übertragen.
Ergänzung: Ich hab gerade mal die Excel-Datei von Colin mit den Firmware Notes (myjxnotes.xls) angeschaut, da hat er ganze Arbeit geleistet und das System wirklich lückenlos dokumentiert, echt klasse.
Demnach teilen sich die Assigner-CPU (6803) und der 63H149 das an diesem angeschlossene 2k-RAM als "Scratchpad", es wird im Bereich der CPU von $1000-$17FF eingeblendet. Die Adresse, die ich in der Firmware zuerst für den Interrupt gesehen hatte, war die Prüfung, ob eine Cartridge eingesteckt ist, die löst nämlich auch einen Interrupt aus. Sämtlicher Status der Tastatur und Daten werden in diesem Baustein zwischengespeichert, und auch der Stack für den Prozessor liegt in diesem RAM. Demnach ist mein zuerst geschriebener, späterer Absatz mit eventuellen Kommunikationsproblemen zwischen diesen beiden Chips hinfällig, denn wenn die nicht stimmen würde, könnte der Prozessor erst garnicht arbeiten und der Synthi würde rein garnichts machen oder nur noch rumspinnen.
Ein Teil der Arbeitsvariablen liegt dagegen im Speicher des 6803 selbst (Zeropage wg schneller Adressierung). Einfach mal in diese Tabelle schaun. Wenn man einen solchen Fehler finden will, kommt man nicht umhin, die Arbeitsweise der Firmware zu verstehen.
Wenns kein Flüssigleitsschaden ist, dann kanns auch einer der Widerstandsnetzwerke sein, was defekt ist. Diese werden im JX für Pullups benutzt, und Leitungen, die nicht sauber auf einem bestimmten Pegel gehalten werden, machen ebenfalls reichlich Ärger, weil sie unberechenbar sind - mal gehts, mal nicht. Auch sowas kann man nur mit dem Oszi aufspüren, ist aber reichlich nervig. Durch den recht einfachen Aufbau des Assigners hält sich aber der Suchaufwand in Grenzen.
irgendwie muß dem Kram doch beizukomen sein. Ich hoffe sehr, daß es kein Flüssigkeitsschaden ist, denn sowas ist ein Faß ohne Boden, je nach Ausbreitung. Hatte ich hier schon mehrfach, einmal bei einem alten Heimcomputer aus den 80ern, und das war übel. Nicht zu vergessen die Säureschäden eines ausgelaufenen Speicherakkus beim Korg Polysix - da kann man idealerweise am besten das Assigneboard tauschen ...
Zur Anmerkung von Florian gerade eben: Nicht nur die Matrixleitungen und deren Stecker anschauen (sind die vertauschbar? korrekt zugeordnet?), sondern auch die Widerstandsnetzwerke prüfen, die an den beiden Sammelschienen anliegen. Defekte Pullups erkennt man mit dem Oszi, da stimmt der Pegel bzw die Flanke nicht.
Nach dem Durchschauen von Colins Exceldatei glaube ich langsam aber an eine andere Fehlerquelle, vielleicht ist ja wirklich das Arbeits-RAM (6116) hin.