Diskussion:Flight Simulator II

Programmfehler (Bugs)

(1) Die Simulation läuft aufgrund der europäischen Netzfrequenz von 50 Hz (Nordamerika 60 Hz) [Korrektur: aufgrund der PAL-Bildwiederholfrequenz von 50 Hz (NTSC 60 Hz)] mit einer um 20 Prozent zu niedrigen Ablaufgeschwindigkeit. Die unterschiedlichen Netzfrequenzen sind den Programmentwicklern von subLOGIC bekannt gewesen, denn beim Programmstart wird die Netzfrequenz durch eine spezielle Programmroutine gemessen und die simulierte Borduhr entsprechend korrigiert. Die Integrationskonstanten für die Simulation jedoch nicht zu korrigieren, sondern nur die Borduhr (weil es dort sofort aufgefallen wäre), das war nicht nett gegenüber allen Anwendern aus der 50-Hz-Welt. Die Konsequenz ist, daß das Flugzeug 20 Prozent langsamer vorankommt oder steigt/sinkt als auf den Instrumenten angezeigt. Das wiederum führt dazu, daß beim Fliegen mit Karte und Stoppuhr, die Geschwindigkeit über Grund, Windgeschwindigkeit und Überflugzeiten nie korrekt ermittelt werden können.

(2) Von den vier vorhandenen Instrumentenlandesystemen (ILS) ist nur bei einem einzigen (Van Nyus ILS 16R) der Landekurs korrekt auf die Landebahn ausgerichtet. Bei den drei anderen gibt es unzulässig große seitliche Winkelabweichungen, die ein präzisen Anflug sehr erschweren.

(3) Die ILS-Kurswegantennen befinden sich nicht hinter dem Ende der Landebahn, sondern am idealen Aufsetzpunkt ca. 300 m hinter der Landeschwelle. Das führt in geringer Entfernung zur Landebahn zu einer extrem empfindlichen Kursweg-Anzeige und somit sehr leicht zum Übersteuern.

(4) Die ILS-Kurswege werden mit einer unrealistisch großen Sektorbreite von +/-10° ausgestrahlt, anstatt mit ca. +/-2,5°. Daraus resultiert eine sehr unempfindliche Kursweganzeige bei mittleren bis großen Entfernungen zur Landebahn.

(5) Wenn die Simulation im Reality-Modus betrieben wird kommt es beim Verlassen des Editors zum Ausfall des Motors.

--geoFlight (Diskussion) 15:23, 19. Apr. 2016 (CEST)

Die Erklärung bei (1) ist technisch nicht klar. Die Netzfrequenz spielt beim C64 nur beim TOD-Timer der CIA eine Rolle - alle anderen Takte des C64 ergeben sich aus dem quarzgenerierten Videotakt und haben mit der Netzfrequenz nichts zu tun, siehe Hardware-Aufbau des C64. NTSC-Geräte sind aufgrund des leicht anderen CPU-Taktes ca. 4% schneller. Die etwa 20% Unterschied habe ich gerade in VICE nachvollzogen. Komisch. Ich schätze, das ist einfach ein Bug - vielleicht misst das Spiel die Rechenleistung und stoppt per TOD-Timer, initialisiert den bei PAL aber fehlerhaft auf NTSC-Einstellungen, dann würde eine bei PAL eine zu hohe angenommene Rechenleistung herauskommen und das Spiel entsprechend langsamer laufen. Eine andere mögliche Fehlerquelle wäre, dass die Simulation fest an die 60Hz Refresh-Rate bei NTSC gebunden ist (hat aber nichts mit Netzfrequenz zu tun). - Die Borduhr kann trotzdem korrekt laufen, falls sie z.B. im Spiel selbst über den TOD-Timer läuft (und der dann korrekt initialisiert wurde) oder ein weiterer Korrekturfaktor eingefügt wurde. - Ich würde die Formulierung auf "Auf PAL-Systemen läuft das Spiel etwa 20% langsamer als auf NTSC-Systemen; gemeinerweise läuft die Borduhr bei beiden Systemen gleich schnell." ändern, das stimmt auf jeden Fall. -- 1570 (Diskussion) 00:42, 20. Apr. 2016 (CEST)

Vielen Dank für die interessante Erwiderung.

Zunächst zur Borduhr.

Die Simulation der Borduhr basiert auf der Time-of-Day (TOD) Funktion des CIA. Dem TOD-Trigger-Input (Bit 19) des CIA wird ein aus der 9-V-Wechselspannung des Netzteils abgeleitetes Signal zugeführt.

Die Messung der Netzfrequenz geschieht beim Flight Simulator II durch eine Routine, die im Hauptspeicher bei der Adresse $ab18 beginnt.

Beim Programmstart wird durch Löschen des Bits 7 im CIA Steuerregister A ($dc0e) der TOD-Timer für eine Triggerfrequenz von 60 Hz initialisiert. Danach wird der Inhalt der Zero-Page-Adressen $5 und $6 auf Null gesetzt und dieses 16-Bit-Wort in einer durchschnittlich 13,02 Takte dauernden Programmschleife so lange inkrementiert, bis das 1/10-Sekunden-Register ($dc08) um den Wert 1 erhöht worden ist. Der Inhalt der Speicherzellen $5/$6 wird dann mit dem Wert 6845 verglichen. Ist der Zählerwert größer oder gleich 6845, dann ist die Netzfrequenz kleiner als 55 Hz. In diesem Fall wird das Bit 7 des Steuerregisters A ($dc0e) auf 1 gesetzt, um den TOD-Timer für eine Triggerfrequenz von 50 Hz zu konfigurieren.

Zur Simulationsgeschwindigkeit.

Die synchronen Prozesse der Simulation (speziell die Berechnung der Flugmechanik) werden in einer timer-gesteuerten Interrupt-Routine ausgeführt. Wenn ich mich noch richtig erinnere, so liegt die Iterationsrate beim CM-FS2 irgendwo in der Größenordnung von 10 bis 20 Hz. Die Taktrate der CPU spielt dabei jedoch keine Rolle. Sie bestimmt nur, wieviel Arbeit die CPU während einer Iteration erledigen kann. Die zwischen PAL und NTSC um ca. 4 Prozent unterschiedliche CPU Taktrate kann eine um ca. 20 Prozent verlangsamte Abarbeitung der synchronen Prozesse nicht erklären.

Wenn der CM-FS2 auf einer 4-MHz-CPU (WDC 65816, Turbo Process von Roßmöller) lief, dann liefen zwar die asynchronen Prozesse (Grafik!) mit vierfacher Geschwindigkeit ab, die Simulationsgeschwindigkeit war jedoch nach wie vor um 20 Prozent zu langsam.

Damals (1989), als ich mich intensiv mit diesem Problem beschäftigt habe, wollte ich den TOD-Eingang des CIA testweise mit einem externen 60-Hz-Signal speisen. Leider habe ich dann die Finger davon gelassen, weil ich meinen C64 nicht „verbasteln“ wollte.

--geoFlight (Diskussion) 13:50, 21. Apr. 2016 (CEST)

Ah, spannend. :-) Wird denn das Ergebnis der TOD-Konfiguration noch irgendwoanders als eben für $DX0E benutzt? - Im Emulator könnte man ja vermutlich relativ einfach etwas rumexperimentieren (z.B. den Intervall für die Simulations-ISR kleiner machen). Wäre vielleicht ein Fall von "Disassembly irgendwo editierbar abkippen und drin rumstochern". -- 1570 (Diskussion) 15:15, 22. Apr. 2016 (CEST)

Der Frage, wie die timer-gesteuerte Interrupt-Routine im Detail ausgelöst wird, müsste ich nachgehen. Das ist alles schon sehr lange her. Meine Aufzeichnungen und Disassembler-Listings habe ich zum Glück noch.

--geoFlight (Diskussion) 22:55, 23. Apr. 2016 (CEST)

1570 hat mich mit seinem oben stehenden Einwurf auf die richtige Spur gebracht. Die Simulationsgewchwindigkeit hängt (im Unterschied zur Borduhr) nicht von der Netzfrequenz ab, sondern von der Bildwiederholfrequenz. Diese beträgt bei NTSC 60 Hz und bei PAL 50 HZ. Leider hatte ich damals keine Ahnung von NTSC.

--geoFlight (Diskussion) 14:21, 29. Apr. 2016 (CEST)

Nur generell (abgesehen von (1), das ja noch diskussionswürdig sein könnte): Die Bugs sollte man doch auch in den regulären Artikel übernehmen, oder? Wer meldet sich freiwillig? --JohannKlasek (Diskussion) 20:15, 20. Apr. 2016 (CEST)

Ich werde die bekannten Programmfehler in textlich komprimierter Form in den Artikel einfügen. Die Erklärung der Fehlerhintergründe ist an dieser Stelle sicher nicht erforderlich.

Für die Fehler (2) und (5) gibt es Patches.

--geoFlight (Diskussion) 13:50, 21. Apr. 2016 (CEST)

Für die Patches gibt es Bezugsquellen? So oder so wäre deren Erwähnung natürlich auch im Hauptartikel sinnvoll. Aber ich glaub, das war ohnehin beabsichtigt ...
Jedenfalls eine tolle technische Recherche! --JohannKlasek (Diskussion) 10:20, 22. Apr. 2016 (CEST)

Die Patches für (2) und (5) habe ich damals selbst erarbeitet. Sie bestehen in beiden Fällen im Editieren von einzelnen Bytes auf der Diskette mittels eines geeigneten Disketten-Tools. Daher würde ich diese relativ komplizierten Patch-Prozeduren nicht unbedingt hier im Artikel veröffentlichen. Es sei denn, ich gebe nur an, welches Byte auf welcher Spur, in welchem Sektor mit welchem Wert zu überschreiben ist (vorausgesetzt alle Original-Disketten sind exakt gleich). Jedenfalls wäre es erstaunlich, wenn sich nach ca. 30 Jahren noch jemand dafür interessiert.

--geoFlight (Diskussion) 22:55, 23. Apr. 2016 (CEST)

Klar, schreib das gerne hin (auf eine Unterseite oder erstmal hier in die Diskussion). Nur Patch ("Track X Sektor Y Byte Z von Wert A auf Wert B setzen") tut schon, bzw. etwas ASM-Kontext wäre nett. Wie man generell patcht etc. sollte wenn in einem anderen Artikel (irgendwann mal) erklärt werden. :-) -- 1570 (Diskussion) 17:55, 26. Apr. 2016 (CEST)

Das würde ich nicht "kompliziert" nennen. Sowas ist gängiges Vorgehen, und wer Interesse an sowas hat der weiss auch wie er vorzugehen hat wenn aufgezeigt wird wo und was zu ändern ist. (Und um Deine Frage von Deiner Benutzerseite im Kontext zu beantworten: natürlich sind moderne Emulatoren, Editoren und sonstige Werkzeuge um ein Vielfaches komfortabler bei sowas als ein Disk Monitor auf originaler Hardware. Man nimmt ja eh ein Disk Image her. Auf einer Originaldiskette rumzupatchen wäre aus heutiger Sicht im Sinne der Erhaltungswürdigkeit von Originalen sowieso ein mittelschweres Sakrileg.) -- GenerationCBM (Diskussion) 16:40, 29. Apr. 2016 (CEST)

Versionsunterschiede

Es soll die C64-Portierung des FS2 in mindestens zwei verschiedenen Versionen (V1.01, V1.05, ...?) gegeben haben.

Wer kennt die Unterschiede zwischen diesen Versionen?

--geoFlight (Diskussion) 22:48, 9. Mai 2016 (CEST)