DOSBox bug tracker at SourceForge (not easy to find 🙁 ):
http://sourceforge.net/tracker/?group_id=52551&atid=467232

Thanks for such a detailed bug report. Way too few people thake time to find out that much before reporting 😀

As for 3), did you check that other Ctrl-F? key combos work? IIRC, the mac keyboard on a macbook pro is a bit strange regarding F-keys.

"dosbox -startmapper" might be a help to you as well 😉

`Moe` wrote:

"dosbox -startmapper" might be a help to you as well 😉

To do so, open the Terminal nd the DOSBox appliation package ("/Contents/MacOS/DOSBOX") and drag the UNIX DOSBox file onto the Terminal, then add the command " - startmapper" to the command line.

I think, the F-Keys does only work in fullscreen mode (press Cmd/Alt-Enter to switch) and, on a PowerBook/MacBook, if you press the Fn key at the same time.

I entered Fullscreen, hold Fn-Ctrl-F1 at the same time and got it:

To exit the Keymapper, just move the Macintosh mouse cursor onto the "Exit" in the right-bottom corner and click it.

`Moe` wrote:

Thanks for such a detailed bug report. Way too few people thake time to find out that much before reporting 😀

As for 3), did you check that other Ctrl-F? key combos work? IIRC, the mac keyboard on a macbook pro is a bit strange regarding F-keys.

"dosbox -startmapper" might be a help to you as well 😉

All the other CTRL-F? commands that I tried work (shutdown, inc/dec cycles, etc.). I haven't gone through them all, but so far it appears that CTRL-F1 is the only one that does nothing.

Using -startmapper on the command line as you suggested does work, and I was able to BIND the key 'p' to the PAUSE event and save. When I hit 'p', it paused DOSBox, but hitting 'p' again did not resume it; it was stuck paused until I killed it.

Nothing in any of the documentation/README says that PAUSE is a toggle, but since I can't find any RESUME event, I assumed that PAUSE was a toggle. Was I wrong? I don't understand how I can successfully bind a key to the PAUSE event and use that key to pause the emulator, yet I am unable to resume emulation by hitting the same key again.

r_wolfcastle - I can't help much with the investigation, only repeat what Moe said and thank you for the report and your willingness to help IIGS_User iron out the bugs and inconsistencies in the Mac OSX version.

IIGS_User wrote:

I think, the F-Keys does only work in fullscreen mode (press Cmd/Alt-Enter to switch) and, on a PowerBook/MacBook, if you press the Fn key at the same time.

I entered Fullscreen, hold Fn-Ctrl-F1 at the same time and got it:

OK, now we have a new more serious bug. 😉

I had successfully used Alt-Enter to toggle in and out of fullscreen mode when I first started playing with DOSBox. But just now I hit Alt-Enter and got a completely blank and completely unresponsive full screen; Alt-Enter not only did nothing, CTRL-F9 wouldn't quit, either. I finally had to hit CMD-OPT-ESC, which did not bring up the normal OS X "Force Quit Applications" dialog, but just killed DOSBox quietly and instantly. This is 100% repeatable. Many Mac users, especially noobs, would not have known to do this, and would have had to resort to the machine's power button.

I then went into my conf file and changed my unfocused priority from "pause" back to "normal", tried it again, and ALT-Enter works just fine to toggle in and out of fullscreen mode. Then from fullscreen mode I tried CTRL-F1, and it did indeed bring up the keymapper as you said, so it appears you are correct that CTRL-F1 only works in fullscreen mode.

As for adding the FN modifier key, this is not necessary, and in fact does not work. For example: FN-F11 on the Mac shoves aside all the application windows to reveal the desktop. CTRL-F11 in DOSBox decreases cycles. FN-CTRL-F11 in DOSBox reveals the desktop just like FN-F11, and has no effect on DOSBox's operation.

HTH.

the last bug is the result of the same thing.
dosbox thinking that it is unfocused and hence it is paused. the only way to fix that is to regain focus or press the X on the menubar.

Can you compile dosbox yourself ? I have an idea what might go wrong.
Obviously dosbox looses focus on macos x (on screenmode switches?). (maybe they run in a different thread ?)
When we pause dosbox we flush for 500 ms second the buffers. and then we go checking for an active event.
Imagine this: unfocus and within those 500 ms a focus. That focus event will not be check by dosbox as it during the buffer flushing. So dosbox could end up stuck forever. However an unfocus and a focus that fast is something that doesn't on the systems that we have tested it on.

Qbix wrote:

the last bug is the result of the same thing. dosbox thinking that it is unfocused and hence it is paused. the only way to fix t […]
Show full quote

the last bug is the result of the same thing.
dosbox thinking that it is unfocused and hence it is paused. the only way to fix that is to regain focus or press the X on the menubar.

Can you compile dosbox yourself ? I have an idea what might go wrong.
Obviously dosbox looses focus on macos x (on screenmode switches?). (maybe they run in a different thread ?)
When we pause dosbox we flush for 500 ms second the buffers. and then we go checking for an active event.
Imagine this: unfocus and within those 500 ms a focus. That focus event will not be check by dosbox as it during the buffer flushing. So dosbox could end up stuck forever. However an unfocus and a focus that fast is something that doesn't on the systems that we have tested it on.

The scenario you describe certainly seems plausible.

Sure, I can try to build DOSBox, although I am an old Unix guy (and more recently reluctant Windows guy), not a Mac maven. Any chance you could either:

a) Tell me how to modify the Portfile ( http://dosbox.darwinports.com/ ) to have it leave the sources, binary w/symbols and -g, etc. on my box, or

b) put me in touch with the person who usually builds the Mac OS X DOSBox distro so I can get some pointers from him/her, or

c) at least tell me if I have to use XCode, or if vanilla gcc for OS X will suffice?

If neither of those makes sense, I'll probably just install XCode from Apple and try to slog through it on my own.

Thanks for your time regardless.

I found this build instructions on how to include a specific patch, (which isn't needed in your case) but it does list how to compile it.
http://november.parodius.com/things/dosbox-instructions.txt
The stuff you may want to play with is in src/gui/sdlmain.cpp
below:

1                        /* Non-focus priority is set to pause; check to see if we've lost window or input focus
2                         * i.e. has the window been minimised or made inactive?
3                         */

this code does the 500 ms flush

1                                        SDL_Delay(500);
2                                        while (SDL_PollEvent(&ev)) {
3                                                // flush event queue.
4                                        }
5

I can verify the pause issue on an older 0.72+ CVS version that has been customized somewhat. It seems as if every complaint except the key mapping issue (which I've covered before) has been covered here before. As for that issue, I submitted a patch in the beta forum a while back that adds a mapper.com file to z:\ that will allow you access the key mapper by typing mapper instead of using some esoteric key combination. This will allow mac users to remap their keys without too much trouble. Of course that patch doesn't help you now, does it?

😀

Good bug reporting though. I've never used the PAUSE feature myself (hell I wasn't aware you could even set it up that way as I've never been interested), so it's good to see that as the OS X port increases in popularity, we will be able to iron out some of kinks still undoubtedly floating around in it.

Another thing. Building DOSBox under Leopard was a bit painful last time I did it due to some depracated Core Audio calls DOSBox uses. I submitted a patch for that as well, however since I haven't updated my CVS build in forever, I have no idea whether or not this is still an issue.

Perhaps I should download the current sources, eh?

EDIT: For a better idea of how to build DOSBox in OS X, try the posts in the following thread by myself and rhoenie:

Topic 16120

He downloads all the supporting stuff and compiles it by hand whereas I just install the Leopard Dev Tools and use MacPorts to make it pretty simple to get all the supporting stuff ready.

EDIT 2: My leopard patch isn't in the current CVS, and of course it isn't in 0.72, so if you want to compile under Leopard, use the patch I posted in the previous thread.

EDIT 3: Removing the 500 ms delay or reducing it does not resolve the issue.

Removing the SDL Event Flush seems to resolve the problem on OS X. As this is obviously not an optimal solution - I will look into dealing with this another way.

Okay here is a patch that solves the issue without removing the flushing:

1*** ./src/gui/sdlmain.cpp.orig	2008-01-16 15:17:15.000000000 -0500
2--- ./src/gui/sdlmain.cpp	2008-02-07 07:20:16.000000000 -0500
3***************
4*** 1229,1247 ****
5  					 * regain window or input focus.
6  					 */
7  					bool paused = true;
8  					SDL_Event ev;
9  
10  					GFX_SetTitle(-1,-1,true);
11  					KEYBOARD_ClrBuffer();
12  					SDL_Delay(500);
13- 					while (SDL_PollEvent(&ev)) {
14- 						// flush event queue.
15- 					}
16  
17! 					while (paused) {
18  						// WaitEvent waits for an event rather than polling, so CPU usage drops to zero
19! 						SDL_WaitEvent(&ev);
20! 
21  						switch (ev.type) {
22  						case SDL_QUIT: throw(0); break; // a bit redundant at linux at least as the active events gets before the quit event. 
23  						case SDL_ACTIVEEVENT:     // wait until we get window focus back
24--- 1229,1251 ----
25  					 * regain window or input focus.
26  					 */
27  					bool paused = true;
28+ 					bool waitmode = false;
29  					SDL_Event ev;
30  
31  					GFX_SetTitle(-1,-1,true);
32  					KEYBOARD_ClrBuffer();
33  					SDL_Delay(500);
34  
35! 					while ((paused) || (!waitmode)) {
36  						// WaitEvent waits for an event rather than polling, so CPU usage drops to zero
37! 						if (!waitmode)
38! 						{
39! 							waitmode = (!SDL_PollEvent(&ev));
40! 						}
41! 						else
42! 						{
43! 							SDL_WaitEvent(&ev);
44! 						}
45  						switch (ev.type) {
46  						case SDL_QUIT: throw(0); break; // a bit redundant at linux at least as the active events gets before the quit event. 
47  						case SDL_ACTIVEEVENT:     // wait until we get window focus back
48***************
49*** 1249,1255 ****
50  								// We've got focus back, so unpause and break out of the loop
51  								if (ev.active.gain) {
52  									paused = false;
53! 									GFX_SetTitle(-1,-1,false);
54  								}
55  
56  								/* Now poke a "release ALT" command into the keyboard buffer
57--- 1253,1262 ----
58  								// We've got focus back, so unpause and break out of the loop
59  								if (ev.active.gain) {
60  									paused = false;

61! 								}
62! 								else
63! 								{
64! 									paused = true;
65  								}
66  
67  								/* Now poke a "release ALT" command into the keyboard buffer
68***************
69*** 1262,1267 ****
70--- 1269,1277 ----
71  							break;
72  						}
73  					}
74+ 					GFX_SetTitle(-1,-1,false);
75+ 					KEYBOARD_AddKey(KBD_leftalt, false);
76+ 					KEYBOARD_AddKey(KBD_rightalt, false);
77  				}
78  			}
79  			break;
80
81

To the original poster: This patch may not work in 0.72 as it is against the current CVS version.

EDIT: Modified waitmode = SDL_PollEvent(&ev); to waitmode = (!SDL_PollEvent(&ev)); as the original version made no sense and only just happened to work on OS X because that would only flush the first event in the queue and if there were no events - get stuck in poll mode forever (high cpu usage) instead of waiting for the next event.

Thanks for the patch, and apologies for going dark on you folks; had a bunch of stuff come up unexpectedly. As the pause thingie is only a minor nuisance, as I've previously noted, I think I'll wait until this patch makes its way into the product and there is a subsequent OS X build.

Thanks again; I'm enjoying DOSBox immensely!

It would appear in the CVS from February 6th, midi playback on OS X is broken. I see a new header file called coremidi.h out there... what exactly is that for?

Okay by default it appears midi output on OS X goes through this new CoreMidi code. By forcing coreaudio in the dosbox.conf file, Midi begins to playback again. Can somebody give me some insight as to where coremidi came from? It sounds interesting... I assume it is still in development however.

hmm coremidi being default now ?
whoops.
Well it is for connecting external midi devices under mac os x

hehehehe... well that explains why it doesn't work for me then 😀 After futzing around I figured out all you have to do is switch the order of the includes for midi_coreaudio.h and midi_coremidi.h in the midi.cpp file and that solves the problem.