From: David L. <dl...@po...> - 2017-07-23 00:30:57
|
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 > > |