Nachdem ich den 4032 wieder am Laufen habe, habe ich doch einen kleinen Fehler gefunden: Der Code für die Taste 'Z' war falsch hinterlegt, man muss 'Y' benutzen. Neue Version folgt ASAP.
Amerikanische Tatstatur: QWERTY anstatt QWERTZ ?
Es gibt 86 Antworten in diesem Thema, welches 15.947 mal aufgerufen wurde. Der letzte Beitrag (
Nachdem ich den 4032 wieder am Laufen habe, habe ich doch einen kleinen Fehler gefunden: Der Code für die Taste 'Z' war falsch hinterlegt, man muss 'Y' benutzen. Neue Version folgt ASAP.
Amerikanische Tatstatur: QWERTY anstatt QWERTZ ?
Genau, ich nehme an, dass wir die Tasten vewechselt haben. Im Original waren z und x für das Drehen vorgesehen, die liegen beim PET unten links nebeneinander, und so soll es auch weiterhin sein.
Das passiert, wenn man mit Vice testen, wo im Tastaturtreiber x und y für die deutsche Tastatur angepasst sind - so ist das jedenfalls bei mir.
Komisch, bei mir auf dem PET 4032 geht alles. Klar sonst hätte ich kein Video machen können . Muss wohl mit VICE zu tun haben ????? oder ????
Gruß Frank
Kann mal einer an einem PET testen ??
Ich habe endlich mal daran gedacht, es bei meinem PET zu testen. Und? Bei meinem geht es nicht.
Das Spiel soll mit den Tasten 4, 6, A und S gesteuert werden können. Bei mir muss ich die Tasten *, ), 0 und ( drücken, das ist extrem unbequem.
Dies enspricht jeweils den Scan-Codes 42, 41, 48 und 40. Diese bekomme ich bei den Tasten aber nur, wenn ich in Vice den 3032 einstelle. Damit läuft aber Moon Patrol nicht.
Offenbar hast Du einen 4032 mit einem älteren ROM im Editor. Gib mal ?peek(57344) ein, und schreib mal, was da herauskommt. Bei mir kommt da 76. (Beim 4032B kommt 169 mit wieder ganz anderen Scan Codes, und beim 3032 kommt 99).
Ich schau mal, ob man das im Programm findet und ggf. patchen kann.
Das Moon Patrol zu Patchen ist mit meinem naiven Ansatz eher aussichtslos. Die von mir o.g. Scancodes waren übrigens hex. Diese Codes kommen im File sehr häufig vor, bis auf 0x40. Ich hatte gehofft, wenn ich das im File direkt ändere (eins nach dem anderen probieren), dann ändere ich die Taste S für Feuer ab. Leider klappt das nicht. ![]()
Als nächstes habe ich geschaut, ob man den Wert 0x97 findet, denn das ist die Adresse für die zuletzt gedrückte Taste. Das kommt 4x vor. Davor steht aber kein gültiger Maschinencode für den 6502, soweit ich sehen kann. Die andere Speicherstelle für die Taste wäre noch 0xA6, aber der Code kommt so häufig vor, damit komme ich auch nicht weiter.
Schade, vielleicht hat noch jemand eine Idee? Ziel wäre, wenigstens die 4 Steuertasten abzuändern, damit das lauffähig wird. Den Quellcode zu bekommen dürfte eher aussichtslos sein.
Das Moon Patrol zu Patchen ist mit meinem naiven Ansatz eher aussichtslos. Die von mir o.g. Scancodes waren übrigens hex. Diese Codes kommen im File sehr häufig vor, bis auf 0x40. Ich hatte gehofft, wenn ich das im File direkt ändere (eins nach dem anderen probieren), dann ändere ich die Taste S für Feuer ab. Leider klappt das nicht.
Du weisst ja gar nicht, wie die Tastatur abfragt wird. Es kann sein, dass an der Stelle gar keine 0x40 auftaucht.
Ausserdem, wie weiter oben schon erwähnt, selbstmodifizierender Code. Da kann zur Laufzeit jede Menge Unsinn gemacht werden.
Es war halt ein Versuch - welche Möglichkeiten gibt es denn noch, die Tastatur abzufragen? Offensichtlich werden die Scancodes benutzt, denn die Tasten passen ja.
Ich habe gerade nochmal in den disassemblerten Code geschaut. Ich finde keinen Zugriff auf $97 (Matrix-Code).
Leider kann man auf die Adresse $97 auch keinen Breakpoint setzen, weil die das IRQ-Routine ja selber draufrum arbeitet.
Aufrufe von $FFE4 oder $FFCF konnte ich auch nicht finden. Wie kann man denn noch die Tastatur abfragen (beim 4032)?
Mit der Adresse $A6.
Bitte melde dich an, um diesen Link zu sehen.
Oder kann man die Tastatur auch über die IO-Register direkt abfragen?
Mit der Adresse $A6.
Bitte melde dich an, um diesen Link zu sehen.
Oder kann man die Tastatur auch über die IO-Register direkt abfragen?
$A6 habe ich inzwischen schon gecheckt. Genauso wie den Zugriff auf den Tastaturpuffer.
Wenn man die Tastatur direkt am IO-Port abgreifen will, muss man eine eigene Scan-Routine schreiben. Das macht keinen Sinn.
Wieso macht das keinen Sinn?
Weil das sehr aufwändig ist. Man muss eine eigene Interrupt-Routine implementieren.
Ich sehe keinen Grund und keinen Vorteil, den Keyboard-Scan nicht von der vorhandenen IRQ-Routine machen zu lassen und sich das fertige Ergebnis abzuholen. Das macht nur Sinn für Programme, die den Kernel komplett ersetzen.
Ok, so ergibt das Sinn. Aber irgendwie muss es ja funktionieren. Kann es sein, dass hier ein Compiler oder etwas vergleichbares benutzt wurde? Was gab es denn 1982?
Es wird sehr viel mit dem Stack gearbeitet:
Kann es sein, dass hier ein Compiler oder etwas vergleichbares benutzt wurde? Was gab es denn 1982?
Sieht so aus. Ab Adresse $1902 liegt irgendeine Art BASIC-Code, der interpretiert wird. Ja, interpretiert. Das war nicht mal ein richtiger Compiler.
Alles sehr merkwürdig.
Wie schon gesagt: neu schreiben ist einfacher, als da irgendwas zu analysieren. ![]()
Wo denn? Welche Adresse? Danach habe ich gesucht und keine gefunden.
Es geht doch um die Tetris-Variante aus diesem Thema (D64) mit 28 Blocks ?
Habe jetzt wahllos einen Fetzen herausgenommen. Hier z.B.:
.C:16e2 AD 51 1F LDA $1F51
.C:16e5 AE 52 1F LDX $1F52
.C:16e8 20 74 1A JSR $1A74
.C:16eb AD 53 1F LDA $1F53
.C:16ee AE 54 1F LDX $1F54
.C:16f1 20 74 1A JSR $1A74
.C:16f4 A0 04 LDY #$04
.C:16f6 4C D3 0E JMP $0ED3
.C:16f9 A5 9E LDA $9E
.C:16fb D0 17 BNE $1714
.C:16fd A5 A7 LDA $A7
.C:16ff 48 PHA
.C:1700 AD 7C 21 LDA $217C
.C:1703 20 2C 17 JSR $172C
.C:1706 A5 9E LDA $9E
.C:1708 F0 FC BEQ $1706
.C:170a A2 00 LDX #$00
.C:170c 68 PLA
.C:170d D0 01 BNE $1710
.C:170f E8 INX
.C:1710 8A TXA
.C:1711 20 2C 17 JSR $172C
.C:1714 78 SEI
Alles anzeigen
Ne, wir waren inzwischen bei Moon Patrol. ![]()
Zur Tetris haben wir ja inzwischen den C-Quellcode.
Oh, ich hatte hier nur ein D64 mit Tetris gefunden. Dann hat sich das erledigt.
Das sieht ja sehr strange aus. Danke für die Mühe!