What has changed in Mini vMac 3.5.0, compared to Mini vMac 3.4.1. This only lists changes that affect behavior, and so doesn't include cleanups of the source code.
not in default compile:
New features in default compile
* 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). 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 in default compile
* None Yet.
Bug fixes in default compile
* 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 have 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 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”.
New features not in default compile
* 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.)
* A new build system option “-lang ptb” selects a Brazilian Portuguese translation of the user interface by Mauricio.
* 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.
* 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”.
Changed behavior not in default compile
* In the Macintosh II emulation, when compiled with color (color depth not black and white), 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).
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.) And also more abnormal reports and debug logging have been put in this code.
* 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 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, and assembly language.
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