jmarsh wrote on 2020-11-28, 22:43:

The vm_remap call is only required on macos because it pretty much disallows mmap'ing anything (shared memory, tempfile, etc.) as executable, and that is the *nix portable way to map the same memory space at two different locations.
Shared memory doesn't work because apple mounts it with no-exec (and several linuxes are doing the same).

ChromeOS solves it another way.
https://chromium.googlesource.com/chromiumos/ … e15cfe8a74a406e

latalante wrote on 2020-11-28, 23:55:

ChromeOS solves it another way.
https://chromium.googlesource.com/chromiumos/ … e15cfe8a74a406e

Unless I'm overlooking something they are skipping over a much simpler solution: linux has memfd_create to associate an fd with memory, avoiding the shmem/tmpfile requirement.

(Maybe a mod could move the dynrec vs. w^x discussion to the other thread? I created it specifically for discussions like this...)

jmarsh wrote on 2020-11-29, 03:53:

latalante wrote on 2020-11-28, 23:55:

ChromeOS solves it another way.
https://chromium.googlesource.com/chromiumos/ … e15cfe8a74a406e

Unless I'm overlooking something they are skipping over a much simpler solution: linux has memfd_create to associate an fd with memory, avoiding the shmem/tmpfile requirement.

(Maybe a mod could move the dynrec vs. w^x discussion to the other thread? I created it specifically for discussions like this...)

That's what I thought: Linux had a more direct interface to allocate shared memory objects to a file descriptor. I'm told you can also send that file descriptor over a socket, and you can "seal" the memfd as read-only and against further modifications so the recipient can't go scribble on it. Pretty interesting stuff. No /dev/shm required.

As for Mac OS X, I see Apple lists vm_remap in their typical style of absolutely terrible documentation.

https://developer.apple.com/documentation/ker … ap?language=occ

They're worse than early 1990s Microsoft documentation. At least Microsoft attempted to describe what the function does and what the parameters mean.

Here, Apple is like "here's the declaration from the header files, we don't feel like describing the function parameters, return value, or even what the hell they mean or how you get your own vm process map. You figure it out, we don't care." If I have to go to some web page on MIT's website to actually read about the function, and comb through the "open source Darwin" part of Apple's site to try to understand it, then you completely suck at your job, Apple Development website. And yet, nobody describes how the hell you get your own VM map handle whatever-the-hell-it-is for yourself so you can use it.

TheGreatCodeholio wrote on 2020-11-29, 04:29:

And yet, nobody describes how the hell you get your own VM map handle whatever-the-hell-it-is for yourself so you can use it.

It's designed to map memory from one task (process) into another (possibly different) task. The vm_map_t arguments refer to the source and target tasks. We want the source and target to both be the current task, obtainable using mach_task_self().

(vm_map_t is a typedef of mach_port_t.)

jmarsh wrote on 2020-11-29, 04:46:

TheGreatCodeholio wrote on 2020-11-29, 04:29:

And yet, nobody describes how the hell you get your own VM map handle whatever-the-hell-it-is for yourself so you can use it.

It's designed to map memory from one task (process) into another (possibly different) task. The vm_map_t arguments refer to the source and target tasks. We want the source and target to both be the current task, obtainable using mach_task_self().

(vm_map_t is a typedef of mach_port_t.)

That's the thing... where did you find out about mach_task_self()? I couldn't find anything about that. The most useful resource I could find was the MIT site that described what it *does*, the next problem was *how do you refer to your own task*. Neither that site, nor Apple's, nor anyone else on the web bothered to describe how you get that.

TheGreatCodeholio wrote on 2020-11-29, 05:04:

That's the thing... where did you find out about mach_task_self()? I couldn't find anything about that. The most useful resource I could find was the MIT site that described what it *does*, the next problem was *how do you refer to your own task*. Neither that site, nor Apple's, nor anyone else on the web bothered to describe how you get that.

Like all the best OS documentation, I found it in a BlackHat presentation slideset (page 10).
Macos stuff loves to use different typedefs for every different function, you can figure out most of what talks to what just by matching the types.
I think it's some misguided attempt at future-proofing, so they can redefine a function's arguments at any point and still say "The function signature hasn't changed, you were just using it wrong before."

I'm playing Tex Murphy 2 from GOG and the mouse cursor is constantly flickering which drives me mad. I tried different output modes and switching to DOSBox X but the issue prevails, any ideas?

Arthandas wrote on 2020-11-30, 15:25:

I'm playing Tex Murphy 2 from GOG and the mouse cursor is constantly flickering which drives me mad. I tried different output modes and switching to DOSBox X but the issue prevails, any ideas?

Try turning down the cycle count. If that helps, you can also try using the cycle count you want and setting a vmemdelay. Try vmemdelay=250 or vmemdelay=400.

Some games, like Corncob 3D and Catacombs, make assumptions about video RAM speed. If they're wrong, things flicker.

TheGreatCodeholio wrote on 2020-11-30, 15:59:

Try turning down the cycle count. If that helps, you can also try using the cycle count you want and setting a vmemdelay. Try vmemdelay=250 or vmemdelay=400.

Neither lowering the cycles or setting vmemdelay has any effect, it flickers just the same even with 500 cycles. So far the only thing that has any effect on flickering is the surface output mode which reduces it (it still flickers, just less).

Arthandas wrote on 2020-11-30, 17:19:

TheGreatCodeholio wrote on 2020-11-30, 15:59:

Try turning down the cycle count. If that helps, you can also try using the cycle count you want and setting a vmemdelay. Try vmemdelay=250 or vmemdelay=400.

Neither lowering the cycles or setting vmemdelay has any effect, it flickers just the same even with 500 cycles. So far the only thing that has any effect on flickering is the surface output mode which reduces it (it still flickers, just less).

Does it flicker in DOSBox SVN, but less noticeably?

The game might be foolishly redrawing the cursor constantly anyway. However SVN does not render line-by-line as DOSBox-X does. SVN renders the screen in quarters, which can help hide that kind of artifact. Another way to check that is to try running it in DOSBox SVN with machine=vgaonly, which is the only mode SVN allows the line-by-line rendering that DOSBox-X uses.

TheGreatCodeholio wrote on 2020-11-30, 17:29:

Does it flicker in DOSBox SVN, but less noticeably?

Nope, it flickers just the same even with machine=vgaonly. I attached a clip showing how it looks.

I suspect that's just the game's management of the cursor: it needs to hide and show the cursor because the fan is animating. Maybe?

According to you though, this is a problem in both DOSBox SVN and DOSBox-X (and probably any fork), which means it may just be accurate emulation of the game's behavior.

Anyone know if the cursor flickers like that on real hardware?

Arthandas wrote on 2020-11-30, 18:03:

..it flickers just the same even with machine=vgaonly.

May test with output=surface and machine=vesa_oldvbe in both dosbox SVN and -X. This assumes a Windows host for dosbox.

TheGreatCodeholio wrote on 2020-11-30, 19:21:

I suspect that's just the game's management of the cursor: it needs to hide and show the cursor because the fan is animating. Maybe?

I don't think that's it, the cursor flickers on static scenes too. If you move the cursor down to the action tabs, it changes to a different looking cursor and this one doesn't flicker at all, even in the scene with the fan.

Anyone know if the cursor flickers like that on real hardware?

I tried looking for some footage on YouTube but no luck.

Arthandas wrote on 2020-11-30, 19:43:

I don't think that's it, the cursor flickers on static scenes too. If you move the cursor down to the action tabs, it changes to […]
Show full quote

TheGreatCodeholio wrote on 2020-11-30, 19:21:

I suspect that's just the game's management of the cursor: it needs to hide and show the cursor because the fan is animating. Maybe?

I don't think that's it, the cursor flickers on static scenes too. If you move the cursor down to the action tabs, it changes to a different looking cursor and this one doesn't flicker at all, even in the scene with the fan.

Anyone know if the cursor flickers like that on real hardware?

I tried looking for some footage on YouTube but no luck.

Is it possible the GOG.COM copy has been patched in some way that affects the cursor? Do original copies of the game have this issue?

Could try today's commit:
https://sourceforge.net/p/dosbox/code-0/4393/

hail-to-the-ryzen wrote on 2020-11-30, 20:22:

Could try today's commit:
https://sourceforge.net/p/dosbox/code-0/4393/

I already did, I've been told to report this issue on dosbox staging github:
https://github.com/dosbox-staging/dosbox-staging/issues/739

I don't want to derail this thread:)

I tested further. It occurs in PCem with the S3 card, but the flicker is less as expected from dosbox surface output and vesa_* machine types.

Then I booted Win95 guest inside dosbox and ran it from a dos box. That showed flickering, too (in the game portion of the window). The evidence weighs toward that it is a real DOS issue, too, at least with a similar video card type.

hail-to-the-ryzen wrote on 2020-11-30, 20:47:

The evidence weighs toward that it is a real DOS issue, too, at least with a similar video card type.

Does it mean it can't be fixed?

Arthandas wrote on 2020-12-01, 01:09:

hail-to-the-ryzen wrote on 2020-11-30, 20:47:

The evidence weighs toward that it is a real DOS issue, too, at least with a similar video card type.

Does it mean it can't be fixed?

It means the game has a flickering cursor problem and both SVN and X are emulating the flicker problem as it would actually occur on real hardware.

If you like, you may consider using the debugger to pinpoint where the cursor draw code is being called, and patching the executable if that may help.