if you have changed the depth since boot (seems to be something strange
with the parameters that I still haven't worked out). If this happens,
we now put a suggested workaround in the warning message.
68k or MacOS code, so they don't need to be a termination point. i.e. don't
split into two basic blocks and thus avoid a full hash search.
Also add missing NQD_unknown_hook NativeOp from previous commit.
This reduces the number of Screen_fault_handler() calls by 80%. i.e. VOSF
is now viable on this turtle MacOS X. Besides, since there is no buffer
comparison, idle sleep can really be effective. SheepShaver in idle mode
on my PBG4 now goes below 8% of CPU resources instead of 70-80% with
bounding boxes based video refreshes.
Caveat: if your program doesn't use standard MacOS routines that call NQD,
then you can expect slower (visual) performance. However, I do think the
new default behavior (VOSF+NQD) is the most common.
This does not improve graphics performance but helps CPU because it reduces
the number of bytes transfered to actual screen. I saw an improvement by up
to 26% in frameskip 4 800x600x16 but also a hit by 3% with frameskip 0.
The next step is to use NQD bounding boxes to help detecting dirty areas.
So far, this is the best I can do without VOSF working (MacOS X performance
bugs -- pitifully slow Mach syscalls)
- Properly handle migration from "screenmodes" and "windowmodes" to "screen"
- Fix has_mode() logic to really test for actual mode availability. i.e.
no longer start in large screen mode if user specified a max size.
SheepShaver since we are typically translating SDL_QUIT events to PowerOff()
on MacOS side. And, if MacOS is not fully booted, it's not really convenient
to shut it down, even with ctrl-C. i.e. you had to kill -9 it.
- Call user handler for KERN_INVALID_ADDRESS too (SIGBUS)
- Check for VALID_THREAD_STATE_FLAVOR in forward_exception()
- Return KERN_FAILURE if forward_exception() got an unknown behavior code
OpenFirmware check for OldWorld 604-based machines?
XXX I have code pending that makes it possible to use PowerMac ID #3035 and
model 510 (PowerMac G3 Series). However, I have a regression with one of my
MacOS 8.6 disks. This is non-standard anyway since it was installed from the
iMac DV 8.6 discs ("yellow" not generic) with MOL -- SheepShaver can't cope
with it.
So I am not surprised it breaks. Otherwise, 8.5 -> 9.0.4 were fine with it.
BTW, the "regression" is Native Resource Manager is not installed and the
boot gets mad later. FWIW, it's the same as for MacOS 9.1. A resource is
very likely not loaded.
Other bugs fixed:
- CD-ROM media are polled and now can be changed without rebooting
- Buffer overflow, memory leak and extra wait in CD-ROM ejection code
1 GB of Mac memory. Only tested on Linux/x86_64 so far but with a somewhat
interesting (MacOS, ROM, RAM size) matrix.
XXX: It should be possible to allocate up to 1.5 GB by relocating the ROM
base to something like 0x60800000.
- 'boot' 3: set boot stack pointer only once at the correct place
- 'gpch' 750: fix FE0A opcode replacement (selector #$0a is virt2phys on pgidx)
- 'gpch' 750: remove bogus patch for SonyVars
- Mark patches "9.0" verified accordingly vs. 8.6
be useful to fix a bug in the AppleShare extension (see DRVR .AFPTranslator
in Basilisk II)
Unrelated improvement: call sheepshaver_cpu::get_resource() directly, don't
get it through another global function.