That's awesome work on your emulation! Especially with lack of examples and supposedly error-prone documents on the standard. 😀 I watched the video clip and the CD audio is certainly robust. Are any audio track problems repeatable?

I wonder if 95 DOS and the 95 mscdex driver produce the same problem as pure dos and its version of mscdex. Also, perhaps a dos program could run via the 95 DOS box and work while mapping through the protected mode layer.

If mapping through mscdex emulation, then I would think that the OGG format would be supported in your emulation, too.

Edit: When 95b+IDE+S3 is not shut down properly, it will freeze on boot; one way to fix is to boot with F8. I think we have a solution, disable scandisk on boot via msdos.sys:

1[Options]
2Autoscan=0

Edit2: the CD audio emulation works flawlessly! Confirmed it works in DOS6.22 and 7.0 (95) via "Cubic Player"; interesting that when using Cubic Player in 95 DOS box, it communicates by "Play by LBA" (Atapi command 0xa5) instead of by MSF. 95 must be using atypical(?) mapping to play back DOS-based CD audio.

Glad to hear that. I just pushed another update that fixes the MODE SENSE command to return the page data the way it's supposed to (the SCSI docs are very bad about documenting the MODE SELECT/SENSE commands and how you format the data).

The update resolves issues with DOS players failing to detect that the CD-ROM drive is capable of CD audio. It allows CCD to detect that playback is active (though the listing mode still says Halted for some reason) and it allows ACDC.EXE (some shareware DOS program I found) to work, although it seems to get hung up with a Disc Error if the fake CD-ROM drive starts with a data track. The update also allows the Windows 95 CD player to autodetect that the CD is already playing if you start playback from DOS then boot into Windows.

The only remaining issue I know of is that, despite formatting the data correctly, given the data + audio CD-ROM format I'm testing CCD still thinks the first track is audio when it is really data. I'm also noticing that DOSBox's CD audio output is a few seconds ahead of where the audio is, and when DOS programs that assume the play time is accurate are involved, it is impossible to "scan" backwards because of it.

I also played around a bit and found that the issue where the CD-ROM drive refuses to play a track happens if you jump to a track, then scan backwards into the previous track, let the previous track play out and run into the next track, and then try to jump back. Doing that reliably recreates the problem.

BTW: Once thing that DOSBox's CD audio emulation might consider emulating at the drive level, is the CD audio volume. I noticed it's emulated at the MSCDEX.EXE syscall level, it'd be nice if that was moved into the CD-ROM image object itself and exposed via ATAPI and MODE SELECT/SENSE. ACDC.EXE seems to have nice controls for that parameter.

That's very good news on the update, thanks!

I'm not able to reproduce the (forward-backward seeking) track problem in 95a; used a cue/bin image of jedi knight, including a data track and audio tracks (MODE2/2352). 😀 I wonder if the image has the same behavior under DOS, too (assuming it was a Win95-specific problem)?

Cubic player is detecting the track order correctly in pure DOS. Do the other DOS CD audio players work correctly in DOSBox "FreeDOS"? Also, I noted that Cubic player does not allow seeking backwards to the previous track, whether in pure DOS or DOSBox "FreeDOS".

(I recall a post that mentioned some players require the data in the last track; and additional DOS players: http://www.bttr-software.de/freesoft/sound.htm#cdplay).

Hooray for progress!

If you're looking for a suitable test, the CD version of Loom was pretty picky about track positioning.

TheGreatCodeholio wrote:

BTW: Once thing that DOSBox's CD audio emulation might consider emulating at the drive level, is the CD audio volume. I noticed it's emulated at the MSCDEX.EXE syscall level, it'd be nice if that was moved into the CD-ROM image object itself

Volume control is implemented in the MSCDEX frontend insofar as there are cdrom device driver functions for it. It is also implemented in the cdrom drive backends; however, it's currently only handled for images and ioctl_dx because they directly process audio samples. See ChannelControl() and CDAudioCallBack() in cdrom_image.cpp and cdrom_ioctl_win32.cpp. An ATAPI frontend will need to pass the control structure containing volume levels, and perhaps the channel selections as well, to the cdrom drive backends via ChannelControl(), similar to how the MSCDEX frontend does.

In regular DOSBox, CCD (CD audio only?) is showing the proper status of "playing" while playing a track. But it shows the Halt status during playback in pure DOS, as you mentioned; is it reading a register value?

TheGreatCodeholio wrote:

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.

Real MSCDEX routing through an internal emulation of MSCDEX... At least we can agree that it's wonky. However, I don't see that it's really easier or more expedient, because all MSCDEX functions end up as function calls to the cdrom drive backends, so why not just do it the right way and make those backend calls directly?

Well the calls aren't directly going through MSCDEX.EXE. The hack uses MSCDEX.EXE to map drives to IDE master/slave. Most of the work is done by calling the CD-ROM image object directly. You could say the MSCDEX.EXE emulation is more of the initial arrangement between CD-ROM drive and IDE device mapping.

Another more thorough test:

https://www.youtube.com/watch?v=8Jy26y635GI&feature=youtu.be

Thanks for the video clip -- I enjoyed watching it! I have to see it again, but I noted the 95 cd player bug (actually an OS bug). 🙁 I wonder if the 98 version does the same - I'll try that. In the clip, I also noted that a real-mode driver forced the drives in compatibility mode yet the 95(b?) cdrom was active on the IDE port. Does that fix any page fault problem?

truth5678 wrote:

Thanks for the video clip -- I enjoyed watching it! I have to see it again, but I noted the 95 cd player bug (actually an OS bug). 🙁 I wonder if the 98 version does the same - I'll try that. In the clip, I also noted that a real-mode driver forced the drives in compatibility mode yet the 95(b?) cdrom was active on the IDE port. Does that fix any page fault problem?

I had to force disable the IDE driver for the primary port so that installing Hexen II wouldn't trigger the pagefault problem in Win95. The version shown is the original Win95 (the one released in August 1995). But that's not what triggered the weird error message. What triggered the message was that somehow, running ACDC.EXE and then unloading it made Windows mistake it's own WIN.COM loader as an MS-DOS program incompatible with Windows. Perhaps ACDC.EXE doesn't quite remove itself from memory properly. Who knows?

hmm, seems it is time for me to make DOSBox-X snapshots as well... need to try these things out now! Thanks!

I'm unable to reproduce the "cd player bug" in 95a. I have track #1 as data and the remaining 7 tracks are audio of "Jedi Knight". I could see the effect in the video clip, so I wonder if the bug is also dependent on the TOC (and cue sheet).

I also didn't think to test the real mode cdrom driver in 95 (I was using the protected mode previously). That is a different and great way to access your emulation and produces a different result from the 95 DOS box. With the protected mode active, the 95 DOS box attempts to access cd audio by an atypical (unsupported and rarer) ATAPI command; however, the real mode driver allows the 95 DOS box simple access to cd audio. 😀 It must be mapping directly via the real mode mscdex layer rather than through the protected mode layer?

I also wonder about the time delay between playback and track position in DOSBox. Is this inherent in DOSBox and part of an audio buffer? Possibly via SDL or part of the DOSBox emulation itself? My cue sheet for Jedi Knight does list the absolute track positions, but does not specify a "pre-gap" size; however, there does seem to be 2 seconds empty at the start of each track.

The CD audio support for both DOS and Windows games in the 95 guest is excellent.

I wonder if images could be swapped through the mscdex emulation. Ctrl-F4 calls "SwapInNextDisk" in bios_disk.cpp. It swaps the disk even where the IDE emulation is active (but only seen in DOSBox "DOS" as a media change). From documentation, it seems that 0x20 and 0x08 handle the ATAPI media change and request (only the change is necessary?). Also, DOSBox mscdex has the following functions: GetMediaTrayStatus; LoadUnloadMedia - eject (Ctrl-F4 probably already does this via "SwapInNextDisk"); and InitNewMedia.

Hints on register values during 95 media change:
http://qemu.11.n7.nabble.com/Qemu-devel-PATCH … r-td173325.html

Also, I wonder if "GetAudioStatus" would lend insight into why CCD is indicating HALT status during playback. In pure DOSBox, CCD does not register any status at all (neither HALT nor PLAYING) while playback is paused (are there multiple registers to check for the pause condition?). A good test would be in a non-emulated system (verified not working in real XP). 😀

Edit: With or without the attached patch against ide.cpp, it is possible to swap the disk (cdrom image) on pressing Ctrl-F4. 😀 It works in pure DOS and 95. However, the patch is also a demo of the atapi command 0x20 which calls the mscdex function which presumably would allow a swap (although the swap works without that code).

I'm very excited about the progress on the CD emulation. Finally we'll have CD audio support in DOSBox Windows 95!!! 😀

great job! Now a win32 binary with that swap patch integrated? Because DOSBox-X is still hard to compile, at least for me (since it, now, heavily borrows features from DOSBox SVN Daum)

I found CCD here, and some problems it has in DOSBox may point out flaws in the emulation.

The first problem I noticed with CCD is that it does not identify data tracks in its (I)nfo function. This turns out to be a plain bug in the program where it tries to get the audio/data attribute from track 0 instead of the correct track number. The invalid track number returns an error, which is ignored, and every track in the list is labeled as audio. The bug can be fixed in CCD.EXE by modifying the byte at offset 0x6DD from 0xF2 to 0x04.

The second problem is that after (H)alting play, CCD acts like play has been stopped rather than paused. It identifies the pause condition when bit 10 of the device status, which indicates playing according to RBIL, continues to be set but the command status word indicates the device is not busy. After changing the device status in DOSBox according to these rules, CCD identifies the pause condition.

I noticed a third problem when fixing the second. After (S)topping play, CCD acts like playing has been (H)alted. The curious thing is that there is no pause command; there is only a stop command, and CCD uses it for both (H)alting and (S)topping play. The difference appears to be that CCD also uses the seek command (to position 0) after the stop command when (S)topping. DOSBox does not currently implement seeking, but I suppose a seek to 0 could cause the pause condition to change to full stop...

With or without the attached patch, IDE emulation allows swapping of cdrom images on pressing Ctrl-F4, then eject. Ctrl-F4 will swap the disk, but activating "eject CD" is also required to update the audio tracks. However, the data portion isn't updated (yet) upon swapping disks.

can anyone post the needed IDE patches for vanilla dosbox please? So I can compile my own win32 binary of dosbox with 32-bit disk access, cd audio and cd swap 😀.