Clarification required for 'digi' and other params
Clarification required for 'digi' and other params
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.
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.
Re: Clarification required for 'digi' and other params
- 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).
- 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
- 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).
Yes, there is such a procedure in all versions of both games.Andrew wrote:There must be some function that compares cmd line params to known words.
- 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
Re: Clarification required for 'digi' and other params
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?David wrote:- digi enables digital sound. It's not a sound card type.
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.David wrote:- 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.)
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 wrote:Yes, there is such a procedure in all versions of both games.
- NewBump, Special and NoLoadSound are given to that procedure.
Re: Clarification required for 'digi' and other params
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.
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
Re: Clarification required for 'digi' and other params
Yeah, looks like Jalal made the same mistake and took j to be a valid param which it isn't.David wrote:The "j" parameter is mentioned here: http://popuw.com/problems.html and http://www.popot.org/popuw_forum_archive/12a.html
Thanks, got it now, so it means NewBump, Special and NoLoadSound do have some purpose after all.David wrote: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.
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?
Re: Clarification required for 'digi' and other params
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:
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:
- Attachments
-
- With Newbump
- newbump_on.png (22.84 KiB) Viewed 3864 times
-
- Without Newbump
- newbump_off.png (22.84 KiB) Viewed 3864 times
Re: Clarification required for 'digi' and other params
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).David wrote: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.
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.
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.David wrote: Special is used in make_dump.
I could not find (yet) any difference between dumps made with and without it.
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 wrote: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:
Re: Clarification required for 'digi' and other params
For PoP1 1.0, if I use LOADFIX three times,Andrew wrote: 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.
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 used the Initial Release but it also works in 1.0 (but not 1.1).Andrew wrote: 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?
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.
Re: Clarification required for 'digi' and other params
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?David wrote: 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.
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.David wrote: 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.
Is there any hint about what NoLoadSound does?
Re: Clarification required for 'digi' and other params
Using these commands:Andrew wrote: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.
Code: Select all
loadfix -180
prince unpack
The intro will start, but the error message appears when you want to start playing -- or when the demo would start.
Re: Clarification required for 'digi' and other params
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 wrote:You may need to repeat the second line. -- This is odd: The amount of free memory randomly changes?
Re: Clarification required for 'digi' and other params
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:
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:
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
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
Re: Clarification required for 'digi' and other params
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:David wrote: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.").
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?
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 wrote: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
Re: Clarification required for 'digi' and other params
Okay, it does something different than with the graphics parameters, but according to the tests below, it still does something.Andrew wrote: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?
Then you used 1.3 or 1.4. I used 1.0, but forgot to say that. Sorry about that.Andrew wrote:Even if I configure the game via Setup to use the PC Speaker
With PoP1.0, DOSBox cycles=3000:Andrew wrote:Don't know how to test this in DOSBox.
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.
No, with herc! the screen keeps showing the command line like you wrote.Andrew wrote:(did you see a different result?)
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.Andrew wrote:tga! resulted in a strange text-mode game when DOSBox isn't configured as a Tandy machine:
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/ )
Re: Clarification required for 'digi' and other params
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).David wrote:Then you used 1.3 or 1.4. I used 1.0, but forgot to say that. Sorry about that.
Works exactly as you described.David wrote: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.
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!David wrote: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/ )
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.