Hi,

I currently don't have the time to do a comparison for the disassemblies, but if there are lot of difference with a hex editor, but a dissassembler shows that the functions are mostly the same, it usually means that the actual code change in the original C/C++ code(or whatever high level language they have used) is most likely small. The difference in a high number of bytes most likely are addresses which has been pushed around when some new code is added to the program.

For the actual functional differences in this case I would look at the parts of the program calling int 10h with AH set to 4Fh as that is the VESA interrupt.(Actually to be more precise that is the Video Interrupt(10h) with VESA functions(4Fh))

That was a great hint! I finally found some time to work with DOSBox Debugger and compare the original english EXE file with the fixed one.

It seems, that in the fixed EXE file, the pointer to the data segment is moved by two bytes, which results in a check right before the vesa function to be interpreted differently.

The broken EXE file points at a wrong place in the data segment at ds:[00DC] that contains "0000", which causes the following jump to be executed and jump over the initialization routine for SVGA/VESA stuff.

101A2:12E0  05FF03              add  ax,03FF
201A2:12E3  2500FC              and  ax,FC00                                     
301A2:12E6  A3D000              mov  [00D0],ax              ds:[00D0]=0800       
401A2:12E9  833EDC0000          cmp  word [00DC],0000       ds:[00DC]=0000         <<== read at wrong address in DS
501A2:12EE  7406                je   000012F6 ($+6)         (down)                                                  
601A2:12F3  E9FE04              jmp  000017F4 ($+4fe)       (down)       <<== probably SVGA initialization
701A2:12F6  B800C0              mov  ax,C000                                     
801A2:12F9  8EC0                mov  es,ax                                       

DOSBox throws a couple of errors like "INT10:Function 7000 not supported" and "VGAMISC:VGA:S3:SEQ:Read from illegal index 5" but starts the game nonetheless. Only on real hardware the screen freezes during startup. I guess MS-DOS is more strict about some things like illegal memory access or not properly initialized hardware.

In the fixed EXE ds:[00DC] points at "0001", which causes the jump not to be executed and initialize SVGA correctly. This works under MS-DOS and also causes no errors in DOSBox.

With this information, i tried to find the corresponding statements in the german EXE file. To properly fix this, one would probably have to track down the point, where the data section gets initialized, but i'm afraid by tampering with the early load routines addresses i'll break stuff (german version loads a larger codepage f.e. to display more characters). A quick and dirty fix is to just invert the jump (JE=74 to JNE=75) after the faulty compare.

This causes the SVGA stuff to be initialized properly and now the german version works as well under MS-DOS. Success! 😀