Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

[David L. <dl...@po...>]

On Sat, Jul 22, 2017 at 4:46 PM, Josh Juran <jj...@gm...> wrote:

> On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:
>
> > I've been doing some work within the Basilisk II code, on Mac OS 10.12 +
> Xcode 8.x.
>
> This is great news.  I have a build that’s stable, but apparently only
> runs on 10.4 (unlike my SheepShaver build).
>

With a bit of work, and a bit of hacking, I was able to get Basilisk II
running, and booting System 7.5.x, in a 640x480 window.  The end result
does have some known bugs, and probably some unknown ones, but it does
build and run.

My work is up at https://github.com/davidludwig/macemu, if you, or anyone
else is interested.  The end result seems to run fine, on macOS Sierra, and
with Basilisk compiled as a 64-bit app.  Be sure to put a pre-compiled copy
of SDL.framework (aka. SDL 1.2.x) inside /Library/Frameworks/.  A copy can
be downloaded from https://libsdl.org/download-1.2.php (grab the Mac OS X
runtime library download, which includes SDL.framework, which includes
Header files and the like).


>
> > I've been able to get it compiling, and almost limping along, but have
> found some parts of the code to be a bit confusing.  In particular, I was
> wondering if there is a reason, or a need, for the app to try to capture
> SIGSEGV?
> >
> > On a similar note, I also noticed some "VOSF" code, which appears to
> deal with display code, on/after a segfault.  Might anyone has an idea what
> this is, or was for?
>
> VOSF is Video On Segmentation Fault.  My guess is that, rather than
> mapping the virtual screen into virtual RAM and copying it to the real
> screen on a timer (which is a waste of CPU and battery if nothing is
> happening), the emulator marks the virtual screen as inaccessible, so
> writes to it elicit SIGSEGV, and the signal handler implements the write
> and schedules a screen update.  The tradeoff is that this is more expensive
> when it does happen.  (Consider this all speculation on my part.)
>
> In practice, SheepShaver in VOSF mode will use noticeably less CPU if the
> insertion point isn’t blinking and the menu bar clock doesn’t display
> seconds, but CPU usage never drops below 4%.  Also, I notice that taking a
> screenshot (by reading the screen buffer from within Mac OS 9) is pretty
> slow.  Maybe non-VOSF is better at this, but I don’t have such a build to
> compare against at the moment.
>

I ended up ignoring+disabling VOSF, in my current work.

If the max CPU-use isn't much more or less than 4% without VOSF, I'd be a
bit inclined to consider removing that code.  It's implementation seems a
bit messy to me, possibly moreso than is worth it (I am unsure), but then
again, I am new to the Basilisk II code.

Cheers!
-- David L.

On Sat, Jul 22, 2017 at 4:46 PM, Josh Juran <jj...@gm...> wrote:

> On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:
>
> > I've been doing some work within the Basilisk II code, on Mac OS 10.12 +
> Xcode 8.x.
>
> This is great news.  I have a build that’s stable, but apparently only
> runs on 10.4 (unlike my SheepShaver build).
>
> > I've been able to get it compiling, and almost limping along, but have
> found some parts of the code to be a bit confusing.  In particular, I was
> wondering if there is a reason, or a need, for the app to try to capture
> SIGSEGV?
> >
> > On a similar note, I also noticed some "VOSF" code, which appears to
> deal with display code, on/after a segfault.  Might anyone has an idea what
> this is, or was for?
>
> VOSF is Video On Segmentation Fault.  My guess is that, rather than
> mapping the virtual screen into virtual RAM and copying it to the real
> screen on a timer (which is a waste of CPU and battery if nothing is
> happening), the emulator marks the virtual screen as inaccessible, so
> writes to it elicit SIGSEGV, and the signal handler implements the write
> and schedules a screen update.  The tradeoff is that this is more expensive
> when it does happen.  (Consider this all speculation on my part.)
>
> In practice, SheepShaver in VOSF mode will use noticeably less CPU if the
> insertion point isn’t blinking and the menu bar clock doesn’t display
> seconds, but CPU usage never drops below 4%.  Also, I notice that taking a
> screenshot (by reading the screen buffer from within Mac OS 9) is pretty
> slow.  Maybe non-VOSF is better at this, but I don’t have such a build to
> compare against at the moment.
>
> Josh
>
>