Your VOL_D app prints an empty line in Dosbox if D: is mounted with IMGMOUNT.

I put some debugging output into the CMscdex::GetVolumeName function. Turns out ReadVTOC returns false, so rtrim never gets called.

1    if (strncmp("CD001",id, 5)!=0) {
2        error = MSCDEX_ERROR_BAD_FORMAT;
3        return false;
4    }

This is the bit where CMscdex::ReadVTOC returns false in this specific case.

It shows nothing because the function call failed. Is ReadVTOC() returning false because of ReadSectors() returning false, or because of the "CD001" id string check?

Sorry, I wrote my reply at the same time as yours again 😀 It's CD001 as noted in the previous post.

Any CDROM compliant to ISO 9660 will have the Standard Identifier of CD001, so there's a mystery. Perhaps the wrong sector is being read somehow. I think Qbix works in a Linux environment, and might be able to figure out where it breaks down.

I tested it with a few different disk images (from different sources, not just this game; in fact not even just games) now. They all produce the same problem when mounted with IMGMOUNT: the CD001 check fails, no disk label is loaded.

I will investigate this. I don't recall any problems at my end with cd images on linux, but I don't have this game.

How does he get directory listings of the image when there is no CD001?

yeah as LoadISOfile calls to determine the format of the iso:
CDROM_Interface_Image::CanReadPVD
which checks for CD001 as well

Be sure to compile dosbox without optimalisation when debugging!

Alright, new development. I tried it on my laptop and it's working alright there! The system is set up virtually identically, the only difference is i386 (laptop, working) vs. amd64 (desktop, not working). Maybe this helps narrow down the problem. Although I can play the game now, I think it's worth tracking down.

In LoadISOFile, the first block is active, i.e.

1    // try to detect iso type
2    if (CanReadPVD(track.file, COOKED_SECTOR_SIZE, false)) {
3        track.sectorSize = COOKED_SECTOR_SIZE;
4        track.mode2 = false;

This CanReadPVD call returns true. This is on the amd64 machine, of course.

Do you want a full log of Dosbox being started with debugging flags enabled? If so, just with the mount commands or also running the game etc.?

Correction: It's not the architecture, after all. It's not working if there are drives defined after the D: drive in question, e.g. E: and F:. If D: is the last drive defined, it's working.

Maybe try some logging to see what is being read, for example in ReadVTOC:

1    char id[5];
2    MEM_BlockRead(data + 1, id, 5);
3+   for (Bit8u i=0;i<5;i++) LOG_MSG("ReadVTOC drive=%u subunit=%u id[%u]=0x%02x",drive,subunit,i,id[i]);
4    if (strncmp("CD001",id, 5)!=0) {
5       error = MSCDEX_ERROR_BAD_FORMAT;
6       return false;
7    }

IMGMOUNT as D: only:

1ReadVTOC drive=3 subunit=0 id[0]=0x43
2ReadVTOC drive=3 subunit=0 id[1]=0x44
3ReadVTOC drive=3 subunit=0 id[2]=0x30
4ReadVTOC drive=3 subunit=0 id[3]=0x30
5ReadVTOC drive=3 subunit=0 id[4]=0x31

IMGMOUNT as D: and an additional MOUNT as E: (E: being mounted before D:):

1ReadVTOC drive=4 subunit=0 id[0]=0x00
2ReadVTOC drive=4 subunit=0 id[1]=0x00
3ReadVTOC drive=4 subunit=0 id[2]=0x00
4ReadVTOC drive=4 subunit=0 id[3]=0x00
5ReadVTOC drive=4 subunit=0 id[4]=0x00
6
7ReadVTOC drive=4 subunit=1 id[0]=0x00
8ReadVTOC drive=4 subunit=1 id[1]=0x00
9ReadVTOC drive=4 subunit=1 id[2]=0x00
10ReadVTOC drive=4 subunit=1 id[3]=0x00
11ReadVTOC drive=4 subunit=1 id[4]=0x00

IMGMOUNT as D: and an additional MOUNT as E: (E: being mounted after D:):

1ReadVTOC drive=3 subunit=0 id[0]=0x43
2ReadVTOC drive=3 subunit=0 id[1]=0x44
3ReadVTOC drive=3 subunit=0 id[2]=0x30
4ReadVTOC drive=3 subunit=0 id[3]=0x30
5ReadVTOC drive=3 subunit=0 id[4]=0x31
6
7ReadVTOC drive=4 subunit=1 id[0]=0x43
8ReadVTOC drive=4 subunit=1 id[1]=0x44
9ReadVTOC drive=4 subunit=1 id[2]=0x30
10ReadVTOC drive=4 subunit=1 id[3]=0x30
11ReadVTOC drive=4 subunit=1 id[4]=0x31

So it seems to depend on the order of the mount commands.

I get a similar condition, but not exactly the same because ReadSectors fails in ReadVTOC; but it seems like it doesn't for you because it goes on to check the identifier.

Mounting out of order in the specific sequence happens to trigger a reordering of (and insertion into) the drive arrays, where there does seem to be an issue; and the attached patch is my attempt to resolve it. While it does seem to work for the particular case here, I'm not completely sure of its correctness.

Your patch solves the problem for me, but of course, I'm not familiar enough with the Dosbox code to judge whether this patch is 'complete' and without side-effects. Thanks a lot to all of you guys for your patience and effort, though!

The patch resolves some aspects of the problem, but not all. Take for example a case where you mount images exactly in reverse order:

imgmount f c:\dosimg\harvest3.iso -t iso
imgmount e c:\dosimg\harvest2.iso -t iso
imgmount d c:\dosimg\harvest1.iso -t iso

With official DOSBox 0.74, only drive F has a correct volume name; drive D and F both appear to be using the first image if you do a directory; and doing a directory on E causes DOSBox to throw an exception (on WinXP, at least). The patch prevents the exception, and allows the correct volume names to be read, but all the drives appear to be using the first image if you do a directory, so that aspect is still not resolved.

At any rate, it's easy enough to avoid the problems altogether by just mounting drives in ascending order. 😉

ripsaw8080 wrote:

Please run the attached program inside DOSBox to see what it displays for the volume labels as DOSBox is reading them. It's quick & dirty and only reads from the D drive. The square brackets are formatting that it adds to make trailing spaces stand out.

Any chance of a version of the utility that would accept a command line parameter for the drive letter? This seems like an EXTREMELY handy utility for DOSBox.

I've already used the existing incarnation along with Command and Conquer Red Alert. I use ISOs for the original RA Allied and Soviet disks, and ISOs for the Counterstrike and Aftermath add-on CDs; all simultaneously mounted. With a preconfigured DOSBox.conf to set up everything tweaked for RA the way I like it, the utility makes it a lot easier to figure out which of the four ISO images is the currently mounted one 😀

Here's one that works more like the VOL command in DOS, but it cuts some corners (e.g. it displays the absence of a volume label as blank instead of saying "has no label").

Actually, if it's really that useful, it shouldn't be terribly difficult to implement the command in the DOSBox shell...

ripsaw8080 wrote:

Here's one that works more like the VOL command in DOS, but it cuts some corners (e.g. it displays the absence of a volume label as blank instead of saying "has no label").

Works perfectly, RS, MANY THANKS!

ripsaw8080 wrote:

Actually, if it's really that useful, it shouldn't be terribly difficult to implement the command in the DOSBox shell...

It would definitely get my vote 😀 Like I said before, it can get quite confusing if you have three or more ISOs mounted. In the case of RA/CS/AM, I have the ISOs mounted in this order; RACD1/RACD2/CS/AM.

The RA Soviet CD and Allied CD have the same amount of files and directories on them, with the same file and directory names... the same holds true for the Counterstrike and Aftermath addon CDs. Heh, the way that I previously was telling them apart is that I knew the two different file dates of CS's and AM's DOS SETUP.EXE files, and I would check each CD like this:

"DIR D: <ENTER>" / press CTRL+F4 / "DIR D: <ENTER>"... repeat, etc...

until I figured out which mounted image was the current one <grin> (I recognized AM's SETUP.EXE by it's file date, and then I knew that the next press of CTRL+F4 would switch me to CD 1).