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

[Josh J. <jj...@gm...>]

On Jul 24, 2017, at 2:27 PM, Brian J. Johnson via basilisk-devel <bas...@li...> wrote:

> That's a fairly good description of VOSF.

Thanks!  

> IIRC, BII keeps the emulated framebuffer RAM read-only

Ah, in that case taking a screenshot by reading framebuffer memory shouldn’t be a problem.

> That tends to be faster than comparing the entire framebuffer with a copy of the previous one, and than copying the entire framebuffer on each frame.

I’m working on a Mac OS emulator, Advanced Mac Substitute: <https://www.v68k.org/ams/>  The emulator memory-maps a disk file for a framebuffer to draw into, and actually displaying it is done by another program in a separate process.  The mmapped file contains an interprocess condition variable which is used for synchronization, allowing the display program to remain idle until the framebuffer is modified.

At the moment, there’s no optimization to exclude untouched screen regions during update.  The big performance win is batching multiple screen writes into a single update.  AMS doesn’t run Apple’s Mac OS, but a reimplementation of it, which knows how to call the emulator’s runtime library to lock the screen temporarily.  Not only does a primitive like FrameRect() draw atomically, but so does MoveWindow().

> Writing framebuffer memory to the screen is a somewhat expensive operation, due to the unusual framebuffer formats used by MacOS, and the desire to emulate low-color (1 to 8 bit) video modes on modern 24-bit display hardware.

AMS only supports monochrome graphics at the moment, so I can’t test the performance of different depths and configurations yet.  But I suspect transcoding a bitmap is a minuscule cost compared to getting it into a window on OS X.  On a Raspberry Pi, the display process transcodes and draws to the Linux framebuffer using a small fraction of the CPU used by the emulator, whereas on OS X the display system tends to use more CPU than the emulator (for relatively simple operations like byte-aligned CopyBits()).

> But it's been a *long* time since I messed with this code....  The performance tradeoffs may have changed in the interim.

If I were going to address macemu performance, I’d start with filesystem I/O, as that’s a major bottleneck for compiling.  Though first I’d fix the bug that makes extfs incompatible with MPW (since extfs is about an order of magnitude faster than using a disk image).

Josh