What has changed in Mini vMac 3.5.8, compared to Mini vMac 3.4.1. This only lists changes that affect behavior, and so doesn't include cleanups of the source code.
:
default compile:
not in default compile:
:
New features in default compile
* None Yet.
Changed behavior in default compile
* Mini vMac should be faster on machines that aren’t PowerPC or x86-32. (And also Macintosh II emulation should be faster.) The C version of the 680x0 CPU emulation was optimized to be about as fast as the previous assembly code (that was only implemented for 68000 emulation on PowerPC and x86-32), and then the assembly code was removed. So Mini vMac should be much faster 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 as well 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 in significantly slower emulation.
* If Mini vMac reports an “Abnormal Situation”, it now also displays a 4 digit hexadecimal number. The original idea was that if something unexpected happens, you should first figure out how to reproduce the problem. Then the same thing can be done on a copy of Mini vMac with debugging stuff enabled. But this idea doesn’t work out so well if the problem can’t be reproduced, and seems to happen randomly and rarely. So now the non debug version of Mini vMac will display a number, which doesn’t take much code, so at least something can be learned.
* A badly behaved program could cause Mini vMac to crash, attempting to fetch an emulated instruction from random memory, which memory protection on a modern computer prevents. 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 while been designed to always be accurate and safe. But for speed, fetching the next instruction would simply increment a pointer to where the instruction is in real memory, and relative branches would just offset this pointer. Only for certain long branches would Mini vMac work out from scratch where the instruction is in real memory. This is good enough for all known correctly working software. But it is in theory possible to write code so that the pointer to the next instruction gets set to arbitrary memory that the operating system may not allow Mini vMac to access, resulting in a crash. And not just in theory, I have seen this happen in programs running in Mini vMac that were malfunctioning. This bug is fixed by keeping low and high limits for the instruction pointer, and checking against them as the pointer is changed.
* There is now some testing code that scrambles the mapping between emulated memory (for RAM and ROM) and real memory, splitting it into two sets of interleaved blocks (in effect toggling one bit of the address). Which exercises all the new boundary checking code. With a number of bug fixes it all worked.
* In the Cocoa port, entering Full Screen should now work in recent versions of OS X, instead of immediately exiting. For safety Mini vMac automatically leaves full screen mode if it notices the screen size has changed, implemented in the Cocoa port by looking for the notification applicationDidChangeScreenParameters. But recent OS X gives this notification on entering Full Screen mode, when it didn’t used to. So the Cocoa now records the main screent Rect, and only exits full screen mode if it has changed. This problem was reported by Tim.
* The Cocoa port would draw incorrectly in full screen mode if the emulated screen is larger than real screen.
* There is a fix for drag and drop in the Cocoa port. When Mini vMac becomes the active application, all emulated key are usually considered to be up, even if the actual keys are still being held down. But there is an exception for modifier keys held down on drag and drop (after which Mini vMac makes itself the active application), so that holding down command and option can be used to rebuild the desktop files of emulated disks. This exception worked in Carbon, but not previously in Cocoa. I’ve now figured out how to get the modifier keys, by using [NSEvent modifierFlags]. This only work in OS X 10.6 and later, so Mini vMac checks that this method is available before using it.
* In the Cocoa port, when Mini vMac is launched by dragging a disk onto the application icon, but there is also a disk1.dsk image, it now matches the behavior of other ports in mounting the dragged image after disk1.dsk instead of before.
* In the Cocoa port, when importing and exporting the text clipboard, Mini vMac was not translating the end of line format.
* In the Cocoa port, when importing the text clipboard, if there were any characters that could not be translated (because they are not in MacRoman), nothing would be translated. Now, such characters will translate to “?”.
* In the Cocoa port, when dragging the Mini vMac window around by its title bar, the emulated cursor position was incorrect. (The emulation continues running during the drag in this port.)
* In the Cocoa port, if the mouse is moved over the dock, the cursor is made visible by the operating system, but if the mouse was then moved directly back into the Mini vMac window (and there was nothing in between), the system cursor was not made invisible again, so the system cursor and the cursor of the emulated Macintosh were drawn on top of each other.
* In the Windows version of Mini vMac 3.4, the Mini vMac window is resizable. This happened when fixing a call to CreateWindowEx to stop using an invalid window style. The fix is now fixed by not including WS_THICKFRAME in the style.
* There have been reports of graphics problems in the Linux version, which is suspected to result from drawing images with one bit per pixel to the screen not being properly implemented in at least some versions of Linux, with at least some hardware. So Mini vMac will now always pass 32 bit per pixel images to the operating system (for Linux and other X versions), even for black and white images. This could potentially be much less efficient, so there is a new compile time option to behave as before, “-ci 0”.
* A C compiler is allowed to assume that two pointers of different types don’t point to the same memory location. But this assumption could break Mini vMac. So now for GCC 4.7.4 the option "-fno-strict-aliasing" is used to prevent this assumption, which appears to make no significant difference in speed. But for other compilers, Mini vMac will now try to work correctly even with this assumption (basically by taking out optimizations for big/little endian), which will slow it down a bit.
* The emulation of the CMPI instruction was considering pc relative addressing to be illegal, when it is actually fine (though odd). As reported by Adam, this broke Dynamix adventure games. This was in Macintosh II emulation, but the bug was also present in the default Macintosh Plus emulation.
* The emulation of the Move to SR instruction now checks for Privilege Violation.
New features not in default compile
* A new build system option “-lang ptb” selects a Brazilian Portuguese translation of the user interface by Mauricio.
* Normally, when in Full Screen Mode, Mini vMac will try to “grab” the keyboard, preventing the operating system from intercepting keys. So in the Windows version, the ‘windows’ key can be used as an ‘option’ key, instead of popping up the “Start” menu. And in the OS X version, Command-Tab won’t switch away from Mini vMac. This is also implemented in the X version. There is a new build option, -gkf 0”, that disables grabbing the keyboard, allowing the operating system to intercept keys when Mini vMac is in Full Screen Mode. This was requested by a maintainer for “Rocket Launcher”.
* Can now use a “Twiggy” Macintosh prototype ROM, after merging in work by Matěj Hybler. (There are two known disk images that will work with it.) The build option is -m Twiggy”. (This is not an officially supported option, advanced users can compile this version if they want to try it.)
* Can now also use an even earlier “Twiggy” Macintosh prototype ROM, merging in further work by Matěj Hybler. (The same two disk images will work with it.) The build option is -m Twig43”. (This is not an officially supported option, advanced users can compile this version if they want to try it.)
* The new option “-ahm” patches the ROM to replace the “Happy Mac” icon displayed on boot when a disk is inserted, with one of the images designed by Steve Chamberlin for his Mac ROM-inator (used with permission).
* The new option “-rsz” allows you to set the size that Mini vMac expects the ROM image to be. The build system will normally select the correct ROM Size for the Macintosh model you have chosen to emulate. But you can now override this, such as to use a ROM image for Steve Chamberlin’s Mac ROM-inator.
* The new option “-chr 0” prevents Mini vMac from checking the ROM checksum. The first 4 bytes of a Macintosh ROM contain a checksum of the remaining bytes, and there is code in the ROM to check the checksum on boot. Mini vMac patches the ROM image, so it disables this checking code. Mini vMac does the check itself before patching the ROM. It also checks that the 4 byte checksum matches one of the known ROM images for the model you have chosen to emulate. This option disables these checks, which is useful if you want to use Mini vMac with a modified ROM image, such as for Steve Chamberlin’s Mac ROM-inator.
* The new option “-drc 0” prevents Mini vMac from disabling code in ROM that checks the ROM checksum on boot. Since Mini vMac patches the ROM, it also patches out this check. If you are using a ROM image with Mini vMac that is already patched (such as for Steve Chamberlin’s Mac ROM-inator ), this check may already be patched out. In that case Mini vMac doesn’t need to, and probably shouldn’t, to avoid interference in case a different method of patching out is used.
* The new option “-drt 0” prevents Mini vMac from disabling code in ROM that tests proper operation of RAM at boot. Mini vMac normally patches the ROM to disable this test, to speed up booting. For greater realism, you can leave this test in.
* The port to SDL 2 now supports importing and exporting the host clipboard (like most other ports). It also supports the same “-d” and “-r” command line options as the X ports. And it now uses the function SDL_GetBasePath for the directory to look for the ROM image and the disk1.dsk, disk2.dsk, etc. images (and also the debug log file, when enabled). In the OS X version, in the "Info.plist" file it uses the key "SDL_FILESYSTEM_BASE_DIR_TYPE" with value "parent", so that Mini vMac will looking for these images in the folder containing Mini vMac, like in most other ports. It also now ignores command line arguments starting with “-psn”, which on OS X allows it to be launched by double clicking without getting an error message. (Previously it had to be launched with the command line.) Like other ports, there are now separate magnify states for when in full screen mode and when not. And when first entering full screen mode, the magnify state is set automatically depending on the screen size. A new feature only in the SDL port so far is that using the scroll wheel of the mouse acts as if arrow keys are pressed, giving roughly the expected behavior of a scroll wheel.
Changed behavior not in default compile
* In the Macintosh II emulation, when compiled with 256 colors or 16 colors or 4 colors, the initial value in the Parameter RAM is now set to boot in color. So the initial picture is in color. (Soon after, the color mode is changed to the value saved on disk.) This didn’t use to work, which is why it was previously set to boot in black and white. It seems to work now, for reasons not investigated yet (probably one of various fixes to video emulation). It still doesn’t work for thousands or millions of colors.
Bug fixes not in default compile
* The video driver in the Macintosh II emulation now implements indexed SetEntries. This is used by the game Crystal Quest (which by the way requires color depth to be 16 colors). Also for non-indexed SetEntries, the driver now returns the no error code. (Apparently this error code is not usually paid attention to.)
* Tara Keeling reported a bug in the Macintosh II emulation, where if the emulation was running slow enough (such as 1x speed), and there is a “disk1.disk” and “disk2.disk”, then the second disk image won’t get mounted. There is code to delay mounting the second disk one second after the first disk, which is good enough for Macintosh Plus emulation, but apparently not for the Macintosh II. So the delay has been increased to four seconds, but also now when a kDriveStatus call is made to the replacement disk driver, the delay is reduced (to about a fifteenth second). The emulated computer appears to be ready for a new disk after this call. (Not reducing the delay to zero is just being conservative.) So even for the default Macintosh Plus emulation, when inserting multiple disks there is now usually much less delay.
* In the built in disassembler ("-dis" option), the shift instructions L and R were reversed (such as for ASR and ASL).
* A problem may be fixed in the Macintosh II emulation, reported by Stephen Barbieri, caused by the FPU emulation not coping with invalid inputs.
* In the Macintosh II emulation, an “Abnormal Situation” report seen when using the Restart command of the Finder has been removed, since this actually seems to work fine now.
* The emulation of the Move from SR instruction now checks for Privilege Violation on 68020 (it is not a Privilege Violation on 68000).
* The build system has a new Development Environment option, Mini vMac C (“-e mvc”), which is really just a particular version of GCC and supporting projects, compiled into a set of cross compilers, that is used for official binaries. The advantage of using a single compiler version is in getting consistent performance across different operating systems. Also it easier to tweak C code to get good performance for a single compiler, than to try to make code that is optimum for all C compilers.
* The build system normally selects the source files needed to compile the requested variation. There is now an option to include all source files: -all-src 1”. To make this work, all source files now have unique names, rather than have multiple files with the same name in different folders in the source archive, for choices of API, sound API, language, icons.
* Support for assembly language is removed, including the option “-no-asm”.
* There is now an option to put generated configuration files into a separate directory from the source files: “-cfg 1”. This is only supported for “-e mvc”.
* The Export command would not overwrite an existing file (after the Standard Put File dialog asks if you want to replace it).
* The build system now supports Xcode 7.3.1 (with “-ev 7310”), and also 8.2.1 (“-ev 8210”). Though not tested, other versions of Xcode in between should also work, by constructing the “-ev” option in the same way.
* The build system now supports Microsoft Visual Studio 2017 (with “-ev 15000”).
:
If you find Mini vMac useful, please consider helping the Gryphel Project, of which it is a part.
Back up to - Changes in Mini vMac versions