Ich wiederum muss mich auf die Aussagen vom Programmierer Peter Thierolf verlassen - wenn ich die höre, habe ich meiner Meinung nach "first hand info". Wenn ein Crack früher verfügbar war, ist das zumindest in den ihm zugänglichen BBSs nicht der Fall gewesen.
Posts by Wiesel
-
-
Warum macht Ihr so ein Geheimnis aus den Details? Ich habe schon vor vielen Jahren im A1K.org Forum erklärt, wie man RDY aus dem Index-Signal erzeugt. Und No-Click kann man super implementieren, indem man die Direction-Leitung immer auf "nach außen" stellt, wenn keine Disk eingelegt ist - dann hört das Laufwerk irgendwann automatisch auf zu klicken wenn's Track0 erreicht hat. Das geht komplett in Hardware, ganz ohne Microcontroller. Die Bilder sehen so aus, als würdet Ihr einen Microcontroller verwenden - allein das ist schon ein no-go, weil dadurch Timings verschoben werden und schlecht programmierte Trackloader versagen könnten. Warum nicht mit ein paar TTL-Chips? Die Samsung-Stepfehler kann man ignorieren, bzw. mit einem Monoflop angehen wenn man's denn unbedingt haben möchte - ich persönlich würde einfach Teac empfehlen und gut ist.
-
Schau' mal auf das Laufwerk selbst, da ist entweder ein Jumper oder ein mini-Schalter. Der muss auf "select 0" stehen. Wenn Du den nicht gleich findest, poste mal ein Bild vom Laufwerk auf dem auch die Bezeichnung zu lesen ist.
Dass "kein Laufwerk angeschlossen" zu diesem ???-Icon führt ist normal, das hat jeder Amiga. Ursache ist, dass das Kickstart immer davon ausgeht, dass df0: vorhanden ist. Ist das Laufwerk wirklich nicht da, wird auch kein "Diskette entnommen"-Signal ausgegeben, so dass der Rechner glaubt, es sei eine Disk eingelegt. Der Versuch, diese nicht-vorhandene Disk zu lesen scheitert natürlich, deswegen wird ein Lesefehler angezeigt.
-
OK, mit der Zielsetzung - die ich im Übrigen generell in meinen Projekten verfolge - ist es natürlich unnötig, weitere Änderungen zu machen. Mir war, als wäre das hier ein "weil-ich-es-kann"-Projekt, denn die geringe Anzahl an Musikstücken die mehr als zwei SIDs braucht, lässt Deine Zielsetzung nicht sofort "aufleuchten"
-
Koennt Ihr das bitte in einem neuen Thread diskutieren
Das ist es nicht wert - wenn ich alles diskutieren wollte wo meine Ideen oder meine Arbeit verwurstet werden, würde ich nicht zum Entwickeln kommen. Lass' uns beim konstruktiven Part bleiben: Wenn eine Quelltextänderung nicht in Frage kommt, dann ist ein gemeinsames Register für mehrere Gate-Bits wohl wirklich mit "gleiche Wellenformen" verbunden.
-
Hallo Jens hast Du vielleicht beim späteren Ultimate SwinSID geholfen?
Gerade nachgeschaut: Meine eMail ging am 24.9.2007 an Andreas Paul. In der erwähne ich aber explizit, dass ich genannt werden will, wenn dieser Phi2-Fix eingesetzt wird. Ob der zu dem Zeitpunkt an "Ultimate SwinSID" gearbeitet hat, kann ich nicht sagen.
Jens
-
So viel mir bekannt ist ist der nicht frei zugänglich.
Nicht? Ich habe damals das Debugging am C64-Bus unterstützt weil ich dachte, dass das ein open-source Projekt sei. So kann man sich täuschen. Ist mein Name wenigstens erwähnt? Immerhin hatte zuvor niemand daran gedacht, Phi2 auszuwerten, was zu Fehlern in der Datenübertragung führte.
TI ist zu wenig "gängig"?
TI ansich ist groß, aber die schmale Version des '154 ist einfach nicht gängig (gewesen). Überhaupt sind mir 24-Pin schmale DIPs erst über den Weg gelaufen, als PAL20L8 und GAL20V8 und 22V10 geläufig wurden, also späte 1980er Jahre. Das alte TTL-Buch von TI (Hochformat, braun, gefühlt Anfang-80er Jahre) zeigt jedenfalls nur die breite Version.
Das Bild vom schmalen HC154 das Du gepostet hast ist für mich noch kein Beweis, dass es die Dinger überhaupt in mehr als homöopathischen Stückzahlen gibt. Tatsächlich würde ich bei einem so neu aussehenden Chip immer mit Aceton reinigen um zu sehen, was es wirklich ist. Es gibt professionelle Fälscherbuden, die an genau diesem Erscheinungsbild zu erkennen sind.
-
Das geht dann aber mit dem Zwang zu gleichen Wellenformen einher, da sie im gleichen Register selektiert werden. Würde die Hardware den Komponisten dann nicht sehr stark einschränken?
Es sind doch SwinSIDs - da kann man die Gate-Bits in eins der unbenutzten Register spiegeln. Das ist ohnehin so eine abgefahrener Mod, dass er vermutlich nur 2-3 mal auf diesem Planeten nachgebaut wird. Da ist auch ein wenig Fummeln im Quelltext erlaubt, finde ich.
Da sagen manche Datenblätter etwas anderes:
Es ging mir um "gängig" - ich habe in meiner gesamten Laufbahn noch nie einen schmalen '154 in der Hand gehabt. Der ist in vielen C64-Bastelschaltungen eingesetzt worden um 16 LEDs anzusteuern - und ich habe nie verstanden, warum man den nimmt, wenn man mit zwei '138 das Gleiche auf weniger Platz für weniger Geld erreichen kann. Diese Rex-Speicheranzeige ("jede LED steht für 4k") hatte sogar noch die lustige Beschaltung, dass jede LED ihren eigenen Widerstand hatte. Das ist noch viel schwieriger zu verstehen, wo doch immer nur eine LED gleichzeitig an sein kann - da hätte es ein gemeinsamer Widerstand für alle LEDs getan. Aber ich drifte off-topic.
Jens
-
So, heute ist endlich der 74HCT154 aus China gekommen und ich wollte ihn ausprobieren ... wie angenommen ein DIP-24 ... aber nicht in "schmal", sondern in "breit"
... Der scheint aber in der Bauform sehr häufig zu sein, daher habe ich das Layout angepasst, damit man beide reinstecken kann.Der LS154/HC(T)154 ist immer "breit" gewesen - deswegen halte ich ihn für überflüssig. Du kannst mit zwei LS/HC(T)138 das Gleiche erreichen, denn der hat mehrere enable-inputs, von denen einer aktiv-high ist. Somit kannst Du mit einfacher Verdrahtung einen 4-zu-16-Decoder bauen der genau das Gleiche macht wie der '154.
Ich würde aber auf die CPU-Zeit schauen und auch die Möglichkeit geben, mehrere SIDs gleichzeitig zu beschreiben (lesen muss natürlich komplett getrennt bleiben). Die Idee wäre, die Gate-Bits der SIDs gleichzeitig antickern zu können. Natürlich ist das bei 16 SIDs und 1MHz noch nicht so schlimm wie bei Midi, wo Du vielstimmige Akkorde faktisch nicht hörbar-gleichzeitig anschlagen kannst, aber wenn Du Effekte wie Auslöschung und/oder Stereo-Panning auslösen möchtest, vielleicht auch mit Phasenverschiebung spielen möchtest, damit Dein 5.1-System mal richtig zur Geltung kommt, wäre so ein mehrfach-Trigger sicher nicht falsch.
Jens
-
Wo du das gerade erwähnst... Ich hab hier noch eine A2000-Tastatur von Cherry (G80-0904) an meinem A2000A. Der dort verbaute Controller ist keiner von MOS sondern ein simpler 8039 mit externem (EP)ROM und 2 TTL (74HCT373 und 74LS373). Das EPROM, ein 2716, habe ich natürlich ausgelesen. Der 8039 mag nicht gerade neu sein, aber er wäre wohl billig zu bekommen, vor allem weil man auch einen beliebigen 8049 nehmen kann wenn man dessen internes ROM abschaltet.
Das Binary würde mich auch interessieren - das Entlöten und Auslesen dieses Eproms steht schon seit vielen Jahren auf meiner "irgendwann-mal-machen"-Liste. Ich habe selbst 2 Tastaturen dieser Art - tolles Tippgefühl, aber das ist ein mehr-schlecht-als-recht funktionierender Code, der in jedem Fall überarbeitet werden müsste. Dieser Tastaturtyp wurde von Commodore Braunschweig in Auftrag gegeben und wurde innerhalb von Commodore immer als "the German keyboard" bezeichnet. Es hat zwei Schwächen:
1) wenn der ACK-Puls sehr früh geschickt wird, macht die KClk-Leitung einen kurzen Impuls "außer der Reihe", der sehr oft zu einem re-sync führt. Teilweise kann innerhalb des re-sync wieder ein re-sync ausgelöst werden.
2) wenn der ACK-Puls zu kurz ist, wird er oft von dieser Tastatur nicht erkennt. Commodore nennt deswegen eine Mindestlänge für den ACK-Puls von 85µs. Bei einer so langen Dauer ist klar, dass es in diesem Controller keine Hardwareunterstützung für das Erkennen von Flanken gibt. Das wäre aber Grundvoraussetzung für die Spezifikation, dass ein Puls bis herunter auf 1µs erkannt werden soll.
Grundsätzlich bin ich der Architektur dieser Controller nicht abgeneigt. Viele der wirklich erschwinglichen MCUs auf dem Markt haben einen 8051-Kern (oftmals den 1T8051 von TSMC), und es gibt Myriaden von freien Entwicklungstools, die auch unter Linux laufen. Da bekommt man einen 20MHz-8051 mit reichlich IO, 128 Bytes RAM (manchmal 256 Bytes und nochmal 1k indirekt adressierbar), 4k Flash und internem RC-Oszillator für deutlich unter 1 Dollar. Dabei ist die on-chip-Hardwareausstattung mit Timern, UARTs und Watchdog sehr wirklichkeitsnah ausgewählt. Ich würde hier in Richtung STC oder Nuvoton schauen, die machen annehmbare Preise - und Support bekommt man ohnehin nicht wenn man weniger als 1 mio Chips kauft, insofern sind alle Chiphersteller an der Front gleich
-
Dann rückt die neue Amigatastatur in greifbarer Nähe
Nein, nicht wirklich - das Protokoll war schon immer bekannt. Wie schon geschrieben: das Hardware Reference Manual war erstaunlich genau - ein Niveau an Dokumentation, das man heute leider kaum noch findet. Allein damit (und mit den Schaltplänen, die seit Jahrzehnten offen liegen) hätte man einen heute erhältlichen Microcontroller forward-engineeren können. Mir ging es mehr darum zu beantworten, wie die Originaltastatur tickt, ob die beschriebenen Timings stimmen, und natürlich eine Erklärung bezüglich der bisherigen Vermutungen, also "warum können BigBox-Amigas den Reset komplett verhindern" (ich glaube dass Melon Dezign in einem 1991er Demo erstmals gezeigt hat, dass das geht).
Meine Todo-Liste bezüglich Tastatur ist noch nicht ganz leer - ich wollte noch ausprobieren, wie eine als "defekt" markierte Tastatur auf Spannungsschwankungen reagiert, und natürlich noch die damals beteiligten Personen befragen, um die Geschichte noch mit ein paar Infos aus erster Hand zu garnieren. Dann können wir zumindest behaupten, dass wir "alles" über die Amiga-Tastatur wissen.
Eine neue Amiga-Tastatur bauen würde bedeuten, dass wir auch Tastenkappen in der "richtigen" Breite bekommen. Die gibt es kaum - etwas "Ähnliches" würde sofort billig und "gewollt aber nicht gekonnt" aussehen. Als Nächstes kommt das Problem, das Tastaturen heutzutage Schüttgut sind. Keine Firma macht sich mehr die Mühe, die Tasten oben und vorn zu bedrucken. Man müsste also durch die heutigen Regelprozesse gehen und Tasten nur von oben bedrucken - nochmals ein Punkt, der die Tastatur "am falschen Ende gespart" aussehen zu lassen.
Ein weiteres Problem wäre der Ersatz für die BigBox-Rechner: Hier war es Standard für eine Amiga-Tastatur, mit einem Spiralkabel ausgestattet zu sein. Ich habe vor ein paar Jahren mal versucht, Spiralkabel zu bekommen - da war nichts zu machen. Erst als ich das Projekt lange abgeschlossen hatte (damals ohne Spiralkabel) habe ich Lieferanten gefunden, die was anbieten konnten, was nicht komplett außerhalb des Budgets lag. OK, die hätte ich jetzt. Fehlen nur noch die Tastenkappen, eine Metallbasis, Platinendesign, ein frischer MCU-code für einen erschwinglichen Controller (bleibt mir bloß weg mit Atmel!), viiiiel Zeit..
-
Bei der Suche nach dem ursprünglichen Autor sind mittlerweile beteiligt: Dave Haynie und Jeff Porter, beide können sich nicht daran erinnern, dass die Entwicklung überhaupt bei Commodore gemacht wurde. Die Vermutung ist also, dass das "originale Amiga-Team" vor der Übernahme durch Commodore diese Entwicklung gemacht hat.
Dale Luck hat dann Bob "Kodiak" Burns mit ins Boot geholt. Der schreibt zwar, dass er sich kaum daran erinnert und auch keinen Quelltext griffbereit hat, aber vielleicht triggert ja mein Disassembly ein paar Erinnerungen. Bob ist "per Regierungsanweisung" Zuhause (landesweite Sicherheitsvorkehrungen wegen COVID-19) und schreibt selbst, dass er nicht sehr beschäftigt ist. Möglicherweise bekommen wir also etwas Gutes aus diesem Corona-Dreck.
Außerdem gibt es Hinweise darauf, dass Chris Raymond an dem keyboard controller gearbeitet hat. Der muss wohl (noch zu Commodore-Zeiten?) in Richtung Apple gewechselt haben; eine 30-Sekunden-Google-Suche hat nichts Verwertbares ergeben. Vielleicht hat ja einer der Männer auf der anderen Seite des großen Teiches einen Kontakt.
Während ich heute früh eine recht umfangreiche Mail an Bob Burns geschrieben habe ist es mir wie Schuppen von den Augen gefallen - ich kann jetzt meine eigene Frage beantworten:
Was übersehe ich?
Die Ports C und D werden tatsächlich zu keinem Zeitpunkt "alle auf 0" gezogen. Mein Hirn war lediglich zu sehr im "Software-Modus", so dass ich die Hardware nicht genauer betrachtet habe. Schaut man ins 6500/1-Datenblatt, Seite 6 links oben, so ist da zu lesen, dass die Pull-up Widerstände werkseitig entfernt werden können. Ein Hinweis darauf ist auch, dass PD7 (die Watchdog-Leitung) einen 47k Pull-up Widerstand hat - und das ist der einzige Pin auf dem ich Aktivität sehe.
Ich habe jetzt an ein paar andere PD-Pins 10k Pullup-Widerstände gelötet und sehe dass sich die Pins alle so verhalten wie der Quelltext es beschreibt. Das ist eigentlich schon Beweis genug, dass die Ports C und D keine Pullup-Widerstände haben, aber die Frage ist dennoch an Bob Burns gegangen. Die Erklärung, dass man bei "keine Taste gedrückt" an den Column-Leitungen dauerhaft 0V misst ist also die Pin-Kapazität: Die Pins werden periodisch auf 0V gezogen und bleiben einfach da.
-
Das ganze noch mal mit Pin 2 ich hoffe das bringt so was
Nicht wirklich - es kommen die 9ms-Pulse auf der Watchdog-Leitung, aber man sieht weder einen Sync-Versuch (Abschicken der power-up key sequence), noch die Pulse, die man vom Amiga zurück erwarten würde. Da die Tastatur mit dem Blinken eines Fehlercodes wartet, bis der Amiga das erste Mal "Piep" gesagt hat, kann's einfach sein, dass die KDat-Leitung (PA0) dieses Chips einfach kaputt ist. Nach ca. 62ms müsste der Watchdog-Test beginnen, was er aber nicht tut - ergo ist im Selbsttest etwas danaben gegangen.
Ich bin mit dem Disassembly so weit dass ich jetzt weiß, dass die Watchdog-Leitung theoretisch für eine weitere Spalte von 6 Tasten verwendet werden kann - und die Dokumentation im HRM unterstützt diese Annahme sogar mit den Scancodes, die in der Scancode-Tabelle im Disassembly liegen. Das habe ich gleich mal in der Praxis ausprobiert: Pin#2 und Pin#36 kurz mit einer Pinzette verbunden und das DisMo der ACA500plus zeigt den "spare"-Keycode $49. Nicht, dass das für irgendwen nützlich sein könnte..
Wenn ich das richtig verstanden habe überschreibt er dann die Speicherstelle, die das letzte übermittelte Byte enthält.
Ich bin zwar ziemlich sicher, dass $3a als temporäre Variable für das zuletzt gesendete Byte verwendet wird (es wird in der retransmit-Routine verwendet), aber ich habe nur eine Stelle gefunden an der mehr als 5 Bytes Stack verwendet werden: In der Reset-Routine. Und da gibt es keinen Re-Transmit, sondern nur Timeouts - erstmal für "output buffer ausleeren" und später maximal 10 Sekunden (genauer: 9999ms), in denen der Computer durch Halten der KDat-Leitung auf 0 den Reset verzögern kann. Die Subroutine die da angesprungen wird überträgt die "reset warning" - und die ist dokumentiert mit "da gibt es keinen re-transmit". Wenn also dieser retransmit-Buffer davon überschrieben wird, ist das nicht schlimm.
Aus meiner Sicht gibt es in diesem Code kein Stack-Problem. Ich habe aber zwei Stellen gefunden, bei denen ich einen off-by-one-Bug vermute, der aber auch nicht ins Gewicht fällt: Einmal beim Abscannen der Rows, da wird eine Row zu viel gescannt (die einfach als "keine Taste gedrückt" gefunden wird), und das Gleiche nochmal beim Abtesten der Columns, wo ebenfalls scheinbar die Schleife einmal zu viel durchlaufen wird.
So ganz schlau werde ich trotzdem noch nicht aus dem Code, denn er erklärt nicht das real-world-Verhalten: Wenn keine Taste gedrückt ist, setzt der Controller alle Column-Bits auf 0 - das ist sicher nützlich um zu erkennen, ob überhaupt irgendeine Taste gedrückt ist. Wenn dann etwas gedrückt wird, beginnt gleich der Scan-Vorgang, aber der wird nicht nur sehr gezielt abgebrochen, sondern auch scheinbar gezielt gestartet, denn ich sehe auf dem Scope nicht, dass da andere Columns auf 0 gezogen werden. Viel schlimmer noch: Ich sehe nirgends im Code, dass Port C und/oder Port D komplett auf 0 gezogen werden. Aber genau das passiert in Wirklichkeit. Ist mein Verständnis von 6502-Code so schlecht? Was übersehe ich? Aktueller Stand angehängt, der Euch aber ähnlich verwirren könnte wie mich, denn da gibt es beim Scannen eine Abweichung zwischen Code und Wirklichkeit.
Ich habe auch die Stromaufnahme der 6570 und 6571 Controller gemessen: Beide im Bereich von 100mA, also höchst wahrscheinlich gleicher Herstellungsprozess.
Jens
-
Ich hab das noch mal mit nem LA gemessen was beim Einschalten passiert.
Der Reset-Puls ist nach dem Einschalten kurz unterbrochen, aber das sollte kein Problem machen, denn da ist der Resonator noch gar nicht eingeschwungen und es kommt ein sauberer Reset von ca. einer halben Sekunde hinterher (wenn ich das richtig lese). Was man sieht ist etwas mager, deutet aber an, dass ein wenig Software läuft: KDat geht low, KClk macht einen kurzen Puls, KDat geht wieder high - so ist ein einzelnes Bit dokumentiert und programmiert. Problem ist, dass man das mit dem Quelltext *nicht* erklären kann, denn das passiert so früh, dass ich Schwierigkeiten habe, das am Quelltext zu erklären.
Wenn Du noch einen Kanal frei hast, würde ich noch Pin#2 anschauen um zu sehen, wann die 9ms-Pulse beginnen. Ich fürchte aber, dass es selbst dann Kaffeesatzleserei ist. Die gewählte Auflösung ist etwas schmal um sich da entlang dem Quelltext zu hangeln - ich dachte zunächst "das passiert ja viel zu früh, direkt nach dem Reset", aber die Pulse auf Clock/data kommen ja erst ca. 1ms nach dem Reset, wo schon rund 1500 MCU-Zyklen gelaufen sind. Wenn Du wirklich wissen möchtest, wo das Teil hängen bleibt, brauchen wir eine sehr viel höhere Auflösung und zusätzlich Pin#2, denn anhand der Pulse auf der Watchdog-Leitung haben wir immer wieder eine Landmarke um abzugleichen, wo im Quelltext wir gerade sind. Die Auflösung sollte dabei hoch genug sein, damit man die 3MHz ablesen kann - wenn Du da wirklich über 1ms speichern kannst, wäre das schon nett.
-
Die mir vorliegenden 6571 sind "16036" gestempelt. Daher sollten die auch noch NMOS sein.
Die spätesten 6570, die ich habe sind von 1992... mit Rev "14".
Es kann natürlich sein, dass die zwei Prozesse noch parallel oder wenigstens in einer Art "Schichtbetrieb" (also wechselweise) gefahren wurden. Schließlich gab es bis zum Schluss auch noch 6581-SIDs die ganz sicher nicht HMOS2 waren. Trotzdem werde ich die Stromaufnahme messen, wenn ich den 500er das nächste Mal auf dem Tisch habe
(da steht momentan ein C64..). -
Aber: Die mir vorliegenden 6571-036 sind alle Rev. 6
Das ist hier ebenfalls so - und die Datecodes sind alle aus den 1990er Jahren. Zu der Zeit hatte CSG AFAIK schon alles auf HMOS2 umgestellt, was *eigentlich* mit einer 85 (anstelle der 65) gekennzeichnet wurde. Es gibt jedoch erstaunlich wenige 8521-CIAs, dafür jedoch nicht wenige 6526-CIAs, die das CSG-Logo haben und ebenfalls 1990er Datecode haben.
Es gibt zwei Möglichkeiten den neuen Herstellungsprozess nachzuweisen - invasiv durch Öffnen des Chips, da würde ich irgendwo auf dem Die eine Bezeichnung suchen.
Die andere Möglichkeit ist die Messung der Stromaufnahme. Im alten 6500/1 Datenblatt steht was von 100mA. Ich würde mich nicht wundern, wenn die Stromaufnahme des 6571-Controllers signifikant geringer ist - das würde auf den Schritt von NMOS auf HMOS2 deuten, der bei allen anderen Chips ebenfalls gemacht wurde.
-
Es wurde auch eine 16mhz version der ACA1221lc für unter 100€ damals angekündigt, ob die noch kommt weiß ich nicht.
Die kann leider nicht mehr kommen, deswegen habe ich die ACA1211 gemacht - ich wollte wieder was im 100,- EUR-Bereich haben. Die ACA1221lc verursacht hohe Kosten in der Nacharbeit, dass ich noch etwas mehr Entwicklungszeit 'reingesteckt habe, um ihr auch den IDE-Speeder zu geben, den ich mit der "neuen" ACA1233n eingeführt hatte. Ich wollte nicht einfach die Karte teurer machen weil ich mich in der Berechnung der Arbeitszeit vertan habe - jetzt bietet sie auch mehr als das, was ich ursprünglich geplant hatte (eben den schnelleren IDE, der anderswo mit einer 3-stelligen Summe berechnet wird).
Und weil's so schön war, hat die ACA1211 den IDE-Speeder auch bekommen
Möglicherweise Modifikationen an Ihrem A1200 Motherboard,
Da habe ich seit einigen Jahren keine Beschwerden mehr gehört - ich kann jedoch nicht sagen ob's daran liegt, dass ich sauber im Vorfeld dokumentiere, dass Mainboards möglicherweise modifiziert werden müssen, oder ob meine Maßnahmen auf der Turbokarte greifen, die dazu dienen, den typischen Gayle-Absturz zu verhindern. Vieles deutet auf Letzteres hin (aka "läuft einfach"), aber da ich keinen wissenschaftlichen Beweis dafür habe, behalte ich den Warnhinweis bei.
-
Läuft das KbClk Signal nur solange auch was gesendet wird, oder sollte das durchgehend Takten?
Wenn meine Vermutung stimmt und der Controller in der wait-for-ack-Routine hängt, dann werden endlos KbClk-Pulse gesendet. Deine Beschreibung, dass die Caps-LED dauerhaft an ist, deutet darauf hin.
Falls Du aber nur einige wenige KbClk-Pulse und dann einen ACK-Puls messen kannst, startet der Controller normal.
Wenn Du eine ACA500plus hast, kannst Du beim Einschalten auf dem DisMo sehen, welche Scancodes von der Tastatur kommen. Wenn der letzte angezeigte Code "FE" ist (der dann nach einer Sekunde ausgeblendet wird), ist alles in Ordnung. Siehst Du "FC", ist die Tastatur nicht durch den Selbsttest gekommen. Siehst Du was ganz Anderes, ist vermutlich ausreichend-viel kaputt um den Chip zum Absturz zu bringen oder endlos in einer Schleife hängen zu bleiben.
-
Das sind 9ms-Pulse - sieht so aus, als würde der Controller in der Routine hängen, die auf den ersten ACK vom Computer wartet. An der Stelle wird noch kein Fehlercode geblinkt, wie Du dem aktuellen Stand des Disassembly entnehmen kannst. Das kann mehrere Gründe haben:
1) Deine CIA defekt und kann den ACK nicht senden, oder KbClk nicht empfangen
2) das Kabel ist nicht in Ordnung, so dass ein ACK nicht am Tastaturcontroller ankommt
3) der Controller ist kaputt und die edge-detection funktioniert nicht, deswegen hängt er dort.
4) Die KbClk-Leitung ist nicht in Ordnung, so dass die CIA die Clocks nicht sieht.
Der ACK-Puls kommt auf KDat. Nächster Messpunkt wäre also PA0 auf Pin#38 (direkt neben Reset). Als Bestätigung, dass der Controller in genau dieser Routine hängt könntest Du auch PA1 (KbClk, Pin#37) messen, da müssten auch in 9ms-Abständen Pulse kommen. Die entsprechenden Zielpunkte an der CIA würde ich gleich mit messen.
-
aber sollte das signal nicht weiter Richtung 0V gehen?
Die untere Schwelle ist mit maximal 0.8V angegeben, und die wird knapp unterschritten. Und die obere Schwelle ist auch "knapp richtig". Frequenz stimmt auch: 6 Schwingungen in 2µs sind 3MHz. Dass die Pegel nicht 100% gemäß Datenblatt sind ist nicht weiter wild, weil allein durch die Tatsache dass es schwingt schon nachgewiesen ist, dass die Pegel erreicht werden. Schließlich kehrt der Treiber auf Pin#11 erst dann die Richtung um, wenn der Eingang an Pin#10 den jeweils anderen Pegel erreicht hat.
Nächster Messpunkt wäre Pin#39 (reset), der ca. 1s nach dem Einschalten eine halbwegs steile Flanke in Richtung 4V machen müsste.
Wenn Reset stimmt, schaust Du an Pin#2 nach dem Signal für den Watchdog. Wenn das mit weniger als 54ms Periode wackelt, läuft der Code.
