Clarification required for 'digi' and other params

[David]

NoLoadSound:
(PoP2 1.0, started on level 4, music off.)

Using Process Monitor, I figured out that:
- If this parameter is not used, then all sounds are loaded before the level starts.
- If it is used, each sound is loaded when it's first needed.
So maybe it should be called "NoPreloadSound" instead?

Another way to check this:
- Make a full copy of the game, because we'll overwrite a file.
- Start (the copy of) the game with "prince.exe yippeeyahoo level4 (noloadsound)". Wait until the level loads.
- Open DIGISND.DAT in a hex editor and zero it out. Or copy some other file over it. Deleting/renaming won't work because the file is kept open.
- Now switch back to the game.
- First do things that have no sound, like jump up or step.
- Then do something that has sound, for example run.
- With NoLoadSound, in the last step the game will exit with Couldn't find resource file "DIGISND.DAT".
- Without NoLoadSound, the sounds will be played. (But the game will quit with the above error if you restart or leave the level.)

[Andrew]

Awesome, that explains it! Yeah, NoPreloadSound would have made its purpose clearer but I guess they didn't care since it was meant to be used only by the developers/testers who knew very well what it was for.

So one more down and just two more to go before we know in detail what all the game params do.

[Andrew]

David, I was just testing PoP with various DOSBox sound card options and have a question regarding gblast<port>. The param seems to be present in the EXEs for PoP1 1.0, 1.1 and 1.3, however more than one source asserts that PoP1 1.3 does not support the Creative Game Blaster. For example:

The 1.3 version I have uses a setup program that doesn't offer GameBlaster as an option. It's possible to add the option in the setup program by modifying SETUP.CFG, which is a text file, but the game crashes if you select GB for music, so apparently there's no support for it.

The buggy Game Blaster support is probably why they removed it in version 1.3, plus it was obsolete along with the Covox Sound Master, another casualty of the version upgrade.

This guy's partially correct in that neither 1.3's Setup nor the EXE contain any mention of covox, but gblast is still present!

So if you have disassembled 1.3 can you check whether the gblast in the EXE is an actual functioning command-line param, or whether the devs did remove GB support and just forgot to remove the param as well?

[Andrew]

There is a check_param call with "gblast" as parameter.
And I see some procedure that is used in gblast mode only. (I called it process_midi_message_gblast.)

The problem is that 1.3's Setup doesn't mention the Game Blaster at all. Moreover if I set sbtype=gb in DOSBox's options and run prince gblast, DOSBox crashes (same effect as editing Setup.cfg as mentioned above). So what's the use of the gblast param in 1.3? Are you able to make it work at all?

[David]

Moreover if I set sbtype=gb in DOSBox's options and run prince gblast, DOSBox crashes

The same for me.
I didn't yet look into the details of the disassembly.

[Andrew]

The same for me.
I didn't yet look into the details of the disassembly.

Ok, look forward to the results of your investigation whenever you get time to look into it.

[David]

I think I figured out why PoP 1.3 crashes in gblast mode.
I used the DOSBox debugger.

Let's follow backward from the crash:

1. Something calls 0000:0000.

Code: Select all

BP 0000:0000
return address = 0E53:000F
(in get_mem_avail)
0E53:0008  B448                mov  ah,48
0E53:000A  BBFFFF              mov  bx,FFFF
0E53:000D  CD21                int  21 <-- this calls 0000:0000
0E53:000F  93                  xchg bx,ax
0E53:0010  CB                  retf

Int 21 should not point to 0000:0000.

2. Something overwrites the interrupt table.

Code: Select all

BPM 0000:0084 (this is where the int 21 vector is stored)
(in sub_183A0)
0E53:B720  BF8C00              mov  di,008C
0E53:B723  B90C00              mov  cx,000C
0E53:B726  C6451DFF            mov  byte [di+1D],FF
0E53:B72A  C7451B0000          mov  word [di+1B],0000
0E53:B72F  C6451600            mov  byte [di+16],00
0E53:B733  83C71E              add  di,001E
0E53:B736  E2EE                loop 0000B726 ($-12)
0E53:B738  2AC0                sub  al,al
0E53:B73A  B91E00              mov  cx,001E
0E53:B73D  BF6E00              mov  di,006E
0E53:B740  F3AA                repe stosb <-- this overwrites the interrupt table
0E53:B742  C3                  ret

ES=0000, DI=008C at the break.

"repe stosb" uses ES for the destination.
Why is ES=0?

3. This is called by:

Code: Select all

return address = CS:B746
(in sub_183C3 = gblast_midi_2_4)
0E53:B743  E8DAFF              call 0000B720 ($-26) <-- this calls the previous procedure
0E53:B746  E85500              call 0000B79E ($+55)
0E53:B749  E82C00              call 0000B778 ($+2c)
0E53:B74C  C3                  ret

4. This is called by:

Code: Select all

return address = CS:B6BE
(in sub_18318 = gblast_midi_1)
0E53:B698  2BDB                sub  bx,bx
0E53:B69A  8EC3                mov  es,bx <-- this sets es=0
0E53:B69C  E8E7FF              call 0000B686 ($-19)
0E53:B69F  85C0                test ax,ax
0E53:B6A1  7C1E                jl   0000B6C1 ($+1e)
0E53:B6A3  BE5400              mov  si,0054
0E53:B6A6  B90D00              mov  cx,000D
0E53:B6A9  E80901              call 0000B7B5 ($+109)
0E53:B6AC  C70637003B00        mov  word [0037],003B
0E53:B6B2  8C1E3900            mov  [0039],ds
0E53:B6B6  C606360001          mov  byte [0036],01
0E53:B6BB  E88500              call 0000B743 ($+85) <-- this calls the previous procedure
0E53:B6BE  B83C00              mov  ax,003C
0E53:B6C1  A30200              mov  [0002],ax
0E53:B6C4  C3                  ret

The "mov es,bx" causes the problam.
The new value of ES is not used anywhere (intentionally), but stosb uses it (implicitly).

Here comes the interesting part: Let's fix this.
Search: 2B DB 8E C3 E8 E7 FF
Replace: 8E C3 -> 90 90
After this, gblast seems to work as in 1.0.
Except that sound effects are different: 1.0 uses pcspeaker for them, while 1.3 seems to play midis (from mt32snd*.dat?).

[Andrew]

I think I figured out why PoP 1.3 crashes in gblast mode.
...
The "mov es,bx" causes the problam.

Interesting. So gblast does have code associated with it but it doesn't work and crashes the game, which was clearly not intended behavior. Some people (see quotes above) seem to think support was deliberately removed, but IMO your finding seems to point more towards an oversight or bug instead. What do you think?

Except that sound effects are different: 1.0 uses pcspeaker for them, while 1.3 seems to play midis (from mt32snd*.dat?).

Confirmed. Is this a side-effect of the hex edit or possibly another bug with 1.3's gblast-related code?

[David]

Is this a side-effect of the hex edit or possibly another bug with 1.3's gblast-related code?

MT32*.dat is enabled for the Game Blaster, Sound Blaster, CompuAdd, AdLib...

Code: Select all

seg000:26BF                      is_gblast_sblast_compuadd:
seg000:26BF 8A 46 F8                             mov     al, [bp+sound_mode]
seg000:26C2 98                                   cbw
seg000:26C3 50                                   push    ax
seg000:26C4 FF 76 FC                             push    word ptr [bp+setup_io+2]
seg000:26C7 FF 76 FA                             push    word ptr [bp+setup_io]
seg000:26CA 9A 02 65 C8 0C                       call    sub_13182
seg000:26CF                      is_adlib:
seg000:26CF C7 06 10 01 01 00                    mov     use_mt32, 1

...and of course for the MT-32.

Code: Select all

seg000:2711 80 7E F8 06                          cmp     [bp+sound_mode], smMidi
seg000:2715 75 12                                jnz     loc_2729
seg000:2717 C7 06 10 01 01 00                    mov     use_mt32, 1

[Andrew]

MT32*.dat is enabled for the Game Blaster

Is this new in 1.3? Because I don't remember ever having gblast with 1.0 result in anything except Game Blaster music and PC Speaker sound effects.

[David]

MT32*.dat is enabled for the Game Blaster

Is this new in 1.3?

It must be, because the MT32*.dat files themselves are new in 1.3.

[Andrew]

It must be, because the MT32*.dat files themselves are new in 1.3.

Oh yeah, true. Too bad the programmers didn't bother to test gblast properly in 1.3.