VOGONS


First post, by tcloud

User metadata
Rank Newbie
Rank
Newbie

Spent a few cycles with the dosbox debugger to find out why Mercenaries 2 would work fine with bin/cue but failed to play in the cdrom drive. It turns out that it has to do with the cdromDrive object located in drive_local.cpp that drive_iso.cpp does not use or call.

What the Mercs code is doing is making a call to Int 21 4E and then subsequent calls to Int 21 4F using DriveLetter:*.* instead of doing a compare for each file, it first checks the attribute for hidden file. After it finds the hidden file attribute it checks for OLD_MERC.DRV filename.

Well it just so happens the code that cdromDrive object derives from uses the stat command on the file. This will only yield whether or not a name is a directory or a regular file. This differs of course with how the whole drive_iso.cpp code handles items. I was thinking about making a patch to the code base but noticed that with MSCDEX a cool system of allowing different types of calls and interfaces be used.

Unfortunately when using a CDRom Drive the cdromDrive object doesn’t utilize any of the code for the above search calls. It’s out of the loop of the code updates it seems and with me not knowing the grand design… I would rather like to collaborate with a developer more familiar with the code before I embark on a refactor (noticed a lot of code that was copied and pasted and could use a little design update). Of course I would be just as happy to let the code maintainers and designers take a look and create a fix.

Last edited by tcloud on 2011-11-03, 00:14. Edited 1 time in total.

Reply 1 of 4, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

yeah. I figured that out as well and thus it only works with bin/cue. (as I added that hidden flag support specificly for mech merc 2 )
At that time I wasn't able to come up with a nice (cross platform) way for the normal cdrom interface

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 4, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Don't get me wrong but can you hit return once in a while? With the forum layout and colors it's hard to focus on a lengthy text without breaks once in a while.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 3 of 4, by tcloud

User metadata
Rank Newbie
Rank
Newbie

After looking at the code I understand why it wasn't an easy patch fix for the cdrom drive. In my head I am thinking that there is a lot of design aspects the team wouldn't want to change, but there are others that would need to change.

In the current design it appears that MSCDEX object is parallel to a cdrom drive object and I can understand how this came about. In a redesign I am thinking about, (not that this the only approach or the best), I would sit MSCDEX on top of the other drive objects whether or not that would be iso, ioctrl or the various other flavors. Now that is not a trivial fix to the issue and would probably need support from the broader community so if a change of that magnitude is done it wouldn't affect parallel work.

I fixed the previous post with carriage returns and used them in this post. Maybe it's just looking too much at a lot of hexadecimal and I just began ignoring format. 😀

Reply 4 of 4, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Don't forget that it works when using a CUE/BIN pair, which has more benefits (faster, no risk to damage your real cdrom).

Water flows down the stream
How to ask questions the smart way!