has moved to the Gryphel Project front page
(Follow the Gryphel Project on Twitter to be notified of the latest news. )
March 19, 2017
The latest Mini vMac Development source snapshot fixes one final known issue with the Cocoa port, and has a number of minor fixes for various development environments.
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. With this fix, as far as I know the Cocoa port is now as good as the Carbon port. So I can use the somewhat faster 64 bit version, which only is possible with Cocoa.
I’ve been testing with various development environments supported by Mini vMac, and made minor fixes for them. There is still more testing I want to do before moving the 3.5 development branch to beta. But no changes other than bug fixes are expected to be made.
March 12, 2017
The latest Mini vMac Development source snapshot adds support for Visual Studio 2017 (with “-ev 15000”) and has been tested with Apple Xcode 7.3.1 (“-ev 7310”) and 8.2.1 (“-ev 8210”). Basically only version information seems to have changed in the file formats.
The emulation of the Move to SR instruction now checks for Privilege Violation, and 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 should now correctly include all icon files with the “-all-src 1” option. And compiling the Windows CE version with “-e mvc” should work again.
Various compiler warnings and other small issues were also fixed. I expect to move the 3.5 development branch to beta soon, after further testing.
Thanks to Christopher Tar for the Gryphel project for sponsoring over a half month of web hosting.
March 5, 2017
In the latest Mini vMac Development source snapshot, for x86-32 versions, Mac II emulation is now even closer in performance to the Macintosh Plus emulation. Previously Mini vMac 3.5 used a non-standard stack alignment for Macintosh Plus emulation on x86-32, when compiled with GCC 4.7.4 (with the “-e mvc” option), which results in smaller and faster code. However, for OS X, any calls to external libraries could crash, and such calls can be generated by the compiler itself. For Macintosh II emulation, such a call is generated for 64 bit division, so previously the non standard alignment was not used. Now instead Mini vMac contains its own (not particularly good) implementation of 64 bit division, used for CPU architectures which don't directly provide it and the compiler would generate a library call. So the non-standard stack alignment can be used. To make it easy to detect if the compiler generates any other problematic calls, on OS X Mini vMac is now linked without the compiler libraries (for GCC 4.7.4).
Compiling with GCC 4.7.4 previously generated warning messages about “aliasing”. 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.
Also in this version, a bug is fixed in the Cocoa port, where it would draw incorrectly in full screen mode if the emulated screen is larger than real screen.
Also fixed is a bug in lazy evaluation of condition flags for the Tst instruction and similar.
February 26, 2017
In the latest Mini vMac Development source snapshot, the emulation of the coprocessor instructions (F line instructions) is reworked to not use the opcode, but instead only use the entry for the opcode in the OpDispatch table. So now the main emulation loop doesn’t need to save the opcode for Mac II emulation, helping to make it perform exactly as fast as Macintosh Plus emulation.
February 19, 2017
In the latest Mini vMac Development source snapshot, the emulation of the 68020 instructions is updated to not use the opcode, but instead only use the entry for the opcode in the OpDispatch table (as the 68000 instructions already do). The next step will be to do the same for F line instructions such as FPU calls. Then the only use of the opcode will be for that lookup, and so the opcode won’t need to be saved, in the most speed critical part of the program. This will help make the Mac II emulation perform exactly as fast as the Macintosh Plus emulation (where the opcode is already not saved).
Thanks to ClockWise for sponsoring over a day of health insurance costs for time I spend on the Gryphel project.
February 12, 2017
The latest Mini vMac Development source snapshot uses the “global register variable” feature of GCC 4.7.4 for the PowerPC and ARM versions (in addition to the x86-64 version added last week). Besides the 3 registers used for x86-64, the PowerPC and ARM versions also use a register to point to the 680x0 emulation variable record (as was done in the old PowerPC assembly language in Mini vMac 3.4.1).
The make file generated by the build system for GCC 4.7.4 (with the “-e mvc” option) now splits compiling C files into two parts, from C to assembly, and then from assembly to object file. Previously the assembly would be generated and then deleted by the single gcc compile command. So now the assembly is left around, making it easier to keep a close eye on what the compiler is doing.
Which helped to notice a major inefficiency in the ARM version, due to an alignment issue in the most speed critical part of the emulation. Fixing this doubled the speed. This problem didn't affect 3.4.1, but all the other optimizations make 3.5 about fify percent faster than 3.4.1 on ARM.
February 5, 2017
In the latest Mini vMac Development source snapshot I've experimented with the “global register variable” feature of GCC 4.7.4, in the x86-64 version of Mini vMac, to make better use of the 8 extra registers (as compared to x86-32). The compiler doesn't seem to generate very good code for this feature, but the result is still faster then when not using it. The x86-64 version of Mini vMac 3.5 is now 10 to 20 percent faster than the assembly language of Mini vMac 3.4.1 for x86-32 (there was no x86-64 assembly language).
January 29, 2017
The latest Mini vMac Development source snapshot has further work on the CPU emulation. The result of the ‘>>’ operator in the C language on signed values is implementation defined, so it can not always be directly used for the 680x0 ASR instruction. But in GCC 4.7.4, it is defined to do sign extension, so it can be used, and so now will be used for “-e mvc”. Also in today’s version, for both ASR and ASL, lazy evaluation of the condition code register is used.
And a bug is fixed in the built in disassembler (“-dis” option). For the shift instructions L and R were reversed (such as for ASR and ASL).
January 22, 2017
The latest Mini vMac Development source snapshot merges in a Brazilian Portuguese translation of the user interface by Mauricio.
This week I mostly have been looking into whether the Retro68 cross compiler could be used for the classic Mac ports of Mini vMac, but concluded probably not.
January 15, 2017
The latest Mini vMac Development source snapshot adds support for 3 more GCC 4.7.4 cross compilers I’ve built, targeting OpenIndiana on x86-32 and x86-64, and also Windows CE for ARM (using the CeGCC project). Also, the Mini vMac 3.5 Alpha Variations Service is updated to use them.
GCC 4.7.4 does not seem to support OpenBSD or Dragonfly BSD. And some random hacking on both didn't succeed in making a working Mini vMac. I may stop producing official Mini vMac binaries for these two for now. There has been little demand for them.
January 8, 2017
The latest Mini vMac Development source snapshot adds support for 5 more GCC 4.7.4 cross compilers I’ve built, targeting FreeBSD and NetBSD on x86-32 and x86-64, and also OS X for PowerPC. Also, the Mini vMac 3.5 Alpha Variations Service is updated to use them.
Code in the build system for using assembly language has been removed. (So options “-no-asm” and “-a” are gone.) Some other code in the build system, also not used now for Mini vMac, has been removed also. The icon files have been moved to the main source directory, and the “platform” directories are gone. There is a new build system option “-cfg 1”, only supported for “-e mvc”, that puts generated configuration files into a separate directory.
January 1, 2017
The latest Mini vMac Development source snapshot adds support for 5 more GCC 4.7.4 cross compilers I’ve built, targeting Linux on x86-32, x86-64, ARM, PowerPC, and Sparc. Also, the Mini vMac 3.5 Alpha Variations Service is updated to use them. Next I'll look at cross compilers for BSDs.
A problem in the Macintosh II emulation reported by Stephen Barbieri may be fixed in the development version. I think it was caused by the FPU emulation not coping with invalid inputs.
December 25, 2016
This week I have updated my scripts for the Mini vMac 3.5 Alpha Variations Service to use my new GCC 4.7.4 compilers for the OS X and Windows versions, for x86-32 and x86-64.
Mini vMac 3.5 uses C language only, and is a bit faster than the x86-32 assembly code of 3.4.1. It is much faster (like double) for variations where the assembly language code wasn’t used, like for Macintosh II emulation.
Also, the Alpha Variations Service now supports the x86-64 version for OS X (which uses the Cocoa API instead of Carbon). It is already a bit faster than the x86-32 version, and I think further improvement is possible.
Thanks to Stephen Barbieri and Anonymous for Christmas presents for the Gryphel project, sponsoring about 9 months of web hosting.
December 18, 2016
In the latest Mini vMac Development source snapshot, 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 will eventually be 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 C code for the CPU emulation on x86-32 using GCC 4.7.4 is now about as fast as the old hard to maintain and limited hand tweaked assembly language code.
Previously I had compiled from GCC 4.7.4 native compilers for OS X (x86-32 and x86-64). This week I followed the instructions for MinGW-w64, which worked perfectly to build cross compilers and supporting files for Window (x86-32 and x86-64). Next I can look into building cross compilers targeting Linux.
Some more software is now hosted by the Gryphel Project instead of only linked to: Manual Maker.
December 11, 2016
In the latest Mini vMac Development source snapshot, the build system is updated to produce more optimized compiles for Windows x86-32, Linux x86-32 and Linux x86-64, for the specific compiler versions I use. (As was previously done for OS X x86-32.) There is also some further fixes and tweaks to the CPU emulation code.
But it is unsatisfactory for Mini vMac to operate at different speeds on different operating systems because of using different C compilers (unlike in Mini vMac 3.4.1, where the same assembly language code is used). A possible solution is to use the same compiler, by making gcc cross-compilers. This may be easier said than done.
Some more software is now hosted by the Gryphel Project instead of only linked to: Manual Maker.
December 4, 2016
In the latest Mini vMac Development source snapshot, the build system is updated to allow compiling a version emulating a Macintosh Plus on OS X Intel (using C code for the CPU emulation) that is about as fast as in Mini vMac 3.4 (which has hand tuned assembly for CPU emulation), or compiling a version emulating a Macintosh II about as fast, whereas Mini vMac 3.4 is much slower emulating the Macintosh II (since there is no hand tuned assembly for the 68020 CPU). The build system only generates the special compiler options for the specific compiler version I use (and use for the Variations Service), since verifying that they work and work well for all possible versions of gcc would be extremely time consuming. For other compiler versions, with only the more generic options, it will work, but may not be quite as fast.
But most of the work this week was in further refinements of lazy evaluation of the condition code register, and in numerous other tweaks to improve the code generated by the compiler.
November 27, 2016
The latest Mini vMac Development source snapshot continues work on the C language version of CPU emulation.
With further refinement, the code using lazy evaluation of the condition code register is of similar speed on x86 to the code using immediate evaluation. So I have removed the immediate evaluation code, because I think lazy evaluation is a better match for the C language.
November 20, 2016
In the latest Mini vMac Development source snapshot, I've experimented with seeing how much faster I could make the C language version of the CPU emulation if I didn't worry about keeping the assembly language versions compatible.
The first particular change that made the assembly language incompatible was to the disp_table array set up by M68KITAB.c, merging the Address Mode and Argument Kind fields. So instead of the CPU emulation having one switch for decoding addresses, and a second switch for getting or setting, there is a single switch that decodes and gets, or decodes and sets. Making the code less compact, but faster. (That’s the basic idea, there are a few complications.)
The C version is now nearly as fast as the x86 assembly (with a particular compiler and compiler options). Of course the same changes could be made to both assembly language versions making them faster yet, but that would take a very long time. Instead I've removed the assembly language to allow faster progress.
So now Mini vMac is a bit slower on x86-32 and PowerPC, but on the other hand, it should be faster elsewhere. And the Macintosh II emulation should be faster. (The assembly language was for 68000 only.)
Some more software is now hosted by the Gryphel Project instead of only linked to: Address Notebook and eDoc.
Thanks to Donovan Preston for sponsoring almost 2 months of web hosting for the Gryphel project.
November 13, 2016
The latest Mini vMac Development source snapshot has a new build option to not grab the keyboard in Full Screen Mode.
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”.
Mostly, this week I was contemplating C compilers. On further testing, the GCC 4.7.4 C compiler I compiled last week produces a significantly slower Mini vMac than the much older version I having been using, and I haven't found any way to improve it. One particular problem is that it seems to be more conservative about “-mpreferred-stack-boundary=2”. So with the best compiler tried so far, at best the C language version is about two thirds as fast as the assembly language version, which I don't find satisfactory.
November 6, 2016
In the latest Mini vMac Development source snapshot, the C language version of 680x0 emulation is roughly 10 percent faster, at least with the old GCC compiler I develop with (from an old Xcode). Changing the command line arguments can get a bit faster yet. (The changed arguments are not yet in the Mini vMac build system.)
The motivation was that, last week as I was setting up to make changes to the PowerPC assembly language to match changes previously made to the C language and X86 language version of the 680x0 emulation, I had doubts whether it was good idea. Assembly language programming is fun, but slow. Keeping 3 versions of the 680x0 emulation in sync slows progress by more than a factor of 3. Eventually adding versions for ARM and x86-64 would make things worse. And adding support to the assembly language for 68020 for faster Mac II emulation doesn’t seem feasible.
The assembly language versions are barely twice as fast as the C version in Mini vMac 3.4.1. Perhaps with some further tweaking and using a more recent compiler, the C language version could be made almost as fast, and the assembly language could be removed, allowing faster progress.
Last week’s experiment with lazy flag evaluation wasn’t very successful, but this week an assortment of tweaks has made a significant difference. The main one is to use tables of function pointers rather than switch statements in a number of places. Another was to fiddle with the flag evaluation code. (Also there is now a more careful distinction between 0/1 and boolean variables. Previously Mini vMac wouldn’t work correctly if a compiler didn’t represent "true" as 1. I don’t know if it works now, I haven’t encountered such a compiler, but now it might.)
Also this week, I managed to compile GCC 4.7.4 (the final version implemented in C rather than C++) in OS X, using the GCC compiler in X code 4.1. It doesn’t immediately seem to result in a faster Mini vMac, but it has some additional options that could be useful. More interesting is the possibility of compiling cross-compilers.
A motivation for the assembly language was that anyone can compile Mini vMac with whatever compiler and get nearly identical performance, as the cpu emulation is the same. But with the Variations Service, I consider this less important now. I mostly only need to worry about the performance of the compilers that I use. This is further simplified if I mostly use one compiler, which can be compiled for many different targets, as GCC can. It is still important that Mini vMac can be compiled with any C compiler, the result just may not be as fast.
Some more software is now hosted by the Gryphel Project instead of only linked to: Network Calender and HappyPlusClock. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Birthdays and Such and EZCalendar.
October 30, 2016
The latest Mini vMac Development source snapshot has an experiment in “lazy evaluation” of the condition code register in the emulation of the 680x0. It can be enabled by setting HaveLazyFlags to 1 in “EM68KGEN.c” So far it doesn’t seem to demonstrate the hoped for benefits, but there is more to try.
Some more software is now hosted by the Gryphel Project instead of only linked to: Big Al Address Book. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: HQXer and PopAddress.
October 23, 2016
The latest Mini vMac Development source snapshot has a couple bug fixes in the x86 assembly language version of the CPU emulation, which makes it work properly with testing code that scrambles the mapping between emulated memory. So the new more careful boundary checking code may be working as intended. Next up is making the same changes to the PowerPC assembly language version of the CPU emulation.
I was traveling again this week, limiting time for Mini vMac. No further significant travel is planned until May.
Some more software is now hosted by the Gryphel Project instead of only linked to: yEnc TZ, MacLHA, and StUU. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: MacUnRAR.
October 16, 2016
The latest Mini vMac Development source snapshot finishes work improving instruction fetching in the x86 assembly language version of the CPU emulation, to match previous work in the C language version.
Then I wondered if this more careful code works as intended, so I wrote 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, using the C language implementation of the CPU, it all worked. But with the x86 assembly language version it doesn't, yet. There is more debugging to do.
A problem reported by Tim in the Cocoa version in OS X 10.11 may be fixed, where entering Full Screen mode didn’t work.
Some more software is now hosted by the Gryphel Project instead of only linked to: DoBinHex DropTool, DeBinHex DropTool, DeHQX, MacBinary II+, and Decode Apple File.
October 2, 2016
(No news is expected next week due to travel. Work should resume the week after.)
In the latest Mini vMac Development source snapshot I’m about half way through improving instruction fetching in the x86 assembly language version of the CPU emulation, to match previous work in the C language version (described two weeks ago). This first half has the most time critical parts, and so far there is no noticeable loss of speed, as accuracy and safety is improved. (There is no known corrrectly functioning software where this greater accuracy matters. But I would prefer that Mini vMac never crashes no matter what.)
Some more software is now hosted by the Gryphel Project where the original web pages have disappeared: ZipIt, CPT2SIT, and NoComment.
September 25, 2016
This past week I’ve worked on the website, making it more Mobile-Friendly, all several hundred pages of it.
The simpler part of this was to include on every page the magic
<meta name="viewport" content="width=device-width, initial-scale=1">
which makes mobile web browsers do what they should have done in the first place. But since many web pages aren’t designed for small screens, mobile broswers do some hacks to make such pages usable, and need to be told such hacks aren’t needed.
The bigger task to was remove any remaining multi column layout, getting rid of all the newfangled <table> tags (added to html mid 1990’s). Besides more Mobile-Friendly, it should also work better on the old web browsers that run on a Macintosh Plus, which also has a relatively small screen.
Some more software is now hosted by the Gryphel Project instead of only linked to: ClipStation, Fix Icons, MacTar, and MacGZip. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Clipboard Master and Coffee Break Lite. This one has a web page, but not with the old Mac version: PopChar Lite.
September 18, 2016
The latest Mini vMac Development source snapshot improves instruction fetching. A badly behaved program can 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 is 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. When fetching the next instruction, it only needs to check against the high limit. And the increment and check is done after the current instruction is fetched, and so it could be done in parallel with other things. A modern computer can do several things at once as long as they don’t interfere with each other. So it shouldn’t affect speed too much.
Actually, at first it slowed things down a lot. But then I figured out it was because the compiler I use for development messed up with the C inline directive. I figured out how to get the compiler to inline if and only if I tell it to, which gained back all speed lost, and a little bit more. So now the build system defined macros MayNotInline or MayInline are used for every function in Mini vMac.
The ability to turn off USE_POINTER and FastRelativeJump for greater accuracy is removed from the source code, since they are now always accurate and safe.
These changes have only been made in the C implementation of CPU emulation so far. The PowerPC and x86 assembly languages versions are to be fixed next.
The same thing has been done to the assembly language source as previously was done API, sound, and language sources. They have been given unique names and moved to the main source folder. (Which has been renamed from “c_src” to “src” since it is no longer just C.) Also, instead of the build system transforming the PowerPC code for MPW, there are two PowerPC versions, and some scripts (in the new file “trans”) to help keep them in sync. The idea being moved to is that the build system only generates configuration files, and the source folder is the source, basically the same in the source archive and when being compiled.
The motivation for working on the CPU emulation is that I would like to make assembly language versions for ARM and X86-64, but there are issues, such as today’s safe instruction fetching, that would be a lot easier to deal with first, before there are more versions to keep in sysnc.
Some more software is now hosted by the Gryphel Project instead of only linked to: Folder Icon Cleaner, PrefsCleaner, ClearRes, and Alias Crony. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: PowerPCheck, StripPPC, and DoDelete.
September 11, 2016
The latest Mini vMac Development source snapshot has some further work on the SDL 2.0 port. 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.
MiniUnZp has been updated to add a reasonable ‘SIZE’ resource so that it can operate with non trivial archives. Also it will now translate the Unicode file names written by OS X into the MacRoman character set. MiniUnZp is still extremely preliminary, but I find it useful.
Some more software is now hosted by the Gryphel Project instead of only linked to: QDvorak, Super Comments, Snapshotter, FCB Inspector, and Disk Charmer. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: MediaSizer and AppDisk.
Thanks to Donovan Preston for sponsoring over 3 months of web hosting for the Gryphel project.
In related news, John Sharp has been using Mini vMac to help with Bare-metal Macintosh Programming. One thing to be aware of is that Mini vMac in general does not attempt to be a complete emulation of the Macintosh hardware, but only emulates the parts of it that are used by Macintosh software. Often, but not always, it will give warning when the software attempts something that hasn't been implemented. But even with this limitation, it seems that Mini vMac is of some use for this project.
September 4, 2016
The latest Mini vMac Development source snapshot has some further work on the SDL 2.0 port. Like most other ports, it can now use the ROM image at a central location, looking in a folder named “mnvm_rom” in the folder that SDL_GetPrefPath returns. What SDL_GetPrefPath returns depends on the platform, on OS X it returns “~/Library/Application Support/gryphel/minivmac”. (Not that SDL for OS X really matters for Mini vMac, since a native port already exists. All the work with SDL is to help port Mini vMac to new platforms.)
Also added to the SDL 2.0 port is the option to let SDL handle scaling (for drawing in Magnify Mode), rather than code in Mini vMac. So whichever version works better can be chosen when using the SDL port to make a more native port of Mini vMac for a particular platform.
Recently I had allowed the Macintosh II emulation to boot in color, since it seemed to work now. But now I found that this may not work for color depths of thousands or millions, and so disabled it again in those cases. This only affects booting, soon after the color mode is changed to the value saved on disk.
The Mini vMac build system has been updated to match source shared with the Mini vMac extras. One (obscure) bug fixed by this is where the Export command would not overwrite an existing file (after the Standard Put File dialog asks if you want to replace it).
There is a new version of ExportFl. The URL is updated, and source shared with other Mini vMac extras, fixing one bug, it should now not crash in other emulators such as SheepShaver (though it still won't do anything useful)
On the page about MPW tools for Mini vMac, I've added example scripts for using SetHTC and CatHTC to Copy/Paste the host clipboard.
Some more software is now hosted by the Gryphel Project instead of only linked to: Joliet Volume Access and Alias Dragon. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Disk Rejuvenator, Better Edit Keys, and KeySwapper.
August 28, 2016
Tara Keeling has created a Nintendo 3DS port of Mini vMac. It was announced in this GBAtemp.net post. There is an article in Mac Rumors about it.
Mini vMac 3.4.1 is now officially released (with no change from the final beta, as usual). The Changes file lists what has changed since Mini vMac 3.3.3. I’ve been using the OS X version extensively the last couple months without problem.
Today’s Mini vMac Development source snapshot has some further work on the SDL 2.0 port. It can optionally use the SDL_RWops for file operations instead of C library routines. It will now ignore 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 on OS X.) Also 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 the ROM image and other files in the folder containing Mini vMac, like in most other ports.
There is a new version of ImportFl, that fixes a bug where where it would not overwrite an existing file (after the Standard Put File dialog asks if you want to replace it). And the URL in the about dialog has been updated. Also, source shared with other Mini vMac extras has been updated, fixing a couple other bugs: ImportFl should now not crash in other emulators such as SheepShaver (though it still won't do anything useful), and it can save to MFS volumes, when the computer supports HFS (previously it had the wrong test, and would support MFS only on computers that didn't support HFS).
For anyone using Macintosh Programmer’s Workshop, I’ve made public some MPW tools for Mini vMac (that I’ve been using for a long time, and have now updated and cleaned up a bit).
Some more software is now hosted by the Gryphel Project instead of only linked to: Text Capture FKEY, DiskTracker, DiskTop, and FaberFinder. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: AppSizer, and Custom Launcher,
August 21, 2016
Today’s Mini vMac Development source snapshot can use a ROM image for Steve Chamberlin’s Mac ROM-inator (which replaces the ROM of a real Macintosh Plus or Macintosh 128K with a megabyte of flash memory, and is a descendant of earlier work by Rob Braun).
Two new options make this possible. “-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.) And the 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.
Another new option could be useful with a Mac ROM-inator image. “-drc 0” prevents Mini vMac from disabling code in ROM that checks the ROM checksum on boot. If you are using a ROM image with Mini vMac that is already patched, 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.
Some other existing options could also be useful for testing a Mac ROM-inator image with greater realism: “-speed z -ta 2 -sony-sum 1 -sony-tag 1”.
Even if you are not using a Mac ROM-inator image, you can still use one it’s features - replacing the “Happy Mac” icon displayed on boot when a disk is inserted. The new option “-ahm” patches the standard ROM with one of 15 replacements icons by Steve Chamberlin (used with permission).
Some more software is now hosted by the Gryphel Project instead of only linked to: FKeyDragger, FKEYRunApp Maker, Function Key Enabler, FKEY Display, FKEYZoom, Heap Size FKEY, and David's FKEYs. (The original web page for FKeyDragger has disappeared.)
August 14, 2016
Today’s Mini vMac Development source snapshot no longer gives an abnormal report upon booting the Macintosh II emulation with System 7.5.5. Recently I had added reports for unrecognized calls to the video driver, but hadn't tested it with System 7.5.5. The Basilisk II source code indicates what the calls are, but I haven't implemented them yet. I just make the driver return an error quietly, for these specific calls, which is valid to do (i.e. emulating an older display made before these calls were defined).
Also in the video driver, I put some error checking into the recent implementation of indexed SetEntries.
There are some further improvements to the SDL 2.0 port. It now uses it now uses the function SDL_GetBasePath for the directory to look for the ROM image, and the disk1.dsk, disk2.dsk, etc. images. It also now supports the same“-d” and “-r” command line options as the X ports. And there is the option to use SDL_Log for logging, instead of using C standard library file calls.
For convenience when developing Mini vMac, the build system now has an “-all-src 1” option to include all source files. The build system normally selects a subset the source files needed to compile the requested variation. 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, and language.
There is now ROM Formatting Information for both versions of the Macintosh 128 ROM and two versions of the Macintosh Plus ROM, which are now listed on a separate page from the main FDisasm page. This is made possible by recently developed techniques for keeping information for similar ROMs in synch.
Mini vMac is reported to work on a Pocket C.H.I.P. (which combines the $9 C.H.I.P computer with a mini touchscreen, keyboard, and batttery).
Jesús A. Álvarez (Zydeco) updated his iOS port of Mini vMac to the 3.4.1 beta (on June 28th).
I’ve added the “Vintage Apple Computers” and the Classic Mac Gaming subreddits to the list of Gryphel Related Forums.
Some more software is now hosted by the Gryphel Project instead of only linked to: ICtoPCexchange, Carpetbag, TTConverter, ViewFont, MacFont, FindFont, and Keyboard Switcher. (The original web page for ViewFont has disappeared.)
August 7, 2016
Today’s Mini vMac Development source snapshot merges in further changes by Matěj Hybler to use an even earlier ROM from the “Twiggy” prototype Macintosh.
The build option is -m Twig43”. (Near the end of the ROM is the string “ROM4.3T 07/04/83”.) Again, this is not an officially supported option, advanced users can compile this version if they want to try it.
And also in today’s version, the SDL 2.0 port now supports importing and exporting the host clipboard (using ClipIn and ClipOut), like most other ports. This includes code for converting between the MacRoman character set and the UTF-8 that SDL expects.
Some more software is now hosted by the Gryphel Project instead of only linked to: Internet Config, and Link GURL Handler. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Where Is My Master, touch, Clipping Converter, FakeIt!, and ICtoAFS.
Thanks to Thomas Chan for sponsoring the Gryphel project, including web hosting.
July 31, 2016
Today’s Mini vMac Development source snapshot merges in changes by Matěj Hybler to support the ROM from the “Twiggy” Macintosh. This is a Macintosh prototype that has a Twiggy floppy drive (used in the original Lisa computer), instead of the Sony drive that the Macintosh 128K ended up shipping with. Except for the disk driver, the ROMs are nearly identical, except most everything is shifted to somewhat different addresses. Probably because the trap patching technique used in Macintosh System Software tends to depend on exact locations of routines in ROM, no System Software that shipped will run with the Twiggy ROM. There are two known disk images that will work with it, one with an early version of MacWrite and one with an early version of MacPaint. However these image don't currently work as is in the Twiggy Mac emulation. Matěj Hybler figured out a small patch to their boot block code to make them work, that disables some sort of check for the disk being bootable. This might be needed because the emulation is still using a replacement disk driver that is trying to imitate the data structures in memory used by the Sony disk driver, while the Twiggy disk driver has significantly different data structures. (With this patch, these two disk images will also work fine in the Macintosh 128K emulation.)
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.)
Formatting information for the Twiggy ROM has been added to the FDisasm page. In the process, I created a bunch of quick and dirty tools to make it easier to synch formatting information for multiple similar ROMs, which could make it possible to do things like provide formatting information for all 3 versions of the Macintosh Plus ROM.
Another change in Today’s snapshot is that 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).
The latest version of FDisasm adds the ability to format jump table offsets as the difference between two symbolic labels (instead of only listing the numeric value). Mac Plus formatting information has been updated to take advantage.
Some more software is now hosted by the Gryphel Project instead of only linked to: Zoomie, MenuSnap, Replace, Text Editor Patches, OtherMenu, SieveAhl, Natural Order, Desktop Valet, Alias Assistant, and Save a BNDL. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Folder Jumper, QuickScrap, ScrapIt Pro, TypeSaver, TakeABreak, and AliasZoo.
July 10, 2016
In today's Mini vMac Development source snapshot, 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 other news, there is a new version of FDisasm that has initial support for FPU instructions, sufficient to correctly disassemble the Floating-Point Arithmetic Package (PACK 4) of the Macintosh II ROM (verified with the MPW Assembler). The disk image with the Mac II formatting information has also been updated.
Some more software is now hosted by the Gryphel Project instead of only linked to: Al's snd INIT, NudgeMouser, Startup Player, DragAnyWindow, NoDesktopCleanup, Shutdown Delay, MenuBall, and PowerClicks. (The original web pages for all except the first two have disappeared.)
June 27, 2016
Today’s Development source snapshot is the start of the 3.5 branch. It might fix graphics problems that have been reported in Linux. I suspect that passing single bit per pixel images to the operating system to draw is not reliable, in at least some versions of Linux, with at least some hardware. So now, for Linux and other X versions, Mini vMac will always pass 32 bit per pixel images to the operating system, 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 for black and white only emulation, “-ci 0”, which you can use if there wasn't any problem in Mini vMac 3.4 and earlier.
In other news, there is a new version of FDisasm that can correctly disassemble the Macintosh II ROM. (MPW Assembler gets back the original binary.) Except that the Floating-Point Arithmetic Package (PACK 4) is not disassembled because FPU instructions are not yet handled. The disk image with the Mac II formatting information has also been updated.
Some more software is now hosted by the Gryphel Project instead of only linked to: FileTyper, Odd Jobs, QuickPop, DarkSide of the Macintosh, BugOff, DeskPicture, and SoundMaster. (The original web pages for BugOff and DeskPicture have disappeared.)
June 19, 2016
Today’s Mini vMac 3.4.1 is the first beta of the 3.4.x branch. The Changes page lists differences from current stable 3.3.3 version. (The only change in the source code from the last Development snapshot is the version number.)
The main reason for moving towards a new stable version now is that improvements to the build system in the 3.4 branch make it work smoother with the Mini vMac Variations service. (See the Mini vMac 3.4 Variations beta service.) The standard variation (with Macintosh Plus emulation) is little changed from the 3.3 branch. The core CPU emulation is identical. The main new feature in 3.4 is build time options for the initial values in Parameter RAM. (These options are supported by the Variations service.) And that sound is improved in the Mac II emulation.
In other news, there is a new version of FDisasm that can correctly disassemble the Macintosh PowerBook 100 ROM. (MPW Assembler gets back the original binary.) Even though the PowerBook 100 has a 68000 CPU, this ROM has some 68020 code. FDisasm can now better handle the full extension word format of addressing mode 6, the absolute long addressing mode, and the Bitfield instructions. The disk images with the PowerBook 100 formatting information has also been updated.
MacLynx has been added to the software hosted by the Gryphel Project. In addition, NCSA Mosaic, that before was only linked to, is now hosted.
June 12, 2016
Today's Mini vMac Development source snapshot has a few more tweaks to sound for Macintosh II emulation. It now clears the FIFO buffer when changing the enable mode to FIFO, or when changing mono/stereo mode when in FIFO mode. In addition, one ReportAbnormal message is now suppressed, about a word sized write to VIA1 that occurs on shutdown in System 6.
MacPerl and Little Smalltalk are added to the software hosted by the Gryphel Project. In addition, some more software is now hosted by the Gryphel Project that before was only linked to: Pocket Forth, UCB Logo, Open Prolog, ProIcon, MacGofer, Caml Light, and MacABC.
June 2, 2016
There is a new Mini vMac Development source snapshot, with much improved sound in the Macintosh II emulation. It is not perfect, but good enough that sound is now enabled by default for Macintosh II in the build system. Variations 5358 and 5359 on the Latest Variations page have this Macintosh II emulation for Intel OS X and Windows. Calls to “ReportAbnormal” are now strewn throughout the code emulating the Apple Sound Chip, so it will tend to give warnings when ever it strays from states that have been tested.
Besides lots of experimentation and debugging, the asc.cpp source file of the MESS emulator was helpful. MESS has lately been merged with MAME, and now under GPL and BSD licenses.
Some more software is now hosted by the Gryphel Project instead of only linked to: MacGambit, Chipmunk BASIC, MacMETH, Yerk, and Mops.
May 26, 2016
Jesús A. Álvarez (Zydeco) has updated his iOS port of Mini vMac. It no longer requires a jailbreak, instead you build it yourself in Xcode (which is free). It works in iOS 7 through iOS 9, is based on Mini vMac 3.4, and has some new features.
Today’s Development source snapshot fixes a bug reported in the Windows version, when compiled with recent development tools. It turns out to have been passing invalid flags to CreateWindowEx, since Mini vMac verion 0.1.1 (the first version to support Windows).
Also there are three additional build system options for initial values in the Parameter RAM: “-mnb” for Menu Blinks, “-kyt” for Keyboard Repeat Threshold, and “-kyr” for Keyboard Repeat Rate.
And also, the SDL 2.0 port now supports drag and drop.
I've added Metronome to the software hosted by the Gryphel Project. In addition a lot more software is now hosted by the Gryphel Project, that before was only linked to. Including almost everthing in Arcade Games, Other Games, Text Editors, Programming Tools, Math, and Astronomy.
Thanks to Chaled Schmidt, Michael Roberts, Matteo Trevisan, Leo Tognella, Bo Winqvist, Michael Roberts, and David OConnor for sponsoring the Gryphel project, including over nine months of web hosting.
January 9, 2016
There is a new Mini vMac Development source snapshot, which adds support for the Simple DirectMedia Layer 2.0 API (the older 1.2 API was previously supported), based upon a port by Manuel Alfayate, after this discussion. The build system option is “-api sd2”.
A new build system option “-dct” selects the initial value of Double Click Time (the maximum time between mouse button clicks which will be treated as a double click) in the Parameter RAM.
June 10, 2015
There is a new Mini vMac Development source snapshot, which updates the build system to support current development tools from Microsoft and Apple. The “-ev” option now supports Apple Xcode 6.3.2, Xcode 6.2, Xcode 4.6.3, and the 6.4 Beta. Though not tested, Xcode versions in between should also work. And for Microsoft, the “-ev” option supports Visual Studio 2013, Visual Studio 2012, and Visual Studio 2015 RC.
There actually doesn’t seem to be much change to the file formats for these IDEs. The only change to Mini vMac build system is to just write different version information. A few more changes were needed to the Mini vMac source code due to compiler and API changes. And also both IDEs now include source code analysis tools, which found a few things to fix, and to change just to avoid warnings.
The Carbon version of Mini vMac can not be compiled with recent Xcode, instead the Cocoa version must be used (with the “-api cco” option).
March 6, 2015
There is a new Mini vMac Development source snapshot, which fixes several reported bugs, adds a couple compile time options, and makes a significant change in how the platform independent and platform dependent code interact.
Thanks to Stephen Chamberlin, Marc Schaedle, Chaowang Zhang, Daniel Shuman, Ursula Katoll, Edward Mendelson, and Gottfried Haider for sponsoring the Gryphel project web hosting with Rackspace for February, January, December 2014, August, July, May, April, and March. (I've returned to the previous method of accounting for how donations are used.)
* The OS X version of Mini vMac was using the wrong syntax for the value of the LSRequiresCarbon key in the Info.plist file in the application bundle, as reported by Ryan Schmidt.
* The Linux, and other X, versions of Mini vMac would crash when exporting a file, if the “out” folder in the application directory didn't exist, and Mini vMac lacked permission to create it, due to not properly handling errors in the routine “FindOrMakeChild” in the source file “MYOSGLUE.c”, as reported by Éric of Montréal.
* The Linux, and other X, versions of Mini vMac can crash if the HOME environment variable is not set, due to missing error checking (which in turn was due to incorrectly disabling an alternate implementation), as reported by fzn.
* The Linux, and other X, versions of Mini vMac will now look for the ROM image in the application directory before looking in the “~/.gryphel/mnvm_rom”, instead of after, to match the behavior of the other ports. This makes it easier to have a ROM image for general use, and still be able try out another ROM image.
* The autoscroll feature (used in full screen mode when the emulated screen size is larger than the real screen) would not work when the emulation was stopped (using the “Stopped toggle” in the “S” command of the Control Mode).
* In the Cocoa port, Mini vMac would fail to mount a disk image located on a file system that doesn't support locking. It now checks the result from the flock call, and only prevents mounting if the file is already locked, and doesn't prevent mounting for other errors.
* The WinCE version wouldn't compile. WM_INPUTLANGCHANGE changed events used by the new keyboard unscrambling code for Windows don't seem to be present in WinCE.
new compile time options:
* A new build system option “-svl” selects the initial value of the Sound Volume in the Parameter RAM.
* A new build system option “-sss” selects the output Sound Sample Size.
some internal changes with visible consequences:
* To make Mini vMac simpler and more maintainable, the interaction between platform dependent code and platform independent code has been changed a bit. Instead of the platform dependent code calling a routine to emulate one tick (sixtieth of a second) whenever appropriate, the main loop of the program is now in platform independent code, which periodically calls platform dependent code to check for events. A visible consequence of this is that the emulation will now stop running in certain circumstances when it used to continue running, such as during the open disk image dialog. The exact situations this happens varies for each platform.
* To minimize glitches in sound output when emulation starts, stops, or just isn't running fast enough, the sound call back functions in the various Macintosh versions and the SDL version will now try to play an appropriate transition in each of these circumstances.
* In the Cocoa port, when the platform dependent code checks for events, rather than using a time out value, it turns out there is a bit less overhead to check for events, sleep, and then check for events again. This allows matching the performance of the Carbon version, making the Cocoa version more ready for prime time. (Apple has declared Carbon very, very deprecated.)
The same fix actually also applies to Carbon. Mini vMac used to use a standard Carbon event loop with a complicated system of timer events only because a manual event loop didn't get quite as good performance. With this change, all ports can use the same platform independent event loop, as described above.
In other not so recent news, a number of bug reports by Steve Chamberlin led to improving FDisasm enough so that its output for the Macintosh Plus ROM can be fed to the MPW Assembler and get back the original ROM. This also works for the Mac 128/512 ROM, and the Mac SE ROM.
December 12, 2014
I've received permission to add Data Desk 7.0.3 to the software hosted by the Gryphel Project. A tool for Exploratory Data Analysis first released in 1986, Data Desk is one of the oldest Macintosh programs still actively developed and sold (for OS X and Windows). A version for Macintosh 680x0 is now freeware to honor Data Desk’s origin.
There are a few changes in the Mini vMac development version in recent months that I hadn't documented previously:
The Virtual-Key Codes of Microsoft Windows, that are independent of differences in keyboard hardware, turn out not to be independent of the choice of Keyboard Layout. Changing the Keyboard Layout to something other than "US" may scramble the Virtual-Key Codes, strangely enough. Mini vMac will now check the current Keyboard Layout, and attempt to unscramble the codes, so that the Keyboard Layout chosen in Macintosh operating system running within Mini vMac will work properly. There is a new build option to disable this fix, -ikb 0, because this is fairly large amount of code and US only users don't need it. But also because I'm not sure I really understand this. Why has no one complained about this issue in the last decade?
Mini vMac on Microsoft Windows will now recognize the Virtual-Key code of VK_OEM_102, and translate it to the Macintosh key code of 0x0A. This key is used for angle brackets in the German keyboard layout, for example.
A new build system option “-cbt” selects the initial value of Caret Blink Time (Rate of Insertion Point Blinking) in the Parameter RAM.
Added build system option “-t fbpc” for FreeBSD on PowerPC.
Added build system option “-t cpu”, to provide a starting point for compiling a combination of operating system and CPU that is not yet supported.
October 7, 2014
Mini vMac is moving back to its original home: "http://www.gryphel.com/c/minivmac". The web pages from SourceForge should now all be moved, but the file downloads are currently still on SourceForge. A few pages not directly about Mini vMac itself are also moved and accessible from "http://www.gryphel.com/".
There is no longer separate documentation for the current stable version (3.3.3) and the version in development (3.4.0 alpha). There is one set of documentation, that in places notes changes in the alpha version.
Please let me know if you notice anything broken.
July 29, 2014
I've added MacPaint 1.3 to the software hosted by the Gryphel Project. MacPaint was one of the very first applications available for the Macintosh, written by Bill Atkinson, the author of QuickDraw, the core Macintosh graphics library.
In 2010 the source code of MacPaint was donated by Apple to the Computer History Museum, for non-commercial use. I compiled the application from this source, and am making the result publicly available, after receiving assurance that this is a permitted use.
I modified the source to compile in MPW Pascal, so my version is not identical to the original. I have added to the version string and the about dialog, to note that this is a modified version.
July 27, 2014
I've added True Clock to the software hosted by the Gryphel Project.
July 25, 2014
Joseph V. Barrile has created and donated a second alternate Mini vMac icon.
May 20, 2014
Today’s development version fixes a bug reported by Ryan Schmidt, in the new “Export” command of the Build System, where the initial name of the file in the Save dialog was not initialized.
March 19, 2014
MiniUnZp is a new application to use in Mini vMac to unzip a compressed archive created by OS X, preserving some of the Macintosh specific information: the file type, the file creator, and the resource fork. It is currently extremely preliminary, but it functions, and may be useful as is. MiniUnZp is based upon Info-ZIP code copyright Mark Adler and many others.
MiniUnZp was created by starting from the Info-ZIP unip code, and stripping out anything not needed to unzip a single archive named "arc.zip" on OS X. Next, this code was made to compile for Mac 680x0, by creating a library that implements c library functions, using the Classic Mac API. Only the very minimum amount of c library functions needed for MiniUnZp were implemented. Still this library could be useful for other projects, and gradually expanded. After this was gotten working, a post processing pass was created to look for the Macintosh specific information that OS X saves in a folder “__MACOSX”, and another pass to delete (for now) “.DS_Store” files.
The next step would be to merge the unzip code and the library glue to create a better Macintosh port. In particular, to make file handling more native. Also it would be better to use Macintosh handles rather than allocating pointers.
March 15, 2014
In today’s development version:
The Build System window now has a progress indicator. The last development version merged in code from ExportFl to support dropping files onto the application icon, and today’s version merges in more code for additional features. The progress indicator at the bottom of the window can display information about what is going on. Clicking on it is equivalent to choosing the “Go” command from the File menu. The Build System can now potentially allow the user interface to remain functional while processing. But calls have to be added to the processing code to allow this, calls that report progress and can yield time to the user interface code.
The Build System now supports drag and drop (when the drag and drop operating system software is present) onto its window, which has equivalent function to dropping a file on the application icon.
The Build System has a new “Import” command in the File menu, which has equivalent function to dropping a file on the application icon.
The Build System has a new “Export” command in the File menu, which saves the window’s contents to a new file, that the “Import” command can read. The new file has the creator set to the Build System, so double clicking on the file will work. The Build System application defines an icon for the files it saves.
It does not make sense to combine the build options “-magnify 1” (to start with magnification on) and “-mf 1” (to disable magnification), and the Build System now prevents this.
March 9, 2014
In today’s development version:
I've added a requested feature that can help in automating the build process. Files can now be dropped onto the build system application icon. This is equivalent to copying the contents of the file, and pasting it into the build system window after removing any existing text (such as by the ‘Select All’ and ‘Clear’ commands), and then choosing the ‘Go’ command. Multiple files can be dropped, and they will be all be processed. (Though if there is an error, that error is reported, and all remaining files are forgotten.) If the build system application was not yet running when icons are dropped on it, then the application automatically quits after processing all the files. Other ways of generating kAEOpenDocuments apple events, besides dropping files on the application icon, should also work, such as AppleScript.
March 5, 2014
In today’s development version:
Changed URL displayed in about screen to "../../c/minivmac/alpha.html".
The Pocket PC version wouldn't compile with "-im 1". Removing the call to GetShortPathName for Pocket PC allows it to compile, but then registration won't work if the path of the application contains spaces. Upon further investigation, it seems all that is needed is to put the application path in quotes when setting registry entries, so GetShortPathName isn't needed. So have made this change for both Pocket PC and the regular Windows version.
Renamed the Build System application to include branch information - "MnvM_b34". This makes it easier to deal with the Stable and Development branches at the same time.
Prevent warning about unused code when using options "-var-fullscreen 0 -fullscreen 1 -mf 1".
The Build System now generates a compile time check in a configuration file when compiling with gcc for x86-64 or x86-32, to make sure the 64 bit configuration is not compiled with a 32 bit compiler, or vice versa. This can result (especially when used with "-no-asm"), in a binary that almost but doesn't quite work correctly. The check is for the wrong predefine being present, rather checking that the correct predefine exists, to reduce the chance of incorrectly giving an error on an unusual compiler version.
OLD NEWS - Previous release notes