(Kap. 6) Fragen und Antworten

(Letztes Update 1998-07-09,16:00)

Hier eine Zusammenstellung der im Joystick-Papier aufgetauchten Fragen.

Fragen und Antworten Letzte Aktualisierung: 1998-07-21
Frage	Antwort	Notiz

`(# 1998-07-15)` Was ist im Joystick-Gehäuse?	Nur die Mechanik und Potentiometer. Keine "Signal-Aufbereitung".	.
`(# 1998-07-15)` Findet die Kondensator-Entladung in der Joystick-Elektronik oder auf der Adapter-Karte statt?	Auf der Adapter-Karte. Im Joystick selber sind lediglich Potentiometer.	.
`(# 1998-07-15)` Der Joystick enthält die A/D-Wandlung und sendet seriell fertige Werte. Wie teuer?	Gibt es bereits.	Force Feedback funktioniert seriell!
`(# 1998-07-15)` Selbstbau Adapter-Karte?	.	Besser vielleicht eine fertige Karte modifizieren - Kondensatoren umschaltbar einbauen.
`(# 1998-07-15)` Parameter für Entladezeit? Wodurch wird das Ende der Entladezeit bestimmt?	.	.
`(# 1998-07-15)` Gameport Spezifikation?	.	.
`(# 1998-07-15)` Welche Libraries mit Joystick-Funktionen gibt es, bzw. gibt es überhaupt welche?	GLUT	.
`(# 1998-07-15)` Ist das BIOS im Protected-Mode irgendwie nutzbar?	.	.
`(# 1998-07-21)` Programmierbeispiele für das Ansprechen der Ports im Protected-Mode?	.	.
`(# 1998-07-15)` Details über den Joystick-Zugriff von DirectInput.	.	.
`(# 1998-07-15)` Linux. Wo sitzt der Joystick-Treiber? Wie kommt er dort hin? Wer hat ihn gemacht?	.	.
`(# 1998-07-15)` Funktioniert eine Joystick-Adapterkarte in einem Linux-PC überhaupt?	.	.
`(# 1998-07-15)` Wie lassen sich die anderen Prozesse kontrollieren oder unterdrücken? Welche Assembler-Befehle gibt es dazu? Was ist im Protected-Mode alles möglich für ein Anwendungs-Programm ohne Betriebssystem-Privilegien? ... oder ist das zu weit gegriffen?	.	.
`(# 1998-07-15)` Wie handhabt der Prozessor das Timeslicing für Multititasking und Multithreading innerhalb einer CLI/STI-Passage? WICHTIG!	.	.
`(# 1998-07-15)` Das BIOS läuft im Real-Mode, also salopp ausgedrückt "Dos" -- kann man das so sagen?	.	Scherzfrage.
`(# 1998-07-15)` Windows-95 verläßt im DOS-Modus den Protected-Mode. Windows kehrt zurrück zu DOS. Kann man das so sagen?	.	.
`(# 1998-07-12)` Wodurch genau werden im Protected-Modus die BIOS-Interrups ersetzt? Namen für den Mechanismus allgemein?	Win32-API.	Im Real-Modus gibt es den BIOS- und DOS-Interrupt-Mechanismus. Im Protected-Modus ... System-Calls ... Notification-Messages ... .
`(# 1998-07-15)` Genaue Plazierung der Uhr im System-Layout?	.	.
`(19980715)` Von der Adapter-Karte wird das digitale Signal aus einer Kondensator-Entladung gewonnen. Welche sonstigen Möglichkeiten gibt es?	?	[E] Suche im Fachhandel A/D-Wandler heraus und schaue, welche Prinzipien angeboten werden, z.B. Conrad-Katalog. Besser: Fachbuch über A/D-Wandlung!
`(#)` .	.	[x] .
`Kennzeichnung wer eine Frage beantworten kann? Elektroniker [E], Grafik-Programmierer [G], Hardware-Spezialist [H], Betriebssystem-Spezialist [B], Pilot [P].`

Vorschlag für Einteilung der Fragen in Gruppen:

Joystick
Adapterkarte
Bus
Port
Assembler/C/C++
BIOS
Treiber
Win32-API
DirectX
OpenGL
Flight model
Sonstige
...

Frage zu Signalübertragung.doc, Box Software/Ansteuerung (# 19980709)

"Software" und "Ansteuerung Schreib- und Lesevorgänge" - ist das das gleiche?

Je nach dem, was mit "Software" genau gemeint ist. (1) Wenn mit "Software" auch Systemsoftware wie BIOS oder Treiber gemeint ist, dann ja. (2) Wenn mit "Software" die Anwendungssoftware gemeint ist, die zwecks Input lediglich irgend eine BIOS- oder Treiber-Schnittstelle nutzt, dann nein.

Mit "Schreib- und Lesevorgänge" dürfte das Schreiben und Lesen der Port-Adresse 201H gemeint sein. Das ist ein Vorgang auf niedrigstem System-Niveau. Dazu gibt es die Assembler/C-Befehle IN und OUT. Diese Befehle werden normalerweise nur von Betriebssystem oder Treiber-Software genutzt. Im Fall von Radtke/Lampton's readstick könnte man sagen, der Treiber ist in der Anwendung eingebaut.

Das Lesen der Joystick-Information ist aber nicht ein einzelner IN-Befehl, sondern ein komplizierterer Vorgang in einer Schleife, die mit dem IN-Befehl schaut wie lange ein bestimmtes Bit gesetzt ist und die Zeit mißt. Deshalb ist hier nicht lediglich von "Schreib- und Lesevorgängen" die Rede, sondern gleich von "Software".

Mit "Software" dürften an dieser Stelle dann folgende gemeint sein: (1) BIOS-Routinen, (2) Treiber-Software oder (3) Low-Level-Prozeduren in Anwendungs-Programmen (wie in Radtke/Lampton's readstick). Dies ist aber nur die unterste Ebene von mehren Software-Ebenen, die typischerweise in einer Anwendung beteiligt sind.

Frage zu Signalübertragung.doc, Box Eventmanager (# 19980709)

Eventmanager, ist das ein eigener Schritt oder ist das in Punkt Programmierung beinhaltet?

(Vergleiche Kommentar "Eventmanager")

Es ist ein Modul der Anwendungssoftware. Radtke/Lampton verwenden C++, dessen Philosophie genau dieses Design unterstützt bzw. herausfordert. (1) Wenn die Anwendung selbst genauer aufgeschlüsselt werden soll, dann ist es sinnvoll, den Event-Manager als eigenen Punkt auszugliedern <(Vergleiche Tabelle "Der Weg des Joystick-Signals" und Kommentar "Event-Manager")> . (2) Wenn die Anwendung als Monolith erscheinen soll, dann ist der Event-Manager darin enthalten.

Da Windows selbst ebenfalls dieses Event-Design besitzt (d.h. es ist objektorientiert), ist es sinnvoll, das Win-API auch als Event-Manager zu betrachten. Dann hat man es im Gesamt-System mit zwei Event-Managern zu tun, dem von Windows und dem von der Anwendung.

Bemerkung zu Events. Um sich noch komplizierere Strukturen vorstellen zu können, kann man den Event als Blase betrachten, die von unten 'blub blub' Schicht um Schicht aufsteigt. Von der Hardware bis zur Anwendung.

...

Frage im Anschluß an Tabelle Signalübertragung.doc (# 19980709)

Mit dem Game-adapter kann man bis zu vier Sensoren und vier Schalter anschließen und die Daten in den PC einlesen. Frage: Geht das auch mit der seriellen Schnittstelle?

Programmseitig ist es kein Problem, das Signal aus der seriellen Schnittstelle zu lesen. Allerdings - wie kommt das Signal dort hinein?

Das herkömmliche Signal über den Game-Port wird von der Adapter-Karte aufbereitet und dem System an einer vereinbarten Port-Adresse zur Verfügung gestellt. Dieser Schritt fehlt dann.

Das Aufbereiten des Joystick-Signals muß dann außerhalb des Computers erfolgen. (Vergleiche an anderer Stelle den Vorschlag, die Analog/Digitalwandlung möglichst sofort hinter dem Potentiometer vorzunehmen - und die unsägliche Kondensator-Entladung wegzulassen!)

Für Unix/Linux gibt es externe Adapter, die als Ausgang eine serielle Schnittstelle zum Computer hin haben.

CHECK - Funktioniert eine Joystick-Adapterkarte in einem Linux-PC überhaupt?

...

(Frage im Anschluß an Tabelle Signalübertragung.doc)

Welchen Einfluß hat die PC-Hardware auf die Verarbeitung der Joystick-Signale ? (CPU, Speicher, Festplatte usw.)

(CHECK - Diese Frage umlagern in geplante Tabelle "Klassifikation der Fehlerquellen".) Die Beantwortung dieser Frage stütz sich auf das Programmbeispiel von Radtke/Lampton, welches das Joystick-Signal auf niedrigster Software-Ebene behandelt.

(1) CPU Takt-Frequenz. In einer Zeitschleife wie in Radtke/Lampton's readstick erhält man bei doppelter Takt-Frequenz das doppelte Resultat. Dieses Problem wird durch die Kalibrierung gelöst . Man muß als Programmierer nur darauf achten, daß die Zahl der Schleifen-Durchgänge innerhalb des Darstellungsbereiches des zum Messen verwendeten Registers liegt (z.B. Register CX hat 16 Bit, d.h. Darstellung max. 32738 bzw. 65536), bzw. man darf die Überschlags-Behandlung nicht vergessen.

(2) Speicher. Normaler Arbeitsspeicher ist beim Lesen der Port-Adressen nicht beteiligt, sollte also keinen Einfluß haben. Allerdings, in einer Multitasking-Umgebung wie Windows weiß man das nicht.

CHECK - Wie lassen sich die anderen Prozesse kontrollieren oder unterdrücken? Welche Assembler-Befehle gibt es dazu? Was ist im Protected-Mode alles möglich für ein Anwendungs-Programm ohne Betriebssystem-Privilegien? ... oder ist das zu weit gegriffen?

(3) Festplatte. Die Aktivitäten der anderen Geräte (die ebenfalls die Port-Adressen nutzen) werden ausgeblendet durch die Assembler-Befehle CLI und STI. Wenn sie sich lassen! CLI/STI gewährleisten, daß der eingeschlossene Codeungestört läft, aber sie verhindern nicht eine Verzögerung, wenn schon ein anderer Prozess Interrupts gesperrt hat. ... Wenn die Festplatte wieder einmal ewig geswappt hat, dann ist der Kondensator länger als normal aufgeladen worden. Vielleicht braucht er dann auch länger als normal, um sich zu entladen. (CHECK - zu Tabelle Fehlerquellen.)

Zu Beginn des Programms schaltet CLI für die Dauer der Zeitmeß-Schleife die Hardware-Interrupts aus, die von anderen Geräten kommen könnten und deren Code dann die Zeitmessung störte. Hinter der Schleife werden mit STI die Interrupts (der anderen Geräte) dann wieder zugelassen. (Vergleiche Kommentar "Data Mode" Stichwort "Event-driven")

CHECK - Wie handhabt der Prozessor das Timeslicing für Multitasking und Multithreading innerhalb einer CLI /STI-Passage? WICHTIG!

Verbesserungsvorschlag für readStick(). Nicht die Anzahl Schleifendurchgänge zählen, sondern davor und danach die Zeit lesen.

CHECK - Neben solchen theoretischen Überlegungen lassen sich evtl. praktische Messungen ausdenken, die verschiedene Environments empirisch erfassen.

(4) ...

...

(Frage im Anschluß an Tabelle Signalübertragung.doc)

Wie wirken sich Fehler an den Potentiometern und Leitungen aus? Lassen sie sich durch „Programmierung” dämpfen ?

CHECK - Diese Frage umlagern in geplante Tabelle "Klassifikation der Fehlerquellen". Evtl. Frage hier als Zentrale verwenden, da die Antwort ohnehin über das Poti hinausgeht.

Welche Fehler könnten das sein? Z.B.:

(1) Wackelkontakte oder Signalschwankungen mit einer Dauer, die wesentlich kürzer ist als die Frequenz mit der das Programm aktualisierte Joystick-Werte braucht. In diesem Fall könnte man einen Wert mehrfach lesen und daraus den Mittelwert bilden.

(2) Unliniearitäten im Hebel-Weg. Die Kalibrierungen (soweit ich Code-Beispiele gesehen habe) erfassen nur die Extremstellungen und die Mittelstellung. Verbesserungsvorschlag: Kalibrierung über den gesamten Hebelweg, um Unlinearitäten herausrechnen. Dazu wäre z.B. folgende Kalibrierungs-Aufforderung denkbar: "Bewegen Sie den Joystick jetzt mit gleichmäßiger Geschwindigkeit mehrmals vom linken Rand zum rechten und zurück."

(3) Einzelne Ausreißer im Zahlenstrom. (Nicht Poti schuld) ...

(4) Systematische Ausreißer im Zahlenstrom. (Nicht Poti schuld) ...

(5) Weitere Fehler ...

(6) Induktionen von nahe am Weg liegenden Nachbar-Bauteilen. Reiches Spektrum! Räumliche Anordnung der Bauteile ist die Ursache. Korrektur durch Software ist denkbar.

(7) Weitere Fehler ...

Frage im Anschluß an Tabelle Signalübertragung.doc (# 19980709)

Wie lassen sich Signale im Flug-Modell dämpfen oder Kurvenverläufe anpassen?

(CHECK - Diese Frage umlagern in geplante Tabelle "Klassifikation der Fehlerquellen".)

Rückfrage: Was genau soll gedämpft werden? Zuerst der Versuch einer Klassifikation möglicher Störsignale (Achtung - unreflektierte Idee.)

(1) Frequenzen < 0.1 Hz Schwingungen länger als 10 Sekunden - kommen die wirklich vor? Kein Lösungsvorschlag. Das Problem dürfte hier weniger im Joystick als im Flugmodell stecken.
(2) Frequenzen 0.1 - 1 Hz Mittelwert-Bildung über wenige Werte möglich. Einschränkung durch Zeit: die notwendige Beobachtungszeit des Signals ist immer noch länger, als die Reaktion dauern darf. Oder? D.h. die Algorithmen sind evtl. komplizierter als (nächter Punkt) bei höheren Frequenzen.
(3) Frequenzen 1 - 10 Hz Hier dürfte der Bereich sein, in dem die Joystick-Achsen flackern (Tischer Beispielprogramm joystc.exe). Dieser Bereich ist mit Software-Mitteln evtl. rel. leicht zu kontrollieren (Gefühlsmäßige Aussage, denn: die Zeit ist kurz genug, um noch innerhalb der geforderten Feedback-Zeit zu liegen, aber lang genug, um nicht mit einzelnen Systemtakten kämpfen zu müssen.)
(4) Frequenzen > 10 Hz Hier dürfte der Bereich der maximalen Ablesefrequenz liegen, da gibt es nichts mehr zu glätten.

Hier gibt es verschieden aufwendige Möglichkeiten. Spontan fällt mir ein:

(Einfach) Mittelwert-Bildung über 3 bis 4 Werte.

(Aufwendig) Wenn die zu dämpfende Frequenz bekannt ist, kann evtl. ein Filter programmiert werden.

(Extrem) Fourie-Analyse des Signalstroms, und aufgrund der gefunden Frequenzen wird das Signal manipuliert. Einschränkungen durch die Forderung nach Echtzeit. Quelltextbeispiele wären vielleicht in der Seismologie oder Akkustik zu finden.

Frage im Anschluß an Signalübertragung.doc, allgemein (# 19980709)

Beruht Windows auf den Routinen in DOS oder auf separaten, völlig neuen Mechanismen?

Die Frage ergäbe ein neues Papier. Es sind viele einzelne Situationen zu betrachten. Unten ein paar lose Aussagen, vielleicht ergeben die ein Bild.

Auf ein und dem selben Rechner können DOS oder Windows oder Linux installiert werden. Der Rechner bootet immer mit dem selben BIOS. Das BIOS läuft im Real-Mode, also salopp ausgedrückt "Dos". (CHECK - Stimmt das wirklich? Unglaublich!) Da Windows wie DOS das selbe BIOS als kleinstes Gemeinsames durchlaufen, ist etwas daran an der Formulierung "Windows baut auf DOS auf". Allerdings das Betriebssystem MS-DOS als solches ist hier noch nicht beteiligt, denn das BIOS ist ja Proprietät der Hardware-Hersteller. Das BIOS enthält minimale Funktionen um auf die wichtigste Hardware zuzugreifen, und dem Besitzer der Maschine einige Einstellungen zu ermöglichen (BIOS Setup)

Das BIOS-Programm endet dann damit, von einer Diskette oder Festplatte einen Bootsektor in den Speicher zu laden und den Instruction-Pointer (Programmfaden) dem Code aus dem Bootsektor zu geben. Manchmal ist noch ein Boot-Manager vorgeschaltet. Erst hier kommt der Begriff "Betriebssystem" im engeren Sinn ins Spiel. Dieser Bootsektor nämlich bedeutet ein bestimmtes Betriebsystem, und von MS-DOS ist nicht die Rede. Insofern baut Windows nicht auf DOS auf.

Windows 95 beherrscht MS-DOS mittels zweier Wege der Rückwärtskompatibilität:

(1) Die DOS-Box
(2) Der DOS-Modus

Das wäre interessant hier zu sehen, was von davon genau "emuliert" und was "importiert" ist.

Zu (1) DOS-Box und Konsole. Hier findet bestimmt eine vollständige Emulation statt. Windows verläßt den Protected-Modus hier nicht. Das Rückwärts-Handling des Dateisystems ist aus Sicht der Systemprogrammierung wirklich beeindruckend! Windows baut nicht auf DOS auf.

Zu (2) DOS-Modus. Hier gibt Windows 95 tatsächlich die Kontrolle ab. An wen? An sich selber, denn der Code, der jetzt läuft, stammt von der Windows-95-CD. Welche Kontrolle? Die Kontrolle über die Hardware, über die Geräte. <Den Bus?> Der Protected-Mode wird verlassen! Windows kehrt zurück zu DOS.

Ich schätze außerdem folgendes. An vielen Stellen in Layout und Code sind durch die Forderung nach Rückwärtskompatibilität Flaschenhälse und Fransen in Kauf genommen worden, die tief in den Kernel reichen. Das Dilemma beginnt 1978 mit einer verrückten Methode, 1 MB Speicher anzusprechen, obwohl der Prozessor nur 64 KB ansprechen kann - die "segmentierte Adressierung" im 8086. Sie zieht sich wie ein roter Faden durch die Systemprogrammierung, bis zum Pentium, der diesen Real-Modus natürlich auch beherrscht - und zwar nicht emuliert, sondern echt! Welcher Systemprogrammierer soll diesen Prozessor verstehen? Wie soll so ein PC stabil sein? Die Compiler versuchen, den Anwendungs-Programmierer von der Problematik zu isolieren, aber das schaffen sie nicht vollständig. Die Anwendungs-Programmierer versuchen den Anwender von der Problematik zu isolieren, aber das schaffen sie nicht vollständig. Historisch kann man auf jeden Fall sagen, Windows baut auf DOS auf. Nicht ganz - Windows-95 ist in Wirklichkeit ein abgespecktes Windows-NT!

Fazit. Windows 95 versucht, etwas völlig neues zu sein. Das gelingt ihm auch, aber nicht vollständig.

... weitere Verknüpfungspunkte ...

CHECK - Kann Windows 95 etwas mit Real-Mode-Treibern anfangen? Wie verläuft aus Sicht der Treiber genau der schmerzliche Übergang von (1) MS-DOS über (2) den verunglückten 80286-er zu (3) Windows 3.11 mit seiner Fähigkeit, im Real-Modus sowohl wie im Protected-Mode zu laufen hin zu (4) Windows-95 mit seiner Fähigkeit, im DOS-Modus die Gerätekontrolle aus der Hand zu geben, hin zu (4) Windows-NT, das tatsächlich eine völlig neue Treiber-Konzeption zu haben scheint?