It's been almost 9 years since Geoffrey Brown kindly contributed BII code for limited bin/cue support (partly inspired by the excellent DosBox team's bin/cue reader). Sadly, the feature never made it into standard builds of either BasiliskII or SheepShaver. I suppose this was due to a number of restrictions: audio output must match CD quality to play, Core Audio in Mac OS X led to a second output device for Mac OS to mix with the emulator output, and a reliance on Posix functions for reading the BIN files. Regardless, with so much of the logic in place and the lack of bin/cue files remaining a notable constraint on SheepShaver (e.g. inability to mount mixed-mode CDs), it seemed worth revisiting Dr. Brown's code.

I've been fiddling off and on for a while and finally made some headway this week. Originally, I focused on Core Audio. Some of the Core Audio calls have changed in the last few years, and while it now compiles, I still hear static with this approach. SDL is actually the better option for cross-compatibility, and since we're using SDL2 in both BII and SheepShaver now, I moved to SDL's new AudioStream API for reading and converting the CD audio. Not only should this remove limitations on matching sound output since SDL can convert to the appropriate format before mixing, but more importantly, CD audio works again!

The volume slider is now operational, and I tweaked the data partition reader to support redbook (MODE1/2352), yellowbook (MODE2/2352), and pure data (MODE1/2048) type discs, although I've not been able to get yellowbook discs to mount yet.


I've put a test build on GitHub for Mac OS X: https://github.com/spolsley/macemu/releases/tag/2.5_20190616. The source code is available in the cdaudio_test branch. Uncertain, but it will probably build on Linux with USE_SDL_AUDIO=1. The build should swap out with an existing SheepShaver setup.

To use it, add a .cue file to the volumes list as a cdrom. My testing has been pretty limited so far, so I'm curious if it works for others.


Here's the list of limitations and issues that I know so far:

- The code is still very messy; comments and unused snippets are strewn about. Also, the way it does things should be improved; it's not really best practice. For instance, the hook in audio_sdl.cpp to play CD sound checks if a CD is playing every time the audio buffer tries to refill. This wastes CPU cycles the vast majority of times. My focus has been on functionality, but I would still like to clean the code and improve performance soon.

- Using SDL will enable CD audio in Windows, but the code continues to use lseek() and read() for handling BIN files. Looks like there might be equivalencies or variants available in Windows, but I don't have a current setup to test that.

- BasiliskII runs and recognizes the data and audio partitions. However, I'm still hearing static when playing the audio. It sounds like the format or rate isn't matching, but I haven't been able to determine the cause or find a fix yet.

- A few driver-level features remain unimplemented for the CD player: Shuffle, Scan, and Program.

- Some games, like Descent, will play CD audio in-game, but others, like Warcraft: Orcs and Humans, will not. It depends on how the game developers handled CD audio. Warcraft tries to open the Internal CD drive as a recording device and uses playthrough to simulate output. This is problematic, because it requires extending driver support to the Sound Input Manager. A skeleton of useful code exists in audio.cpp, but the 68k assembly for icon loading is indecipherable to me. It crashes SheepShaver and fails to build in BasiliskII.

Does anybody have a good reference for Sound Input Manager? I've been pouring over Inside Macintosh's Sound chapters, various documentation archived at Macintosh Garden, and a slew of technical notes. Maybe my eyes have glazed over, but I can't seem to find details on the expected arguments and responses to register a sound input device. It's all beyond my knowledge. I'm hoping someone here will have an idea. If this is enough of a start that others are interested or able to help, we might be able to get stable, cross-platform bin/cue support in all Sheep and BII builds soon!

That is awesome news, thanks for revisiting this issue and making such quick progress.

I will definitely do some testing and report back.

I have tested Decent II. When I start the game I can get the CD music working in the main menu. I have swapped between MIDI and redbook audio and the difference is obvious.

However, when the introduction movie for the first level finishes, the game crashes with "Error locking sound 76". I have not been able to find a away around that yet. Enabling MIDI music results in the same error.

I also tested Warcraft II.

When I launch the game, I go to the advanced tab under Startup Options and next to "CD Audio Source" the menu has "none" selected and there are no other options. When the game starts, there is no background music.

However, when I go to the CD Audio Player, the CD tracks will play in there.

Thanks for testing, almeath!

It looks like Warcraft II is the same as Warcraft I, using the CD player as a Sound Input device and passing through audio. Unfortunately, I still haven't found better documentation on the Sound Input Manager.

For Descent, I wonder if the lack of CD scanning is the problem. Error -76 is "tk0BadErr: track 0 detect doesn't change", so maybe it's related. Descent I doesn't have videos and doesn't crash, so I'll need to download Descent II and try to reproduce the crash.

Another issue with these mixed-mode games is timing. For some reason, in Warcraft and Descent, gameplay is too fast and controls are too slow. Maybe it can be fixed in settings, but some adjustment will be necessary to make them play correctly.

I've continued to play around with the Sound Input Manager and am now much more familiar with how Sheepshaver & BII handle drivers. The patched driver which traps out to audio.cpp's logic is making headway but is still fighting me when it comes to registering the STR# resource of available inputs.

Despite slow progress, in the midst of testing I discovered that Mac OS 9 can actually load the native driver (perhaps due to changes like embracing digital audio). I have put up a test build which should support both bin/cue mounting and CD playthrough with Mac OS 9 guests:

https://github.com/spolsley/macemu/releases/tag/2.5_20191107

My hope is to get the patched driver working for better compatibility with earlier Mac OS versions, but it's probably more important to first figure out why BII is playing static and add Windows functions for reading bin/cue files. In the meantime, this might give options for mixed-mode CDs under Mac OS 9 that didn't work before.

I should note that a couple games I've tested work, but Warcraft I still refuses to play CD audio. I thought having playthrough enabled would change that. There must be something else going on, maybe in the way it's recognizing the disc. If anyone is able to download and test some mixed-mode use cases, I'd like to hear what is or isn't working!

So is it possible to switch between modes using a prefs value, so that you can use the old buggy audio for most situations, and switch to passthrough for configurations where it works?

Then we can use the current setup while figuring out how to get the patched driver working with 8.6 and below.

Bin/Cue support is great... because now OS 9 can load up pretty much ANY bin/cue which can be read by Toast and converted If you could add support for iso/wav/cue format too, that'd be awesome, as support for that format is rather lacking on macOS.

I tried running Warcraft II in OS 9.0.4 with base extensions. In the initial game configuration options under Audio Source it says "Internal CD". However, once the main part of the game is running, there is no CD audio playing. The digitized sound in the introduction and main menus seems to work correctly. The CD tracks will still play in the Apple CD Audio Player application.

In Decent II, I tick the option to disable MIDI music in the initial configuration options. When the game starts the screen is entirely black but I can hear the audio to the intro sequence. I press escape and then the main menu displays correctly, and under the audio options it is confirmed that CD audio is playing. When I start the game, the intro movie/animation will play correctly here, but then as soon as it is done the screen goes black, I hear the OS alert sound, and then the game crashes and takes me back to the desktop with no error message or window.

Thanks for the feedback! I've updated the build with a couple improvements: (same link, but re-download to get the new executable)

https://github.com/spolsley/macemu/releases/tag/2.5_20191107

• Warcraft II CD audio now works! (due to a change in the "AudioPlay" control call)
• Better Apple CD Player compatibility
  
  • CD scanning is mostly implemented, need to add track bounds
  • Sometimes the player issued a duplicate "resume" call, which no longer yields an error

@adespoton, I haven't added a prefs toggle yet. It would be possible, but since the sound input patch doesn't load either way, I'm not sure there's a noticeable difference for pre-OS 9 users. What I'd really like is to get the native driver to load in OS 8.

@almeath, your comments led me to investigate a couple different avenues:

Warcraft I & II Notes
I found Warcraft II getting stuck in a loop. It would set the start position, pause, set the end position, and then check status, repeating until playback started, but it never actually initiated playback. I think the problem was in Sheepshaver's implementation of "AudioPlay". Apple's documentation is a bit unclear, but I've changed it to start playback from the current position when being called with an end position.

Unfortunately, Warcraft I is still resistant. In the readme, it notes only an internal Apple CD drive with playthrough will work, and these patch notes from Warcraft II v1.23 provide more context for the problem:

That patch was released for Warcraft II about a year after Warcraft I's Mac debut. It suggests to me to WC1 has very rigid expectations in its code for CD audio. The lack of support for multiple drives may be the key problem since Sheepshaver can attach any number of CDs. It's also likely there's still some value being reported incorrectly that doesn't match the game's expectations of an internal Apple CD drive.

Descent II & Nanosaur Audio Notes
Regarding Descent II, the sound error is a different issue. I'm not sure if it's tied to the audio output driver or a missing/mis-implemented opcode. The crash is very similar to what happens when launching Nanosaur in Sheepshaver. Both games are open-source (Nanosaur, Descent II), and I've found the origin of the error in code: it's an attempt to play a sound before initializing the sound object.

In Nanosaur, it crashes when trying to show the loading screen with a T-Rex running next to the title. The T-Rex skeleton is loaded and attempts to play the footstep sound, despite not having the level sounds loaded at that point, only the menu sounds. I found an old tool from DescentBB to track down the troublesome file in Descent II, and it appears to be a background hum noise ("de_hum_2") which loads during the enemy overview screen.

To me, it seems like a bug in the games, at least in Nanosaur's case, but somehow they don't crash on real Macs. I can only assume something's wrong in Sheepshaver, maybe it's reporting the incorrect value or not computing something which would prevent the attempt to play unloaded sounds.

For Nanosaur, the fix is to use version 1.1.6, the charityware distribution. Its additional charity title screen apparently prevents the crash, but the game doesn't play correctly due to Quickdraw 3D issues. For Descent II, different versions didn't help, but if you disable sound effects on the launch screen, it will run. Unfortunately, it has similar speed issues to Descent I, making it unplayable.

General Comments
Of the games I've tested, only Warcraft I isn't working, but I'd like to find other games with the same problem. Something open source would be ideal; seeing the code is the most likely way to get it running apart from trial and error.

Then there's the speed issue. It seems many of these mixed-mode games associate their timing with the CPU speed in some way. The gameplay for both warcrafts can be adjusted nicely, but scrolling is way too fast. The game runs ok in Descent I, but the controls are too slow; conversely, the game and controls are too fast in Descent II. I'm beginning to wonder if it would be possible to add a speed control feature like Qemu and DosBox have.

@Elyus, thanks for all your work on this. Warcraft II now works properly for me.

However, in Decent II I am still experiencing all kinds of problems like black screens and crashes with error type 3, or the error type 76 etc. I cannot actually get it to the main part of the game without crashing, even with the sound effects turned off.

Anyway, as you said it is not really playable until there is some kind of speed limiting feature available in SheepShaver. That would be an extremely useful improvement, as there are many games that are processor speed sensitive.

I think I may have some level of an idea of what's wrong in Warcraft I, from messing with CD drivers back in the day.

The internal Apple CD didn't implement a number of calls in the driver because it assumed it was the only optical media present. It also didn't implement the associated error checks.

Can someone try running WCI with the Mt Everything and Joliet extensions added? I think MG has them. This *may* implement the missing error handling needed.

However, even with that, WCI will likely die as it'll be making CDA calls without first initializing the playthrough; Apple in their infinite wisdom originally pre-loaded everything into memory and left it running, slaved to the internal CD-ROM drive. This meant WCI could just use the interface without having to initialize anything and indicate WHICH device was being used.

If this continues to be an issue and I've got the time (unlikely, but possible), I could crack open a copy of WCI and patch it and make it available somewhere. That would probably be easier than making SheepShaver work properly with it without adding a performance hit to SS.