What mount command(s) are you using?

Thanks for asking. I tried both

mount c d:\games\pinball
imgmount d d:\games\pinball\theweb.iso -t iso
c:
cd \theweb
web

and

mount c d:\games\pinball
mount d d:\games\pinball\thewebcd -t cdrom -label THE_WEB -ioctl
c:
cd \theweb
web

Both methods result in the same message about the missing CD. Can the game be run using a physical disc and -usecd x !?

[edit]
No, doensn't work either. Maybe my copy (http://www.mobygames.com/game/windows/gamefes … inball-classics) is broken for Dos. Mobygames lists it as windows only, though Dos executables are on the disc, and the dos installer works fine.

Regards,
Ronald

Qbix said that -usecd is redundant if you are already using -ioctl. Also, is it possible that you installed the game using a different mount setting than the one you're currently trying to run with?

Ah, ok, didn't know that. I double-checked the installation. Default, the game installs in c:\propin\theweb and places the user in there directly after installation. Even then, the error message shows up.
I will try Qemu to see what it gives me...

the usecd is only redundant if you use -usecd 0
not in other cases.
Anyway the code added by the patch mentioned is quite simple. I think I modified to reflect my changes.
you could try the original patch instead.

Qemu's behaviour is exactly the same, and patching the game to v1.52 or Dosbox using prompt's original patch doesn't help either.
I guess either Interplay messed up their compilation, or my copy is broken.

@prompt: Can you please check to see if your copy works in CVS?

Regards,
Ronald

You should pm him Ronald.

Can you check if the game works if you mount a cue sheet that includes the audio tracks? I never tried to use the original cd or an iso without the audio tracks.
I know that the game worked just after the patch got included, so you could try to checkout the cvs of that date.
Otherwise, I don't have access to that game at the moment, but I will check as soon as possible.

Thank you for joining the discussion prompt! Mmm.. that's the strangest thing, my disc doesn't have any audio tracks, so I suppose that's why it rejects the CD on startup (duh!). Did you try the stand-alone version, or Interplay's compilation, prompt?
Now, let's find out if I can make a bin/cue combination with a couple of fake audio tracks to see if that helps anything...

Regards,
Ronald

My copy is from some compilation that I can't remember the name of, but it has the audio tracks.
If I remember correctly the windows version does not play the audio tracks, so that is may be why they decided to exclude them on your disc.
I can post the cue sheet as soon as I have access to it.

Ok, here is the cue sheet. The size of binary is 534'416'736 bytes, you will need that to calculate the length of the last track.

Great, thank you prompt, I'll check it out...

Regards,
Ronald

Hi all,

Still not working for me. According to this entry http://dosbox.sourceforge.net/comp_list.php?s … er=P&search=web the game is still not playable in DOSBox (also not in Bochs and native DOS6.22 according to the author). I've obtained a different CD with audio tracks that results in the same error mentioned in the first post.

Maybe someone can review the logging output that I've attached to see what's going on, may well be a game bug I suppose!? If I can do something myself to debug the issue, please let me know what steps to take 😅

Regards,
Ronald

EDIT: tested the game in VMWare on DOS6.22, doesn't work, same error. This game is a b!tch 😒

hmm they do a get abstract filename. that one might be interresting to check. (1503)

I think the driver function 85 (stop audio) is part of their shutdown sequence although it might be part of the detection as well. I don't know from my head what should be reported if there is no audio playing when issue a stop.

I found what is keeping this game from running. I got the idea from Qbix that pulling the abstract file name from the volume descriptor is unusual, so I used the DOSBox debugger to set a breakpoint on INT 2F (MSCDEX) to see what the code was doing afterwards. It is comparing the abstract file name to the string "Pro_Pinball_1". I guess this was used as some kind of non-standard identifier. It seems that CD imaging programs don't copy the abstract file name to the volume descriptor in the image for some reason. I don't know if this was intended as a weak copy protection, or maybe it just kind of works out that way. Once I saw what the problem was, it took 2 seconds to get around it... but being a bit warez-ish, I probably shouldn't go into details. 😉

does it work with an iso with the correct abstract filename ?
It could be that our routine is broken. it is afterall not that often used.

I confirmed that DOSBox is reading abstract filename from the iso correctly (by hacking the image). So it seems there are two possibilities: 1) the abstract filename wasn't copied into the image, 2) the original disc had an error in mastering such that the abstract filename was left blank and therefore the DOS version of the game can't work. The second possibility isn't beyond the pale, because the Windows version of the game on the disc was probably used more often than the DOS version at the time.

what is the volume label of the disk?

My MSCDEX specs says that the abstract filename was (at that time) limited to the 8.3 standard and that any longer was an extention

1Get Abstract File Name
2
3     AX     1503h
4     ES:BX  Transfer address; pointer to a 38 byte buffer
5     CX     CD-ROM drive letter (A=0, B=1, ... Z=25)
6
7MSCDEX will copy the name of the abstract file in the VTOC for that drive
8letter into the buffer space provided. The abstract filename is presently
9restricted in the High Sierra proposal to 8.3 but we require 38 bytes here
10for the possibility at a later date of handling 31 character file names plus
116 bytes for a ';' and 5 digit version number and 1 byte for a NULL at the
12end. Carry will be set if the drive letter is not a CD-ROM drive and
13error_invalid_drive (15) will be returned in AX.

But maybe the mentioned "later date" had allready arived at that time. (I got 2.1)

The volume label is "THE_WEB". I guess you're wondering if the abstract filename was not copied to the image because it's not a valid filename (either in format, or the fact that there is no such file in the root directory of the disc)... and that may be the case. However, by hacking the strings in either the game executable or the disc image, the game starts up and works. I opted for a 1-byte hack of the code in the executable so it doesn't care if the strings match or not.