Two problems I've encountered since getting DosBox for my Mac.
1) The download comes with a "DosBox Preferences" file that I assumed would be the same as dosbox.conf for the PC build. However, nothing I changed in this file did anything. I renamed it to "dosbox.conf" and it works perfectly now.
I know there was discussion about having DosBox look for "DosBox Preferences" vs. "dosbox.conf", and apparently that was changed, but the name of the file wasn't. Easy enough to fix.

2) Not a DosBox issue, but could be cause of frustration for some. The newest (aluminum) official Mac keyboards no longer have specific buttons Volume Up, Down, and Mute and instead took over F10 F11 and F12 (and yet they still have F16-19 in the same place), which gets in the way of Cycles Up/Down. To fix this the user can go into their System Preferences, click Keyboard and Mouse, and make shure you're on the "Keyboard" tab. There should be a check box that says "Use all F1, F2, etc. keys as standard function keys". This box wil be unchecked. Check it.
Now, when DosBox is open, you should be able to use Ctrl+F11 for cycles down and Ctrl+F12 for cycles up.

Ocarina654 wrote:

Two problems I've encountered since getting DosBox for my Mac.
1) The download comes with a "DosBox Preferences" file that I assumed would be the same as dosbox.conf for the PC build. However, nothing I changed in this file did anything. I renamed it to "dosbox.conf" and it works perfectly now.
I know there was discussion about having DosBox look for "DosBox Preferences" vs. "dosbox.conf", and apparently that was changed, but the name of the file wasn't. Easy enough to fix.

The file "DosBox Preferences" will be recognized if you place it in your Preferences folder.

Well even if that is true, there's nothing that would tell anyone that is the case.

Its not a big issue, but having the preferences file NOT work as downloaded could be somewhat off-putting to new users. Since I've used DosBox on other OSs in the past, I knew that there was likely a way to fix this quickly, namely, renaming the file.

Ocarina, have you looked at Boxer? Among other things it automatically installs the appropriate configuration files and changes the keymappings to more mac-like ones (i.e. not based on function-keys). While I realise that Boxer is not DOSBox, and the issues continue to exist with the main DOSBox package, Boxer is intended to be an alternative Mac distribution rather than a front-end.

Another issue with the Mac port which I'm hoping the developers could shed some light on: it doesn't seem to be possible to mount a CD-ROM in such a way that CD audio will play.

In OS X, mixed-mode CD-ROMs are mounted by the filesystem as two volumes, one of data and one of audio tracks. These volumes correspond to separate devices: e.g. the audio volume might be /dev/disk1 and the data volume would be /dev/disk1s0. Ostensibly, /dev/disk1 is a representation of the entire disc and /dev/disk1s0 is just the data track; there are additional devices (disk1s1, s2, s3 etc.) for each audio track, but these are not exposed as individual volumes by the filesystem. The OS X filesystem exposes the audio volume for /dev/disk1 as AIFF files for each audio track, with the data track nowhere to be seen.

In any case, it seems that DOSBox is unable to access the audio tracks from the CD regardless of how it is mounted. I've tried the following (paths are examples only):
MOUNT D /Volumes/CDData -t cdrom -usecd 0 #DOSBox sees only CD data, no audio tracks
MOUNT D /Volumes/CDAudio -t cdrom -usecd 0 #DOSBox sees only the .AIFF representations of the audio, no audio tracks
MOUNT D /dev/disk1 -t cdrom -usecd 0 #DOSBox sees nothing
MOUNT D /dev/disk1s0 -t cdrom -usecd 0 #DOSBox sees nothing

The -usecd 0, -ioctl and -noioctl switches seem to make no difference to this.

Does SDL support cd audio under OSX?

I don't have enough SDL experience to answer that question fully, but I did some tests based on the sample code from the SDL_CD-ROM wiki page.

Audio CDs and mixed-mode (ISO9660 data+audio) CDROMs produced the following output:
Name: disk1
Status: 0 (corresponds to CD_TRAYEMPTY)
Tracks: 0
A call to SDL_CDEject() ejected the disc.

Data CDs or an empty drive both produced the following output:
Name: Fake CD-ROM Device
Status: 0 (CD_TRAYEMPTY)
Tracks: 0
A call to SDL_CDEject() did not eject the disc, even when a data CD was in the drive.

In every case, the physical CD-ROM device was /dev/disk1. SDL_NumCDDrives() reported 1, and calls to SDL_CDOpen() for drive numbers higher than 0 returned NULL as expected, so it's at least detecting that the CD drive exists.

This is with Leopard 10.5.3 running on a Macbook with an internal DVD/RW drive. I've found no mention so far in the SDL documentation that the SDL_CD-ROM library has problems on OS X, but these tests strongly indicate that it does.

Reading the SDL sources audio playing seems supported.
Maybe you could check AudioFilePlayer.c in the cdrom/macosx
directory if you can identify something, how it works or so.

Argh... actually, I missed out a vital call that DOSBox is perhaps also missing: SDL_CDStatus() must be called on an SDL_CD struct in order to populate the track listing. This must be done before attempts to inspect the SDL_CD's properties or play audio from the CD, otherwise the SDL_CD will report that there are no tracks (and indeed that the drive is empty). After calling this, the SDL_CD's status is updated to CD_STOPPED and it reports the proper track data instead of 0 tracks.

Because of the way that the SDL internals differ from platform to platform, it could be that you don't need to call SDL_CDStatus() in advance on Windows and Linux platforms - but on OSX it is responsible for parsing the table-of-contents file of an audio CD, and is the only time this happens. So it's possible this call was omitted from DOSBox's CDROM handling, causing CDs to appear empty on OS X?

Regarding CD audio playing itself - judging from the sourcefiles in /cdrom/macosx/ it looks like SDL grabs the AIFF files directly from the mounted audio CD volume on request and feeds them to a generic audio file player (AudioFilePlayer.c), which itself looks to be copied from Apple sample code. I don't suspect there's any problems with the audio CD support, it's probably just not getting this far.

So it's possible this call was omitted from DOSBox's CDROM handling, causing CDs to appear empty on OS X?

No, as far as i see it's called, especially for the GetAudioTracks function.
If you can compile dosbox, maybe you can add some logging to those
functions to see if they return with an error or so.

Ok, I was completely wrong and not paying any attention... DOSBox *is* enumerating the CD tracks properly so the problem does seem to be related to audio playback after all. Once I'm able to get DOSBox to compile I'll see if I can find any errors occuring at that stage.

Finally managed to build DOSBox 0.72, and did some testing with the CDROM functions to figure out why CD audio is not playing on OS X.

One initial bug: CDROM_Interface_SDL::PlayAudioSector and CDROM_Interface_SDL::StopAudio both call SDL_CDClose followed immediately by SDL_CDOpen. This is causing the CD's track data to be irrevocably lost: id, offset and length are all set to 0 for every SDL_CDtrack in cd->track. Playing a track then fails because it tries to play from 0 offset for 0 frames. Haven't yet figured out why the data is getting wiped but it's presumably an OSX-only bug in SDL.

After commenting out those close-and-reopen lines, CD track data is retained properly and CD players can correctly determine track offsets and lengths. However, now the SDL_CDPlay() call fails with errorcode -6: this means SDL found the AIFF audio file associated with that section of the CD, but the call to the (OSX-specific) LoadFile() function is failing so it can't open it.

SDL is eating the reason why this call fails, which could be any number of things, so I'll need to recompile SDL and tinker with it to figure it out. Before that I'll try with the SVN version of SDL.

Thanks for looking into it. Can you debug the sdl library? (i know it is possible
under windows, but not sure if/how it is possible under linux/osx).

I've tracked down the problem in SDL's code now... it turns out to be an endianness bug when parsing AIFF audio chunks. SDL's implementation was copied from some old Apple sample code, which may have worked on PowerPCs (which are big-endian IIRC), but not on Intels. I'll file a bug with SDL about it once I've checked for any further problems.