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!

IMGMOUNT as D: only: ReadVTOC drive=3 subunit=0 id[0]=0x43 ReadVTOC drive=3 subunit=0 id[1]=0x44 ReadVTOC drive=3 subunit=0 id[2]=0x30 ReadVTOC drive=3 subunit=0 id[3]=0x30 ReadVTOC drive=3 subunit=0 id[4]=0x31 IMGMOUNT as D: and an additional MOUNT as E: (E: being mounted before D:): ReadVTOC drive …

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.

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 …

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.

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

Copy code to clipboard 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.

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.

The label is what the BSD 'file' command returns. I assume it's adding those quotes for clarity. Every CD image I have here (no matter whether it's been created by me or someone else) has a fixed-length name in this output of 'file' - including trailing spaces. I'm afraid Qbix could be right; it …

Things are starting to get interesting... the labels of the images are: Copy code to clipboard 1 'DISK1 ' 2 'DISK2 ' 3 'DISK3 ' Same on the images I got from my friend.

Like the attachment.

I can load saved games as well if I use regular MOUNT. I'm starting the game with exactly the same commands you listed. The problem occurs both with small and large installation. My CONFIG.INI looks matches yours exactly.

The mount commands: mount c /home/standard/Games/PC/ mount d /media/cdrom -t cdrom That way, the first CD is recognised, I can start and play the game, but I can't switch the CD for obvious reasons. Which, after what I assume to be one third of the game, is required. Using imgmount d /home/standard/ …

There are two subtle differences in the directory listing: 1. Using regular MOUNT, [.] and [..] entries are included, but they aren't there using IMGMOUNT. 2. Using regular MOUNT, the entries are ordered as I'd expect them to be, i.e. directories first, then files. Using IMGMOUNT, directories are …

I used regular dd and dd_rescue on my own CDs as well as images made by a friend of mine when I ran into the problem (don't know what program he used, but I assume something Windows-based).

No, single-track CDs.

Harvester is a game coming on three CDs. I'm using Dosbox 0.74 on Linux. Anticipating trouble with switching CDs, I made ISO images from the CDs. I mounted the first image into the host system's filesystem and used the regular MOUNT command within Dosbox (without any flags apart from -cdrom). Worked …