So the Cocoa now records the mainscreent Rect, and only exits full screen mode if it has changed.This problem was reported by Tim. Forsafety Mini vMac automatically leaves full screen mode if it noticesthe screen size has changed, implemented in the Cocoa port bylooking for the notification applicationDidChangeScreenParameters.But recent OS X gives this notification on entering Full Screenmode, when it didn’t used to. *In the Cocoa port, entering Full Screen should now work inrecent versions of OS X, instead of immediately exiting. With a number of bug fixes it all worked. Which exercises all the newboundary checking code. *There is now some testing code that scrambles the mapping betweenemulated memory (for RAM and ROM) and real memory, splittingit into two sets of interleaved blocks (in effect togglingone bit of the address). This bug is fixed by keeping low and high limits forthe instruction pointer, and checking against them as the pointer ischanged. And not just in theory, I haveseen this happen in programs running in Mini vMac that weremalfunctioning.
But it is in theorypossible to write code so that the pointer to the next instruction getsset to arbitrary memory that the operating system may not allow MinivMac to access, resulting in a crash. This is goodenough for all known correctly working software. Only for certain long branches would Mini vMac workout from scratch where the instruction is in real memory. But for speed,fetching the next instruction would simply increment a pointer to wherethe instruction is in real memory, and relative branches would justoffset this pointer. Since this is only a bad read,I don’t think any further harm was possible besides crashing Mini vMac.Most kinds of memory access emulated by Mini vMac have for a quite whilebeen designed to always be accurate and safe. *A badly behaved program could cause Mini vMac to crash, attempting tofetch an emulated instruction from random memory, which memoryprotection on a modern computer prevents. So now thenon debug version of Mini vMac will display a number, whichdoesn’t take much code, so at least something can be learned. But this ideadoesn’t work out so well if the problem can’t bereproduced, and seems to happen randomly and rarely. Then the same thing can be done on a copyof Mini vMac with debugging stuff enabled. The original idea wasthat if something unexpected happens, you should first figure out howto reproduce the problem. *If Mini vMac reports an “Abnormal Situation”, it nowalso displays a 4 digit hexadecimal number. So Mini vMac should be muchfaster for variations where the old assembly code could not be used.Also, the x86-64 version is now faster than the old x86-32 assembly,and so is now preferred on machines that can run both x86-64 and x86-32.(On OS X, various bug fixes should make the Cocoa port now work aswell as Carbon port, which wasn’t available on x86-64.)The C code is tweaked for a specific version of the GCC compiler.While other compilers are still supported, they can result insignificantly slower emulation. (And also Macintosh II emulation should be faster.)The C version of the 680x0 CPU emulation was optimized tobe about as fast as the previous assembly code (that was onlyimplemented for 68000 emulation on PowerPC and x86-32), and thenthe assembly code was removed.
*Mini vMac should be faster on machines that aren’t PowerPC orx86-32.
0 kommentar(er)
