I think there are several CD-ROM games from the Windows 95 era that have Redbook CDDA. I remember in my old-school FPS collection that several of the CDs had audio tracks, including Quake and both Quake expansions (albeit, there was a DOS version of Quake first). I think it wasn't until 1998/1999, after games like the original Unreal Tournament demonstrated you could get high quality sound with the right compression format while using a relatively small amount of system resources, that the industry as a whole moved away from using Redbook. That's not to say that there weren't many games during the Windows 95 era that didn't use Redbook, but some games did use it. Heroes of Might and Magic II is another one I can think of off the top of my head with CD tracks (of course, there was also a DOS install for that game as well, but I'm just saying).

Oh, there are a whole bunch of games that use redbook audio. The first two that come to mind are Pitfall: The Mayan Adventure and Sonic CD.

One of the relevant multimedia interfaces is missing from NT-based versions of Windows; there is a DLL replacement known as _inmm.dll that can be used to redirect programs to play music from audio files instead of the CD. I don't know if it works with Win9x.
_inmm.dll : another solution for problematic CD audio?

Programs that do not use the original winmm.dll (Frogger, for instance) are incompatible with this solution.

If DOS programs can play redbook audio in DOSBox, why would this be so different? Don't DOS programs use the same ATAPI interface?

SedrynTyros wrote:

I think it wasn't until 1998/1999, after games like the original Unreal Tournament demonstrated you could get high quality sound with the right compression format while using a relatively small amount of system resources

Unreal Tournament used tracker music like the rest of Epic Games' releases (from Silverball on) and was Epic's last to do so. Interplay was already using some form of ADPCM compression for music in Starfleet Academy and Fallout in 97. Similar games with ADPCM music followed suit (GTA2) but they were still in the minority. Redbook was still very much used for quite the while. MP3 was barely used (patent$$$) and Ogg Vorbis hadn't surfaced yet.

I've first encountered MP3 games in 2000 when there was a newfound obsession over distributing high quality games through dial-up connections by games companies willing to compress the hell out of things. realMedia specifically...

Anyway that's besides the point. Dosbox-X getting redbook working under Windows 95 is a neccessity since there's numerous games designed for Windows 95 that use CD tracks.

It seems like a worthwhile effort to bring redbook audio to DOSBox/95; however, trying the _inmm.dll method could possibly provide an immediate fix for CD audio in MM6.

I believe DOS games access CD audio via the MSCDEX driver -- whether explicitly or in the dosbox example, via code. Documentation available: http://www.phatcode.net/res/220/files/mscdex21.txt. It would be possible to access the MSCDEX driver from the Win95 command prompt, too, at least in a non-emulated system. However, DOSBox is also dependent on SDL_sound to playback CD audio via a disk image; I believe mounting the physical CDROM drive will allow CD audio without requiring SDL_sound.

Codeholio's IDE emulation uses ATAPI commands to communicate with the CDROM (image) from 95. The commands for CD audio are not yet implemented. Also, I tried the DOS-based Cubic player (http://www.cubic.org/player) in a Win95 dos box, but it also tried to access the CD via the ATAPI commands. The real mode CD requests must be routing through the protected mode layer. I have not yet tried to load a MSCDEX driver in 95's autoexec.bat or config.sys to see if it grants real mode access at the 95 DOS prompt.

On looking at the DOSBox MSCDEX code, the CD commands appear somewhat similar to the ATAPI ones. This is promising because there is a template to fashion the ATAPI CD audio commands after the MSCDEX commands (dos_mscdex.cpp). Further, the SDL_sound library allows for cue/bin image files for CD audio playback in DOSBox/DOS, so the code must be there to port to the ATAPI commands, too (cdrom_image.cpp). One strategy is to implement the "Play Audio" ATAPI command first which requires the command in ide.cpp; also, I believe a command is required or must be enhanced to provide the track listing(?), although I'm less sure on the details of it. Ideally, much of the MSCDEX code could provide documentation for the ATAPI code, but this also requires extensive knowledge of IDE emulation and the data structures used in both cases. 🙁 Otherwise, a major difficulty is the debugging effort and having good tools; it's less than ideal to boot Win95 on every code change.

The "Play Audio" command (0x45) is not implemented in a recent(?) version of Bochs: https://raw.github.com/larsr/bochs-svn/master … odev/harddrv.cc

Edit: the SDL_sound library is only required for cue/bin files with compressed music; it is not required for uncompressed music tracks in a cue/bin format. I also believe Codeholio's IDE emulation handles both iso and cue/bin file formats -- if this is true then the "Play Audio" command requires one less hypothetical step. 😀 I am curious (and I'll check into it) how the music track listing should be retrieved for dosbox/95 games; through the CDROM Table of Contents or the Cue sheet?

Also relevant is SAPUCDEX, which is used in the NTVDM to provide missing MSCDEX functionality:
SAPUCDEX by SaPu

Jorpho wrote:

Oh, there are a whole bunch of games that use redbook audio.

Most of the Dynamix Windows games and many of the DOS games do, going all the way back to Stellar 7.

Confirmed that the only way to access a host CD image from dosbox/95 is by Codeholio's IDE emulation. Likewise, I believe the 95 DOS box must map the MSCDEX commands onto the ATAPI commands to establish communication with the CDROM. This would mean that ATAPI is the way to establish CD audio, given the solution is by modifying the dosbox code. The other path is an older version of d-tools, but that is not a perfect nor simple solution.

From trying to read and understand the IDE code, I think the emulated IDE device is just that -- a device (although a very complex code base); and the commands are routed by the 95 OS to the underlying computer system (in this case the system is emulated). I consider this promising since there is already CD audio in the dosbox mscdex code, therefore the underlying emulated hardware must carry the CD audio functionality. Here is an example from the (ordinary) Read function (0x28):

1CDROM_Interface *cdrom = getMSCDEXDrive();
2bool res = (cdrom != NULL ? cdrom->ReadSectorsHost(/*buffer*/sector,false,LBA,TransferLength) : false);

That code is referencing function in the underlying dosbox "hardware" (cdrom.h). The CD audio commands could be set up the same way -- and presumably the underlying interface to the CD hardware is the existing MSCDEX emulation in dosbox code. If this is somewhat correct, the other problem is setting up the "IDE registers" properly and any required handling of audio on the IDE side. I don't know whether this is actually possible, but it does seem a reasonable path to try. 😀

Edit: in addition to modification of the IMGMOUNT command, the above is explained better on page 3 of this thread (by the author Codeholio). Also, an expanded ATAPI command for "Table of Contents" is required before the other commands.

The MSCDEX emulation would ideally not be involved with Win9x. Mapping ATAPI commands through MSCDEX seems wonky, although it might be expedient to do that initially. Ideally there would be ATAPI frontend code that accomplishes the same thing for Win9x (and real DOS + real MSCDEX + real cdrom device driver) on the cdrom device backend (cdrom_image.cpp) that the MSCDEX frontend does for the internal DOS.

Thank you for the helpful suggestions, ripsaw. 😀

I have been looking at the mscdex emulation in dosbox and the "Table of Contents" ATAPI command in the ide emulation. The stumbling block to an "audio track listing" is that command (0x43); I have so far tried to recruit the GetAudioTracks and GetAudioTrackInfo functions in the mscdex code in an attempt to list the audio tracks. However, I then found, or at least believe, that the mscdex emulation provides a "listing" of the cd audio tracks via the cue sheet file. The reason is that mounting the bin file via imgmount will not enable the CD track listing, however, the cue sheet file does; this was tested in dosbox and its mscdex emulation (actually just in a single example of a cue/bin pair).

The Win95 cdfs driver (the analog to mscdex in DOS) uses the ATAPI commands to communicate with the CDROM drive. To find an audio track listing, it requests the table of contents which reports a series of bytes. This series contains a 4 byte header and then the track entries which consist of the absolute start time for each track (for example: minutes, seconds, frames). The main information to find is the number of tracks and then the start time for each track (via the mscdex emulation, if possible). That should provide the cd-da track listing. The necessary and remaining ATAPI commands for CD audio playback are (or should be) Play, Pause, and Stop Audio.

As an aside, I further tried D-tools in a 98se guest (DOSBox) in attempt to mount CD audio tracks. However, it did not work as before, even with the relevant MCI driver loaded. I did confirm that ISO files mount without difficulty.

Last, the IDE emulation is conflicting with the S3 video driver in Win98se; at least this is my impression. The IDE in 98se also leads to the page fault problem which was mentioned earlier. I believe the fix is to follow danoon's recommendation (I believe Bochs has a similar implementation in its CPU core code) to disable page fault recursion in the normal core; also, this core could be used as a page handler core along with core=dynamic. Testing the modified normal core I posted here, it did show resistance to the page fault overruns in WinME; however, the instructions are not all re-entrant, this is presumably the cause of the repeated errors in the Windows shell. I agree that this problem is probably related to the ME IDE driver loading at start. I thought it was just part of the rigorous requirements of ME's drivers, such as multimedia features of video and audio; but the page fault problem should alleviate much of the issues of installing different operating systems (as danoon has already successfully done). Furthermore, there is a different problem with the loading the PCI S3 driver with IDE active in 95b and later; some of this is related to my disabling of mmio, but there is more to it. The video driver is not finding its ports or memory addresses on boot in these cases. However, Win95 retail and 95a do not have this problem, with or without the IDE active. It seems that the the later versions of 95 are using a different (protected mode?) paging scheme which is active with the IDE emulation; the older paging scheme (or compatibility mode paging) works fine.

Edit: confirmed that CD audio must be tested in Win95, not in DOS 6.x (at least without a working DOS IDE driver). I tried to set up audio track entries in the TOC (Table of Contents) command and the modification results in 95 repeatedly asking to Play Audio (0x45). The entries do not correspond to the cue sheet; but it may be of interest that both commands should be implemented before testing either one separately.

In an attempt to show an audio track listing via the "Table of Contents" (0x43 or TOC) command, I entered a fake function(s) for Play Audio (0x45). Used the lines from the "default" case to bypass it. Then, tried to write different sequences of bytes for 0x43, but so far unsuccessful in finding the audio tracks in 95, at least via the "CD Player" built-in to the OS; the ISO files are showing, however.

I wonder if the TOC command is enough to find the track listing (.cda files) in 95. If so, it should be a matter of having the known TOC bytes from another source and then writing those into the 0x43 command; one audio track should be enough for testing. I haven't yet found an open source emulator which appears to handle the TOC command, which would be helpful in uncovering the problem.

Edit: since 95 is requesting the 0x45 command (play audio, not play audio msf), I would guess that the track start position must be written in LBA, not in MSF format (is there a third format, too?).

Edit2: Nero Burning Rom 5.5 (Image Drive) supposedly will mount cd audio tracks in 95 (link to the Vogon thread in an above post). Tried Image Drive in 98se and it mounts ISO images without issue; it also will mount NRG images (presumably with CD audio tracks). I have not yet tested the latter. I believe this software will also work in 95, but requires a dll file (olepro32?); my guess is IE4 or IE5 has this file. If this works, this would be an ideal solution since it supports an "eject CD" function and the SCSI driver appears stable.

Confirmed that NRG formatted images, containing data and audio tracks, will mount in DOSBox/9x via D-tools 3.47 or Nero5. However, the cue/bin formatted image will not (verified by D-tools so far). This is not necessarily a software specific problem, but possibly a problem with mounting cue/bin files in the guest OS. If this is true, then it would be difficult to test the TOC command (0x43) in DOSBox/9x because any CD audio tracks would cause the guest OS to fail; in this case, 0x43 would have to detect the data track only.

I, um. Maybe I'm missing something, but wouldn't it be better to mount the image outside the emulation, and then get the emulation to see it as a native disc?

I have been testing the page fault problem in 95b. Modifying the "vcache" values in system.ini has been yielding very good results so far. Where the default vcache values have resulted in page fault errors, increasing the vcache has allowed the IDE emulation to co-exist with 95b (along with the S3). I don't have later versions to test with, but please try the following:

1[vcache]
2MinFileCache=32000
3MaxFileCache=40000

It also seems to increase disk access times.

truth5678 wrote:

I installed WinME under the "modified" normal core. A couple of glitches along the way, as in the dynamic core, but the OS installed. When I included ESDI, then it the emulation stopped as in the dynamic core.

Attached is a picture of the status window of WinME(+ATA) after the emulation stopped. It shows a few ATA reads and then it stops; however, there is no message about a page fault (the top frame of attached picture). However, when I excluded the IDE driver, then the log shows page faults (the bottom frame in the attached picture). This suggests that page faults are not the cause of the IDE driver not working properly in WinME; it would be consistent with the difficulty in loading the other drivers under WinME.

What CPU setting did you use? All my testing is done with the CPU set to pentium. The 486 emulation seems a bit weird.

SedrynTyros wrote:

Looks like Windows 95 OSR 2.1 doesn't recognize CDDA tracks on mounted discs. Bummer ....

DOSBox-X doesn't return the actual TOC. It currently returns a bullshit TOC that always reports a 640MB-ish data CD. I did that to get IDE emulation to work with Win95 as quick as possible. I will begin adding code to report the true TOC according to your ISO/CUE image.

SedrynTyros wrote:

I think there are several CD-ROM games from the Windows 95 era that have Redbook CDDA. I remember in my old-school FPS collection that several of the CDs had audio tracks, including Quake and both Quake expansions (albeit, there was a DOS version of Quake first). I think it wasn't until 1998/1999, after games like the original Unreal Tournament demonstrated you could get high quality sound with the right compression format while using a relatively small amount of system resources, that the industry as a whole moved away from using Redbook. That's not to say that there weren't many games during the Windows 95 era that didn't use Redbook, but some games did use it. Heroes of Might and Magic II is another one I can think of off the top of my head with CD tracks (of course, there was also a DOS install for that game as well, but I'm just saying).

There are quite a few games going as far back as 1995-ish that used audio compression. I remember finding some guy's Geocities website about mid-1998 that described how Command & Conquer used ADPCM compression for it's music and sound effects and how to decode it (most of it being 22KHz mono 4-bit ADPCM).

Anyway, when I wrote the ATAPI emulation in DOSBox-X I coded it to bullshit a CD with one data track that is always 640MB-ish because I was lazy at the time and I wanted to quickly see if I could get Win95 to see it. It sounds like it's time for me to implement it properly 😀

truth5678 wrote:

In an attempt to show an audio track listing via the "Table of Contents" (0x43 or TOC) command, I entered a fake function(s) for […]
Show full quote

In an attempt to show an audio track listing via the "Table of Contents" (0x43 or TOC) command, I entered a fake function(s) for Play Audio (0x45). Used the lines from the "default" case to bypass it. Then, tried to write different sequences of bytes for 0x43, but so far unsuccessful in finding the audio tracks in 95, at least via the "CD Player" built-in to the OS; the ISO files are showing, however.

I wonder if the TOC command is enough to find the track listing (.cda files) in 95. If so, it should be a matter of having the known TOC bytes from another source and then writing those into the 0x43 command; one audio track should be enough for testing. I haven't yet found an open source emulator which appears to handle the TOC command, which would be helpful in uncovering the problem.

Edit: since 95 is requesting the 0x45 command (play audio, not play audio msf), I would guess that the track start position must be written in LBA, not in MSF format (is there a third format, too?).

Edit2: Nero Burning Rom 5.5 (Image Drive) supposedly will mount cd audio tracks in 95 (link to the Vogon thread in an above post). Tried Image Drive in 98se and it mounts ISO images without issue; it also will mount NRG images (presumably with CD audio tracks). I have not yet tested the latter. I believe this software will also work in 95, but requires a dll file (olepro32?); my guess is IE4 or IE5 has this file. If this works, this would be an ideal solution since it supports an "eject CD" function and the SCSI driver appears stable.

Again, it's my fault that the TOC command was implemented hastily to only return one large data track. I will work on properly returning the image's table of contents and then Win95 should be able to see audio tracks properly.

ripsaw8080 wrote:

The MSCDEX emulation would ideally not be involved with Win9x. Mapping ATAPI commands through MSCDEX seems wonky, although it might be expedient to do that initially. Ideally there would be ATAPI frontend code that accomplishes the same thing for Win9x (and real DOS + real MSCDEX + real cdrom device driver) on the cdrom device backend (cdrom_image.cpp) that the MSCDEX frontend does for the internal DOS.

It is wonky, but it was the quickest way to add IDE ATAPI emulation to DOSBox without reimplementing a whole lot of stuff and tie it into IMGMOUNT. Using the MSCDEX emulation like that isn't all bad.

TheGreatCodeholio wrote:

truth5678 wrote:

I installed WinME under the "modified" normal core. A couple of glitches along the way, as in the dynamic core, but the OS installed. When I included ESDI, then it the emulation stopped as in the dynamic core.

Attached is a picture of the status window of WinME(+ATA) after the emulation stopped. It shows a few ATA reads and then it stops; however, there is no message about a page fault (the top frame of attached picture). However, when I excluded the IDE driver, then the log shows page faults (the bottom frame in the attached picture). This suggests that page faults are not the cause of the IDE driver not working properly in WinME; it would be consistent with the difficulty in loading the other drivers under WinME.

What CPU setting did you use? All my testing is done with the CPU set to pentium. The 486 emulation seems a bit weird.

Used that modified normal core posted a few threads below this one. 😀 Also, I believe I used pentium cpu with it. However, I'm now unsure whether the page faults can be ruled out for WinME+IDE; but perhaps 98se would prove a better test subject.

Edit: the vcache setting helps with the page fault problem when the S3 driver is not loaded; also, the S3 driver potentially loads when the PIO cycle times are changed from 120ms to 512ms in ide.cpp (identify bytes), but on next boot Windows may not load, instead press F8 on boot and choose the option of "step by step confirmation" to load Windows. I wonder if slowing down the ide emulation further would help and whether there is a way to have Windows boot and load drivers more slowly (tried to add delay to spin-up and spin-down delays and other like parameters).

Okay it took some work but I fixed the READ TOC command emulation and added all the commands necessary for CD audio playback to work.
I'm able to make up a .cue file with an ISO image and some WAV files and the Windows 95 CDPLAYER.EXE program is able to see audio tracks and play them. The biggest issue is that for whatever reason, DOS programs in pure DOS mode using MSCDEX.EXE have some stupid hangup with some of the status the IDE ATAPI emulation returns, even though it's valid according to all the docs I can find.

http://youtu.be/p0KKMvuBvYY

Edit: It also seems that CD player (or the IDE emulation?) will sometimes decide that a certain track doesn't want to play. Hm..