Menu
▾
▴
Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?
|
From: Brian J. J. <bjj...@ya...> - 2017-07-24 18:27:26
|
That's a fairly good description of VOSF. IIRC, BII keeps the emulated framebuffer RAM read-only, until it gets a SEGV due to the emulated CPU writing into it. Then it unlocks that particular page, makes a record of it, and resumes execution. When it's time to do a screen update, BII knows that only the pages it has unlocked could have changed from the previous frame, so it only needs to write those pages to the screen. 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. After updating the screen, BII locks the emulated framebuffer RAM again, so new writes will be caught. 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. But it's been a *long* time since I messed with this code.... The performance tradeoffs may have changed in the interim. Brian J. Johnson On Saturday, July 22, 2017, 3:46:21 PM CDT, 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ basilisk-devel mailing list bas...@li... https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
