Reverse Engineering der NLT II

[HenneNWH]

Sagen wir es mal so: Ich konvergiere gegen eine native 64-Bit Version der SCHICKM.EXE.

"kurz" ist der relative Begriff für den Arbeitsaufwand, welchen ich hierfür betreiben muss.
Es wird erst released wenn es fertig ist.

Der Plan sieht folgendermaßen aus:
* Behilfsweise Zugriffe auf das Datensegment mittels globaler Variablen nativ machen. (Beendet, wenn die Werte von p_datseg, ds_read und ds_write 0 sind)
* Unstimmigkeiten an den Spielständen (Pointer) so hinbiegen, dass sie zukunftstauglich sind.
* ONLY-DOS-Code auskommentieren z.B. EMS, AUDIO-CD
* Grafik mit SDL2 einbinden (kann von GEN.EXE übernommen werden)
* Tastatur- / Maus mit SDL2 einbinden (kann von GEN.EXE übernommen werden)
* Dateieingabe portabel gestalten (SCHICK.DAT, *.CHR und Savegames)
* Dateiausgabe portabel gestalten (Savegames und TEMP/*)
* Binäräquivalenzcodedifferenz weiter gegen 0 gehen lassen, sodass ein binäräquivalentes DOS-Binary mit SDL-Anbau für moderne OS vorhanden ist.
* Musikausgabe wie bei GEN.EXE

Ab diesem Punkt sollte ein lauffähiges Programm vorhanden sein,
welches mit Sicherheit sehr häufig wegen mittlerweile erkennbaren Speicherzugriffsfehlern abstürzt.

Dann wird wie bei gen und gen_dos geforkt, d.h. es gibt einen Ordner schick_dos,
in welchem ich versuchen werde andere Versionen der SCHICKM.EXE/BLADEM.EXE nachzubauen um die Unterschiede der anderen Versionen in die Weiterentwicklung zu integrieren.
Dadurch wird die neue SCHICKM.EXE flexibler und kann hoffentlich mit verschiedenen Versionen der SCHICK.DAT betrieben werden.

[cmfrydos]

Für Riva haben wir jetzt einen funktionierenden Tracer, der Stackframes und aktive Interrupt-Handler anzeigt und Aufrufe in Intervallen aufzeichnen sowie z. B. für Speedscope exportieren kann. Das macht die Arbeit so viel leichter ! Allein in den letzten zwei Stunden konnte ich so über 40 Spielfunktionen identifizieren und annotieren.

[HenneNWH]

@cmfrydos: Großartig! Bei größeren Projekten manchmal Abstand und neu justieren notwendig.
So kommen neue Ideen, man verhindert das frustrierende "sich in irgendetwas verrennen" und auf einmal läuft es.
Wie die alten Hasen hier im Forum wissen gab es bei Bright-Eyes/BrightEyes immer mal größere Pausen, was meinem RL geschuldet war.
Diese Zeiten waren notwendig um neu zu denken und zu überlegen, was das Beste für mich und dieses Projekt ist.

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3778 Bytes
* auskommentierte Zeilen in der symbols.h = 95.2 %
* es kompilieren auch schon einige Dateien (105 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg   : 87
# ds_read    : 63
# ds_write   : 43
# host_read  : 2561
# host_write : 607
# _ptr_      : 393

[Obi-Wahn]

[HenneNWH]

Es gibt etwas zu feiern: Die direkten Lese- und Schreibzugriffe auf das "Datensegment" sind jetzt eliminert.

Die indirekten Zugriffe mittels dem Zeiger/Pointer p_datseg, werden anschließend mit dem Umsortieren der globalen Variablen entfernt.

@siebenstreich: Den Schiffsreise-Bug, welchen du mal bearbeitet hast, habe ich heute etwas untersucht.
Es gibt Schiffe mit einer Geschwindigkeit von 150 km/h.
Dieser Wert wird in einer Bit8s Variable gespeichert, welche fälschlicherweise den Wert -106 haben sollte.
Das ergibt im Sinne des Spiels keinen Sinn, muss aber erstmal wegen der Binäraquivalenzcodedifferenz so bleiben,
genauso wie alle anderen Fehler, welche der GCC und Clang anmeckern.


Zwischenstand:
* Binäräquivalenzcodedifferenz = 3708 Bytes
* auskommentierte Zeilen in der symbols.h = 96.1 %
* es kompilieren schon einige Dateien (108 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg   : 62
# ds_read    : 0
# ds_write   : 0
# host_read  : 2527
# host_write : 596
# _ptr_      : 393

[llm]

Es gibt etwas zu feiern: Die direkten Lese- und Schreibzugriffe auf das "Datensegment" sind jetzt eliminert.

ein grosser Sprung!

[NewProggie]

Es gibt etwas zu feiern: Die direkten Lese- und Schreibzugriffe auf das "Datensegment" sind jetzt eliminert.

ein grosser Sprung!

Aber nur ein kleiner Schritt für Henne ;-)

[HenneNWH]

Ohne Proben ganz nach oben!

[siebenstreich]

Es gibt etwas zu feiern: Die direkten Lese- und Schreibzugriffe auf das "Datensegment" sind jetzt eliminert.

Bravo!

Ohnehin ist es sehr befriedigend zu sehen, wie die höheren Datenstrukturen jetzt sukzessive Gestalt annehmen und der ganze vorherige Ballast dadurch unnötig wird und verschwindet.

@siebenstreich: Den Schiffsreise-Bug, welchen du mal bearbeitet hast, habe ich heute etwas untersucht.
Es gibt Schiffe mit einer Geschwindigkeit von 150 km/h.
Dieser Wert wird in einer Bit8s Variable gespeichert, welche fälschlicherweise den Wert -106 haben sollte.
Das ergibt im Sinne des Spiels keinen Sinn, muss aber erstmal wegen der Binäraquivalenzcodedifferenz so bleiben, genauso wie alle anderen Fehler, welche der GCC und Clang anmeckern.

Sehr gut. Eine Fehlerursache im Umfeld "typecast signed-vs-unsigned" hatte ich auch vermutet bzw. die Sache durch trial-and-error auch irgendwie repariert, aber ohne zu verstehen was genau passiert. Die Schiffe mit 150 km/h sind übrigens Schnellsegler, gibt es in der Variante Begleitschutzfahrt (kostenlos) und Luxuspassage (vergleichsweise teuer). Mich wundert jetzt nur, dass ich den Bug damals in Zusammenhang mit einem Langschiff (Geschwindigkeit 120, passt noch in 7 Bit) notiert hatte. Ist da noch mehr? (Das ist mir öfter passiert: Man sucht nach einem Bug und findet drei davon. Oder fünf.)

[HenneNWH]

Das Umsortieren der globalen Variablen und das Entfernen von p_datseg sind zwei verschiedene Punkte, die hoffentlich bald abgeschlossen sind.
Der hohe Wert der Binäräaquivalenzcodedifferenz hängt direkt mit dem Umsortieren zusammen.
Im Datensegment meiner Version sind 6 Bytes, die dort nicht hingehören und noch dafür sorgen,
dass die Offsets vieler Variablen um 6 Byte verschoben sind. Das wird sich sicher noch klären.

Meiner Erfahrung nach sollte Fehler, wie der Schiffsreisebug, erst behoben werden, wenn die Problematik vollständig verstanden wurde.
Ist der Code in einem lesbaren Zustand, wird es wesentlich einfacher die Unstimmigkeiten endgültig zu beheben.

Mit Sicherheit wird es noch ein paar Tage dauern. ;-)

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3666 Bytes
* auskommentierte Zeilen in der symbols.h = 97.7 %
* es kompilieren schon einige Dateien (108 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg   :36
# host_read  : 2527
# host_write : 596
# _ptr_      : 393

[siebenstreich]

Meiner Erfahrung nach sollte Fehler, wie der Schiffsreisebug, erst behoben werden, wenn die Problematik vollständig verstanden wurde.
Ist der Code in einem lesbaren Zustand, wird es wesentlich einfacher die Unstimmigkeiten endgültig zu beheben.

Ja, stimmt schon. Aber wessen Leben verläuft schon perfekt linear?  

Warum treibt mich dieser Schiffsreise-Bug so um?

Es ist nicht der Bug an sich. Von dieser Coleur gibt es viele in der Schicksalsklinge.

Sondern: An dieser Stelle produziert der GCC einen anderes Programmverhalten als der BCC, wohlgemerkt aus demselben C-Code. Anders formuliert: Trotz Binäräquivalenz (selbes Resultat mit dem BCC) liefert der GCC ein Programm, das sich anders verhält als das Original. Das finde ich etwas verstörend, und es ist die einzige mir bekannte Stelle, wo das passiert. Und deswegen fände ich es wichtig, genau zu verstehen, was hier abläuft.

[HenneNWH]

Heute gibt es wieder gute Neuigkeiten:
* Der Pointer/Zeiger p_datseg wurde komplett entfernt
* Das Datensegment hat durch das Umsortieren der Variablen die richtige Größe bekommen.
* Dadurch ist der Wert der Binäräquivalenzcodedifferenz drastisch gefallen (um ca. 1341 Bytes).

Zwischenstand:
* Binäräquivalenzcodedifferenz = 2325 Bytes
* auskommentierte Zeilen in der symbols.h = 100 %
* es kompilieren schon einige Dateien (108 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg  : 0
# host_read  : 2521
# host_write : 596
# _ptr_      : 393

[HenneNWH]

Das Datensegment mit BCC hat jetzt wirklich genau dieselbe Größe!

Zwischenstand:
* Binäräquivalenzcodedifferenz = 555 Bytes
* es kompilieren schon einige Dateien (108 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# host_read  : 2434
# host_write : 562
# _ptr_      : 389

[Shihan]

Nice! Das ist cool!

Da werd ich ganz neidisch

[Obi-Wahn]

Super! Das (Zwischen-)Ziel ist sooo nah!