letzter Beitrag von x1541 am
Was ich noch aus meiner Messung von gestern weis das auf der KbClk am Stecker nach dem einschalten nur kurz ein Taktsignal anliegt.
Läuft das KbClk Signal nur solange auch was gesendet wird, oder sollte das durchgehend Takten?
Den Rest werde ich heute Abend messen.
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.
Angeblich sind die Controller 6570-036 und 6571-036 gleich....
Zumindest die verbauten Chip Revisionen sind unterschiedlich - was natürlich nicht viel Erkenntnis bringt:
Ich hab' hier noch viele "Chicken lips" A500 und A2000 Tastaturen rumliegen und mal nachgeschaut was
da genau verbaut wurde:
Auf den frühen Modellen (1987) sind es - wie bekannt: 6570-036
Diese haben den Aufdruck "13" - also: Rev. 3 Chips.
Spätere Tastaturen hatten dann den Aufdruck "14" darauf... also Rev. 4 Chips.
Aber: Die mir vorliegenden 6571-036 sind alle Rev. 6
Das hilft uns zwara nicht weiter bei der Frage welche Unterschiede da waren... aber es gab
auf jeden Fall welche.
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.
Aber: Die mir vorliegenden 6571-036 sind alle Rev. 6
Es gibt jedoch erstaunlich wenige 8521-CIAs, dafür jedoch nicht wenige 6526-CIAs, die das CSG-Logo haben und ebenfalls 1990er Datecode haben.
Die 8521er, die als 6526 gelabelt wurden haben trotzdem einen "21" Marker; genauer sogar: "216".
Die mir vorliegenden 6571-036 sind "16036" gestempelt. Daher sollten die auch noch NMOS sein.
Die spätesten 6570, die ich habe sind von 1992... mit Rev "14".
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..).
Noch ein kleiner Nachtrag:
Alle mir bekannten 8521, die NICHT mit 6526 gelabelt wurden, waren 8521R0 und hatten auch den Aufdruck "20".
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
Ich würd`s ja messen... aber die nächsten 5 Wochen steht mein Office voll mit KFZ-Steuergeräten - und ich kann die nicht loswerden, weil alle
OEMs und Zulieferer grad Shutdown gedrückt haben. 
Ich hab das noch mal mit nem LA gemessen was beim Einschalten passiert.
Direkt am 6570-036 gemessen.
Danach kommt leider nichts mehr.
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.
Das ganze noch mal mit Pin 2 ich hoffe das bringt so was
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
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.
Dann rückt die neue Amigatastatur in greifbarer Nähe
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..
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..
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.
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
.......
Grundsätzlich bin ich der Architektur dieser Controller nicht abgeneigt. Viele der wirklich erschwinglichen MCUs auf dem Markt haben einen 8051-Kern
Vorsicht... der 8039 hat keinen MCS-51 Core, sondern den MCS-48... und der ist extrem übel - IMHO.
Ich musste den mal für ein Projekt (mit 8749) in Assembler programmieren und war z.B. entsetzt, das der
nicht mal relative Sprünge konnte. Ein Branch hat nur die untersten 8 Bit des PC ausgetauscht.
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.
Wenn man im Netz etwas sucht findet man eine Erwähnung, daß es einen fehlerbereinigten Code gab, nur habe ich den bisher nirgendwo finden können.
Nachtrag: Hier wird es erwähnt: https://www.amigafuture.de/app.php/kb/viewarticle?a=2565
Ein Branch hat nur die untersten 8 Bit des PC ausgetauscht.
Erinnert irgendwie an den 6502, dessen Branch-Befehle sind gegenüber einem JMP/JSR stark eingeschränkt.
Erinnert irgendwie an den 6502, dessen Branch-Befehle sind gegenüber einem JMP/JSR stark eingeschränkt.
Nicht ganz... Du kannst beim MCS-48 nur innerhalb der gleichen Page springen; d.h es wird das
Lowbyte durch den Wert beim Branchbefehl ausgetauscht - eine Addition findet nicht statt.
