(Kap. 3) Der Weg des Joystick-Signals

Diese Tabelle zeigt die Stationen, die das Joystick-Signal vom Anwender bis zum Bildschirm durchläft.

(Vergleiche Anlage "Tabelle Signalübertragung" und Anlage "Datei Signalübertragung.doc")

Der Weg des Joystick-Signals (1998-07-10,15:10)
Station	Zugriff	`Notiz`
Anwender Bewegt den Hebel	Intuitiv, visueller Feedback, Force Feedback, Try and Error, Training.	`Random. Dies ist die Signalquelle aus Sicht der Anwendung. Dieses "Signal" ist es, das möglichst naturgetreu bis zur Anwendung übermittelt werden soll.`
Mechanik Zwischen Hand und Potentiometer.	Hebelgesetz	.
Potentiometer Setzt geometrische Information (Winkel) in elektrische Information (Widerstand) um.	Wahl des Potentiometers	`Signalquelle aus Sicht der Joystick-Elektronik.`
Joystick-Elektronik	Gibt es nicht. Außer bei Force Feedback oder evtl. anderen seriellen Joysticks.	`Die Drähte des Kabels von der Adapter-Karte sind direkt mit den Potis bzw. Knöpfen verbunden.`
Kabel Von Joystick zu Adapter-Karte	Je ein Draht zu jedem Potentiometer und Knopf.	`Signalquelle aus Sicht der Adapter-Karte` `(CHECK - Gameport Spezifikation)`
Adapter-Karte "Horcht am Bus", ob eine bestimmte Port-Adresse (201H) gefragt ist. Sie antwortet, indem sie "ein Signal auf den Bus legt", und zwar eines, das die gefragte Port-Adresse (201H) mit Inhalt füllt.	Kein Zugriff bei fertigen Karten. Beliebiges Verhalten bei Selbstbau.	Der Bau einer eigenen Karte ist möglich, die Karte muß sich "lediglich" an die Spezifikation des System-Bus halten. `(Hardware Analog/Digitalwandlung, Kondensator-Entladung)`
Systembus Das Signal verläßt den joystick-spezifischen Bereich und wird für das System sichtbar, man sagt "es liegt am Bus". Dort ist es unter Port-Adresse 201H abfragbar.	(Oszilloskop, Digital Analyzer)	`Hinweis: Die Ports sind ein Speicherbereich, auf den sowohl Karte wie auch Prozessor Zugriff haben.` `Die Bus-Spezifikation wird beim Bau einer Karte und beim Bau des Computers gebraucht, bei der Programmierung hilft sie normalerweise nicht. Vielleicht wäre sie nützlich zur Frage, wie verschiedene Hardware (Prozessor, Taktrate, Busbreite, ...) das Signal beeinflußt.`
Port-Adresse 201H Das Signal liegt als Byte im Port an einer vereinbarten Adresse () Niedrigste Software-Ebene, typischerweise von BIOS, Treibern und API-s genutzt, seltener von der Anwendungs-Software selber.	Schreib- und Lesevorgänge mittels der Assembler/C-Befehle `In` und `Out`	`Signalquelle aus Sicht der System-Software` Beachte: Ein einzelner Lesevorgang liefert ein einzelnes Byte den sog. Joystick-Status - eine für sich betrachtet wertlose Information. Das Status-Byte muß über eine gewisse Zeit beobachtet werden, um Zahlenwerte daraus zu bekommen! Hier steckt wohl der springende Punkt beim Joystick-Tuning via Software! Diese Zugriffs-Art wird normalerweise verwendet von BIOS, Treibern und evtl. von Low-Level-Funktionen innerhalb der Anwendung. Beispielquelltext readStick() von Radtke/Lampten.
BIOS-Routinen Liefern 2 Knöpfe und 4 Achsen (Achsen je als 16-Bit-Zahl)	Interrupt 15H Funktion 84H (Erst ab AT)	`... mißt die Dauer der Impulse um daraus Zahlenwerte liefern zu können ...` `Dieser Zugriff wird typischerweise von DOS-Anwendungs-Software verwendet, die nicht bis auf Port-Ebene hinuntergehen will (z.B. Joystc.c von Tischer).`
DOS-API .	(Interrupt 21H - keine Joystick-Unterstützung)	`-`
Windows API .	Multimedia-Funktion `joyGetPosEx()` ... und ca. 15 weitere Funktionen, incl. Joystick-Verwaltung	`(Vergleiche Anhang "mm.hlp", Auzug aus Borland C++ Hilfedatei)`
Compiler Libraries	.	`CHECK`
Direct Input .	Zugriff mittels COM-Interface (MS Component Object Model) ab Version 5. ... wrappt die Win32-API-Funktionen ...	`...`
Eventuelle weitere Schichten .	.	`.`
`Nur für Radtke/Lampton` Eventmanager Zentrales Design-Element der Anwendung, hier tritt das Signal in die Anwendung ein.	Zugriff über anwendungs-interne Low-Level-Assembler-Prozedur readstick(), erhält von dort 2 Knöpfe zu je 1 Bit und 4 Achsen zu je 16 Bit. (Vergleiche oben, Ebene der Port-Adresse 201H) .	`Signalquelle aus Sicht des Flugmodells (Vergleiche Programmbeispiel readstick() )` `Charakteristisch für objektorientierte Programmierung` `Vergleiche Kommentar "Event-Manager"`
Flugmodell Signal wird endlich verarbeitet. Der Anwender-Befehl flie޴ in das Programmgeschehen ein.	Wahl des Flugmodells.	`.`
Grafik Schicht zur Aufbereitung der Ausgabe.	(Kein Zugriff mehr)	`.`
Bildschirm Ausgabe.	(Kein Zugriff mehr)	`.`
Anwender Ergebnis wird für den Anwender sichtbar. Rückkopplung via Handbewegung. Signalablauf beginnt von vorne.	(Kann auf Effekte achten)	`.`
Hinweis - sprachlich verwirrend ist folgendes: Die Tabelle beginnt oben* mit den "unteren System-Schichten" und endet unten mit den "oberen System-Schichten".*