has moved to the Gryphel Project front page
(Follow the Gryphel Project on Twitter to be notified of the latest news. )
October 7, 2018
The latest Mini vMac 36.04 beta fixes a few issues in the classic Macintosh port. (The fixes were developed inside Mini vMac.)
The new “-svd 0” option is now implemented in classic Macintosh port. While doing this, it turned out that the build system was generating an incorrect Rez command for the MPW development environment. It also turned out that if debug logging was turned on for this port, and the log already existed when Mini vMac started, the log wasn’t cleared.
An unrelated change is that default version of XCode chosen by the build system is now 9.4.1, the latest version supported. Since XCode is no longer used for official Mini vMac builds, there is no reason to default to the specific antique version previously used. Similarly, Microsoft Visual Studio 2017 is now the default version chosen for that development environment.
September 30, 2018
The latest Mini vMac 36.03 beta attempts preliminary translations for the strings “copy variation options” and “Variation options copied”, by looking at Apple’s translated strings for the Edit menu of the Finder, and using Google Translate. Only “Copy” and “Copied” are translated, not “Variation Options”. The Localization pages are updated accordingly.
September 23, 2018
I have begun moving the Gryphel Project to “GRY” format digital signatures. There are three new keys:
Gryphel Key 3 is the new main public key, to be used only for signing other keys.
Gryphel Key 4 is for signing variations. The Gryphel Project Variations Service now uses this key, for both Mini vMac 3.5.8 and Mini vMac 36 in beta.
Gryphel Key 5 is for signing other downloads. The Mini vMac standard variations are now signed with this key.
The MPW tools for digital signatures, SigChkTl, SigWrtTl, and MkKeysTl, have been updated to the latest code and use “GRY” format.
September 16, 2018
Today’s Mini vMac 36.02 beta has a few fixes.
The game PowerMonger was reported not to work in Mini vMac 3.5.8, though it worked in 3.4.1. This was due to a bug in emulating the TRAPcc instruction.
While looking into a report of issues with Num Lock, I found that on Windows, if Num Lock is on, the operating passes virtual key codes like VK_NUMPAD0 through VK_NUMPAD9, but if Num Lock is off, it passes virtual key codes like VK_LEFT, VK_RIGHT, VK_UP, and VK_DOWN. A flag bit indicates whether VK_LEFT means the left arrow key or the 4 key on the keypad. So now Mini vMac will check that flag, and map the keys on the keypad to the emulated Macintosh keypad, regardless of whether Num Lock is on. (But this doesn’t fully explain the reported issue.)
It also turns out that on Windows (at least on some machines and os versions) the operating system does not use virtual key codes VK_LCONTROL/VK_RCONTROL/VK_LMENU/VK_RMENU, but instead uses VK_CONTROL/VK_MENU with that same flag bit to indicate whether it was the left or right key. If Mini vMac is compiled with “-km” options that require distinguishing between left and right, then that is checked for VK_CONTROL/VK_MENU.
Also on Windows, I noticed that the “menu key” (VK_APPS), is usually on the right side of key (if present at all), and so now maps to the right option key instead of the left, if -km options require distinguishing them.
The Cocoa OS X port now implements distinguishing between left and right modifier keys. But this requires looking at undocumented flags of the key event, which might or might not always work, so it is not done unless -km options are used that require it. (I have not found any way to distinguish left and right modifiers in the Carbon OS X port.)
Also in the Cocoa OS X port, launching Mini vMac by drag and drop of a disk image on to the application icon would not work because of the new code to allow drag and drop of the ROM image. Some initialization stuff for Cocoa caused file open requests to be received earlier than expected, so that initialization has been moved later, after the ROM has been looked for in the usual places.
September 9, 2018
Today’s Mini vMac 36.01 is the first beta of the 36.xx branch. The Changes page lists differences from current stable 3.5.8 version. (The only change in the source code from the last Development snapshot is the version number.)
In other news, AutQuit7 is updated thanks to this report. It now uses launchUseMinimum in launchControlFlags, so that AutQuit7 can launch “app” even if the preferred memory size is greater than the largest unused block.
September 2, 2018
Today’s Development source snapshot has some assorted fixes in preparation for moving to beta.
Reconsidering a feedback about the control mode, I changed my mind and decided that variations of Mini vMac without the control mode should not be supported. The build system will now consider it an error if “-km” options result in no key mapping to the control mode.
While in that area, if the “control” key is not mapped to the control mode, but some other key is, the user interfaced strings are now adjusted.
Also, when using the “-km” options, it may not make sense for the K command of the control mode to toggle the emulated control key. There is a new option “-ekt <dst>” to choose which emulated key to toggle. The user interface strings are adjusted accordingly. When this option is not chosen, Mini vMac will pick an emulated key that is not mapped to any real key, instead of always the control key.
I have concluded that “Abnormal Situation” reports in the regular non debug versions of Mini vMac are not on the whole helpful, and so are now disabled by default. There is a new compile time option “-abr 1” to enable them.
I spent a few days tracking down a twice reported issue when compiling with Microsoft Visual Studio 2017. It worked fine with an older version of Studio 2017 that I had, but once I downloaded the latest version, I was able to reproduce the problem. Turning off optimization made the problem go away. This compiler provides a way to set optimization level per function, so I was able to narrow it down to single simple function, where it was generating an “shr” instruction when it should have been an “sar” instruction. I don’t see any way this is undefined C behavior, so it looks like a compiler bug. To maximize the chance of a correct compile, I have changed the Mini vMac build system to disable optimization for this compiler. (This compiler is not used for the versions of Mini vMac that I provide.)
Trying to using the Location and Time Zone options (-alc, -lcy, -lcx, -atz, -lcd, -lczs, -lcz) when emulating a Mac 128K, 512K, or 512Ke will now generate an error. These options are saved in the Extended Parameter RAM, which these machines don’t have.
August 26, 2018
Today’s Development source snapshot removes the length limit on the Control-P command to copy the variations options, and adds an option to disable code signing.
Previously, converting a string from a cross platform C string constant to a representation that can be placed on the host clipboard involved a fixed sized buffer. Now that part of the conversion is done in two passes, first to find the length of the result, and second to actually produce the result. (The fixed size was 512 bytes, so it would be unusual to have hit this limit. It would need quite a lot of variation options.)
While in this area, I added the “copy variation options” command to the list in the help screen (Control-H). It would be nice to have translations of this string, and also the string “Variation options copied”, to the other ten languages supported by Mini vMac 36.
Also while in this area, I noticed that in the help screen, the original intent appears to have been that the letters on the left would be surrounded by single quotes. But that displaying a single quote wasn’t implemented properly and showed up as space. After implementing displaying the single quote, I think it looks better without. However, I noticed that preceding the “-” there are two spaces, since one was supposed to be the single quote. Somehow I never noticed this before. I have changed that to a single space.
Recently code signing has been added to the Cocoa OS X version of Mini vMac. But it has disadvantages. Apple could choose to revoke the certificate any time, and Mini vMac would stop working. Also, since Mini vMac doesn’t use Apple’s time stamp server (because that would break reproducible builds), Mini vMac will probably stop working when the certificate expires, 5 years after being issued. (The plan is to renew the certificate every year, so that a compile of Mini vMac should work for at least 4 years.)
Some people may prefer to avoid these issues, so I have added an “-sgn 0” option to disable code signing. The disadvantage is that OS X will by default refuse to run it (as happens with Mini vMac 3.5). This new option can be used in the Advanced Variations Service.
August 19, 2018
Today’s Development source snapshot adds a Serbian translation contributed by SerbXenomorph. This translation uses the Latin alphabet. SerbXenomorph contributed the translation in the Cyrillic alphabet, which was converted to the Latin alphabet with multiple online conversion services, which all gave the same result. It would take much more work for Mini vMac to support the Cyrillic alphabet, in its private cross platform font. Maybe someday. (According to Wikipedia, “Serbian is practically the only European standard language whose speakers are fully functionally digraphic, using both Cyrillic and Latin alphabets.”)
Today’s snapshot also adds a new compile time option, “-sbx 1”, to enable Sandboxing in the Cocoa version for OS X. This is an Apple security mechanism, so that any bugs, or even maliciousness, in Mini vMac can only do limited harm. This option might be the default in a future version of Mini vMac. However, it does remove some capabilities. The single requested “entitlement” allows Mini vMac to read and write files that the user has selected, with the Open File dialog, or by dragging into the Mini vMac window or icon.
But Mini vMac’s ability to automatically find files by name in special locations is severely restricted. It is prevented from finding “vMac.ROM”, “disk1.dsk”, “disk2.dsk”, etc. in the folder containing the application. It can find such files in a “mnvm_dat” folder created inside the application, but only read only. It does not have access to “~/Library/Preferences” to find “vMac.ROM” (but it does get access to the corresponding folder inside its container folder, which is obscure). It does have read only acces to “/Library/Application Support/”. Furthermore, if these named files are links that won’t work unless the file linked to is in one of the few places that a Sandboxed application has access to.
The Cocoa version for OS X now looks for the ROM image in one additional place, “/Library/Application Support/Gryphel/mnvm_rom/”, which can be read by a Sandboxed application.
August 12, 2018
I’ve changed my mind, and will trying using Apple’s code signing for the Macintosh OS X port, for 64 bits. This is implemented in the Mini vMac 36 Alpha Variations Service as of today. This allows Mini vMac to run on OS X without having to bypass Apple’s GateKeeper feature.
Hopefully, what I’ve implemented will work without causing too many problems. Normally signing an application involves requesting a signed time stamp from an Apple server. This is impractical for the Variations Service. And another problem is the result of this depends on the current time, which breaks the build process of compiling twice and checking for an exact match.
But it turns out to be possible to instruct the code signing tool to not do the time stamp. One possible consequence is that the application may stop working when the signing certificate expires in 5 years, since the application doesn’t have a signed time stamp to prove it was compiled before that. If I get a new signing certificate from Apple every year, this may not be too much of a problem.
Thanks to Scott Rickard, Anonymous, Trevor Glahn, Leonid, Chris Hanson, and Henry Shawcross for sponsoring one month of web hosting for the Gryphel project and over 4 days of health insurance.
August 5, 2018
The latest Mini vMac Development source snapshot fixes support for all supported IDEs in the new configuration tool. The new tool always uses the equivalent of “-cfg 1 -no-src 1” in the old build system, but these options were previously only implemented for “-e mvc”.
Also, Apple Xcode 9.4.1 is now supported.
And also, a memory leak is fixed in the Cocoa port for OS X, when exporting the clipboard. This was found by the Xcode Analyze feature.
July 29, 2018
The latest Mini vMac Development source snapshot adds a new way of finding the ROM image.
It was pointed out to me that using undocumented calls is not a good idea, so I have disabled the new code for working around the silly Path Randomization misfeature of OS X, which prevents finding the ROM image in the folder containing Mini vMac.
Instead, on all platforms (not just OS X), if the ROM image is not found in any of the locations that Mini vMac looks, the error can now be recovered from. You can drag the ROM image onto Mini vMac, and booting will resume. (Any of the methods that would normally mount a disk image will work to get the ROM, such as the Open dialog.)
July 22, 2018
Using the new (old) configuration tool, and some other techniques, the Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service now only takes around 5 seconds for the preliminary result, down from 10 last week. Instead of generating a temporary page when the request is made, the cgi script waits for the preliminary result to become available.
The latest Mini vMac Development source snapshot merges in some fixes to the configuration tool from Ryan.
July 15, 2018
The latest Mini vMac Development source snapshot tries out backtracking a bit in the build system. Instead of a 68k Macintosh program to generate files to compile, it uses a cross platform standard C command line tool to generate a script to write configuration files, as was done prior to Mini vMac 3 over a decade ago.
This should allow the Variations Service to be more efficient, and is also more convenient for experienced programmers. The trade off is in making it harder for others to compile their own variations. Now I would prefer for people to use the Variations Service, and this is not only because of the funding model. Helping beginners figure out how to compile does not scale. And trying to making Mini vMac work well with random versions of random compilers also does not scale. With the Variations Service I can ensure quality of the compiled variations. The Variations Service has greatly improved in past months, fully automatic with 30 second turnaround (and still getting faster).
The source snapshot is now a standard compressed archive, in “.tgz” format. The source for the configuration tool is in “setup”folder. In a unix like system it can be compiled using something like “gcc setup/tool.c -o setup_t”, then run with something like “./setup_t -t mc64 > setup.sh”, and the output run with “. ./setup.sh”, and then Mini vMac can be compile with “make”.
The new configuration tool is still a work in progress. It should be better documented when it is more settled.
July 8, 2018
The latest Mini vMac Development source snapshot merges in a number of fixes from Ryan.
The “-min-extn” option wasn’t working after the addition of the ‘P’ command of the Control Mode (for getting the compile time options).
The source image is now larger so that “-all-src 1” can work.
In the Cocoa version for OS X, the key NSHighResolutionCapable has been added to the Info.plist file, so that the Mini vMac window frame will draw in higher resolution on a Retina screen.
There is a new compile time option, “-gse 1”, for the Cocoa version for OS X, which on computers with more than one GPU allows the operating system to change which one is used. Otherwise on a MacBook pro, it is reported that the higher power discrete GPU is always used instead of the lower power integrated GPU, and that besides wasting power for no noticable benefit, it also takes time to switch on the discrete GPU when Mini vMac starts. update : I seem to have missed part of this patch. This will be fixed next snapshot.
“-gse 1” should probably become the default in the future. But I don’t have a MacBook pro to test it on, and I have a few questions about it.
A bug is fixed in the new “-svd 0” option, where in the Cocoa version in OS X 10.6 and prior, the “out” folder would not be created, if didn’t already exist.
July 1, 2018
“www.gryphel.com” is now HTTPS only, following current recommendation. Access to unencrypted HTTP is permanently redirected to the encrypted page.
If you want to access this website with very old web browsers, there is now http://www.gryphel.org, which has the same content, hosted by the same web server, but it works with unencrypted HTTP.
Due to travel, there won’t be a new development source snapshot until next week. Ryan has contributed a number of fixes.
June 24, 2018
The gryphel.com domain now points to new server. It may take up to a few days for this change to propagate across the entire internet. (If your DNS hasn’t updated yet, you will still get the old server.)
The new server and old server are currently identical for gryphel.com, except that the new server supports HTTPS encryption, i.e. https://www.gryphel.com.
In a few days, when the older server is no longer being used, and if everything looks good, any access to an unencrypted page like http://www.gryphel.com will be permanently redirected to the encrypted page. So if you notice problems with the encrypted pages, let me know now.
For very old web browsers that don’t support modern HTTPS, there is now http://www.gryphel.org. It is handled by the same new server, but this domain will not be redirected to HTTPS.
June 17, 2018
I’ve decided it is time for this website to support HTTPS (encryption), mostly to make Google search and web browsers happy. Rather than making the changes on the current web server and hoping it all works, I set up a new web server with up to date software, and if all works well, will switch the gryphel.com domain to it.
Current recommendation is to force browsers to use HTTPS, and even for HTTPS not support some of the older versions. But this website is intended to work with the oldest web browsers. To satisfy both, this website will be available on two different domains: “gryphel.com” will use HTTPS, and “gryphel.org” is for HTTP.
http://www.gryphel.org currently works for static content. (Supporting the Variations Service and the feedback form is yet to come.) https://www.gryphel.online is the current location of the HTTPS version. When everything is working properly, gryphel.com will be changed to work as gryphel.online does, and gryphel.online will probably be removed. (‘gryphel.online” is a free sample domain from my registrar.)
While there are two web servers, any changes to this site have to be made on both of them. So hopefully this transition period will be short.
If you notice problems with the new web server, let me know. At my location, the HTTP version seems at least as fast as the old web server, and HTTPS is less than twice as slow. HTTPS takes more round trips to the server to set up, so may be even slower from locations further from eastern US.
I considered supporting HTTP/2, which speeds up modern websites that access lots of different resources, but for this minimalist website, it seems more likely to just add a bit more overhead, and possibly compatibility issues. I also considered IPv6, which seems simple to support on the web server, but neither of the two internet connections I have available support it, so I can’t support it.
June 10, 2018
Today’s Mini vMac Development source snapshot fixes a reported bug where the Control Mode didn’t work on ports other than OS X. This was broken when the “-km” option was added.
Also, I’ve put in a work around for the Path Randomization misfeature added in macOS Sierra (10.12). If an application that Apple thinks is trustworthy is bundled together with malicious library code in the same folder, the malicious code may be run by the application. The silly way that Apple has chosen to prevent this is to in effect move the application somewhere else before running it, so it can’t find the library code. It can’t find anything else in the application’s folder either, which is a problem for Mini vMac, which looks for things in its folder, such as the ROM image file. So now the Cocoa port of Mini vMac will try to find the original location of the application, and use that instead of the location it is running from, when looking for the ROM image and other things. (Mini vMac doesn’t look for external library code, so Path Randomization has no benefit.) This is done using some undocumented SecTranslocate calls as suggested by “Objective-See” and Jeff Johnson. Previously, I have recommended using “xattr -rc <path to Mini vMac>” from the command line to disable Path Randomization. This will no longer be needed for Mini vMac 36.
June 3, 2018
This week I’ve tried to make the Variations Service automatically recover from the sort of network failure that happens every few weeks or so (or sometimes two days in a row). Previously the service would stop working until I noticed and fixed it manually.
I’ve also tried to make the Gryphel web server a bit more robust in some situations.
May 27, 2018
Today’s Mini vMac Development source snapshot adds the new build system options “-alc, -lcy, and -lcx” to allow manually setting the location fields in the Parameter RAM, and the options “-atz, -lcd, -lczs, and -lcz” to allow manually setting the time zone fields.
The “GetPRAM” tool has been updated to support these location and time zone options.
These Parameter RAM fields are not much used. Two example programs that can use the location fields are MacAstro and Star Atlas.
May 20, 2018
The Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service now only take 10 seconds for the preliminary result, down from 15 last week. (And 20 seconds total, down from 30.)
This was made possible in part by a new compile time option in today’s Mini vMac Development source snapshot. “-svd 0” disables the save dialog for OS X and Windows when exporting a file (as used by the Mini vMac extra ExportFl and other tools). Instead the exported file is saved in a folder named “out” without a dialog, as was previously done in the Linux version. This makes it easier to run Mini vMac in an automated script and get results out.
Another change is that when the recently added “-ef 1” option is used to save errors to a file, the error file will be exported to the real computer, rather than staying in the emulated computer as before. (Unless “-nex” is also used.)
There is also another new option “-no-src 1” to only generate the configuration files and not save the source files. When the options “-cfg 1” and “-all-src 1” are used together, the generated source folder is identical for all variations. So it could save time to not generate it. But it doesn’t seem to be a significant amount of time, so the variation servce is not yet using the “-no-src” option.
Some additional speed was gained in the Alpha Variations Service by using ssh multiplexing.
May 13, 2018
There are changes to the Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service. Instead of compiling the requested variation twice, verifying they match, and then presenting the result, it will now compile once, present a preliminary result, and then compile again, verify, and present a final result.
So it now only takes 15 seconds instead of 30 to get to the point of downloading your variation (and you can verify the checksum and signature). Before actually running the variation, you should wait for the download page to update with the final result, which should only take another 15 seconds.
Another change is that the Alpha Variation Service is now reproducible. That is, if you ask for the same options twice, you will get the exact same application archive. (The file name will be different, but the contents are the same.) Previously different variation requests would get applications with different names, like “mvm10280” and “mvm10281”, which made the resulting archives different, even though the compile process was otherwise reproducible. Now all variations get the same name “minivmac”, and the application archives are renamed to something unique as a final step. The Sponsor Code used does not effect the resulting Variation, so two sponsors requesting the same variation will get the same result. (With no Sponsor Code, a demo is created, which is different from the sponsored variation.)
Today’s Mini vMac Development source snapshot has a fix to allow the Alpha Variations Service to report errors correctly. The simplest way to fix it was to remove the option of using “;” to allow multiple variations in one run. The new Alpha Variations Service no longer uses this, it always processes one variation at a time, and never in larger batches. (Larger batches would not work properly since all variations now all have the same name.)
Another change is that the build system now will report the name of an unrecognized option in the error message, not just hilighting it, to allow the Advanced Variations Service to work better.
Thanks to Herb Mann, Sam Coupe, Michael Cremer, Callum Fraser, Roland Zimmerman, Ian Dunbar, Chris Hanson, and Henry Shawcross for sponsoring one month of web hosting for the Gryphel project and over 6 days of health insurance.
May 6, 2018
Today’s Mini vMac Development source snapshot adds a new build system option “-km <src> <dst>”, for changing the mapping between keys on the real Keyboard and keys on the emulated Keyboard, or the Mini vMac Control Mode.
April 29, 2018
Today’s Mini vMac Development source snapshot adds the new build system options “-hcr, -hcg, and -hcb”, to select the initial value of red, green, and blue components of the highlight color in the Parameter RAM. This was requested by Karl.
The new “GetPRAM” tool can be used to get the numeric values these options require. It gets Parameter RAM settings in a format that can be used with the the Mini vMac build system or the new Advanced Variations Service. So you first use the Macintosh Control Panels to select the desired settings, then launch GetPRAM.
Also in today’s snapshot, the error message generated by the build system always include the name of the option which had the problem, making error messages from the Advanced Variations Service more useful. (If you use the build system application directly, not telling it to save error messages to a file and quit, it would usually highlight the text of where the problem was.)
April 22, 2018
There is now an Advanced Variations Service for Mini vMac 36 Alpha, where options are entered as text, instead of the long list of controls in the regular Variations Service that is getting unwieldy as more and more options are added. (The plan is to remove all but the most popular options from the regular Variations Service and call it the Basic Variations Service.)
The Advanced Variations Service is actually easier to use than the regular Variations Service when you want something mostly like a variation you already have, because of the new ‘P’ command of the Mini vMac Control Mode to get the options of an existing variation.
April 15, 2018
Today’s Mini vMac Development source snapshot adds a number of features to the build system. The motivation is that the Variations Service page gets unwieldy as more and more options are added. So I’m thinking of instead having a Basic Variations Service, which only has the most popular options, and a new Advanced Variations Service, which allows pasting in options as text. (With the new ‘P’ command of the Mini vMac Control Mode to get the options of an existing variation, you would be able to easily update a variation.)
If the new option “@” is used, no developer options are permitted to the right of it. This will allow the Variations Service to allow the user to specify options as text without the chance of breaking the service. (For example, the ‘-e’ option to select the the development environment would not work well.)
The new option “-ef 1” causes the build system to write error messages to a text file, instead of displaying an alert dialog. This will allow the Variations Service to allow the user to specify options as text, and get any error messages, such as about bad syntax, back to the web page shown to the user, rather than breaking the service.
If the new option “!” is used, options to the right of it will override options to the left of it. Normally it would be an error for the same option to be used twice. It is still an error for an option to be used twice on the same side of ‘!’.
The new option “-cte 1” causes the build system to generate source code that causes the compiler to generate an error. This is for testing the variation service.
If the new option “-bte” is used, the build system will treat it as an error. This is for testing the variation service.
April 8, 2018
WordMaker 1.0.4, a word processor, has been added to the software hosted by the Gryphel Project. Josef of Team Amiga Source Code Preservation notified me that they had obtained the source code and permission to GPL it, among a batch of other software, mostly for Amiga, originally from New Horizons Software, Inc.
April 1, 2018
Today’s Mini vMac Development source snapshot adds a new ‘P’ command to the Mini vMac Control Mode, which copies to the clipboard (of the real computer, not the emulated computer) a string containing the options describing this variation of Mini vMac.
The string generated by the ‘P’ command starts with a new option, “-br”, which is for future use and currently has no effect. It tells the build system that the requested options were from a specific branch (version) of Mini vMac. So “-br 36” means from branch 36. If the default settings have changed from since that older version, then the build system will use defaults of the old version, rather than the current defaults. So if you use the ‘P’ command on some variation of the current alpha version of Mini vMac, and pass it to the build system of some future version, the newly generated variation will behave as close as possible to the earlier variation.
There are three new build options that may have different defaults in some future version: “-eci”, “-ecr”, and “-eck”. They can be used to disable the ‘I’, ‘R’, and ‘K’ commands of the Mini vMac control mode, which are use to operate the emulated Interrupt Button, emulated Reset Button, and emulated Control Key. In the future they may be disabled by default. In the original Macintosh, the Interrupt and Reset buttons were disabled by default. You needed to install the “Programmer’s Switch” to use them. The original Macintosh did not have a control key. And, using the ‘K’ command accidently would be confusing.
March 25, 2018
Today’s Mini vMac Development source snapshot adds a new build option “-iid 1” to enable a new “Insert Ith Disk Image” feature. When this feature is enabled, if the Control key is held down and a number key from ‘1’ to ‘9’ is pressed, then Mini vMac will try to mount a disk image named from "disk1.dsk" to "disk9.dsk" in the folder containing the application.
This is the same series of disk image names that are automatically mounted when Mini vMac is launched. But it stops at the first image not found. So if you leave a name unused, then you can use a control-number key to mount disks after launch. Or, you can use a control-number key to remount a disk that was automatically mounted at launch and then later ejected.
One example use is if you have one copy of Mini vMac running a development environment (such as MPW) that is used to compile a program to a disk image. The disk image is then unmounted and mounted on another copy of Mini vMac running a testing environment. If the compiled program crashes badly, the development environment is not disturbed. The control-number key feature makes it easier to move the disk image back and forth between the two copies of Mini vMac.
Also, the version numbering scheme has changed as of this snapshot. Instead of “3.6.0”, it is “36.00”. The distinction between major and minor version numbers has not been useful. Instead there is now a single branch number. This allows more bug fix releases (up to 99 instead of up to 9) without taking more space in the version string.
And also with this snapshot, the Mini vMac Alpha Variations Service and the Alpha Changes list are back.
March 18, 2018
SigCheck, SigWrite, and MakeKeys have been updated and renamed to PSgCheck, PSgWrite and PMakKeys. They are being replaced by a similar set of tools, with the same names, that use a different format for keys and signatures (instead of formats that are sort of but not quite compatible with MacPGP): SigCheck, SigWrite and MakeKeys.
March 11, 2018
Today’s Mini vMac Development source snapshot fixes a bug in emulating the trace flag of the CPU. (Thanks to Tara Keeling for causing its discovery.) It seems that in months of testing of Mini vMac 3.5, I never used Macsbug. Stepping through code (with Command-S or Command-T) doesn’t work properly. An optimization to the main cpu emulation loop isn’t valid when the trace flag gets set. I found a way to fix it which doesn’t change the optimized main loop, but just the code before and after. But it can change the timing of other kinds of interrupts by one instruction, potentially causing subtle differences in behavior anywhere. So I don’t plan to put this fix in stable Mini vMac 3.5, it needs more extensive testing.
I’ve added a blinking busy indicator to the status bar in GSgWrite. This is partly to reassure the user that it is working, but mostly it is to tell the AutoSlow feature of Mini vMac that it is working. So that documentation doesn’t need to say to turn off AutoSlow. (Other tools will be updated later to include this code.)
On further consideration, I’ve decided to backtrack and say that GSgWrite, SigCheck, SigWrite, and MakeKeys are still in Alpha, not in Beta, because of not being satisfied with the format for public and secret keys. They are currently using a format that is sort of compatible with PGP, but not actually what PGP would ever produce. For multiple reasons, I’m thinking it would be better to define a GRY format for keys, and then have one set of tools that only deal with GRY format keys (and work with GRY format signatures), and also have another set that uses the PGP semi compatible format that is currently used (and work only with PGP format signatures). I have defined the GRY keys format, and have code that implements them. Tools using this code will come soon.
Thanks to Chris Hanson, Steven Stepanek, Hendrik Cyrus, Mike Keller, Jeremy W Karpenske, Joseph Oswald, and Arnaud Abbati for sponsoring about one month of web hosting for the Gryphel project and over 4 days of health insurance.
March 4, 2018
SigCheck, SigWrite, GSgWrite, and MakeKeys are updated again, to fix an issue with the keyboard shortcut for the Host Copy command not working in System 6 and before. They have also been made generally more robust in System 6 and earlier, in protecting against desk accessories doing odd things. Also, they now work on a Mac 128K.
MakeRand has been updated to use the current editing code used in the other tools.
And finally, in today’s Mini vMac Development source snapshot, the build system is updated to use the same current editing window code. This includes the Cut/Copy/Paste commands that use the Host Clipboard, a working Undo command, and some other improvements.
February 25, 2018
There are new versions of SigCheck, SigWrite, GSgWrite, and MakeKeys, which are now declared to be in Beta (instead of Alpha).
The error reporting is a bit better, aborting with command-period can now work, and the user interface is now generally responsive when the programs are busy.
If you are checking a lot of signed messages with the same public key, you can put the key in a file named "pub_key.txt" in the same folder as the SigCheck application, and it will use that instead of asking for it.
Similarly, if you sign a lot of messages with the same secret key, you put the key in a file named "sec_key.txt" in the same folder as the SigWrite or GSgWrite applications, and it will use that instead of asking for it.
February 18, 2018
GSgWrite is a new tool for writing digital signatures that is very similar to SigWrite, except that it uses a different signature format. SigCheck has been updated to handle this new format. (Also SigWrite has been updated to include recent improvements in the text editing window code from SigCheck.)
The main difference in GSgWrite from SigWrite is that when a message containing a public key, or even a nested signed message, is signed with GSgWrite, the signed message contains the exact same text without modification. The PGP format created by SigWrite is designed to be read in one pass from beginning to end, so some kinds of text could cause confusion and have to be modified. The “GRY” format created by GSgWrite is designed to be scanned backwards from the end to find the end of the message body.
This makes the GRY format incompatible with the PGP format. And since it is incompatible anyway, some further changes were made.
First, the GRY format is a bit more compact. For a 1024 bit key, the body of the GRY signature is always exactly 3 lines of 64 characters each. Second, the GRY format format attempts to mitigate known weaknesses in the md5 checksum by including a second md5 checksum, of the same data with the bytes in reverse order. Even if someone finds a practical way to generate a file with a given md5 checksum, finding a file that also has the second checksum right is likely to be more difficult. (The size of the signature depends on the size of the key, not on the size of the digest. A larger digest is fine as long as it is smaller than the key.) Also, CRC-24 checksums for both orders are included in the digest, since code for CRC-24 is already there (used for protecting the signature body against accidental corruption).
February 11, 2018
Today’s SigCheck 0.4.0 now has a working Undo command, since I was in the area of the editing code. Again, this will later be added to all the other Mini vMac extras which share this code for an editing window.
Also in this version, it finds the end of the message that is signed by scanning backwards from the end of the text. Which would allow most anything to be in the signed message without modification, such as a public key or a nested signed message. But this would be incompatible with MacPGP, so I will define another signed message format to allow this, in the near future.
Thanks to Justin Williams, Rienk Koolstra, Marcin Rusinowski, Leo E Tognella, Jonathan Heiman, and Grafico Freelancer for sponsoring about one month of web hosting for the Gryphel project and 6 days of health insurance.
February 4, 2018
Today’s SigCheck 0.3.0, when run in Mini vMac, adds commands to the Edit menu that operate with the clipboard of the real computer instead of the emulated Mac. They have keyboard shortcuts that use the Option key. So Command-Option-V will paste the clipboard of the real computer into SigCheck. This simplifies using SigCheck, as ClipIn is not needed.
This feature will later be added to the other digital signature tools, and also the Mini vMac build system, and also other Mini vMac extras, which all share code for an editing window.
January 28, 2018
The Mini vMac Variations Service now signs the md5 checksum and other information for generated variations. (Automated signing was the reason for the lengthy excursion into digital signatures.)
The Variations Service has its own new signing key, with its own new page: Gryphel Key 2. There is also a new page for the main Gryphel Project Key, at Gryphel Key 1. This page also has links to copies of key placed elsewhere on the web, to help verify that it is correct.
January 21, 2018
MakeRand is a new tool for making random hexadecimal data, to be used with MakeKeys. So the digital signature tools (also including SigWrite) should now be usable. (SigCheck was already usable, for checking signed messages found on this website.) But these tools are still under development.
January 14, 2018
SigWrite is a new tool for writing digital signatures that can be verified with SigCheck (which has been updated). MakeKeys is a new tool for making secret and public keys to be used with SigWrite and SigCheck. These tools are regular Macintosh applications, unlike last week’s MPW tools to do the same thing. These tools are still under development and may have different behavior when finished.
One missing piece is a tool to generate truly random hex data to be used as input to MakeKeys. I'll adapt more code from MacPGP, which looks at the timing of key presses, to make such a tool soon.
January 7, 2018
There are new versions of SigWrtTl and MkKeysTl, two MPW tools which are still under development. The source code is being cleaned up to match previous work on SigCheck and SigChkTl, which in the process has served as code review, finding a number of things to fix.
December 31, 2017
SigWrtTl and MkKeysTl are two new MPW tools. They are still under development. Regular Macintosh applications to do the same thing should follow. SigWrtTl writes digital signatures that can be verified with SigCheck, SigChkTl, or MacPGP. MkKeysTl makes secret and public keys to be used with SigWrtTl and the verifying tools.
Also to come is a tool for making a file a random bytes for using with MkKeysTl. I decided to split random byte generation from MkKeysTl so as to make MkKeysTl much easier to test.
December 24, 2017
Last week’s SigCheck alpha is only the first of a planned trio. The second is a tool to sign a message, and the third to create a private/public key pair. Hopefully the next two should go faster from already being familiar with the MacPGP source. Also, as I remove unneeded code from MacPGP, I’m leaving code for both signing and key generation in as long as possible, rather than going through this process from scratch three times.
SigCheck can’t be finished until the other two utilities are done, because in some circumstances I want to use a slightly different format for signed messages than MacPGP does. In particular, when the signed message contains a public key. MacPGP allows reading several signed messages in a single file, and it reads the file linearly, so to reliably find the end of a signed message, some sequences of characters are not allowed in the body. So a public key gets modified a bit. SigCheck assumes there is only a single signed message, and could be changed to scan backwards from the end, so anything can be allowed in the body, such as an unmodified public key. For a balance of simplicity and compatibility, I think my signing tool will usually write MacPGP format, but if that would require modifying the body, it would use a different format, so the body remains unmodified.
December 17, 2017
SigCheck is a new tool for checking the signed checksums on this website. It is still under development, but seems to work. (It is regular Macintosh application, unlike last week’s SigChkTl MPW tool.)
December 10, 2017
SigChkTl is a new command line tool for Macintosh Programmer’s Workshop for checking the signed checksums on this website. It is still under development. A regular Macintosh application to do the same thing should follow.
December 3, 2017
After two weeks studying MacPGP source, digital signing looks relatively simple. I now have a much smaller amount of code that given a signed message and a public key in ascii armored format, will check the signature. I just have to clean it up to make a Macintosh program that can be used to check all the many signed checksums on this website.
(I think that these days it would actually be legal to distribute MacPGP here, but it would be necessary to fill out a form to notify the government, which I’d rather not deal with. Making a utility that only deals with digital signatures, rather than general encryption, I think avoids this issue. Also, a simple utility ought to be easier to use.)
November 26, 2017
I’ve increased the limit to 25 for the maximum number of requests per day to the Mini vMac Variations Service. This is just to make sure that no one who is using the service reasonably needs to worry about the limit.
The download page for a sponsored variation now displays the number of remaining requests available for the day. This limit is actually per build server, but this distinction doesn’t usually matter, since usually only a single build server is active, except for brief maintenance periods.
Mostly this week I have been looking at the source code for MacPGP. The Gryphel Project website has lots of signed checksums, but doesn’t provide a way to check the signatures. So I’m looking into whether it is possible to create a simple utility to do this kind of check.
Thanks to Johan Klassen and Chris Hanson for sponsoring over a month of web hosting for the Gryphel project.
November 19, 2017
With yet more optimizations, the turnaround time for the Mini vMac Variations Service is now usually down to 30 seconds (from one minute last week).
Thanks to Gianluca Abbiati, Malte Meyer, and Luis Hernandez for sponsoring over 3 months of web hosting for the Gryphel project.
November 12, 2017
With assorted optimizations, the turnaround time for the Mini vMac Variations Service is now usually down to one minute (from two minutes last week, and hours before last week).
November 5, 2017
I have set up an old Macintosh (Intel) to be dedicated to compiling variations for the Mini vMac Variations Service. This speeds up turnaround from hours to minutes. (At least when it is running. The scripts are designed to halt on first error, so that when I check on the machine later, it is easier to tell what happened, and try to make sure it doesn't happen again. So reliability should increase over time.)
The Variations Service has been reworked to allow more than one machine to do compiles. Eventually this might be useful in meeting larger demands than one machine can handle. But the much more immediate use is to make maintenance simpler. I can set my main computer to compiling variations while doing maintenance on the old Macintosh, so there is no interruption in service.
Supporting more than one machine doing compiles at the same time has consequences. Both machines trying to update a single list of the latest compiled variations would be messy, so that list has gone away. Instead, when a variation is requested, a new web page is made for it (which says that the variation is being compiled), and when the variation is compiled, the web page is replaced with a new version that has a download link and md5 checksum. Both machines can write such pages at the same time, since they are writing to different pages.
October 29, 2017
I’m back from travel. After considering feedback, I have implemented a new way to use the Mini vMac Variations Service. With the increased automation in the build system to reduce the cost of making variations, I can now offer as many variations as you can reasonably want for a year for a single donation of ten dollars or more. Where reasonable is defined as up to ten per day, every day. I personally regularly use about five variations total, so hopefully this should be much more than enough.
When you make a donation, you will receive a Sponsor Code to use in the form for the Variations Service.
With a Sponsor Code, you can skip the Demo version, so this is faster than the previous method of sponsoring a single variation. And not having to making a donation for each variation of course speeds and simplifies things. (Sponsoring a single variation will likely go away in the near future.)
I will retroactively send out Sponsor Codes to at least the people who have donated ten dollars or more in the last year.
Speaking of which, thanks to Chris Hanson for sponsoring over a month of web hosting for the Gryphel project.
October 22, 2017
I’ve been doing some travelling this week. But before that, I figured out a few ways to further automate the Variations Service, which could eventually allow more frequent batches, and consequently faster turn around.
October 15, 2017
Today’s Development source snapshot adds the Czech translation by Anonymous. (This required adding support for 11 new characters.)
I’ve updated the program strings on the localization pages to more exactly match the Mini vMac source code, which included work on scripts that convert between HTML and Mini vMac’s representation of international characters. I also created a primitive script to automatically convert received feedback from the web form with international characters into plain ascii HTML format, which led to finding a few mistakes I had made processing the Czech translation previously.
October 8, 2017
Today’s Development source snapshot is the start of the 3.6 branch. It has the Catalan translation by ArduinoXino. (This required adding support for a new character, ‘·’. The new Czech translation requires more new characters, and so will come later.) The one other change is to make the URL in the Mini vMac about message be the main Gryphel Project page, rather than the Mini vMac page, mostly since it is shorter, in case anyone tries to type it in from here.
The page hosting the game Glider by John Calhoun now includes the source code.
Thanks to W Brian Barnes for sponsoring a week of web hosting, and two variations, for the Gryphel project.
October 1, 2017
A Czech translation for the Mini vMac user interface has been anonymously contributed.
Thanks to G.S. Brenac for sponsoring over 3 days of web hosting, and a variation, for the Gryphel project.
September 24, 2017
ArduinoXino has contributed a Catalan translation for the Mini vMac user interface.
A page has been added to the software for Mini vMac collection with a link to Apple’s Thread Manager, which is needed by other software like MacBalsa.
September 17, 2017
Some more software is now hosted by the Gryphel Project: BinHex and Unpit.
September 10, 2017
Some more software is now hosted by the Gryphel Project: 3D-Edit (by request), MockPackage, and PackIt.
August 20, 2017
Today’s Mini vMac 3.5.8 updates the stable version to fix a problem on PowerPC OS X, and also fixes an issue affecting the Variation Service. Mini vMac 3.5.8 on platforms other than PowerPC OS X (‘mach’), and x86-32 OS X (‘imch’), should be identical to Mini vMac 3.5.7, except for the version string and modification date.
It was reported that “Mini vMac 3.5.7 wont run on PPC G3 systems”. It turns out that the GCC flag “-mmacosx-version-min” should be specified for all files compiled, not just the platform dependent code. It affects things like the required CPU. Making this change happens to have no effect on Mini vMac for x86-64 OS X, there is some effect for x86-32 OS X, and the largest effect is for PowerPC.
August 13, 2017
Mini vMac 3.5.7 is now officially released. That is, it is now declared to be the stable version, with no change made to the source code or compiled applications. It is available from the main Mini vMac Download page. The Changes file lists what has changed since Mini vMac 3.4.1. The 3.5 branch began June 27, 2016, entered beta April 2, 2017, and 3.5.7 was created July 9, 2017.
August 6, 2017
The Mini vMac 3.5.7 beta download page now offers Macintosh 128K emulation (the original Macintosh), in addition to the Macintosh Plus standard variation and a Macintosh II variation.
July 30, 2017
There are new pages for links to software for Mini vMac, using a format more consistent with hosted software, for: DYOH Architecture, DYOH Landscape, Sprout!, and MacMinix.
So now finally every program has its own page in the Software pages. (This has been a long project.) Most of these pages host a copy of the program, so in the index pages the “(hosted)” has been removed, it can be assumed a program is hosted if not marked with “(link)”. The about section in the main page has been updated to reflect that most programs are now hosted.
Thanks to Andrew Y. for sponsoring over 3 days of web hosting, and a variation, for the Gryphel project.
July 23, 2017
There are new pages for links to software for Mini vMac, using a format more consistent with hosted software, for: DateView, Eudora, UserLand Frontier, MacFlow, and Apple DocViewer. Some more software is now hosted by the Gryphel Project instead of only linked to: XLISP-STAT.
July 16, 2017
The Mini vMac 3.5.7 beta download page now offers Macintosh II emulation, in addition to the Macintosh Plus standard variation. This page and the download Mini vMac 3.4.1 page have been reorganized a bit.
I’ve added notes for using Mini vMac in recent versions of OS X.
There are new pages for links to software for Mini vMac, using a format more consistent with hosted software, for: Hypercard Player, Dali Clock, and InTouch.
Thanks to Brian Stevens for sponsoring over a week of web hosting for the Gryphel project.
July 9, 2017
Today’s Mini vMac 3.5.7 beta has a few bug fixes.
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 “?”.
After an “Abnormal Situation” is dismissed, it neglected to clear the 4 digit code, with the result that the code could be displayed when other messages are displayed, such as for the “About Mini vMac” command. The code is now cleared.
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.
In the Cocoa port, some more problems are fixed in the fix in Mini vMac 3.5.5, for incorrect cursor position while dragging the Mini vMac window. After the a dialog window, such as for open disk image, the mouse position would not be updated until the mouse moved. So Mini vMac now checks the mouse position after dialogs. A harder problem is the mouse position would not be updated after using the menubar, or window controls such as the close box (clicking and dragging off the control, so the window isn’t closed, and the mouse is moved). Mini vMac isn’t notified about these clicks. So instead now whenever Mini vMac notices that it hasn’t been given time to run for long enough, it will check the mouse position, which usually will take care of these cases. Perhaps it would have been simpler to find some way of getting the correct mouse position while dragging the Mini vMac window. But it is nicer, and ought to be more efficient, to rely on events for mouse position when possible, rather than constantly asking the OS where the mouse is.
The recent report about odd behavior on a Windows 10 tablet may now be understood, with no fix needed.
There are new pages for links to software for Mini vMac, using a format more consistent with hosted software, for: The Fool’s Errand, At the Carnival, 3 in Three, Disk First Aid, Disk Copy, TrueType™, Compact Pro, Acta, and MORE.
Thanks to Shitara Zenya for sponsoring over 3 days of web hosting, and a variation, for the Gryphel project. (Which also led to finding the Cocoa clipboard import issue.)
July 2, 2017
The Beta Variations Service now allows arbitrary screen sizes. Besides the menu choices, there is also a text field where you can instead type whatever size you like. (When the form is submitted, if this field is not empty, it is checked whether it is valid).
One of the two Abnormal Situation reports I mentioned last week turns out to be more or less reproducible. It is also reproducible in Mini vMac 3.4.1. It may be that all that is going on is that some Mac software can be a little buggy, and access address space it isn’t supposed to. So I’ve been thinking that there is no evidence of any situation where Mini vMac 3.5.6 is worse than Mini vMac 3.4.1, after months of testing, and it is time to leave beta.
But now there is odd report from a Windows 10 tablet user to look into first.
Some more software is now hosted by the Gryphel Project instead of only linked to: SgInfo.
June 25, 2017
Some more software is now hosted by the Gryphel Project instead of only linked to: LEE and Glider Design!. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: CRLF.
Three weeks of using Mini vMac 3.5.6, with the new enhanced Abnormal Situation reports, have yielded two reports. These two reports suggest the problem is not a new call to report an Abnormal Situation for what is actually a normal situation, but instead that something is randomly accessing memory. So I think the next step is to write (optional) debugging code to catch unusual accesses to memory, to greatly increase the percent of the address space that generates an abnormal situation report, hopefully making the reports much more frequent.
Thanks to William Winter for sponsoring over 2 weeks of web hosting for the Gryphel project.
June 18, 2017
Some more software is now hosted by the Gryphel Project instead of only linked to: MacShell, MicroArchitecture Simulator, and PDP-8/E Simulator.
I’ve finally obtained OS X 10.12 (Sierra), and verified the reported (twice) problem with the new Path Randomization “feature”. The operating system can copy the application somewhere else before executing it. So Mini vMac won’t see files that are placed in the same folder, like the ROM image. One workaround I’ve seen mentioned doesn’t seem to work, at least in 10.12.5 - moving Mini vMac to a different folder doesn’t turn off Path Randomization. One workaround that does seem to work is to run the command “xattr -c <path to archive>” in the Terminal to clear extended attributes on the downloaded Mini vMac archive before expanding it.
June 11, 2017
The Mini vMac Variations Service has changed again. A donation of two dollars or more to the Gryphel Project is now required. Perhaps this might encourage some people to use it, who previously didn't want to impose. For other people, the Beta Variations Service is still free. Actually, the main reason for the change is to encourage more people to test the Beta.
For the stable Variations Service, a Demonstration version is free. A Demo version is identical to the regular version, except that the word “Demo” floats across the emulated screen. (Code for this has been in Mini vMac for a while now.) If the Demo looks suitable, you can then sponsor that variation, with a donation of two dollors or more, and I'll produce the non Demo version. (A donation of exactly two dollars is fine and appreciated. The marginal cost of producing an additional variation is small.) Once sponsored, that variation is available to everyone, under the GPL license.
Some more software is now hosted by the Gryphel Project instead of only linked to: Sparrowhawk, Crossword Solver, Snow, and Markov. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Cruciverbalist, PlayFreeLotto, and CuliDataBase.
June 4, 2017
Today’s Mini vMac 3.5.6 beta fixes an issue in the Cocoa port and fixes a design flaw in “Abnormal Situation” reports.
Also, in other recent news, Tara Keeling has updated her Nintendo 3DS port of Mini vMac. It is announced in this GBAtemp.net post. It now supports Macintosh II emulation, with color.
The fix in Mini vMac 3.5.5, Cocoa port, for incorrect cursor position while dragging the Mini vMac window caused another problem. If you switched to Mini vMac using command-tab, the mouse position wasn’t updated until the mouse is moved. This is fixed by fetching the current mouse position when Mini vMac is activated, rather than only rely on mouse movement events. (Before 3.5.5, the Cocoa port would frequently fetch the mouse position, which was giving incorrect results during dragging the Mini vMac window.)
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. Which is what has happened. Over a few weeks I saw a couple Abnormal Situation reports in the beta that I couldn’t reproduce. Mini vMac worked fine afterwards, so I suspect that the report was not needed, it is just a situation that is rare but valid. I just need to find out which report, out of couple hundred, to remove. So I enabled debug logging and continued to use Mini vMac for weeks. And so far it has worked perfectly, unfortunately. Maybe I just haven’t used it enough.
So now in today’s version the regular non debug Mini vMac will display a number when reporting an Abnormal Situation, which doesn’t take much additional code. So if anyone runs across this issue, you can tell me this 4 digit hexadecimal number, and I will know exactly which report to remove.
(By the way, an explanation for all these “Abnormal Situation” reports: When trying to emulate some aspect of Macintosh hardware, my current strategy is not to try to figure it all out and then implement the entire emulation as best I can. Because if I did that, inevitably there would be a mistake somewhere, and when that causes some software to malfunction, I won’t have any clue of where to look for the mistake. Instead I would start with a place holder Abnormal Situation report. Then I find some Macintosh software that reaches that report, and look at that area of its code, and try to figure out what it is trying to do. Then I try to implement just enough emulation for it to work correctly, and give an Abnormal Situation report for code that does something else. If the Macintosh software still doesn't work, the problem is probably in the code I just wrote. If it does work, then I next try find some other Macintosh software that hits one of the new Abnormal Situation reports. And iterate. The result is code that is usually correct for what it does, and will tell you exactly where to look when it reaches something that hasn’t been implemented yet.)
Some more software is now hosted by the Gryphel Project instead of only linked to: SndConverter Pro, SndCataloguer, SndCollector, Simple Card, and Gene. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: FIT2EPS and EZIndex.
May 28, 2017
Testing proceeds on the Mini vMac 3.5.5 beta.
Some more software is now hosted by the Gryphel Project instead of only linked to: SignatureQuote, Swapper, kb8to7 and kb7to8, ChunkJoiner, Encryptinator, and Checksum. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Find In Files, TextToMac, Alex’s Encrypt, and Verifile.
May 21, 2017
Some more software is now hosted by the Gryphel Project instead of only linked to: MacBALSA.
Testing proceeds on the Mini vMac 3.5.5 beta. But actually, this week I have been traveling. There should be more work on Mini vMac next week.
May 14, 2017
Testing proceeds on the Mini vMac 3.5.5 beta.
Some more software is now hosted by the Gryphel Project instead of only linked to: LOANCALC, HTML Pro, MacSOUP, xLogicCircuits, xComputer, xTuringMachine, xModels 2D and 3D, and xSortLab. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: EveryHour and TextToHTML.
(Adding hosted software is a way for me test Mini vMac.)
I have noticed an issue in the Cocoa version that I haven’t found a fix for. Unlike in the Carbon version, the window bottom corners are rounded. Which slightly messed up the screenshots I’ve been making. It seems there used to be an undocumented way in Cocoa to make the bottom corners square “[window setBottomCornerRounded: NO]”, but it doesn't work anymore. For my purposes, a work around is to make screenshots in full screen mode, which actually works better.
May 7, 2017
Today’s Mini vMac 3.5.5 beta has three bug fixes.
After emulating an ADD instruction, if the value of the X flag was needed later, but in between there was another instruction that set the other flags not including the X flag, the lazy evaluation of the X flag was incorrect. This broke signing with MacPGP. While fixing this, I put in some debugging code to allow disabling lazy flag evaluation, so one can see if this code is responsible for an observed bug.
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.
Some more software is now hosted by the Gryphel Project instead of only linked to: Glk Hugo, Billionth Birthday, The TimeKeeper, iTime, and NETime. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Coffee Timer.
April 30, 2017
Today’s Mini vMac 3.5.4 beta has two bug fixes.
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.
In the Cocoa port, when import and exporting the text clipboard, Mini vMac was not translating the end of line format.
Some more software is now hosted by the Gryphel Project instead of only linked to: Inform, MaxZip, MaxTADS, Glulxe, and IFDropFile.
Thanks to Are Hansen for sponsoring over 2 weeks of web hosting for the Gryphel project.
April 23, 2017
Today’s Mini vMac 3.5.3 beta may fix a bug in the Windows version where the Mini vMac window is resizable. This bug was added in 3.4 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.
Also, two calls to display “Abnormal Situation” are removed after discovering they were called in normal situations.
Some more software is now hosted by the Gryphel Project instead of only linked to: Zippy-Type, Big Al FileLock, and GameMaker. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: TextChanger and Drop•BB.
Thanks to Chris Paterson for sponsoring almost 2 months of web hosting for the Gryphel project.
April 16, 2017
Today’s Mini vMac 3.5.2 beta may fix a bug found by Tara Keeling 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 I’ve increased the delay 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.
This version also fixes an issue with 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.
It also fixes an issue in the build system where “SCRNHACK.h” could be included in the generated source code when it isn't needed.
Debug information logging (“-log 1”) is now implemented in the classic Mac port. And logging code has been added to the replacement disk driver in “SONYEMDV.c”.
Some more software is now hosted by the Gryphel Project instead of only linked to: QuickLearner and Soundex. And some software is now hosted by the Gryphel Project where the original web pages have disappeared: Mini App Pack.
April 9, 2017
Another game is now hosted by the Gryphel Project: Dungeon of Doom.
Testing proceeds on the Mini vMac 3.5.1 beta.
April 2, 2017
Today’s Mini vMac 3.5.1 is the first beta of the 3.5.x branch. The Changes page lists differences from current stable 3.4.1 version. (The only change in the source code from the last Development snapshot is the version number.)
March 26, 2017
The latest Mini vMac Development source snapshot has a few minor fixes, mostly of compiler warnings. In preparation for moving to beta, this week I tested it with more development environments, then tested production compiles with each option individually, then recompiled the last couple hundred variation requests.
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 sponsoring over a half month of web hosting for the Gryphel project.
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 over 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.)
OLD NEWS - Previous release notes