Clarification required for 'digi' and other params

[Andrew]

David, first of all where's your site hosted now? For now I am referring to this archived version.

You placed the digi param under Sound card and in the colored version I sent you I said it must refer to a Digidesign sound card since that was the only one which seemed to apply.

Now what I want to know is (better late than never! ), are you sure digi refers to a sound card? The reason I ask is that in the EXE the video params are all grouped together, the ones for sound are grouped separately and so on. But digi seems to be included with bypass, megahit/improved, draw, %d, pack and unpack, and not with stdsnd, adlib, ibmg, gblast, sblast, tandy, disney, mvpas, compuadd and midi where it belongs. Digidesign is not mentioned by Setup and I don't have a real card to test (plus no details even about which model the game supports if it does), so I'm a bit unsure about this param.

Other unsolved issues:

1. j - Again not sure if it's a real param or not, since it seems to do nothing with any version of PoP1.

2. NewBump, Special and NoLoadSound (for PoP2) - None of these seem to work, not real params after all? (NoSounds does work BTW.)

There must be some function that compares cmd line params to known words. When you disassemble/debug can you perhaps see whether these params are really matched or not? That would confirm once and for all whether they deserve to be on the list.

[David]

- digi enables digital sound. It's not a sound card type.
- j is not a parameter. In 1.0 it appears after cga, and someone thought it was a parameter.
(Joystick mode is automatically enabled if a joystick is detected.)
Instead it is the first of the four numbers that make up the coordinates of a rectangle: 106, 24, 195, 296. (top, left, bottom, right)
It is the area that needs to be redrawn during the intro (before the first story text).

There must be some function that compares cmd line params to known words.

Yes, there is such a procedure in all versions of both games.
- NewBump, Special and NoLoadSound are given to that procedure.
See the "check_param" in the disassemblies I just posted.
PoP1 1.0 and 1.4: viewtopic.php?f=68&t=3423
PoP2 IR: viewtopic.php?f=64&t=3424

[Andrew]

- digi enables digital sound. It's not a sound card type.

So it doesn't refer to Digidesign! My fault for mixing the two up because your table listed it under "Sound cards". I'm not sure though what "digital sound" means. If I have a different sound device selected in Setup I can still make PoP use the PC speaker using stdsnd. But if I have PC speaker selected, digi does nothing (as expected) since it can't select another device and its parameters automatically. So what is digi there for anyway?

- j is not a parameter. In 1.0 it appears after cga, and someone thought it was a parameter.
(Joystick mode is automatically enabled if a joystick is detected.)

Ah, I took it for granted that j was a valid param to enable joystick mode because you mentioned it as such in your table under "Other". Since the "someone" was you I figured it had to be correct. Or are you saying that params table wasn't your creation? I'll remove j from it now in any case.

Yes, there is such a procedure in all versions of both games.
- NewBump, Special and NoLoadSound are given to that procedure.

Ok, but are all params given to check_param() which evaluates and accepts/rejects them, or only valid ones? If these words pass through some validity check that other made-up words don't, then of course they must be valid params although after all these years we still have no idea what it is they actually do. Perhaps it's possible to "follow" these three params through the disassembled code and try and figure out what they trigger...

[David]

The "j" parameter is mentioned here: http://popuw.com/problems.html and http://www.popot.org/popuw_forum_archive/12a.html

Perhaps you misunderstood what check_param does.
check_param(param) checks if param appears in the current command line.
For example, PoP1 calls check_param("megahit") and sets cheats_enabled based on the result.

Code: Select all

seg000:0179		    mov	    ax,	offset param_megahit ; "megahit"
seg000:017C		    push    ax		    ; param
seg000:017D		    call    check_param
seg000:0182		    cmp	    ax,	1
seg000:0185		    sbb	    cx,	cx
seg000:0187		    inc	    cx
seg000:0188		    mov	    cheats_enabled, cx

[Andrew]

The "j" parameter is mentioned here: http://popuw.com/problems.html and http://www.popot.org/popuw_forum_archive/12a.html

Yeah, looks like Jalal made the same mistake and took j to be a valid param which it isn't.

Perhaps you misunderstood what check_param does.
check_param(param) checks if param appears in the current command line.
For example, PoP1 calls check_param("megahit") and sets cheats_enabled based on the result.

Thanks, got it now, so it means NewBump, Special and NoLoadSound do have some purpose after all.

Although ASM isn't my strong suit I tried following what NoSounds does and it seems to affect the load_req_sounds() procedure to turn off all sounds but not level_music. Similarly NoLoadSound seems to be related to the load_sounds() procedure, but I can't quite make out how it's supposed to affect the game. Haven't checked NewBump and Special yet.

Also, do you know what digi does?

[David]

I think I figured digi out.
First I set the sound device to Sound Blaster Pro.
Then I decreased the free memory by 128 kB (type the LOADFIX command twice).
The game won't start if I use the digi option, it says there is not enough memory for the game "w/Digital Sound".
The game starts if I don't use the digi option, but there are no digital sounds, instead there are pcspeaker sounds. (The MIDI sounds are still present.)

So the digi option tells that if there is not enough memory to start with digital sounds, then don't even try to start without them.

Special is used in make_dump.
I could not find (yet) any difference between dumps made with and without it.

I could find one difference between running with and without Newbump: (But maybe there are more?)
Start level 2. Press F1 to enable frame-by frame mode. Run-jump into the quicksand.
Press space until the kid touches the sand. (Alternately, you could record a video and find the first frame there.)
The results are below:

[Andrew]

I think I figured digi out.
First I set the sound device to Sound Blaster Pro.
Then I decreased the free memory by 128 kB (type the LOADFIX command twice).
The game won't start if I use the digi option, it says there is not enough memory for the game "w/Digital Sound".
The game starts if I don't use the digi option, but there are no digital sounds, instead there are pcspeaker sounds. (The MIDI sounds are still present.)

So the digi option tells that if there is not enough memory to start with digital sounds, then don't even try to start without them.

Interesting! So digi provides an extra low mem check only for digital audio, but only useful if the available memory is low but not too low (otherwise the same insufficient memory error is shown anyway and the game refuses to start).

Do you know of a way I can check the effect of the similar bypass param in DOSBox? It apparently makes the game not quit if there's not enough memory, presumably leading to corruption as play continues.

Special is used in make_dump.
I could not find (yet) any difference between dumps made with and without it.

Try as I might I couldn't either, when using special with watchmem or the Alt+D method. The developers must have used it to debug only certain special levels or sequences or characters or something, and unless one can trace via the disassembly as to when exactly it is triggered there's no point blindly guessing.

I could find one difference between running with and without Newbump: (But maybe there are more?)
Start level 2. Press F1 to enable frame-by frame mode. Run-jump into the quicksand.
Press space until the kid touches the sand. (Alternately, you could record a video and find the first frame there.)
The results are below:

Are you sure that's reproducible? I tested it and both seemed the same, when I got the timing of the jump exactly same both times. It seems to me the difference in your screenshots can perhaps be explained by slightly different jump timing and location?

[David]

Do you know of a way I can check the effect of the similar bypass param in DOSBox? It apparently makes the game not quit if there's not enough memory, presumably leading to corruption as play continues.

For PoP1 1.0, if I use LOADFIX three times,
without bypass: quits with an error that says "Requires 246 KB", "243 KB available".
with bypass: A dialog appears: "Insufficient Memory. Press any key to return to DOS."
So it still notices that there is not enough memory, only a bit later.

Are you sure that's reproducible? I tested it and both seemed the same, when I got the timing of the jump exactly same both times. It seems to me the difference in your screenshots can perhaps be explained by slightly different jump timing and location?

I used the Initial Release but it also works in 1.0 (but not 1.1).
Also, an easier way is to just run, without jumping.
Press F1 (in cheat mode), then press the left arrow repeatedly (don't hold it) until the kid falls into the sand. This eliminates any timing differences.

[Andrew]

For PoP1 1.0, if I use LOADFIX three times,
without bypass: quits with an error that says "Requires 246 KB", "243 KB available".
with bypass: A dialog appears: "Insufficient Memory. Press any key to return to DOS."
So it still notices that there is not enough memory, only a bit later.

I see the error dialog with bypass as you mentioned, and it shows up as soon as the game starts (not even title screen shown). So perhaps with a little more mem free instead of 192KB allocated (LoadFix x 3) bypass should even allow the game to start before throwing that low mem error. How strange all this seems now in these days of 8GB and more of RAM being common! Who was it who said that 640KB of RAM should be more than enough?

I used the Initial Release but it also works in 1.0 (but not 1.1).
Also, an easier way is to just run, without jumping.
Press F1 (in cheat mode), then press the left arrow repeatedly (don't hold it) until the kid falls into the sand. This eliminates any timing differences.

Ah, I was using 1.1 so that explains it. This sort of difference makes no sense in any case, so for testing purposes NewBump must have a greater effect somewhere else in the game.

Is there any hint about what NoLoadSound does?

[David]

So perhaps with a little more mem free instead of 192KB allocated (LoadFix x 3) bypass should even allow the game to start before throwing that low mem error.

Using these commands:

Code: Select all

loadfix -180
prince unpack

(You may need to repeat the second line. -- This is odd: The amount of free memory randomly changes?)
The intro will start, but the error message appears when you want to start playing -- or when the demo would start.

[Andrew]

You may need to repeat the second line. -- This is odd: The amount of free memory randomly changes?

I noted that too. It's weird, looks like DOSBox is doing some dynamic memory juggling because sometimes the game runs and sometimes it quits with an insufficient memory error.

[David]

Something I recently discovered:
For all graphics mode and sound card parameters, an "!" at the end means that the game won't check if the selected hardware is available.
This is the most visible if you start the game with prince herc! (without the "!" the game exits with "Graphics mode not available.").
Here is the relevant part of the disassembly:

Code: Select all

seg000:16B5                 cmp     [bp+param], 0
seg000:16B9                 jz      loc_16D1
seg000:16BB                 push    [bp+param]
seg000:16BE                 call    strlen
seg000:16C3                 add     sp, 2
seg000:16C6                 mov     si, ax
seg000:16C8                 mov     bx, [bp+param]
seg000:16CB                 cmp     byte ptr [bx+si-1], '!' ; last char of param
seg000:16CF                 jz      loc_16F6
seg000:16D1 
seg000:16D1 loc_16D1:                               ; CODE XREF: parse_grmode+A1j
seg000:16D1                 push    [bp+gr_mode]    ; grmode
seg000:16D4                 call    check_grmode
seg000:16D9                 sub     ah, ah
seg000:16DB                 mov     [bp+gr_mode], ax
seg000:16DE                 or      ax, ax
seg000:16E0                 jnz     loc_16F6
seg000:16E2                 mov     ax, offset gr_mode_not_av ; "Graphics mode not available."
seg000:16E5                 push    ax              ; text
seg000:16E6                 call    puts
seg000:16EB                 sub     ax, ax
seg000:16ED                 push    ax              ; exit_code
seg000:16EE                 call    far ptr exit
seg000:16F3 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
seg000:16F3                 add     sp, 2
seg000:16F6 
seg000:16F6 loc_16F6:                               ; CODE XREF: parse_grmode+B7j
seg000:16F6                                         ; parse_grmode+C8j
seg000:16F6                 push    [bp+gr_mode]    ; grmode
seg000:16F9                 call    set_gr_mode

Another thing: gblast and sblast accept a hex number, one of 210,220,230,240,250,260. Most probably this is a port number.
For example: prince sblast240
(You can change DOSBox's related setting with config -set "sblaster sbbase=240".)
Here is the relevant part of the disassembly:

Code: Select all

seg000:2017                 mov     bx, [bp+param_ptr]
seg000:201A                 cmp     byte ptr [bx+6], '2' ; port number: 210..260
seg000:201E                 jnz     loc_205A
seg000:2020                 cmp     byte ptr [bx+7], '1' ; = 31h
seg000:2024                 jl      loc_205A
seg000:2026                 cmp     byte ptr [bx+7], '6' ; = 36h
seg000:202A                 jg      loc_205A
seg000:202C                 mov     ax, offset sblast_port
seg000:202F                 mov     word ptr sblast_port_ptr, ax
seg000:2032                 mov     word ptr sblast_port_ptr+2, ds
seg000:2036                 mov     al, [bx+7]
seg000:2039                 cbw
seg000:203A                 mov     cl, 4
seg000:203C                 shl     ax, cl          ; now ax=310h..360h
seg000:203E                 sub     ax, 100h        ; now ax=210h..260h
seg000:2041                 mov     sblast_port, ax
seg000:2044                 jmp     short loc_205A

[Andrew]

For all graphics mode and sound card parameters, an "!" at the end means that the game won't check if the selected hardware is available.
This is the most visible if you start the game with prince herc! (without the "!" the game exits with "Graphics mode not available.").

Your finds are always so interesting, David! While herc! resulted in the game being stuck at the DOS prompt with the music and sounds and game play still continuing as usual in the background (did you see a different result?), tga! resulted in a strange text-mode game when DOSBox isn't configured as a Tandy machine:



BTW, what would be the use of ! with sound card params? While specifying the incorrect graphics mode results in a "Graphics mode not available" error, specifying the incorrect sound card doesn't result in a corresponding "Sound card not available" error (I think it defaults to PC Speaker?). So what would ! with a sound card param do since there seems to be no fatal hardware check to override as is the case with the graphics mode?

Another thing: gblast and sblast accept a hex number, one of 210,220,230,240,250,260. Most probably this is a port number.
For example: prince sblast240

Don't know how to test this in DOSBox. Even if I configure the game via Setup to use the PC Speaker, specifying sblast results in proper SB16 audio. Remember, this is even without any IRQ, DMA or Port specified. Even if I use sblast210/230/240/250/260 the game doesn't complain although DOSBox is set to use 220h. So the game must be having defaults hardcoded, or perhaps does some sort of auto-detection.

[David]

So what would ! with a sound card param do since there seems to be no fatal hardware check to override as is the case with the graphics mode?

Okay, it does something different than with the graphics parameters, but according to the tests below, it still does something.

Even if I configure the game via Setup to use the PC Speaker

Then you used 1.3 or 1.4. I used 1.0, but forgot to say that. Sorry about that.

Don't know how to test this in DOSBox.

With PoP1.0, DOSBox cycles=3000:
sblast240 results in pcspeaker sound effects + midi music.
sblast240! results in pcspeaker for both sound effects and music.
sblast220 and sblast220! results in digital sound effects + midi music.
The best way to check is to start with megahit 1 and listen to the sound of the closing gate (sound effect) and the music after it.

(did you see a different result?)

No, with herc! the screen keeps showing the command line like you wrote.

tga! resulted in a strange text-mode game when DOSBox isn't configured as a Tandy machine:

Hey, that's funny! Looks like tandy would use the same area as screen memory as the text mode. And a row has the same width in both cases.
It would be better if the bottom half was visible.
If you have mode.com, you can use this command: mode con lines=50
(If you don't, you can download FreeDOS's mode.com from: http://www.ibiblio.org/pub/micro/pc-stu ... mode/2005/ )

[Andrew]

Then you used 1.3 or 1.4. I used 1.0, but forgot to say that. Sorry about that.

It's all right, I probably should have remembered to test with 1.0 or 1.1 too besides 1.3 (no point using 1.4 since it doesn't support any of the audio/video params).

With PoP1.0, DOSBox cycles=3000:
sblast240 results in pcspeaker sound effects + midi music.
sblast240! results in pcspeaker for both sound effects and music.
sblast220 and sblast220! results in digital sound effects + midi music.
The best way to check is to start with megahit 1 and listen to the sound of the closing gate (sound effect) and the music after it.

Works exactly as you described.

Hey, that's funny! Looks like tandy would use the same area as screen memory as the text mode. And a row has the same width in both cases.
It would be better if the bottom half was visible.
If you have mode.com, you can use this command: mode con lines=50
(If you don't, you can download FreeDOS's mode.com from: http://www.ibiblio.org/pub/micro/pc-stu ... mode/2005/ )

I did have mode.com but didn't think of using it. With lines=50 I was even able to complete a few levels. If the text mode characters were chosen a bit carefully I'm sure it might even be possible to play the game properly all the way through. If only they had included text mode support - that would have been awesome! In fact I remember using a text mode font editor long time back in DOS and if it works under DOSBox it might be possible to make the game look better in 80x50 char mode. Now wouldn't that be something!

So to summarize what's left after all this investigation by you are the following PoP2 params:

NewBump: Some very minor graphical differences found but main purpose not discovered yet.

Special: Used in the make_dump() procedure but how exactly and for what not discovered yet.

NoLoadSound: Purpose not discovered yet.