8-Bit-Breadboard-Computer auf Basis einer 6502-CPU - Die Tastatur spinnt: Hardware-Debugging, Fake-Chip und mehr

Bisherige Artikel dieser Serie - hier könnt ihr nochmal alle Grundlagen nachlesen, falls ihr jetzt erst einsteigt: Ich entwickle momentan die Software für den Bin/Dez/Hex-Converter für meinen Breadboard-Computer. Und dort bin ich gerade an der Stelle, wo die Überprüfung der Eingabe der Dezimalzahlen für den Dezimal zu Hexadezimal / Binär Konverter stattfindet.

Ich prüfe gerade meinen Code, ob die Eingabe von maximal 255 für die Dezimal-Eingabe funktioniert. Diese soll:


und wundere mich, warum ich an der 2. Ziffer keine 4 oder 5 eingeben kann. Dass ich nichts höher als eine 5 eingeben kann, ist vom Code ja so gewollt, aber warum funktioniert 24x und 25x nicht, wohl aber 23x.

Nachdem ich durch die im letzten Teil implementierte Debug-Ausgabe sichergestellt habe, dass ich auch die richtigen Werte miteinander vergleiche, erscheinen eine Menge Fragezeichen über meinem Kopf? Woran mag es dann liegen, dass er zwar eine 0, 1, 2 und 3 annimmt, aber keine 4 oder 5 ?

Also schalte ich um auf Programmbank 7, dem Tastatur-Testprogramm. Und da zeigt sich schnell, was schief läuft: die Tastenreihe 4, 5, 6, B reagiert nicht mehr. Ich ziehe das Keypad vom Breadboard und messe es separat durch, kann aber nichts auffälliges finden. Außerdem weiß ich nicht mehr so genau Bescheid, welcher Headerpin jetzt für welche Spalte / Zeile der Tastatur steht.

Als ich die Tastatur wieder ins Breadboard stecke, funktioniert sie gar nicht mehr.

Ich erinnere mich, dass ich mal statt der 5V Betriebsspannung so um die 6 Volt durch den Breadboard-Computer gejagt habe. Der 6522er sollte doch nicht etwa dadurch Schaden genommen haben?

Ein Blick ins Datenblatt für den W65C02, die CPU sagt mir, dass die bis zu 7 Volt ab kann. Und auch dem W65C22 sollten 6 Volt nichts ausmachen:



Trotzdem ist es ein schneller Test, den WDC 6522er gegen einen anderen 6522er auszutauschen, um zu sehen, ob es an dem liegt. Ich habe ja noch einen von Rockwell (vermeintlich von Rockwell) herumliegen, den ich vor einiger Zeit in China bestellt hatte. Den WDC 6522 hatte ich eigentlich nur aus Verlegenheit als Ersatz bei Mouser mitbestellt, um dort die Grenze für die Versandkostenbefreiung zu erreichen. Um wo ich ihn schon hatte, hab ich natürlich den genommen, weil der bis 14 Mhz kann.

Schon wieder eine Chip-Fälschung aus China


Also tausche ich den WDC mit dem Rockwell aus und: Kurzschluss! Zum Glück hatte ich mein Labornetzteil auf 500 mA begrenzt und es gleich bemerkt und es wieder abgeschaltet, sonst wäre wohl etwas in Rauch aufgegangen.

Auch wenn die Laserung noch so professionell aussieht, ich bin schon wieder einem China-Fake, einer Chip-Fälschung, aufgesessen. Wer weiß, was sich in dem 40-poligen Gehäuse verbirgt. Auf jeden Fall kein 6522, denn dann wäre die Pinbelegung nicht so, dass es ein Kurzschluss gibt. So langsam beschleicht mich das Gefühl, das aus China nur Fakes und Schrott-Chips kommen. Bisher habe ich keine guten Erfahrungen gemacht.
Da seit Neuestem auch immer rund ein Euro Portokosten auf China-Importe kommen, lohnt sich das Risiko, zumindestens für Chips (Sensoren und China-Arduinos/STM32s/ESP8266s/ESP32s sind ein anderes Thema) meiner Meinung nicht mehr. Hier werde ich jetzt öfter bei Reichelt, Pollin, Conrad oder Mouser bestellen.

Und wenn man mal von der professionell gemachten Laserung absieht und den angeblichen Rockwell R65C22P2 schräg gegen das Licht hält, dann kann man vertikale Riefen und Streifen sehen, die wohl von einem Bandschleifer stammen. Auch sehen die Pins an den Seiten so aus, als ob sie mit feinem Sandpapier behandelt worden sind, wahrscheinlich um Lötzinnreste abzutragen und den Chip wie neu aussehen zu lassen (es sind aber trotzdem noch geringe Reste vorhanden).

Der chinesische Betrüger hat also ein paar professionelle Maschinen in der Werkstatt stehen und gibt sich viel Mühe, seine Fälschungen gut aussehen zu lassen.

Allerdings sollte man bei den Datecode "1901" stutzig werden. Dieser würde nämlich für den Januar 2019 stehen. Und Rockwell gibt es schon seit längerem nicht mehr, wie uns Wikipedia verrät:



1999 ist Rockwell Semiconductor in Conexant aufgegangen. Chips nach 1999 müssten also das Conexant Logo tragen. Und allgemein glaube ich nicht, dass Conexant 2019 noch 6522 Chip produziert haben.

Vielleicht mache ich mir irgendwann mal die Mühe herauszufinden, was wirklich in dem DIP-40 Gehäuse steckt. Momentan sortiere ich den "R65C22" aus und makiere ihn mit einem Aufkleber mit der Aufschrift "Fälschung". Nicht, dass ich in Versuchung komme, damit nocheinmal eine Kurzschluss zu verursachen.

Der W65C22 ist es nicht

Eine andere Möglichkeit, zu testen, ob der W65C22 (und auch der Code) in Ordnung ist, ist die Tastatur rauszurupfen und mit einem Jumperkabel die Kurzschlüsse, die bei einem Tastendruck entstehen würden nachzuahmen.

Und siehe da: der WDC 6522 tut was er soll und funktioniert immer noch einwandfrei. An ihm kann es also nicht liegen.

Also doch die Tastatur

Dann muss es wohl an der Tastatur liegen. Ich messe sie durch, in dem ich jeweils ein (oder zwei) Ausgänge über ein Multimeter-Dioden/Durchgangstest an ein (oder zwei) Eingänge lege und dann die Tasten durchdrücke. Das sieht eigentlich ganz okay aus.

Wie kann es dann sein, dass die Tastatur jetzt gar nicht mehr reagiert?

Vielleicht ist ja auch etwas intern kurzgeschlossen. Ich messe alle Verbindungen ohne eine Taste zu drücken durch, kann aber nirgends einen Durchgang finden.

Die Idee gefällt mir aber trotzdem, denn wenn eine Taste ohne Knopfdruck, also von Hause aus, etwa durch abgeblätterten Silberleitlack (was ich für unwahrscheinlich halte) kurzgeschlossen würde, dann würde ewig auf das Loslassen einer Taste gewartet werden und das Programm würde nicht weiterlaufen, um den Tastendruck auszugeben und es würde auch so aussehen, als ob die Taste nicht angenommen werden würde.

Software-Lösung: Selbsttest der Tastatur

Ich könnte ja einfach mal schauen, ob an der entsprechenden Stelle am Programm schon eine Taste gedrückt ist, etwa durch einen Debug-Ausgabe. Und siehe da: daran liegt es. Was für eine Odyssee, die Fehlerursache herauszufinden.

Ich beschließe, diesen Stolperstein für die Zukunft aus dem Weg zu räumen und am Anfang des Programms nach dem Reset, also dem ioInit die Tastatur zu prüfen, ob nicht schon irgendeine Taste gedrückt ist und dann eine Warnung auf dem LCD auszugeben.

Und wenn ich schon dabei bin, kann ich eigentlich auch gleich feststellen, welche Taste denn der Missetäter ist und die mit ausgeben.

Und siehe da: die Taste 4 ist der Querschläger, der mir den Tag versaut:



Source-Code

Natürlich will ich euch den Source-Code für den Keypad-Selbsttest nicht vorenthalten. Dieser wird jetzt nach jedem Reset automatisch ausgeführt und wenn etwa nicht stimmt, sagt mir eine Warnung, was mit der Tastatur nicht stimmt. Ich habe die Unterroutine in key.inc untergebracht.

; last edit: Oliver Kuhlemann (www.cool-web.de), 2020-09-02 test_keypad: ; checkt, ob Kurzschluss in Tastatur ; oberen 4 Bits Port A Output, unteren 4 Bits Port Input ; standardmäßig sind die Leitungen auf High, wir müssen also auf low prüfen lda #%11110000 sta VIA_DDRA lda #$0F ; alle Output-Leitungen auf low sta VIA_PORTA lda VIA_PORTA ; sollte $0F bleiben, sonst hängt eine Taste cmp #$0F beq test_keypad_done ; alles okay ; Eine Taste hängt. Meldung ausgeben LCD_CLEAR LCD_PRINT msgTastaturKlemmt ; welche Taste(n) hängt? Durchtesten und ausgeben lda #%11101111 sta keyOut ldx #4 ; 4 Output-Leitungen nacheinander mit LOW versorgen... nextKeyOutTest: lda keyOut sta VIA_PORTA ; und schauen, ob das bei einer der 4 Input-Leitungen ankommt... lda VIA_PORTA sta keyIn ; ein unteres Bit auf 0? Dann Taste gedrückt and #%00001111 cmp #$0F ; $0F = Standardwert = nichts gedrückt beq keinHaengerHier ; Hänger ausgeben ldy keyIn lda KEY_ASC, y LCD_CHAR_AKKU keinHaengerHier: dex beq test_nextKeyOutTest_done; wenn 4x durch, raus rol keyOut ; bits eins nach links schieben = nächste Leitung bra nextKeyOutTest test_nextKeyOutTest_done: wai ; auf Cont.-Taste warten LCD_CLEAR ; LCD wieder leeren test_keypad_done: rts msgTastaturKlemmt: ;1234567890123456 ASCII WARNUNG! Key-Pad BYTE lcd_ue ASCII berpr BYTE lcd_ue ASCII fen! Eine ASCII Taste h BYTE lcd_ae ASCII ngt: BYTE 0

Sie tut wieder!

Ich hatte schon die Befürchtung, das Keypad wieder mit dem Skalpell (Schrauben hat sich der Hersteller ja leider eingespart) öffnen zu müssen, aber nachdem ich die Taste 4 ein wenig malträtiert habe, sprang sie irgendwie wieder zurück und alles war wieder gut.

Trotzdem: diese schlecht verarbeitete Tastatur bleibt ein Wackelkandidat, der jederzeit wieder querschießen kann. Gut, dass ich dann eine Warnmeldung bekommen und nicht vergebens an den falschen Stellen suchen muss.

Video

Auch diesmal habe ich meine Tests, Messungen etc. wieder in einem Video dokumentiert. Dort erkläre ich auch noch einmal ausführlicher den neuen Assembler Code.



Ausblick

Im nächsten Teil werde ich das Hexadezimal / Dezimal / Binär Konvertierungs-Tool und Spielchen dann hoffentlich zu Ende entwickeln und euch vorstellen und den Source-Code erklären. Besonders der Decimal Mode des 6502 wird dabei nicht zu kurz kommen.