Anyone?

Regarding the issue in DOSBox with re-starting audio tracks in Blood, that is fixed in SVN. The problem was not emulating a device status bit that indicates whether or not audio is playing. That status bit ultimately comes from the device driver, not MSCDEX. So, maybe you can try a different device driver, possibly the two most common generic ones: OAKCDROM.SYS and VIDE-CDD.SYS

ripsaw8080 wrote on 2021-01-25, 22:15:

Regarding the issue in DOSBox with re-starting audio tracks in Blood, that is fixed in SVN. The problem was not emulating a device status bit that indicates whether or not audio is playing. That status bit ultimately comes from the device driver, not MSCDEX. So, maybe you can try a different device driver, possibly the two most common generic ones: OAKCDROM.SYS and VIDE-CDD.SYS

I wonder if this has to do with the fact that I am using a SCSI CD-ROM Driver

Edit: I am using Adaptec's ASPICD.SYS driver with a Plextor PX32-CSI CD-ROM Drive. Other games such as shadow warrior work fine, but I have noticed some issues with blood when CD-ROM drivers are loaded.

Not sure if Blood is unique among Build-engine games in relying on the device status bit for "audio is playing". If the status bit is indeed the problem in your case, I suppose a relatively simple TSR program could simulate it using the device busy status as the source for play status.

ripsaw8080 wrote on 2021-01-26, 00:01:

Not sure if Blood is unique among Build-engine games in relying on the device status bit for "audio is playing". If the status bit is indeed the problem in your case, I suppose a relatively simple TSR program could simulate it using the device busy status as the source for play status.

Would this contain the necessary information: https://makbit.com/articles/mscdex.txt?

From the above document, I have found the bit for busy within the status structure, but I am confused as to what the "audio is playing" is. If you could help point this out for me, I could probably write a TSR in assembly or c that would convert the "audio is playing" calls to the busy bit.

Edit: From what I remember, other build engine games like Powerslave don't have this looping issue either. I am really starting to think that Blood uses a more advanced status bit that my current cd-rom driver doesn't support.

You seem to have that backward; you'd be simulating the "audio is playing" bit using the "busy" bit.

The first thing to look at is the Device Driver Request Function: http://www.delorie.com/djgpp/doc/rbinter/id/09/45.html

After calling that function, the request header will contain the device status word, of which bit 9 indicates busy: http://www.delorie.com/djgpp/doc/rbinter/it/96/25.html

The idea is for the TSR to watch for calls to the above function for IOCTL Input Function 6: Device Parameters: http://www.delorie.com/djgpp/doc/rbinter/it/49/14.html

Then set bit 10 of the parameter bits to be the same as bit 9 from the device status word: http://www.delorie.com/djgpp/doc/rbinter/it/50/14.html

This is based on the DOSBox issue of not emulating bit 10 of the parameters as the reason audio tracks were not restarted in Blood. It's not clear at this point if that's the same problem with your device driver, so please keep that in mind.

I could write the TSR in a few minutes, as I've written others for CD-ROM device requests; but you seem interested in tackling it yourself, so I'm teaching you how to fish instead of giving you a fish. 😉

ripsaw8080 wrote on 2021-01-26, 01:17:

I could write the TSR in a few minutes, as I've written others for CD-ROM device requests; but you seem interested in tackling it yourself, so I'm teaching you how to fish instead of giving you a fish. 😉

Yup, that's my philosophy in life 😉

ripsaw8080 wrote on 2021-01-26, 01:17:

After calling that function, the request header will contain the device status word, of which bit 9 indicates busy: http://www.delorie.com/djgpp/doc/rbinter/it/96/25.html

I currently do not know how to access the the ES:BX request header (by the way, I am doing this with Watcom c, not assembly). The only other issue I am having is knowing how to write the audio playing bit. I guess I got ahead of myself and attempted something I hadn't before (Low-Level programming is not my strong suite). Well, A for effort I guess??? If worst comes to worst, I may just use use a Panasonic 2x CD-ROM drive with my sound blaster 16 so as to not use ide, however, I really want to avoid this. Here's the code if anyone wants to see it, but its pure cringe (I am still a bit new to C; Guess I was spoiled by Java, Python, and Lua):

For interrupt stuff in C, calling assembly library functions or even using inline assembly is fairly common.

My implementation for the idea is attached -- don't look at the included assembly source if you want to puzzle it out for yourself. 😉

I hope the binary can at least show if the "audio is playing" bit is indeed the problem in your case. If not, it was not a waste of my time, as I verified that the TSR fixes the issue in DOSBox 0.74(-3), which is the current stable release version. I tested in Blood patched to v1.11, but IIRC the issue is the same in One Unit Whole Blood.

ripsaw8080 wrote on 2021-01-26, 21:13:

For interrupt stuff in C, calling assembly library functions or even using inline assembly is fairly common.

My implementation for the idea is attached -- don't look at the included assembly source if you want to puzzle it out for yourself. 😉

I hope the binary can at least show if the "audio is playing" bit is indeed the problem in your case. If not, it was not a waste of my time, as I verified that the TSR fixes the issue in DOSBox 0.74(-3), which is the current stable release version. I tested in Blood patched to v1.11, but IIRC the issue is the same in One Unit Whole Blood.

Thanks! I will try this out soon to see if it fixes it.

It works!!! Thank you very much!

Glad to hear that it solves the problem. Kind of funny that the cause of the problem in DOSBox pointed to the possible cause in your case, but I guess the obscure parameter bit that Blood relies on is the sort of thing someone programming a device driver might neglect.

ripsaw8080 wrote on 2021-01-28, 18:09:

Glad to hear that it solves the problem. Kind of funny that the cause of the problem in DOSBox pointed to the possible cause in your case, but I guess the obscure parameter bit that Blood relies on is the sort of thing someone programming a device driver might neglect.

Without loading this TSR, both my SCSI and Panasonic (interface) CD-ROM Drives do not loop the audio and only work when the TSR is loaded. If this problem is this common on some older CD-ROM drivers, is there any way you could upload that fix to the blood patches site at http://www.r-t-c-m.com/knowledge-base/downloa … /blood-patches/, or would that not be probable? I can imagine that this would be really helpful for others that have this same issue on old hardware.

The "original patches" section there looks like it could be applicable. I guess you'd need to contact the site maintainer.

The PC Gaming Wiki is another place to consider: https://www.pcgamingwiki.com/wiki/Blood