VOGONS


3 bugs in 0.72 on Mac OS X

Topic actions

First post, by r_wolfcastle

User metadata
Rank Newbie
Rank
Newbie

I hope this is the right place to report bugs; I searched and searched for a bug report form but couldn't find one.

First of all, kudos for 0.72!! I am able to run my much-beloved and missed larn, and the CPU tuning and such are fantastic!

Running Leopard (10.5.1) on a new Macbook Pro (Intel).

Problem #1) I am attempting to set the following in the config file [sdl] section:

priority=higher,pause

When I run DOSBox, it comes up paused even though it is obviously the app with focus. Since there is no documented keystroke on Mac OS X to un-pause it (see the second bug below), it is stuck there.

HOWEVER, if I remove focus by switching to another app or minimizing DOSBox and then return focus to DOSBox, and do that *twice*, then it magically becomes un-paused, and from then on it correctly pauses and unpauses on de-focus/focus exactly as advertised. This is 100% repeatable, and I backed out all my other changes to verify that this change to the conf file, and this change alone, causes the problem.

Another clue: If I start with the default conf file and make this change, then the first time I de-focus and re-focus on DOSBox, it appears visually that nothing at all has happened. But if I also include this change to the conf file:

windowresolution=1024x640

then DOSBox initially comes up paused and original size. After I de-focus and re-focus once, DOSBox resizes to 1024x640, but then becomes PAUSED again without showing the welcome text, BLASTER setting, etc. It is only after the second time that I de-focus and re-focus that it fully comes up, and also executes any extra commands I may have added at the end of the conf file.

Problem #2) INTRO documents the key to pause the game (and presumably it is a toggle to un-pause it as well) as ALT-PAUSE. There is no such key on the Mac; I assume this is a reference to the PC's pause/break key. I decided I'd try to set it to something else, but...

Problem #3) CTRL-F1 does not appear to start the keymapper as advertised. Perhaps this functionality has not yet been ported to OS X.

I have an obvious workaround for problem #1, and #2 and #3 are really of no consequence to me, but I thought I'd report them for completeness.[/img]

Reply 1 of 23, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

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

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 2 of 23, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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 😉

Reply 3 of 23, by IIGS_User

User metadata
Rank Oldbie
Rank
Oldbie
`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:

Attachments

  • keym.png
    Filename
    keym.png
    File size
    13.09 KiB
    Views
    2733 views
    File comment
    Keymapper
    File license
    Fair use/fair dealing exception

Klimawandel.

Reply 5 of 23, by r_wolfcastle

User metadata
Rank Newbie
Rank
Newbie
`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.

Reply 6 of 23, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

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.

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 7 of 23, by r_wolfcastle

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 8 of 23, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 9 of 23, by r_wolfcastle

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 10 of 23, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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:

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

this code does the 500 ms flush

                                        SDL_Delay(500);
while (SDL_PollEvent(&ev)) {
// flush event queue.
}

Water flows down the stream
How to ask questions the smart way!

Reply 11 of 23, by darkgamorck

User metadata
Rank Member
Rank
Member

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.

Reply 12 of 23, by darkgamorck

User metadata
Rank Member
Rank
Member

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.

Reply 14 of 23, by darkgamorck

User metadata
Rank Member
Rank
Member

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

*** ./src/gui/sdlmain.cpp.orig	2008-01-16 15:17:15.000000000 -0500
--- ./src/gui/sdlmain.cpp 2008-02-07 07:20:16.000000000 -0500
***************
*** 1229,1247 ****
* regain window or input focus.
*/
bool paused = true;
SDL_Event ev;

GFX_SetTitle(-1,-1,true);
KEYBOARD_ClrBuffer();
SDL_Delay(500);
- while (SDL_PollEvent(&ev)) {
- // flush event queue.
- }

! while (paused) {
// WaitEvent waits for an event rather than polling, so CPU usage drops to zero
! SDL_WaitEvent(&ev);
!
switch (ev.type) {
case SDL_QUIT: throw(0); break; // a bit redundant at linux at least as the active events gets before the quit event.
case SDL_ACTIVEEVENT: // wait until we get window focus back
--- 1229,1251 ----
* regain window or input focus.
*/
bool paused = true;
+ bool waitmode = false;
SDL_Event ev;

GFX_SetTitle(-1,-1,true);
KEYBOARD_ClrBuffer();
SDL_Delay(500);

! while ((paused) || (!waitmode)) {
// WaitEvent waits for an event rather than polling, so CPU usage drops to zero
! if (!waitmode)
! {
! waitmode = (!SDL_PollEvent(&ev));
! }
! else
! {
! SDL_WaitEvent(&ev);
! }
switch (ev.type) {
case SDL_QUIT: throw(0); break; // a bit redundant at linux at least as the active events gets before the quit event.
case SDL_ACTIVEEVENT: // wait until we get window focus back
***************
*** 1249,1255 ****
// We've got focus back, so unpause and break out of the loop
if (ev.active.gain) {
paused = false;
! GFX_SetTitle(-1,-1,false);
}

/* Now poke a "release ALT" command into the keyboard buffer
--- 1253,1262 ----
// We've got focus back, so unpause and break out of the loop
if (ev.active.gain) {
paused = false;
Show last 22 lines
! 								}
! else
! {
! paused = true;
}

/* Now poke a "release ALT" command into the keyboard buffer
***************
*** 1262,1267 ****
--- 1269,1277 ----
break;
}
}
+ GFX_SetTitle(-1,-1,false);
+ KEYBOARD_AddKey(KBD_leftalt, false);
+ KEYBOARD_AddKey(KBD_rightalt, false);
}
}
break;


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.

Reply 15 of 23, by r_wolfcastle

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 17 of 23, by darkgamorck

User metadata
Rank Member
Rank
Member

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.

Reply 18 of 23, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 19 of 23, by darkgamorck

User metadata
Rank Member
Rank
Member

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.