Atari Falcon mit merkwürdigem Tastaturproblem (Ghost-Touch)

[kcr]

Hallo Allerseits.

Habe neuerdings an meinem Falcon ein merkwürdiges Phänomen entdeckt, was doch ganz schön stört...
Und zwar scheint er sporadisch (aber gefühlt immer öfter) vor allem nach Mausbewegung im TOS (und auch bereits in XBoot) selbstständig Tasten zu drücken.
Bewege ich die Maus ist es so, als würde ich eine Taste gedrückt halten - es kommt der Tastenklick wie aus dem Maschinengewehr. Nicht immer aber immer wieder.
Es scheint vornehmlich die ESC-Taste zu sein, aber nicht nur. Öffne ich ein Laufwerk geht's los und er aktualisiert mir ständig den Inhalt... also so, als ob die ESC-Taste gedrückt wird. Manchmal hört es nach tatsächlichem Drücken auf die Tastatur auf, manchmal nicht, geht aber meist gleich wieder los.
An der Tastatur liegt es nicht, habe ich schon gegen getestet und auch nicht an der Maus. Keine Ahnung was das sein kann, hatte ich bisher noch nie... Kann mich auch nicht entsinnen, wann es angefangen hat, bzw. was ich geändert haben könnte. Habe vor kurzem die Vulture RAM-Erweiterung von Lotharek eingebaut, aber das wird es wohl nicht sein.
Jemand eine Idee? Werde hier noch verrückt.   
Dank im Voraus.

PS: Habe mal kurz die Maus abgemacht, und mit Tastatur bedient. Da scheint alles ok. war aber auch kein langer Test.

PPS: Es scheint sogar nur nach Mausbewegung zu sein - irgendwie interpretiert der Falcon (sporadisch) Mausbewegungen als Tastenklick.

[czietz]

Hier ist, was passiert: Wie Du sicherlich weißt, werden Tastendrücke und Mausbewegungen vom Tastaturcontroller über dieselbe Schnittstelle zum ACIA auf dem Mainboard übertragen. Bei Mausbewegung kommt zuerst ein spezielles Byte, das bedeutet: es folgende Mausdaten -- es folgen dann zwei Bytes mit x- und y-Bewegung. Ein Problem entsteht, wenn das erste Byte verloren geht. Dann weiß TOS nicht, dass es sich um Mausdaten handelt und interpretiert die x- und y-Bewegung stattdessen als Tastendrücke. Z.B. hat [Esc] den Code 1, sodass eine kleine Mausbewegung (nur um ein x- oder y-Increment) als Drücken von [Esc] interpretiert würde.

Wie kann nun ein Byte bei der Übertragung verloren gehen? Der ACIA hat keinen FIFO für empfangene Daten. Kommt ein Byte an, muss es abgeholt werden, bevor das nächste Byte ankommt. Sonst ist das erste Byte unwiederbringlich verloren. Deshalb kümmert sich in TOS ein Interrupthandler mit hoher Priorität darum, dass Bytes aus dem ACIA abgerufen werden. Wenn Du aber ein Programm (auch Hintergrundprogramm aus dem AUTO-Ordner oder ACC) benutzt, dass für zu lange Zeit Interrupts sperrt und Du in dieser Zeit die Maus bewegst, dann kommt es zum partiellen Datenverlust und damit zum von Dir beschriebenen Phänomen einer scheinbar hängenden Taste.

Zur Fehlersuche: Da Du schreibst, dass das Problem auch schon in XBOOT auftritt: Startest Du irgendwas noch vor XBOOT?

Andernfalls kommen für den Datenverlust auch noch schlechte Verbindungen oder sich langsam verabschiedende Tastaturcontroller, ACIA oder MFP (kümmert sich um den Interrupt) in Betracht.

[kcr]

Ok, habe noch weiteres festgestellt: das Phänomen passiert, wenn ich bei Festplattenzugriffen die Maus bewege. Also z.B. wenn ich den Fileselektor Freedom2 starte, er die CPXe lädt und ich dabei die Maus bewege. Bewege ich die Maus nicht, ist alles ganz normal. Da konnte ich auch sehen, dass es die Tasten ESC, 1,2 und 3 sind, da es ja ein Fileselektor ist und die Eingabe sichtbar wird.

Also Tastatur kann es nicht sein, die habe ich gegen getestet.

[czietz]

Ok, habe noch weiteres festgestellt: das Phänomen passiert, wenn ich bei Festplattenzugriffen die Maus bewege.

Dann liegt die Vermutung nahe, dass der Festplattentreiber zu lange die Behandlung der ACIA-Interrupts verhindert. Keine Ahnung, warum? Vielleicht braucht die Platte ungewöhnlich lange, um auf bestimmte Dinge zu reagieren?

Da konnte ich auch sehen, dass es die Tasten ESC, 1,2 und 3 sind, da es ja ein Fileselektor ist und die Eingabe sichtbar wird.

Das passt zu meiner Theorie. 1, 2 und 3 haben nämlich die Scancodes 0x02, 0x03, 0x04. D.h. eine Mausbewegung nicht um einen Schritt sondern um 2, 3, 4 führt statt zu [Esc] eben zu den weiteren Tasten.

[kcr]

@czietz Vielen Dank für deine Antwort. Ja, das hört sich alles sehr vernünftig an, was du da schreibst, auch wenn ich da nicht so die Ahnung von hab  Aber das Prinzip habe ich verstanden 
Ich denke nicht, dass es ein Softwarefehler ist. Habe gerade nochmal getestet: der Fehler tritt sofort nach dem Laden von HDDriver auf. Es sei denn, es liegt am HDDriver... werde da mal die Einstellungen checken.
Kann es ansonsten eventuell sein, dass vielleicht einer der Pins am Tastaturanschluss eine kalte Lötstelle hat oder so oder ist das Blödsinn?

[Lukas Frank]

Was für eine Festplatte steckt denn im Falcon? Vielleicht ist die kurz vor tot?

[kcr]

Also ich glaube, ich hab's: es ist der HDDriver 11.01

Habe die Option "IDE Beschleunigter Modus" Deaktiviert. -> Alles läuft wie es soll.

Puh, da ist mir ein STein vom Atari-Herzen gefallen 

Wofür ist denn die Option gut? Für den Laien klingt IDE Beschleunigung ja erstmal gut - muss da die Platte mit kompatibel sein? Es ist ein "normaler" Falcon mit mechanischer IBM 20GB Festplatte.

[czietz]

Wofür ist denn die Option gut? Für den Laien klingt IDE Beschleunigung ja erstmal gut - muss da die Platte mit kompatibel sein? Es ist ein "normaler" Falcon mit mechanischer IBM 20GB Festplatte.

Eventuell ist das ein Punkt, zu dem Du Uwe Seimet (den HDDRIVER-Autor) befragen solltest. Aus meiner Sicht sollte HDDRIVER auch im "beschleunigten Modus", der den Transfer von mehreren Sektoren am Stück ermöglicht, nicht so lange die Interrupts sperren, dass es zum oben beschriebenen Problem kommt.

[kcr]

Ok. Vielen Dank. Werde mal bei Herrn Seimet nachfragen.

[czietz]

Hm, ich habe da so eine Vermutung? Hast Du im HDDRIVER die Blitter-Unterstützung für IDE aktiv? Falls ja: Verschwindet das Problem, wenn Du diese Blitter-Unterstützung abschaltest und dafür den "beschleunigten Modus" wieder einschaltest?

[kcr]

Blitter Unterstützung habe ich auch deaktiviert, weil damit z.B. BadMood offenbar ein Problem hat.

Aber ich werds nochmal testen.

[czietz]

Blitter Unterstützung habe ich auch deaktiviert, weil damit z.B. BadMood offenbar ein Problem hat.

Das heißt: Mit Blitter-Unterstützung aus und beschleunigtem Modus an tritt das beschriebene Problem weiterhin auf? Das ist eine wichtige Frage, weil dann meine oben angedeutete Vermutung falsch wäre.

[jeloneal]

Bist du sicher, dass du den Blitter nicht nur im TOS sondern explizit auch in HDDRiver deaktiviert hast? Ich könnte mir vorstellen, dass HDDriver die TOS Einstellung ignoriert.

[kcr]

Ja, ich habe die Einstellungen im Hddriver gemacht.

@czietz Nein, du hattest wohl Recht. Ich habe die Blitter-Unterstützung zusätzlich deaktiviert, da ich festgestellt habe, dass sich BadMood aufhängt. Nach Ausschalten dieser Option läuft auch das.
Der ursprüngliche Fehler war aber schon durch die Deaktivierung der IDE-Beschleunigung verschwunden.

[czietz]

Nein, du hattest wohl Recht. Ich habe die Blitter-Unterstützung zusätzlich deaktiviert, da ich festgestellt habe, dass sich BadMood aufhängt. Nach Ausschalten dieser Option läuft auch das.

Es reicht, also entweder die Blitter-Unterstützung oder(!) den beschleunigten Modus abzuschalten? (Sorry, dass ich nochmal nachfrage. Ich kann es mangels passender Hardware nicht selbst testen.) Dann wäre meine Vermutung wohl richtig.

Das ist so ein "Well, f***, that didn't work"-Moment. Ich fühle mich mitschuldig, weil ich Uwe Seimet wohl auf die entsprechende Idee gebracht habe. Ich schreibe ihm mal, morgen oder in den nächsten Tagen, wenn ich Zeit habe.

[kcr]

Aha, also du bist der Übeltäter 

Aber ja, du scheinst wieder Recht zu haben: Habe mal den beschleunigten Modus wieder aktiviert OHNE Blitter Unterstützung -> bislang keine Fehler. Scheinbar geht also tatsächlich entweder oder, aber nicht beide gleichzeitig.

Übrigens: Im Gegensatz zu der eingeschalteten Blitter Option in HDDriver läuft BadMood mit eingeschalteter Beschleunigung für IDE.

[czietz]

Aha, also du bist der Übeltäter 

Man könnte auch sagen, der Foren-User ist schuld, der Uwe einst überhaupt auf die Idee mit dem Blitter gebracht hat.

Ich habe jedenfalls meine Vermutung mit Uwe diskutiert und er bittet Dich @kcr, mit ihm Kontakt aufzunehmen, damit Du einen potenziellen Fix auf Deinem Falcon testen kannst. Seine E-Mail-Adresse findest Du auf der Webseite: https://www.hddriver.net/de/contact.html

[kcr]

Na klar, mache ich gerne 

Werde ihm gleich schreiben...

Edit: Mail ist raus...

[goetz @ 3rz]

Aha, also du bist der Übeltäter 

Man könnte auch sagen, der Foren-User ist schuld, der Uwe einst überhaupt auf die Idee mit dem Blitter gebracht hat.

Uwe hatte Blitter-Support so 1993-1994 schonmal testweise in HDDRIVER eingebaut, aber nicht herausgebracht. Nachdem Christian hier über IDE-Support in AHDI berichtete, und nach Erfahrungen mit ppera’s Treiber, habe ich Uwe Mitte Februar angeschrieben, ob wir das mit dem Blitter nochmal probieren wollen.

Wollte er. Und da meine Lightning ST noch nicht einsatzbereit war, hab ich auf dich zum Test verwiesen

Und als Ergebnis haben wir jetzt HDDRIVER mit Blitter-Support, fein.

[czietz]

Nachtrag:

6. September 2020: HDDRIVER 11.03 ist verfügbar

Änderungen in dieser Version
•HDDRIVER: Problem behoben, das bei Kombination von beschleunigter IDE- Übertragung und Blitter-Unterstützung zu scheinbaren Tastendrücken bei Mausbewegungen führen konnte.
•HDDRUTIL: Die Bus- und Geräte-IDs unter "Geräte und Partitionen" sind für jedes Gerät editierbar und nicht mehr nur für Geräte mit einer Bus-ID größer als 2.

(Quelle: HDDRIVER-Webseite)