What has changed in Mini vMac 3.1.3, compared to Mini vMac 3.0.4. 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
* If Mini vMac, on Mac OS X or Windows, doesn't find the ROM file in the folder containing the application, it will now also look in a specific central location. In OS X it checks in "/Users/[your_UserName]/Library/Preferences/Gryphel/mnvm_rom/". In Windows XP, "C:\Documents and Settings\[your_UserName]\Application Data\Gryphel\mnvm_rom\". Windows 98, "C:\WINDOWS\Application Data\Gryphel\mnvm_rom\". And in Vista, I think "C:\Users\[your_UserName]\AppData\Roaming\Gryphel\mnvm_rom\". Usually "mnvm_rom" would be an alias (on OS X, on Windows this is called a short cut) to where ever you keep your ROM collection. This avoids having to create an alias to the ROM image for each emulated Mac you use.
Changed behavior in default compile
* The alternate CPU emulation of Mini vMac 3.0.4 is now the main and only emulation. (The “-alt-cpu” build option is gone.) This makes Mini vMac slightly faster, and allows more accurate detection of illegal instructions without speed penalty. It also reduces the amount of code to be optimized in assembly language (Currently only done for PowerPC). The PowerPC assembly code version has been revised to match the new emulation, and is now used for the PowerPC Linux version.
* More accurate mouse and keyboard event handling, by using an event queue to communicate between the platform dependent code and the platform independent code. Previously, the platform dependent code would tell the platform independent code every emulated sixtieth of a second the current mouse position and up/down state of the mouse button and keys. If the host computer was very busy, or just slow, then a down and up pair could end up being processed in the same emulated sixtieth, and they would cancel each other out and be lost entirely. Also a mouse button state change might not be processed until well after it happened, and the mouse position might be different by then. (Though if Mini vMac is not getting time every sixtieth of a second, so that these problems can be observed, then sound emulation isn't likely to work either, emitting horrible noises. But it is possible to compile Mini vMac without sound. And also if the host computer is a device without a keyboard, such as using handwriting recognition, then there might not be separate key down and key up.)
* The Macintosh and Windows versions now match the X version in not initially filling the sound buffer with silence, but instead waiting to accumulate real sound samples before starting to play sound. This may reduce the tendency to stutter as the program starts, mostly by giving the emulation more time to get settled into a regular rhythm before attempting sound. I also changed the X version to match the Macintosh and Windows version in only skipping a single sound block on underrun, rather than stop playing sound until the buffer is refilled.
* Includes code sent by Jesús A. Álvarez ("zydeco") from his iPhone/iPod Touch port that improves support for the Disk Copy 4.2 disk image format, using information found in the Lisa Emulator Project by Ray A. Arachelian. Mini vMac will now get the correct size of the data in a Disk Copy 4.2 disk image, and will identify such an image even if it is not in HFS or MFS format.
* When Mini vMac is in full screen mode, it tries to send all key events to the emulated computer, instead of any normal meanings they would have in the host operating system. But I've decided that it went too far with this. So now in OS X, in full screen mode, it will no longer disable force quit (command-option-escape). This was just too dangerous, especially during development of Mini vMac. You can still send command-option-escape to the emulated computer, using the F1 and F2 keys, which are mapped to 'option' and 'command'.
* The X version now uses mouse motion events when possible instead of XQueryPointer, which is alleged to be inefficient. (Especially if the program is using the display on another computer, so that XQueryPointer requires a round trip over the network. I've never tried this. I don't know if anyone has.)
* Thanks to a tip from William Nolan, Mini vMac now has, when accessing the emulated computer's memory, a special case for little endian processors that allow unaligned access (such Intel), similar to the existing special case for big endian (such as PowerPC). This makes it a bit faster.
* I've made a number of small changes to the replacement disk driver that I think make it act closer to original Apple versions. (But which don't make any known observable difference.)
* None Yet.
New features not in default compile
* Support for the new Mini vMac Variations service.
* You can choose the emulated screen size (“-hres and -vres”).
* There is an initial port to GTK+. However, this port isn't complete yet. It will allow the Linux version to better match the other ports, with menus and an open file dialog. It also will make possible a port to Maemo, which is based on Gtk. The build option is “-t lx86 -api gtk”. (The build system now optionally allows you to choose what API to use, instead of automatically setting it from the selected target.)
* Can now use a Macintosh Classic ROM, thanks to assistance from David Sibley and "Gord". The build option is -m Classic”. Though it runs, it is not necessarily an accurate emulation of a Mac Classic. A Mac Classic is supposed to be nearly identical to a Mac SE, but there are a few minor differences. There may be more differences that I don't know about. I can't really work on this much further until I own a Mac Classic. Getting the Mac Classic emulation to work to this extent involved fixing some issues in the emulation of the VIA chip.
One thing to be aware of is that the Mac Classic ROM should be 512K. Apparently some ROM acquisition programs only save the first 256K. The CopyRoms program should save the correct size.
* Can now use a Macintosh SE FDHD ROM, thanks to assistance from Steve Secker and David Sibley. The build option is -m SEFDHD”. It is currently identical to the Macintosh SE emulation, except for expecting a different ROM (which should be named 'SEFDHD.ROM').
* Have begun emulation of the Macintosh II. The build option is -m II”. It doesn't yet emulate the FPU or ASC, but some software will still run. Since a Macintosh II can be hard to find there is also a build option -m IIx” which accepts the ROM from a IIx, but otherwise currently is identical to the Mac II emulation. The Macintosh IIcx, the Macintosh II FDHD, and the Macintosh SE/30 all have the same ROM as the Macintosh IIx.
* You can choose the emulated screen color depth (“-depth”) in the Macintosh II emulation.
* With the build system option “-sony-sum 1”, Mini vMac will update the checksum in a Disk Copy 4.2 disk image when it is unmounted. This prevents other programs that deal with such images from complaining about an invalid checksum. (I didn't include this by default, because it makes Mini vMac slightly bigger and slower.)
* With the build system option “-sony-tag 1”, Mini vMac tries to support file tags. There are an additional 12 bytes for each 512 byte block on a 400K or 800K floppy disk, containing some additional information that was supposed to aid in recovering damaged disks, but was never actually used much. The Disk Copy 4.2 disk image format can support these tags. (The more usual raw format, such as found in Blanks, does not.)
* The build system option “-sony-dc42 0” completely disables support for disk images in disk copy 4.2 format. This could be useful when trying to compile the smallest and simplest version of Mini vMac possible for some specific purpose. It should not be used when compiling a version of Mini vMac for general distribution, because a primary goal of Mini vMac is that disk images that work with any past version of the program should also work with the current and any future version (at least when default compile options are used).
* There is now a build system option “-vsync 1” for OS X only, which turns on OpenGL double buffering and sets AGL_SWAP_INTERVAL to 1. This eliminates the "tearing" issues noted Manuel Alfayate. Unfortunately it isn't yet a real solution. Beside using much more memory, it also reduces the maximum speed of emulation unpredictably and erratically, because it makes aglSwapBuffers block until the vertical retrace, when Mini vMac is expecting to give the emulation extra time, for above "1x" speed. Anyway it helps to illustrate the issue. Now that I've seen what it looks like with vsync, I can see the difference in certain games.
Changed behavior not in default compile
* There are some refinements to the “Alternate Keyboard Mode”. Typing ';' now locks the mode on, there is no temporary state. (I found holding ';' while typing other keys too much strain.) Typing 'm' now leaves the mode. (I find 'm' slightly easier to hit than 'u', and it is no longer needed for entering the mode.) The 'shift' and 'option' keys now override the mode like the 'command' key does. (So anything except lowercase letters can be typed without leaving the mode.) When compiled with the Alternate Keyboard Mode, Mini vMac now starts up with the mode on rather than off. (I think I've reinvented what I've read about the vi editor. You are normally in command mode, and only use insert mode temporarily.) A number of the mappings are changed: 'a' - semicolon, 'b' - backslash, 'e' - backspace, 'h' - equal, 'n' - minus, 'o' - ], 'r' - return, 't' - tab, 'u' - [, and 'p' and 'w' are now not used.
* The “Alternate Keyboard Mode” option now gives a visual indication of the current keyboard mode, intended to be easy to see in peripheral vision, without covering up where text is normally typed.
* The Macintosh SE emulation, in full screen mode, will now emulate the ADB protocol for mouse movement, instead of just poking the changes into emulated low memory. This turned up a bug where apparently emulated ADB devices were responding to commands too quickly, before the emulated Mac was ready. I increased the constant that specifies the delay.
Bug fixes not in default compile
* Two bug fixes in the 68020 emulation, in distinguishing between long DIV and MUL, and in bit field operations with width of 32.
* The build system now has a separate argument for the memory size of the emulated machine (“-mem”), instead of including this in the model (“-m”).
* The build system now supports Xcode 3.1, using the option “-ev 3100”. Mini vMac compiles without warnings, which wasn't possible with the SDK that comes with Xcode 2.4.1.
* The build system now supports Microsoft Visual Studio 2008 Express, using “-t wx86 -ev 9000”.
* The build system supports compiling the Pocket PC version with Microsoft Embedded Visual C++ 4 for ARM and the emulator (“-t wcar” and “-t wc86”).
* The build system supports using the command line tools of the LCC compiler (“-e lcc -cl”).
* The build system supports the Sun c compiler (“-e snc”).
* The build system now has an “-an” option, for changing the programs abbreviated name, from the default "minivmac". So the Mini vMac variations are compiled with say "-an mnvm0001", instead of "-n mnvm0001-3.1.0-umch". The abbreviated name must be 8 characters or less, and should only include lowercase letters, numbers, and underscores.
* The build system will now check if the folder "System Folder:Preferences:Gryphel:Build:output" exists, and if so direct output there, instead of "minivmac:output:". This is useful if you keep the minivmac source disk image on a flash drive, avoiding excessive wear.
* The build system can now resolve aliases of folders, such as the output preference folder. So the output can be directed anywhere, such as to another disk.
* The build system can now handle multiple sets of options at once, separated by ";". I use this in the process of compiling the set of Mini vMac Variations. To allow this to work, the build system no longer replaces the entire output folder on each run, but just replaces folders within the output folder.
* I've removed the "-pk" option of the build system to restrict the program to a more manageable scope. And anyway I find it more convenient to handle post processing in external scripts.
:
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