Beiträge von 0xdeadbeef im Thema „Kleiner Maustreiber“

    Mir ist gestern nach dem Testen eingefallen, daß ich in meinem Brotkasten ja derzeit einen ArmSID verbaut habe. Nur um sicherzugehen, habe ich den Test inzwischen nochmal mit einem Shortboard mit echtem SID wiederholt, aber das Verhalten ist identisch. Der ArmSID bildet die PotX/Y-Erfassung also anscheinend recht genau ab.

    Jupp. Finde ich jetzt eigentlich gar nicht überraschend. Wenn Du die PotXY-Werte direkt nach dem Umschalten des Multiplexers ausliest, kann das mit einem echten SID eigentlich überhaupt nicht funktionieren.

    Ich vermute, daß Vice die PotX/Y-Eingänge des SID nicht wirklich detailliert simuliert, sondern nur die Stellung des Multiplexers berücksichtigt.

    Ich wäre sehr dankbar, wenn jemand mal mein Programm (Anhang) mit 1351-Maus in Port 2 an echter Hardware testen könnte.

    Habe das "Minesweep" von der TestDisk gerade auf meinem echten Brotkasten und einer MouSTer-Maus an Port2 ausprobiert.

    Zur Sicherheit habe ich vorher nochmal den "besseren" Maustreiber (Nummer 2/M1351.64.*) von der 1351-Demodisk ausprobiert und auf Port 2 konfiguriert: dieser Treiber funktioniert an Port 2 wunderbar.

    Demnach dürfte es nicht laufen.

    Dem ist leider so. Mit der Maus in Port 2 bewegt sich der Mauszeiger die ganze Zeit ruckelnd von oben nach unten, sobald man die Maus einmal berührt hat und das bleibt so, auch wenn man die Maus danach nicht anfaßt. Bewegungen der Maus haben keinen Einfluß. In Port 1 funktioniert die Maus dagegen.

    Das entspricht ehrlich gesagt meinen Erwartungen. Der Multiplexer ist erst zu kurz auf Port 2 umgeschaltet, also stammen die PotX/Y-Werte noch von Port 1. Ohne Maus in Port1 wird also nur irgendwelcher Mist gemessen. Wenn eine Maus eingesteckt ist, werden nach dem Ende des IRQs dutzendfach plausible PotY/Y-Werte an Port1 gemessen.

    Jeder CIA hat zwei Ports (A und B) mit jeweils 8 Pins (0..7). PA6 und PA7 sind die Schaltplanbezeichnungen der Pins 6 und 7 von PortA.

    Alle diese 16 Pins sind jeweils als OpenDrain-Ausgang mit integriertem Pullup oder als Eingang benutzbar. Diese Auswahl geschieht über das jeweilige DDR-Register (DDRA/DDRB).

    Also ich kann nur sagen, wie PotX/Y-Eingänge nach meinem Verständnis funktionieren, weder wie genau sie in Emulatoren nachgebildet sind noch wie gut die Mausroutine in diesem Basicspiel funktioniert.

    Tatsache ist, daß PA6 von CIA1 die PotX/Y-Leitungen von PortA (1) mit dem SID verbindet und PA7 die PotX/Y-Leitungen von PortB (2). Wenn beide Bits gesetzt sind, dann sind sowohl PotX/Y von PortA als auch PotX/Y von PortB mit dem SID verbunden und damit untereinander kurzgeschlossen.

    Sicher ist auch, daß diese beiden Ausgänge des CIA1 Teil der Tastaturmatrix sind und deshalb von der Kernal-Tastaturroutine benutzt werden. Soweit ich weiß, programmiert die Kernal-Routine die Pins von PortA des CIA1 als Ausgänge und schiebt dann eine 0 (low-Pegel) von PA0 nach PA7 (0xFE wird geladen und dann per ROL rotiert und nach 0xDC00 geschrieben). Der Quelltext des Kernals läßt vermuten, daß am Ende des Keyboard-Routine immer ein Wert von 0x7F im Register 0xDC00 steht. Damit wäre PA6 high und PA7 low. Was PA6/7 angeht, wäre damit also PortA ausgewählt. Vermutlich bleibt dieser Wert stehen bis zum nächsten Interrupt. Habe das kurz in Vice ausprobiert und da ist es auch so:

    Code
    break ea31
    io dc00

    --> "Port A: 7f DDR: ff"

    Wenn man also am Anfang des umgebogenen IRQs PotX/PotY ausliest und zwischenzeitlich niemand 0xDC00 überschrieben hat, dann war ja längere Zeit PortA mit dem SID verbunden und das Auslesen der PotX/Y-Werte ist kein Problem. Vermutlich klappt deshalb die Mausroutine in dem Basicspiel auch ohne explizites Warten auf Port A. Wenn man nun allerdings am Anfang des umgebogenen IRQ-Handlers auf PortB umschaltet, indem man eine 0x80 nach 0xDC00 schreibt, dann muß man eine Zeit (>1.6ms) warten, bis der SID über seine Lade-/Entladefunktion die Widerstände an PotX/Y sicher ausmessen konnte. Keine Ahnung, wie exakt das Emulatoren nachbilden. Meine Vermutung wäre: gar nicht.

    Aus diesem Grund wartet der genannte "bessere" Maustreiber von der 1351 Demodisk knallhart 4ms im Treiber, nachdem er die CIA-Pins umgeschaltet hat. Ob das eine elegante Lösung ist, sei mal dahingestellt.

    IMHO muß das höherwertige Bit (7) gesetzt sein, 1<<7 = 0x80.

    Und wenn man nichts in 0xDC00 schreibt, dann steht da halt drin, was irgendjemand vorher reingeschrieben hat - im Zweifelsfall die Tastaturroutine des Kernals, wenn die nicht umgebogen wurde.

    Aber wie gesagt: eigentlich reicht es nicht, direkt vor dem Auslesen umzuschalten. Wenn die PotX/Y-Leitungen des SID vorher durch den Tastaturscan o.ä. mit dem anderen Port verbunden waren, braucht es eine gewissen Zeit, damit das Lade-/Entladespielchen mit den Kondensatoren abgeschlossen werden kann.

    Es gibt ja nur jeweils einen PotX- und PotY-Eingang am SID. Zwischen den beiden Ports wird daher mit einem Analogschalter 4066 umgeschaltet, der wieder über PA6/PA7 von CIA1 angesteuert wird. Diese Leitungen werden auch von der Bios-Tastaturabfrage umgeschaltet, was einer der Gründe ist, warum man einen Interrupt für die Maus braucht. Um vom Tastaturscan unbeeinflußte Ergebnisse zu bekommen, müssen die PotX/Y-Eingänge des richtigen Ports >1.6ms mit den PotX/Y-Eingängen des SID verbunden sein, bevor man die Werte ausliest.

    Kennst Du die 1351 Demodisk? Ansonsten siehe Anhang.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das "bessere" Demoprogramm von der C1541 Demodisk (M1351.64.*) schreibt tatsächlich entweder 0x40 (Port1) oder 0x80 (Port2) in CIA-Port-Register bei 0xDC00 und wartet dann 4ms vor dem Auslesen der POT-Werte.

    Das einfache Demoprogramm tut das aber nicht. Hier sind wohl (wie auch normalerweise ohne spezielle Programme) die beiden Pins PA6/PA7 die meiste Zeit high sein, weil die Kernal-Tastaturabfrage meines Wissens eine 0 (Low-Pegel) durch die Ausgänge PA0..PA7 schiebt. Nach dieser Logik wären alle vier Schalter des 4066 die meiste Zeit eingeschaltet und damit wären POTX/Y von PortA und PortB die meiste Zeit gleichzeitig quasi kurzgeschlossen. Das ist aber auch genau der Grund dafür, daß das eben das einfache Beispiel ist. Es geht halt auch irgendwie, aber es darf kein Paddle oder so am anderen Port angeschlossen sein und wenn man den Wert gerade einliest, während der Keyscan den Multiplexer deaktiviert, dann zuckt die Maus.

    -> Habe mir Deine Funktion nicht angeschaut, aber ich würde erwarten, daß irgendwo 0x40 nach 0xDC00 geschrieben wird und das müßtest Du in 0x80 ändern. Oder so.