Rather, use an address override prefix (0x67) though Intel Core optimization
reference guide says to avoid LCP prefixes. In practise, impact on performance
is measurably marginal on e.g. Speedometer tests.
Not quite the way I wanted to do it but it will do for now.
(on a real Mac, the real audio hardware should be able to pull/grab the data
from our buffers - an extra thread with its own set of buffers is wasteful!)
Not quite the way I wanted to do it but it will do for now.
(on a real Mac, the real audio hardware should be able to pull/grab the data
from our buffers - an extra thread with its own set of buffers is wasteful!)
- Don't export transfer types definitions (formerly used by older API)
- Handle ADD instructions in ix86_skip_instruction() (generated by icc 9.1)
- Use "%p" format for EIP/RIP addresses
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.
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.
- 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
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
them. So, if someone has BeOS and wants to give it a try, please change and
test this new code. Corner case could be a resume_thread() when emul_thread
is not suspended.
Fixlet to powerrom_cpu: call idle_resume() from TriggerInterrupt().
prefs items changes but it should now be simpler to add other ethernet
emulation means (slirp, tap-win32).
# Basilisk II driver mode
ether {guid}
becomes
ether b2ether
etherguid {guid}
# Basilisk II Router mode
routerenabled true
becomes
ether router
as BasiliskIIGUI.app, or /Applications/BasiliskII.app if none was found.
Also make yet another arrangement for MacOS X "difference". This scenario
was not working: WarningAlert -> ErrorAlert, the latter was not performed
because the exit status was not properly filled in sip->si_status...
- Rewrote dispatch loop to accomodate GTK+1.2 for MacOS X (which doesn't
like threads nor forks(!)). The latter also requires an additional patch
to the version 0.7 available on SourceForge
- Run-time detect JIT capability so that we could hopefully use the ppc GUI
on intel based Macs (check!)
STANDALONE_GUI. This is the second step towards a more interesting GUI alike
to VMware. Communication from/to the GUI is held by some lightweight RPC.
Note: The step should be enough to provide a tiny GTK GUI for MacOS X.
<http://lists.nongnu.org/archive/html/qemu-devel/2006-04/msg00245.html>
This does improve slirp performance a lot, especially in FTP passive mode
transfers. i.e. now, they are equally as fast as non passive mode. I get
approx. 800 KB/sec in B2 and 500 KB/sec in SheepShaver (over a DSL line).
In native env, the max download data rate from my ISP is around 950 KB/sec.
