Hello, Guest the thread was called23k times and contains 481 replays

last post from 0xdeadbeef at the

250466+ oder der Versuch ein klassisches Board etwas zu optimieren

    Also die Abbildung zeigt, daß beim VIA/6522 PortA ein Open-Drain-Ausgang ist und Port B ein Push-Pull-Ausgang. Ist das beim CIA auch so?

    Das würde zumindest erklären, warum für den Keyscan anscheinend immer PortA auf Ausgang konfiguriert wird. Aber diesen wichtigen Unterschied nicht explizit im Datenblatt des CIA zu erwähnen, erscheint mir irgendwie fahrlässig.

    Danke!


    Kannst Du auch 0xdeadbeef Frage, ob Port B beim 6526 auch Push-Pull ist -wie beim R6522- auf Basis der physikalischen Chips (Die) beantworten?


    Das wäre auch hinsichtlich eines "reverse" scannings beim Keyboard, das immer wieder mal rumgeistert, durchaus wissenswert.


    Das mit den Konstantstromquellen war mir klar, allerdings schreibt CSG ja davon, dass es sowohl aktive als auch passive Pullups wären, meinen die damit, dass ein Teil schaltbar ist und der andere dauerhaft aktiv oder wie ist das passiv ansonsten zu verstehen?


    DANKE!


    0xdeadbeef : mir war nicht bewusst, dass Du die Tests deines Boards schon mit angesteckten Testadaptern gemacht hattest, sorry!

    Beim "Nachfolger" 8521 das gleiche - wie erwartet:



    Links vom Super-Buffer/PP ist der Pullup

    Quote from Ruudi

    Das mit den Konstantstromquellen war mir klar, allerdings schreibt CSG ja davon, dass es sowohl aktive als auch passive Pullups wären, meinen die damit, dass ein Teil schaltbar ist und der andere dauerhaft aktiv oder wie ist das passiv ansonsten zu verstehen?

    Exakt! Ein Teil ist dauerhaft... und der Rest wird dazugeschaltet.

    Hm, OK. Das Antecken des Logic Analyzers ändert den Pegel von PA0 nicht wirklich.


    Ich mußte mich zu der schmerzhaften Erkenntnis durchringen, daß mein DSLogic Plus wohl einen Defekt bezüglich der Einstellung der Spannungsschwelle hat. Zugegebenermaßen hatte ich mit dem mal einen Unfall (*Hust*), deshalb hatte ich einen Ersatz gekauft, aber der ist gerade in der Firma. Ich habe also mal meinen alten ScanaPlus angeschlossen, der sogar nur 100k im Eingang gegen Masse hat, aber auch der scheint das Signal nicht sichtbar zu verändern.

    Der ScanaPlus hat zwar nur 9 Eingänge, aber für diese Messung sollte das eigentlich reichen.

    Damit ist mir auch auf Anhieb eine sinnvolle Messung des Keyscans im Kernal gelungen. Man sieht, daß der Keyscan am Ende der Interruptroutine stattfindet und daß PA7 niemals auf 1 geschaltet wird.



    Insofern steht den Messungen jetzt nicht mehr wirklich was im Weg. Allerdings wollte ich heute noch eine Minimalinbetriebnahme der MicroKey-Platine machen und muß nach ein paar "real life-"Dinge erledigen, die ich schon zu lange vor mir herschiebe.

    Jood: schön zu sehen, dass ich mit meinem Intronix hier nicht allein bin ;-)


    0xdeadbeef : interessant wäre das Verhalten, wenn mehrere Tasten gedrückt sind, insb. die beiden Shift, die CTRL oder C= Taste und eine "normale". Um das zuordnen zu können, würde ich vorschlagen, auch den B-Port mit aufzuzeichnen.


    Wenn keine Taste gedrückt ist, sollte nur der initiale, kurze Puls auf allen A-Port-Bits zu sehen sein, bei einer Taste ein kompletter Durchlauf (PA0-7 sequentiell low), aber bei mehreren Tasten ???


    Da wird die Assemblerroutine unübersichtlich, so nur auf dem Papier betrachtet...


    Was mich interessieren würde wären Fälle resp. Programme, die weder alle noch einzeln hintereinander, sondern zwei bis 7 der PAx PARALLEL auf GND ziehen, wenn Jemand so ein Scan-Verhalten kennt, bitte melden, DANKE!


    Programme, die z.b. den Plastik-Klaviatur-Aufsatz verwenden, müssten meiner Meinung nach (ab Erkennung irgendwas gedrückt) voll dekodieren, jedenfalls aber bis zu drei gedrückte "normale" Tasten entspr. der drei Stimmen des SID. Der Kernal macht das m.W.n. nur für sinnvolle, sprich belegte Kombinationen der oben genannten Sondertasten und normalen Tasten.


    Das wäre hinsichtlich der Kompatibilität der div. Keyboard-Adapter für PC-Keyboards interessant, denn diese übermitteln meist auch nur "sinnvolle" Kombinationen, aber eben nicht z.b. gleichzeitig gedrücktes "QWERTZ".


    Das kann bei Spielen, die anders scannen und in Joystick-Emulation auch zwei der Richtungstasten gleichzeitig zulassen möglicherweise zur Unspielbarkeit mit solchen Adaptern führen...


    Ich überlege, meinen SX64 mit der Elektronik einer älteren drahtlosen PC-PS2-Tastatur (aber unter Verwendung der echten SX-Tastatur!) und "verstecktem" internen Receiver und entsprechendem Wandler zu pimpen ;-)


    Also anstelle dem hässlichen Nachbaukabel GAR KEIN Kabel mehr...

    Quote from Ruudi

    Ich überlege, meinen SX64 mit der Elektronik einer älteren drahtlosen PC-PS2-Tastatur (aber unter Verwendung der echten SX-Tastatur!) und "verstecktem" internen Receiver und entsprechendem Wandler zu pimpen ;-)


    Also anstelle dem hässlichen Nachbaukabel GAR KEIN Kabel mehr...

    Moin.


    Wenn Du das gebaut hast, sag mir definitiv Bescheid. Das wünsche ich mir für meinen SX schon lange. Am liebsten natürlich für eine USB-Tastatur, dann könnte ich zusätzlich auch meine Logitech K400 Plus verwenden.


    Jörg.

    Ich denke das direkt nach der Erkennung "Taste gedrückt" ein einfaches Einlesen beide Port genügt,

    siehe meinem Scan:


    0x00 = Startkennung, wenn dann 0xFF folgt ist keine taste gedrückt, Kernal bricht Scan ab.


    Wenn etwas anderes folgt kann über simples Einlesen beider Ports bestimmt werden welche Tasten

    gedrückt wurden.


    Edit: Alternativ kann man das auch über die Zeit machen, nach der Startkenung (0x00 -> != 0xFF)

    einen Timer starten, und dann im Interrupt die Reihen lesen...


    Dazu war ich aber zu blöd!


    Mfg Jood

    Gerne, aber USB wirds bei mir zumindest nicht werden, hab noch genügend alte Logitech PS2- Tastaturen und Mäuse rumliegen und PS2 ist vom Protokoll her sehr einfach und mit kleinem µC beherrschbar, USB ist da schon wieder ne ganz andere Liga, sollte dann ja nicht nur mit EINER USB-Tastatur funzen sondern mit allen oder wenigstens vielen... Und jetzt:


    :zzt:

    Quote from Ruudi

    Um das zuordnen zu können, würde ich vorschlagen, auch den B-Port mit aufzuzeichnen.

    Na ja, mein LA mit 16 Pins hat offenbar einen Hau und der jetzt angeschlossene hat nur 9 Pins. Ich könnte höchstens meinen zweiten DsLogic aus der Firma zurückholen. Mal sehen.

    Quote from Ruudi

    Ich überlege, meinen SX64 mit der Elektronik einer älteren drahtlosen PC-PS2-Tastatur (aber unter Verwendung der echten SX-Tastatur!) und "verstecktem" internen Receiver und entsprechendem Wandler zu pimpen

    Ich war bisher der Meinung, daß man für eine saubere Lösung einen 8x8 Matrixschalter wie den CD74HCT22106 braucht. Aber die Erkenntnis, daß man PortB vernünftigerweise nicht auf Ausgang (high) programmieren sollte, eröffnet eventuell neue Möglichkeiten für eine einfachere Lösung, die nur PortA belauscht und PortB entsprechend kurzzeitig schaltet, um Tastendrücke zu simulieren

    Das Problem ist aber halt, daß man aus dem Pegel eines Pins auf PortA an sich nicht unbedingt auf den Zeitpunkt schließen kann, an dem PortB gelesen wird. Beim Kernal-Keyscan bleibt PA7 zum Beispiel dauerhaft low (solange keine Taste gedrückt ist). Selbst wenn man auf PA0 lauscht und dann den Keyscan für PA7 abpaßt, ändert das nichts daran, daß die an PA7 hängenden Tasten jederzeit ohne Keyscan ausgelesen werden können. Was der Kernal meines Wissens auch tut (laut Kommentaren für doe Stop-Taste).

    Ich fürchte deshalb, daß man auf diese Art keine 100%-Lösung hinbekommen kann.

    Mir ist zwar auch nicht ganz klar wie das im Kernal umgesetzt ist, ich nehme an über Interrupt

    oder Flag2, aber auch wenn du eine an PA7 angeschlossen taste drückst startet der Keyscan.


    d.h. wenn ein Keyscan gestartet ist, muss du nur auf PA 7 warten...


    Mfg Jood

    Ja, ich gebs zu, ich habe schon länger einen PIC18F als PS2-C64 KeyController am Laufen und unter reinem Basic resp. Kernal funzt das auch soweit schon ganz gut.

    Habe mich an den Kernal-Routinen orientiert, wie sie im VC20-intern von Data-Becker gut dokumentiert sind. (vermutlich auch im "alten" C64 intern, da fast paste&copy)


    Ich wollte es schon mal hier auf F64 veröffentlichen, aber dann hab ich kurz Kaiser angespielt und festgestellt, dass Joystick-Benutzung das Ganze komplett durcheinander bringt...


    Als Vorteil braucht es weder analoge Switch-Matrix noch sonst teure Spezialchips, das PS2-Protokoll hat der Compiler schon als Library mit an Board und mitlauschen C64-seitig kann ich prinzipiell auch, d.h. könnte ich auch Keyrah like die C64 Tastatur (ob mit oder Ohne aktiven C64) ins PS2-Protokoll übersetzen (was ich aber nicht vorhabe, da ich nach über 30 Jahren am PC einfach die AT-MFII-Tastatur deutlich besser gewohnt bin...)


    PA7 ist nicht das Problem, sondern eher Teil der Lösung, daher auch meine Frage nach abweichenden Scan-Vorgängen, insb. deren Anfangs"vektor" auf Port A, um die erkennen zu können. Der Rest ist aktuell eine kleine "DRL", eine Dioden-Widerstandslogik, die mir den Portpin-Change-IRQ am PIC immer dann auslöst, wenn eine interessante Flanke anliegt und dann muss natürlich der dazu passende Wert schnellst möglichst rausgeschrieben werden... Bei bis zu 64 MHz CPU-Takt, vergleichbar mit ca 25 MHz einer 6502, sollte ich damit aber immer schneller sein als ein C64 oder auch C128 im native mode. (Assembler im IRQ-Teil, ansonsten C)


    Problematisch sind Scans, die sehr unregelmäßig kommen und von der Dauer her auch unregelmäßig sind, oder Initialmuster, auf die ich reagieren MUSS, mit was auch immer, nur um überhaupt einen Detail-Scan dann auszulösen, sowie diese von Joystick-B-Aktionen oder gar Joystik-B UND Joystick-A Aktionen gleichzeitig zu unterscheiden.


    (ok, da kann man jetzt sagen, am C64 würde das genauso zu ner Fehleingabe führen, die vom Programm dann zu unterdrücken ist, aber der Unterschied ist eben, dass ich ja damit auch aktiv Joystick A Werte vorgeben würde, die in Wirklichkeit von der PS2-Tastatur gelesen wurden, und damit rechnet vermutlich kein Programm, wie auch?)


    Oder scans, die die Reihenfolge der aktiven PA-Pins umkehren oder gar willkürlich wählen, um z.b. nur ein paar Tasten abzufragen. Dazu noch die Pegel-Wechsel auf PA6/7 wenn Paddles oder Maus mit im Spiel sind, Geos z.b. habe ich bislang komplett ignoriert offen gesprochen.


    Da ich selbst nur sehr wenige Spiele am C64 spiele, davon einige wie Kaiser, die in Basic mit nur wenigen Hilfsroutinen in Assembler basieren, kann es gut sein, dass meine Lösung die hardcore Spieler enttäuschen würde...


    Daher möchte ich es zunächst 100% für die großen CBM anpassen, die haben zum Einen eine noch größere Matrix, zum Anderen sind die SK-Modelle ja von akutem Tastaturmangel geplagt, klar, man kann, wie auch am C128D C64-Tastaturen anschliessen, aber braucht man dann auf den SKs auch ein passendes ROM dafür und verliert den Ziffernblock und dort sind weder Joysticks noch Maus ein wirkliches Problem, d.h. wenn es wo geht, dann dort!

    Also es gibt zumindest Spiele wie Commando, die PA7 die ganze Zeit auf low lassen und so die Space-Taste ohne Keyscan erkennen.

    Koronis Rift reagiert aus Space, ohne daß PA7 dazu auf low gezogen wurde, aber nach dem Drücken von Space erscheinen auf PA7 alle 20ms ca. 13µs lange High-Pulse.

    Gibt noch andere Exoten, aber ich werde einen Thread dafür eröffnen.

    Fürs Protokoll: ich habe eben gerade "Attack of the Mutant Camels" (mein erstes kommerzielles Spiel, das aber leider im Strudel der Zeit verloren ging) mit dem U64 und meiner alten Datasette von einem TAP-File auf eine Kassette aus den 90ern gespielt und dann mit dem 250466+ ganz "old style" wieder von Datasette geladen. Ich kann jetzt also jetzt bestätigen, daß auch eine Datasette wie erwartet am 250466+ funktioniert. Hätte nicht gedacht, daß ich nochmal ein Spiel von Kassette laden würde ;)