Beiträge von Dragonsphere

Zitat von llm

oder willst du zwingend super-alte Systeme supporten?

DAS fragst du in DIESEM Forum?!

Auf die Gefahr hin, dass die 286er Fangemeinde jetzt aufheult, denke ich aber, dass 386er als Mindestanforderung wohl klar geht.

Welche Anforderungen hat da eigentlich das Spiel selbst? Hat jemand zufällig die Packung zur Hand?

Zur Musik habe ich auch noch ein paar neue Erkenntnisse:

Nach dem Setzen der Instrumentdaten beginnt die eigentliche Musiksequenz in der MNU.ADL ja mit einem Befehl, der im OPL-2 Output nicht zu finden war:

Zitat von Dragonsphere

60 06 A9

War nicht zu finden...

Eventuell Timing über den PIT und daher nicht in den OPL-2 Befehlen?

Im Header der ADL Dateien findet sich in den letzten beiden Byte (also Offset 0x18 und 0x19) allerdings dazu passend auch der Wert A9 06

An späterer Stelle findet sich in den ADL folgender Befehl.

Zitat von Dragonsphere

E9 23 24

Timer des OPL-2 wird programmiert und Register 43 -54 erhalten neue Werte

Das Programmieren des Timers sieht in der RAW so aus:

00 02 = Clock change Befehl im RAW Format

A9 06 = Wert der geschrieben wird, wieder unsere A9 06!

Die Modding Wiki verrät uns:

To convert the clock speed to a Hertz measurement (Hertz is cycles per second, and the delays are in units of one cycle), use this formula: 

iHertz = 1193180.0 / iClockSpeed

0xA906 = 43.270

1193180 /43270 = 27 Hz

60 ist also wohl der Befehl für "Change Timer" in den ADL Dateien und zu Beginn der Sequenz wird hier das Timing auf 27 Hz geändert, was zudem die vorgesehene Timerfrequenz laut Header ist.

Der Playercode im Spiel scheint diesen Befehl aber zunächst zu ignorieren, aber an späterer Stelle, beim ersten E9 Befehl auszuführen.

Der E9 Befehl bzw. was dazu in den RAW Daten steht, war mir ja eh noch ein Rätsel. Es scheint aber schlichtweg eine Art Wartebefehl für das Timing zu sein.

Nach diesem Befehl folgen im Raw-OPL-Code auch mehrere Delays, aber gerade bei den ersrten auch eine Verringerung der Lautstärke, weshalb ich zunächst an einen Effekt wie Volume Slide gedacht habe.

Insgesamt wird nach jedem Befehl E9 aber 105 Ticks (in der MNU.ADL) gewartet, bevor ein Note-Off Befehl folgt. Was ja Sinn macht.

Die Programmierung des Timers würde dann beim ersten Wartebefehl erfolgen. Auch das macht ja Sinn.

E9 wäre dann das Pendant zur "delta time" bei Midi. Allerdings finde ich in den Musikstücken immer nur E9, nie E8 o.ä. und es folgt auch kein Datenbyte darauf. Und der Player würde dann in "Wartezeiten" von sich aus die Lautstärke verringern, also so eine Art Fade out starten...

Was wir jetzt aber über das ADL Dateiformat von BlueByte wissen:

Header

(hier von MNU.ADL)

Es fehlen uns noch die Angaben zur Geschwindigkeit des Songs, neben dem Timer-Wert. So etwas wie BPM oder, analog zu Midi, ticks per quarter-note. Diese Infos dürften hinter den noch zu klärenden Bytes stecken.

Die Musiksequenz funktioniert ähnlich wie Midi, allerdings mit eigenen Befehlen und eng angepasst an den OPL-2:

Ich versuche mich demnächst mal an einem Player.

Zitat von llm

Zitat

hier, wie gewünscht, der aktuell Stand mit allen Dateien als ZIP.

schon lange nicht mehr bare Metal Win32 API in neuem Code gesehen

das lässt sich natürlich nicht ganz so einfach auf Linux oder DOS portieren

schon eine Strategie: also Qt (auf jeden Fall Multiplatform) oder irgendwie sowas, oder selbst gemalte Pixel-Oberflächen und damit auch DOS kompatibel?

Alles anzeigen

Ja, die Mapview.cpp ist schleet portierbar. Wie gesagt, hatte ich dafür jetzt erstmal einfach Visual Studios Windows API Vorlage genommen, um ein bisschen auszuprobieren. War auch erstmal mehr als Test für die beiden Header-Dateien gedacht, die bis auf Verweise auf HDCs auch keinen Win32 API Code beinhalten, was ja leicht durch entsprechende Screenbuffer bzw. Pointer/Handle ersetzt werden kann.

Den ganzen "Fenster-Kram" bräuchte man ja für DOS sowieso nicht. Da brauchen wir ja sowie eine andere Oberfläche und damit ein eigenes Hauptprogramm.

Um für DOS das Speichermanagement mit möglichst geringem Aufwand anzupassen, würde ich einfach mit dem oberen Speicherbereich arbeiten und XMS verwenden.

Mit Qt habe ich noch nichts gemacht, gucke ich mir aber natürlich gerne an.

Zitat von llm

Code

//Ein Hexfeld hat einen Durchmesser von 24 Pixeln

ist das nicht eher die Seiten/Kantenlänge?

Es ist eine Seitenlänge der quadratischen Tile-Grafik und damit der Durchmesser des Felds von einer Außenkannte zur anderen:

Zitat von llm

baut

hab noch byte durch byte_t ersetzt - beisst sich mit std::byte wenn man aktuellere C++ Standards verwendet und das böse "using namespace std" macht

Dieser "böse" Code macht aber vieles auch lesbarer und stand damals sogar als quasi Standard für den Beginn jedes C Programs in meinem Lehrbuch. Würde man heute vermutlich nicht mehr so in ein Tutorial schreiben.

Den und die 16 Bit Datentypen habe ich aus Faulheit, beim kopieren des unter DOS mit Borland C++ geschriebenen Codes, mitgenommen. Ist sonst ja auch ein bisschen schwierig, wenn ein int auf einem anderen System plötzlich deutlich größer ist.

Daher kam übrigens auch die cpp Dateiendung für eigentlichen C Code, die du hier mal angemerkt hast. Wenn ich in der alten Borland IDE im Code IOSTREAM verwende, ist es für den alten Compiler sofort C++ und er kann das nur verarbeiten, wenn die Dateiendung auch cpp ist.

Ich sollte mir wohl mal einen moderneren Compiler unter DOS installieren

Zitat von llm

Zitat von Dragonsphere

Habe am Wochende die Zeit gefunden mal Visual Studio einzurichten und etwas Code zu schreiben

sollten Map.x und Map.y auf dem Screenshot nicht eher width und height sein?

Da postet man einmal einen Screenshot und schon werden hier die paar Zeilen Code im Hintergrund analysiert

Aber ja, width und height wäre hier natürlich korrekt. Werde ich entsprechend anpassen. Wie geschrieben habe ich erstmal nur etwas rumprobieren wollen und da war ich an der Stelle wohl etwas schreibfaul.

Das ganze basiert auch auf den Standarddateien, die Visual Studio für eine Windows Desktopanwendung generiert und hat noch so einige Macken.

Zitat von llm

Zitat

Ich habe erstmal nur etwas rumprobiert. Ist auch mein erstes Windows-Projekt seit bestimmt 10 Jahren, da musste ich mich erstmal wieder etwas reindenken.

stell einfach mal ein Zip ein dann kann ich das CMaken und auch linuxen

llm, hier, wie gewünscht, der aktuell Stand mit allen Dateien als ZIP. Ich habe inzwischen noch 2x Skalierung der Bitmaps und Scrollen ergänzt.

Damit es funktioniert, muss in der MapViewer.cpp bei den globalen Variablen den Pfad zu HL1914-1918 angepasst werden. Einen Datei-Öffnen-Dialog gibt es aktuell noch nicht.

lib.h enthält alles, um die Bitmaps für Gelände und Einheiten einzulesen und zu zeichnen.

fin.h entsprechend alles, um eine Karte zu lesen und zu zeichnen.

Der Code in den beiden Dateien sollte sich auch recht problemlos für andere Systeme verwenden lassen.

Edit: Die kompilierte EXE im x64\Debug Ordner funktioniert natürlich nicht, da sie meine Pfadangaben verwendet. Ich habe hier aber zum Testen auch nochmal die Spieldateien in gepackter und ungepackter Form abgelegt.

Zitat von llm

hast du auch ein Github Projekt oder sowas?

Kommt

Ich habe erstmal nur etwas rumprobiert. Ist auch mein erstes Windows-Projekt seit bestimmt 10 Jahren, da musste ich mich erstmal wieder etwas reindenken.

Beruflich brauche ich nur ab und an etwas SQL, ansonsten ist Programmieren bei mir inzwischen reines Hobby und da hauptsächlich unter DOS

Werde den Code in den nächsten Tagen mal etwas aufhübschen und dann bei Github einstellen.

Habe am Wochende die Zeit gefunden mal Visual Studio einzurichten und etwas Code zu schreiben

Ich bekomme jetzt eine History Line Karte korrekt in ein Windows-Fenster gezeichnet. Alle Grafiken werden aus den komprimierten, originalen Spieldateien geladen.

Bei der Musik bin ich wieder ein kleines bisschen weiter:

Alles nach der TRCK-ID und der seltsamen Größenangabe, zu der ja llm schon etwas schrieb, scheint sich als Stream aus einem Befehlsbyte, dem dann unterschiedlich viele Datenbytes folgen, interpretieren zu lassen.

In der MNU.ADL beginnen die TRCK Daten mit 0x40 gefolgt von den Instrument-Registerdaten für Channel 0, dann 0x41 und die Instrument-Daten für Channel 1 usw.

0x40 + Channel scheint also der Code für "Set instrument data" zu sein.Generell scheinen 10er Hexzahlen für die Kommandos zu stehen.

Was dann kommt, versuche ich mal als Tabelle darzustellen (alle Zahlen in Hex):

Das sieht schon mal sehr vielversprechend aus. Allerdings gibt es haufenweise offene Fragen und von einem Player bin ich noch weit entfernt.

Unklar sind zum Beispiel die Registerwerte. Wenn eine Note gespielt werden soll, stehen die entsprechenden Werte für die OPL-Register korrekt in der ADL-Datei.

Bei einem "35 BE" in der ADL Datei, wird aber zum Beispiel 3F geschrieben, nicht BE. Die Lautstärkeangaben passen aber durchgehend nicht. Schon beim setzen der Instrumentendaten werden vom Spiel andere Lautstärkeangaben verwendet, als in der ADL Datei stehen.

Und wenn Ex komplexe Effekte, wie bei einem Tracker, auslöst, wird es natürlich richtig spaßig. Auch das auf E9 anscheinend unterschiedlich viele Datenbytes folgen können, macht es nicht leichter.

Und generell ist noch völlig offen, wie das Timing funktioniert. Auch die Angaben im Header sind noch ein großes Rätsel.

Mir ist aufgefallen, dass die Datei erst geladen wird, wenn eine Karte geladen wird. Wenn man DosBox und einen Hexeditor nebeneinander offen hat, muss man also nicht nach jeder Änderung das Spiel komplett neu starten, es reicht zurück ins Hauptmenü zu gehen, die Datei im anderen Fenster zu ändern und dann in HL wieder ein Spiel zu starten und zu gucken, was das Spiel draus macht.

Ich habe für meine bisherigen Tests TROLL genommen, da hat man den Spähpanzer direkt neben dem HQ stehen und als 2-Spieler Karte kann man sie schnell beenden, ohne die alten Zeitungsartikel o.ä. überspringen zu müssen.

Zitat von llm

ich hab keine Ahnung - gibt es eine Möglichkeit die "Stärken" irgendwo im Spiel zu sehen

Einheit anklicken und Maus bei gedrückter Maustaste nach unten ziehen. Dann erscheint ein ? und wenn die Maustaste los gelassen wird ein Fenster mit den Einheitendetails.

Das Handbuch ist natürlich praktisch, wenn man die Werte mehrerer Einheiten in der Datei schnell abgleichen will.

Was ich in deinem Screenshot gerade sehe: Einheiten, die über zwei Felder gehen, stehen (wie auch bei der Nummeriereung) zweimal drin. Das bedeutet ja, man könnte z.B. dem Bug des Schlachtschiffs andere Angriffswerte geben, als dem Heck... Das muss ich nachher dringend mal ausprobieren

Zitat von llm

Zitat

Die UNIT.DAT im Hauptverzeichnis des Spiels mit den Wertden der einzelnen Einheiten!

Ist die auch in so einem Lib-Format?

Es gibt zwei Dateien mit dem Namen! Einmal im Unterverzeichnis "LIB", die enthält die IDs aus UNIT.LIB in der für die Nummerierung im Spiel passenden Reihenfolge.

Und noch einmal im Hauptverzeichnis des Spiels. Das ist die, die ich hier meine.

Die ist nicht im LIB Format. Es scheinen einfach Datenblöcke von etwa 70 Byte pro Einheit zu sein. Direkt die Bytes an den Offsets 0 und 1 der Datei ändern Reichweite/Geschwindingkeit des Spähpanzers.

Für den geplanten Editor sind aber andere Infos ja eigentlich noch viel wichtiger: Die UNIT.DAT im Hauptverzeichnis des Spiels mit den Wertden der einzelnen Einheiten!

Hat vielleich jemand, auch von denen ohne Programmiererfahrung , gerade Zeit und Lust ein bisschen mit einemHexeditor und dem Spiel auszuprobieren, wofür die einzelnen Bytes stehen?

Der Anfang der (entpackten) Datei sieht so aus:

00000000 10 06 1E 06 00 32 0C 00 01 02 00 23 23 04 00 00 .....2.....##...
00000010 00 00 03 00 00 05 07 01 00 02 00 50 41 4E 5A 45 ...........PANZE
00000020 52 00 00 00 00 00 00 00 00 00 00 00 53 50 8E 48 R...........SP.H
00000030 50 41 4E 5A 45 52 00 00 00 00 00 00 00 00 00 37 PANZER.........7
00000040 00 03 00 00 00 0C 04 37 06 00 1A 0C 00 01 02 00 .......7........
00000050 3C 3C 04 00 00 00 00 03 00 00 05 07 01 00 03 01 <<..............
00000060 50 41 4E 5A 45 52 00 00 00 00 00 00 00 00 00 00 PANZER..........
00000070 00 41 37 56 00 00 00 00 00 00 00 00 00 00 00 00 .A7V............
00000080 00 00 00 00 5A 00 05 00 00 00 0E 07 19 03 00 3F ....Z..........?
00000090 1C 00 02 02 14 37 41 10 00 00 00 00 00 00 00 05 .....7A.........
000000A0 07 01 00 17 02 42 4F 4D 42 45 52 00 00 00 00 00 .....BOMBER.....
000000B0 00 00 00 00 00 00 47 4F 54 48 41 00 00 00 00 00 ......GOTHA.....
000000C0 00 00 00 00 00 00 00 00 00 64 00 00 00 00 00 0E .........d......
000000D0 07 1E 03 00 3F 1C 00 02 02 19 41 4B 10 00 00 00 ....?.....AK....
000000E0 00 00 00 00 05 07 01 00 17 03                   ..........

Es gibt also auf jeden Fall Datensätze, die mit einem Kategorienamen und dem Namen der Einheit enden. Der erste Datensatz ist also der Spähpanzer.

Laut Handbuch hat der folgende Werte:

Angriffswerte:

gegen Luftziele 0/0

gegen Landziele 1/35 (in Hex 01/23)

gegen Wasserziele 1/35

Verteidigungswert 30 (1E als Hexwert)

Geschwindigkeit 6

Gewicht 3

Gruppenstärke 6

Produktionskosten 55 (37 als Hexwert)

Das zweite Byte könnte also die Geschwindgkeit oder die Gruppenstärke sein. Das dritte ist höchstwahrscheinlich der Verteidigungswert.

Die Bytes 11,12,13 sind wohl die Angriffswerte.....

Also probiert doch mal aus, ob ihr durch Ändern einen Super-Spähpanzer erschaffen könnt

Ich hänge die entpackte UNIT.DAT mal mit an, dann könnt ihr euch die einfach runterladen und editieren.

Zitat von llm

das hab ich doch schon vor Tagen gepostet

Ich werde wohl blind und vergesslich... Hatte deinen Beitrag dazu sogar kürzlich nochmal gelesen und jetzt beim Tippen war's weg. Das kommt davon, wenn ich neben Arbeit und Familie immer nur hier und da mal ein bisschen Zeit dafür finde.

Leider bekommt es mir wohl nicht sonderlich gut, wenn ich meinem Arbeitgeber sage, ich brauche mehr Freizeit um ein DOS-Spiel auseinandernehmen zu können und meiner Frau mit derselben Begründung bei Kindern und Haushalt komme....

Zitat von llm

sieht ja auch fast so aus als wenn das beinhahe klar wäre wie es läuft

könntest du deinen alten Player drauf ummodeln oder unterscheidet sich das doch zu stark?

Ich habe jetzt eine Anhnung wo und wie die einzelnen Instrumente definiert werden. Aber leider noch absolut keinen Plan, was die Noten angeht.

Ich weiß noch nicht, ob die Daten ähnlich einer Midi-Datei gespeichert sind (wie CMF z.B.) oder in Pattern, wobei das ja eigentlich erst später mit der Demo scene aufkam.

Es könnte theoretisch sogar ein Stream aus den Registerwerten sein, denn vergleicht man die Werte aus der RAW oder DRO Datei mit denen in der ADL gibt es schon Ähnlichkeiten, aber auch große Unterschiede.

Eventuell kommen hier erst nur Daten für Channel 0, dann für 1 usw.

Die 14 gleichen Noten am Anfang von Track 2 suche ich aber noch.

Zitat von llm

kennen mich null mit dem OLP2 aus - also wenig "das kenn ich doch irgendwo her" Momente

Ich habe früher gerne damit experimentiert und mir auch Player für einige Formate geschrieben, da ich z.B. nicht auf die vorkompilierte Object-Datei angewiesen sein wollte, die beim HSC-Tracker dabei war.

Ist alles ewig her, aber ich wusste noch, wo ich die Infos zu den einzelnen Registern finde und habe auch noch meine Quellcodes von vor 20+ Jahren dazu.

Aber Reverse-Engeneering eines Musik-Dateiformats ist für mich komplettes Neuland

Für alle Interessierten hier die Links zu den von mit genutzten Beschreibungen der OPL-2 (und OPL-3) Register:

Programmer's Guide to Yamaha YMF 262/OPL3 FM Music Synthesizer

Programming the AdLib/Sound Blaster

Zitat von llm

auch bin ich mir nicht sicher welche ADL/AFX Datei abgespielt wird wenn man im Menü ist

Dank der "sprechenden" Dateinamen des Spiels ist das doch ziemlich eindeutig:

MNU.ADL - Musik im Menü

MNUHI.ADL - Musik zur Highscoreliste

Und dann gibt es die drei Stücke, die während des Spiels laufen:

ONGAME1.ADL

ONGAME2.ADL

ONGAME3.ADL

Die MNU.AFX dürfte die "Soundeffekte" im Menü enthalten, die auch über den Adlib/OPL-2 laufen.

Deine DLO-Aufnahme dürfte also den Anfang von MNU.ADL enthalten und dann zum Anfang einer der "ONGAME" ADLs wechseln.

Meine RAW-Aufnahme ist einfach ein etwas längeres Stück von MNU.ADL.

Die MNU.AFX habe ich mir am Wochenende mal näher angesehen und die ist recht interessant, denn sie enthält die Soundeffekte für das Menü und ist wie eine LIB-Datei aufgebaut:

00000000 B4 01 00 00 41 44 4C 58 00 00 00 3F 41 48 44 52 ....ADLX...?AHDR
00000010 00 00 00 0A 02 00 01 00 0A 00 A4 01 8D 05 49 4D ..............IM
00000020 41 50 00 00 00 00 54 52 43 4B 3F 00 00 00 40 82 AP....TRCK?...@.
00000030 7F FA 55 02 92 80 93 57 02 00 30 FE 10 63 2A 10 ..U....W..0..c*.
00000040 63 2A 60 05 8D 00 01 D2 20 4D 77 20 41 44 4C 58 c*`..... Mw ADLX
00000050 00 00 00 3F 41 48 44 52 00 00 00 0A 02 00 01 00 ...?AHDR........
00000060 0A 00 A4 01 8D 05 49 4D 41 50 00 00 00 00 54 52 ......IMAP....TR
00000070 43 4B 3F 00 00 00 40 82 7F FA 55 02 92 80 93 57 CK?...@...U....W
00000080 02 00 30 FE 10 41 2E 10 41 2E 60 05 8D 00 01 D2 ..0..A..A.`.....
00000090 20 4D 77 20 41 44 4C 58 00 00 00 3F 41 48 44 52  Mw ADLX...?AHDR
000000A0 00 00 00 0A 02 00 01 00 1E 57 A4 01 8D 05 49 4D .........W....IM
000000B0 41 50 00 00 00 00 54 52 43 4B 3F 00 00 00 40 B2 AP....TRCK?...@.
000000C0 C0 FF 59 00 91 00 C1 07 00 06 30 FE 10 57 31 10 ..Y.......0..W1.
000000D0 57 31 60 05 8D 00 03 A4 20 4D 77 20 41 44 4C 58 W1`..... Mw ADLX
000000E0 00 00 00 3F 41 48 44 52 00 00 00 0A 02 00 01 00 ...?AHDR........
000000F0 1E 57 A4 01 8D 05 49 4D 41 50 00 00 00 00 54 52 .W....IMAP....TR
00000100 43 4B 3F 00 00 00 40 B2 C0 FF 59 00 91 00 C1 07 CK?...@...Y.....
00000110 00 06 30 FE 10 02 32 10 02 32 60 05 8D 00 03 A4 ..0...2..2`.....
00000120 20 4D 77 20 41 44 4C 58 00 00 00 3F 41 48 44 52  Mw ADLX...?AHDR
00000130 00 00 00 0A 02 00 01 00 1E 57 A4 01 8D 05 49 4D .........W....IM
00000140 41 50 00 00 00 00 54 52 43 4B 3F 00 00 00 40 B6 AP....TRCK?...@.
00000150 C0 FF 8A 00 91 00 C1 07 00 08 30 FE 10 57 31 10 ..........0..W1.
00000160 57 31 60 05 8D 00 03 A4 20 4D 77 20 41 44 4C 58 W1`..... Mw ADLX
00000170 00 00 00 3F 41 48 44 52 00 00 00 0A 02 00 01 00 ...?AHDR........
00000180 1E 57 A4 01 8D 05 49 4D 41 50 00 00 00 00 54 52 .W....IMAP....TR
00000190 43 4B 3F 00 00 00 40 B6 C0 FF 8A 00 91 00 C1 07 CK?...@.........
000001A0 00 08 30 FE 10 02 32 10 02 32 60 05 8D 00 03 A4 ..0...2..2`.....
000001B0 20 4D 77 20 42 45 45 50 31 00 00 00 04 00 00 00  Mw BEEP1.......
000001C0 42 45 45 50 32 00 00 00 4C 00 00 00 43 55 52 53 BEEP2...L...CURS
000001D0 4F 52 31 00 94 00 00 00 43 55 52 53 4F 52 31 42 OR1.....CURSOR1B
000001E0 DC 00 00 00 43 55 52 53 4F 52 32 00 24 01 00 00 ....CURSOR2.$...
000001F0 43 55 52 53 4F 52 32 42 6C 01 00 00             CURSOR2Bl...

Also am Anfang kommt erstmal ein Offset zu einem Index. Hier 01 B4, also Offset 436.

Und dort finden wir dann genau solche 12-Byte Einträge aus Namen + Offset, wie in den LIB Dateien: Der erste Eintrag ist "BEEP1", beginnend an Offset 4.

Die Daten sind dann kleine ADL Dateien, was das Format nochmal sehr anschaulich zeigt. Die Effekte dürften ja eigentlich nur aus den Instrumentdaten und vielleicht ein oder zwei Noten bestehen.

llm , du hattest ja bereits geschrieben, dass hinter den IDs vier Byte mit einer Größenangabe o.ä. folgen, bei unserem BEEP1 blieben so genau 30 Byte Daten über.

Es ist also sehr wahrscheinlichh, dass die TRCK-Chunks der ADL-Dateien mit den Instrumentdaten beginnen.

Das lässt sich ja schnell prüfen:

Hier der Anfang des TRCK Chunks aus der MNU.ADL:

00000022 54 52 43 4B 02 12 00 00 40 B1 8B 71 11 00 61 40 TRCK....@..q..a@
00000032 42 15 01 06 41 64                               B...Ad

Nach der ID + 4 Byte (ab Offset 0x2A) folgen hier also 40 B1 8B 71 11....

Gucken wir mal in meine RAW Aufnahme HLMNU.RAW:

00000070 03 00 B1 20 8B 40 71 60 11 80 00 E0 61 23 7F 43 ... .@q`....a#.C
00000080 42 63 15 83 20 01 01 E3 06 C0 7F 43 64 21 DB 41 Bc.. ......Cd!.A

An Offset 0x72 steht, wonach wir suchen: 0xB1 wird an Register 0x20 geschrieben, 0x8B an Register 40, 0x71 an Register 60... Das passt ja schon richtig gut!

Ich habe euch grün markiert, wo es passt und rot, wo es Abweichungen gibt.

Die Abweichungen in den RAW-Daten lassen sich alle mit Blick auf den Programmer's guide zum OPL-2 schnell klären:

0x7F an Register 0x43 stellt Channel 0 auf maximale Lautstärke. Keine Ahnung, warum das hier zwei mal gemacht wird, aber es ist an sich nichts besonderes.

Und 0x20 an Register 0x01 stellt den OPL-2 auf "Waveform select enable", was an dieser Stelle wichtig ist, da als nächstes mit 0x01 an 0xE3 eine neue Waveform programmiert wird.

0x40 und 0x41 scheinen in den ADL-Daten also nicht für Daten zu stehen, die direkt an den OPL-2 geschrieben werden, sondern eine Art Steuerbefehel zu sein.

Geschrieben werden in diesem kurzen Ausschnitt die Register: 0x20,0x40,0x60,0x80,0xE0. Das entspricht den Modulator-Registern für Channel 0.

Mit 0x23,0x63,0x83,0xE3,0xC0 folgen dann die Carrier-Registerwerte.

Damit wird hier ein komplettes Instrument für Channel 0 programmiert und ist in der kleinsmöglichen Form, nämlich den direkten Registerwerten für den OPL-2, in der ADL Datei hinterlegt.

Nur ein Wert für die Instrumentlautstärke fehlt, was der Player als volle Lautstärke interpretiert.

Weiter geht es in der MNU.ADL dann mit einem Intrument für Channel 3. Wieder beginnend mit den Modulator-Registern.

Aber zurück zu BEEP1:

00000026 54 52 43 4B 3F 00 00 00 40 82 7F FA 55 02 92 80 TRCK?...@...U...
00000036 93 57 02 00 30 FE 10 63 2A 10 63 2A 60 05 8D 00 .W..0..c*.c*`...
00000046 01 D2 20 4D 77 20                               .. Mw 

Wenn wir davon ausgehen, dass es hier auch so ist, dann kennen wir nun die Bedeutung der ersten 11 Byte:

0x40 - Zählt nicht, dann kommen die Werte für fünf Modulator-Register und dann die für fünf der sechs Carrier-Register.

Wenn ich etwas Zeit finde, packe ich die Werte mal in den Instrument-Editor eines Adlib-Trackers und gucke, ob ich dann einen bekannten Ton aus dem HL-Menü bekomme

Der History Line 1914-1918 Artikel in der Modding Wiki ist jetzt soweit fertig.

Ich habe in den letzten Tagen nach und nach immer ein bisschen mehr Infos ergänzt und hoffe, ich habe nun alles wesentliche zusammen. Haben hier ja wirklich eine Menge rausbekommen

Ergänzend hier auch nochmal die ersten ca. 25 Sekunden der Menümusik als RAW mit RDOS Adlib Catcher gespeichert.

Das Format ist noch etwas simpler aufgebaut als DRO, da hier die Register direkt mit drin stehen.

In der Datei wird an Offset 0x144 zum ersten Mal eine Frequenz auf Kanal 0 ausgegeben. Hierfür wird 0xCA an Register 0xA0 und 0x29 an Register 0xB0 geschrieben.

Binär sieht das dann ja so aus:

Register 0xA0: 11001010

Register 0xB0: 00101001

Gemäß der oben von mir zietierten Abbildung aus dem alten Programmer's guide ergibt das also:

F-Nummer: 000111001010 (= 458)

Block: 010 (= 2)

Die F-Nummern können zwar nicht direkt als Frequenz in Herz gelesen werden, aber die "Blöcke" recht gut als Oktaven. Damit bekommt man dann ja auch die F-Nummern für die Noten:

Note          C      C#       D      D#      E       F       F#       G       G#     A       A#       B
F-number     342     363     385     408     432     458     485     514     544     577     611     647

Und da haben wir ja auch unsere 458 aus den Daten, direkt in der Mitte. Auf Kanal 0 wird also als erste Note ein F in Oktave 2 gespielt, oder F-2, wie es im Tracker aussehen würde.

Die nächste Note für Kanal 0 dann an Offset 0x2EC, hier werden 0x41 und 0x2A in die Register geschrieben, was F-Nummer 577 und Block 2 ergibt. Also ein A-2.

Und dann, an Offset 0x458 wieder 0xCA und 0xA0, also wieder ein F-2.

Für Track 0 sähe also der Anfang eines Pattern etwa so aus:

A-2

......

F-2

......

A-2

Jetzt müssen wir die Sequenz nur noch irgendwie in der ADL-Datei wiederfinden....

Nachtrag:

Richtig viel los ist auf Kanal 2, also bei den Registern 0xA2 und 0xB2. Die ersten 14 (!) Noten sind hier alle F-3.

(Einfach mal mit dem Hexeditor nach der Bytefolge "CAA22DB2" suchen).

Das müsste sich doch auch in der ADL erkennen lassen.

Ja, das DRO-Format meinte ich. Jetzt muss man nur bedenken, dass Yamaha ja diese F-Nummern für die Frequenz nutzte....

A0-A8: Frequency Number:

   Determines the pitch of the note. Highest bits of F-Number are stored
   in the register below.


B0-B8: Key On / Block Number / F-Number(hi bits):

   Í─7─┬─6─┬─5─┬─4─┬─3─┬─2─┬─1─┬─0─À
   ║       │KEY│ Block Num.│ Freq  ║
   Ë───┴───┴───┴───┴───┴───┴───┴───¢

   bit 5:    KEY-ON. When 1, channel output is enabled.
   bits 2-4: Block Number. Roughly determines the octave.
   bits 0-1: Frequency Number. 2 highest bits of the above register.

         The following formula is used to determine F-Number and Block:

        F-Number = Music Frequency * 2^(20-Block) / 49716 Hz

Aus:

Programmer's Guide to Yamaha YMF 262/OPL3 FM Music Synthesizer

Written by Vladimir Arnost, QA-Software

Und aus einem uralten Player von mir habe ich noch diese Funktion, die die aktuell gespielte Frequenz eines Kanals ermittelt:

Function GetFreq(chan : byte) : word;
{liefert die aktueller Frequenz eines Channels in Hz}

var pitch : word;
    b1    : byte;

begin
  set_bit(OPLReg[$B0+chan],5,false);
  b1 := OPLReg[$B0+chan];
   asm
    xor bx,bx
    mov bl,chan
    mov si,bx
    xor bx,bx

    mov cl,byte ptr [offset OPLReg+$A0+SI]
    mov ch,b1
    and ch,3                        { h”here Frequenz bits }
    sub cx,FreqStart
    mov al,b1
    shr al,2
    and ax,7                        { oktave   }
    mov dx,FreqRange
    mul dx
    add ax,cx
    mov pitch,ax
   end;


  if pitch > 2751 then pitch := 0;

  getfreq := pitch;
end;

Ja, ich hatte das erst so verstaden, dass in den Chunks mit "TRCK"-ID tatsächlich 33 oder 34 Byte mehr Daten vorhanden sind, als trck_value vermuten ließe. Da hätte ich dann auf die Instrumentdaten getippt.

Zitat von llm

wenn man vom trck_value die trck_data.size abzieht kommt immer 33 oder 34 als Rest raus fuer alle adl/afx Dateien

in den Daten selber sehe ich aber keine Bezug dazu

Die 34 Byte könnten doch die Instrumentdefinition für den jeweilgen Channel/Track sein.

Rein für die benötigten Register des OPL-2 braucht man mindestens 12 Byte, oft sind es in Instrument-Dateien aber mehr, wenn einzelne Nibble oder sonstige Bit-Bereiche eines Registers in mehreren Byte gespeichert sind.

Wenn wir mal vom Adlib Visual Composer von Adlib selbst als Standard ausgehen, dann besteht ein Instrument aus mindestens 17 Werten.

Adlib selbst hat das in den früheren Versionen als Words gespeichert, was mich sehr gewundert hat, als ich mal einen Player für *.ROL/*.MUS geschrieben habe. Da BlueByte ja bei HL aber auch dazu neigte, kleine Zahlen in Words zu speichern, kann das hier aber auch sehr gut passen.

Und mit 2x17 wären wir genau bei den 34 Byte. Die 33 Byte könnten vielleicht Instrumente für den Percussion Mode sein, da braucht man nicht alle Register.

AdLib Instrument Format - ModdingWiki

Skorbin klappt es jetzt? Ich hatte den Link tatsächlich nur als "Linknamen" drin.

Habe heute Mittag mit einer Wikiseite angefangen: https://moddingwiki.shikadi.net/wiki/History_Line_1914-1918