:
April 4, 2021 - permanent link
The MkKeysTl command line tool now supports multiple platforms, as was done for SigChkTl and SigWrtTl.
Compiling command line tools for m68k and mppc targets is now automated like all the other supported platforms. Except that they are not reproducible builds yet. It does not seem to be possible to clear junk out of the “Reserved for system use” area of a resource fork without the operating system immediately putting junk back in. Another approach would be to have to my tool for creating a “.sit” archive file clear this area in its output.
March 9, 2021 - permanent link
I noticed that some Apple System Software disk images I have fail the new test in Mini vMac 37 that is designed to protect files that aren’t actually Macintosh disk images by refusing to mount them. (The -ndp option, which defaults to on.) The boot blocks of these System Software images are garbage.
So today’s Mini vMac 37.03 beta no longer looks at the boot blocks, but only checks the master directory block.
February 14, 2021 - permanent link
The SigWrtTl command line tool now supports multiple platforms, as was done for SigChkTl.
While doing this, I worked out how to automate compiling command line tools using a networked virtual machine (in this case to compile for Apple Silicon), like is done for the Mini vMac Variations Service. To finish being able to compile for all supported platform with one command, I next should figure out how to automate compiling command line tools for m68k. Perhaps by using, for now, the technique used for compiling Mini vMac 3.5 for m68k, which is slower than current methods, but fast enough when not for the Variations Service.
January 30, 2021 - permanent link
A Chinese translation for the Mini vMac user interface has been anonymously contributed.
Unfortunately, as mentioned on the Mini vMac Localization page, displaying Chinese characters is not currently feasible for Mini vMac. I used Google Translate to convert the characters into Pinyin, and added a Chinese Pinyin page. This translation can be included in the next branch of Mini vMac. But I gather, from people who have previously considered doing the Chinese translation (1 2 3), that it would not be very useful. (Elsewhere I have seen it compared to an English speaker trying to read English written in the International Phonetic Alphabet. Even without previous practice it is doable, but slow and awkward.)
January 27, 2021 - permanent link
The SigChkTl command line tool now supports multiple platforms. It was previously written in a platform independent fashion, but I only provided a binary for MPW. I had compiled it for OS X, and use that extensively, but only for my own private use. After creating the cross platform command line tool ua608d, I decided I could support multiple platforms for other tools.
January 14, 2021 - permanent link
The ua608d command line tool is now also compiled for Apple Silicon.
January 12, 2021 - permanent link
PCalc has been added to the software hosted by the Gryphel Project. (As part of testing the Mini vMac 37.02 beta.)
December 20, 2020 - permanent link
Today’s Mini vMac 37.02 beta should fix sound not working on Apple Silicon, as reported by Patrick. Some of the deprecation warnings by the compiler should have been looked at more closely. A patch by Dominik Reichardt to the library SDL could be adapted to Mini vMac.
Also for this beta, I obtained a new Apple signing certificate. They expire after a while, so I think it best to get a new one for each new branch of Mini vMac. But not change the signing certificate for the previous branch of Mini vMac, since the idea is that the Variations Service will always give the exact same results given the same options. Compiling with different signing certificates for Mini vMac 36 and 37 turned out to be tricky, Apple signing tools are very finicky.
December 13, 2020 - permanent link
Today’s Mini vMac 37.01 is the first beta of the 37.xx branch. The Changes page lists differences from current stable 36.04 version. (The main change in the source code from the last Development snapshot is just the version number. The other change is suppressing some deprecation warning messages when compiling the Apple Silicon version. I need to replace usage of OpenGL sometime, but not now.)
Moving to beta means no further changes except bug fixes in this branch. It is happening now so as to have a stable version supporting Apple Silicon as soon as possible.
December 9, 2020 - permanent link
The latest Mini vMac Development source snapshot adds support for Microsoft Visual Studio 2019 (with “-ev 16000”).December 4, 2020 - permanent link
The latest Development source snapshot makes the Apple Silicon version significantly faster, when compiled by the Variations Service (select branch 37 and use the option “-t mcar”). This was accomplished by choice of compiler configuration options.
It is now of comparable speed or faster on an M1 Mac Mini as it is on an Intel i7 Mac Mini. It probably could be decisively faster, except for a compiler limitation. For other targets, Mini vMac takes advantage of the “Global Register Variable” extension of GCC, but GCC is not available yet for Apple Silicon, and Apple’s Clang compiler has poor support for this extension. On initial reading, I thought it wasn’t supported at all, just a possible future feature. But on giving it a try, and then some trial and error, I found a way to invoke it that seemed to work, and didn’t crash the compiler. But only for a single variable, attempting two causes the compiler to emit spurious invalid instructions that the assembler complains about. This does not inspire confidence, but even a single global register variable significantly speeds up Mini vMac, so I think it is worth trying to use. (All the other compiler configuration tweaks so far seem to generate better code that isn’t significantly faster.)
The next step is to support the latest version of Microsoft Visual Studio, and then move Mini vMac 37 to beta, so as to have a stable version supporting Apple Silicon as soon as possible.
November 28, 2020 - permanent link
The Variations Service now supports compiling Mini vMac 37 (Alpha) for Apple Silicon. On the Text Based Variations Service page, select branch 37 and use the option “-t mcar”.
The result is only a bit faster than the Intel version in Rosetta 2. The next step is to optimize for this particular compiler.
November 22, 2020 - permanent link
The latest Development source snapshot adds support for XCode 12.3 command line tools, for both x86-64 and Apple Silicon, matching the results from the IDE.
The next step is to use this to add Macintosh on Apple Silicon to the Variations Service.
November 19, 2020 - permanent link
Work on the reference CPU emulator has been interrupted by Apple’s announcement of new ARM based Macintosh Computers.
The latest Development source snapshot adds support for XCode 12.3 (with “-ev 12300”), and a new target “-t mcar” (Macintosh on ARM).
I now have access to one of these new computers with ARM (also known as Apple Silicon, and the specific chip is called M1). Mini vMac for x86-64 seems to work fine on an M1 Mac Mini using Rosetta 2, with reasonable performance. A typical CPU score from Speedometer is around 146.000. On an Intel i7 Mac Mini 2018, a typical score is 438.000.
Mini vMac compiled for ARM on XCode worked on the first try, and got a score of 219.000. But this is without any tweaking for this specific compiler at all. With tweaking, I would be surprised if it does not end up faster than the i7 Mac Mini.
The Speedometer CPU score is a very rough measure. Other scores from even the same program give somewhat different results. For example, the Math score is actually already slightly better for the new M1 version than on the i7.
The next step is to support compiling for Apple Silicon with XCode command line tools, and then add it to the Variations Service.
November 4, 2020 - permanent link
The latest Development source snapshot fixes a few minor issues in the CPU emulation code.
I’m working on a way to deal with reports of Mini vMac not emulating software correctly that a different Macintosh emulator can, when the emulation of the CPU is the likely problem, by creating a reference CPU emulator. The reference emulator is designed to be as simple as possible while still being as accurate as possible, unlike the current CPU emulation of Mini vMac which is more about balancing performance and compactness. But the important difference is that the reference emulator will be designed to be easily grafted into another CPU emulator, using the CPU state of the host emulator, so that individual instructions can run on either emulator. By varying exactly which of the 65536 primary opcodes go to which emulator, one can determine exactly which one is causing a difference in behavior.
Creating the reference CPU emulator, using the current one in Mini vMac as a starting point, is also serving as a code review. I have noticed a number of minor issues, the most serious of which is that some opcodes would not be recognized as illegal. Mostly, a number of comments were incorrect.
October 21, 2020 - permanent link
I’ve upgraded the hardware for the Variations Service. It is more than twice as fast, around two seconds to compile a variation. But the main motivation is that having more memory allows having multiple virtual machines (with VMware Fusion). This allows moving away from using a single set of cross compilers, using other compilers with whatever operating system they require in a virtual machine. Which will allow for supporting more platforms, especially new platforms.
Using a newer Macintosh required using a newer version of macOS. Which was the main factor in this taking a while. I’ll skip rants. Actually, in the end, so far it seems this macOS version can run the Variations Service fine. After disabling most of the OS.
October 4, 2020 - permanent link
The latest Development source snapshot fixes a bug where, if the ROM image file that Mini vMac finds is not the desired ROM, but a different valid Macintosh ROM that has been renamed, and the undesired ROM is larger than the desired ROM, Mini vMac would display a “ROM checksum failed” message instead of the “Unsupported ROM” message. This is because Mini vMac loads and computes the checksum of the expected number of bytes, rather than the actual ROM image size. (It is intended behavior that Mini vMac will work if the ROM image file has some extra junk at the end.) Mini vMac now checks that the checksum field at the start of the ROM is recognized, before verifying the actual checksum. Thanks to a bug report for pointing out this issue.
September 27, 2020 - permanent link
The latest Development source snapshot fixes the bug that the program Winter Games by Epyx would not work in Mini vMac. Thanks to Jesus A. Alvarez (“zydeco”, author of the iOS port) for figuring out why, and providing a patch to Mini vMac to fix it. The game directly modifies the VBL queue data structure of the Macintosh operating system to add a VBL task, instead of calling the operating system routine VInstall, but doesn’t account for the possibility of the queue being empty. The fix is to have the Mini vMac replacement disk driver add a VBL task at boot, as the original disk driver does, so that the VBL queue is not empty.
September 20, 2020 - permanent link
From the Mini vMac Variations Service error logs, I realized that Mini vMac would fail to compile with the options “-m II -em-cpu 0”" (Macintosh II emulation with 68000 CPU). This is fixed in the latest Development source snapshot. However, these options still do not work, because the Mac II ROM does not work on a 68000. So in addition, the Mini vMac compile setup code now gives an error message for these options.
September 12, 2020 - permanent link
The latest Development source snapshot may fix a bug where, in Linux (and other ports using X11), if two keys on the keyboard are configured to act the same way (such as if the caps lock key has been made to act as an additional control key), Mini vMac would only recognize one of the keys. Thanks to Adrian Carpenter for reporting this issue, and providing a patch to fix it.
September 6, 2020 - permanent link
I have set up a copy of the Gryphel Project web server in a VMWare Fusion virtual machine. This makes it easier to test changes before going live. In particular, I used it to further test last weeks work on the Variations Service (using a VMWare Fusion VM for the OS X compile) and fix a few glitches. Before going live with it, the next step is to further reduce the memory requirements of the OS X VM.
August 30, 2020 - permanent link
I have figured out how to make the Variations Service use a VMWare Fusion virtual machine to compile the OS X versions of Mini vMac, without losing speed. Before the current scheme of using a set of cross compilers, Mini vMac was compiled with VMWare Fusion images, but a virtual machine was booted and shut down for each compile, which was much slower. The current set of cross compilers are efficient and convenient, but have some limitations.
The biggest advantage of using a single GCC version for all compiles is increasing the odds that Mini vMac will work correctly on the platforms I don’t use much myself. Another is that it will run equally efficiently for all platforms on the same CPU, and the source only needs to be tweaked for that one compiler version.
But the big limitation is that my particular GCC version doesn’t support all platforms. Especially platforms that didn’t exist when it was released. Like the upcoming ARM Macintosh. So the quickest way for Mini vMac to support such new platforms is to figure out how to efficiently use a native compiler for that platform. I’ve generalized the techniques used to coordinate between the Mini vMac web server and the build server (via ssh), to coordinate between the build server and another machine that does a native compile. Since only ssh is used to communicate, the native compile machine can either be virtual or real, and local or a few hundred miles away.
I don’t have an ARM Macintosh yet, so it is a different cross compiler limitation that is being solved now. For the OS X version, my cross compiler only has the C compiler, other native tools are needed to build the application. In particular a native tool is needed to sign the application, and different versions of OS X have different versions of this tool that give different results. The build server and my main development machine are running different versions of OS X, and so compiles give different results, which is inconvenient. Running the OS X compile in a virtual machine, that has the same OS version as the build server, allows my development machine to give the same result.
A difficulty in using OS X in a virtual machine this way is that recent version of OS X have dozens of background processes running, for cloud this and cloud that, that have less than zero value for this use (or ever, for me), and raise memory requirements. I’ve been looking into them one by one to see what can be disabled. An additional benefit is that I might be able to trust recent versions of OS X more, after removing the unwanted stuff.
August 16, 2020 - permanent link
Blanks version 1.1 adds a 720K HFS image, by request.
We have resurrected the only surviving version of the source code to Professional Air Traffic Control Simulator. A pdf of the unreleased development version PATCS 1.2 source was passed into the open source tool pdftotext, and the result manually cleaned up (hopefully with not too many mistakes), and compiled using Microsoft QuickBasic. Also, some additional documentation has been uploaded here.
August 9, 2020 - permanent link
Professional Air Traffic Control Simulator has been added to the software hosted by the Gryphel Project, with permission of the author.
August 5, 2020 - permanent link
Previously, access to the Mini vMac Variations Service has been a perk for sponsors. But it has been a bit of a problem that for me to receive notification of a donation by email and send out a sponsor code can take some hours.
So now I have arranged to also sell the codes through the e-commerce company FastSpring, which makes them available immediately after purchase. Since FastSpring won’t have anything to do with donations, I have renamed sponsor code to “Subscriber Code”.
August 1, 2020 - permanent link
ua608d is now also ported to MPW for PowerPC Macintosh. While doing that I’ve been contemplating how to add back in support for PowerPC Macintosh for Mini vMac. I set up an old Mac Mini G4 as a headless build server, but it turns out that SheepShaver on a more recent Intel Mac Mini is faster at compiling. I just need to figure out how to reduce the overhead in invoking it. For Mini vMac 3.5.8, compiles used a set of VMware Fusion VMs, and took a minute. Mini vMac 36 now uses a set of cross compilers that takes only few seconds, but with the disadvantage of only supporting a limited number of platforms. A hybrid approach may be possible.
July 23, 2020 - permanent link
ua608d is the first public release of a new command line tool for unarchiving two Macintosh System Software disk images from Apple: “SSW_6.0.8-1.4MB_Disk1of2.sea.bin” and “SSW_6.0.8-1.4MB_Disk2of2.sea.bin”, made necessary when it was pointed out that the current version of Stuffit Expander no longer can deal with them, which breaks the “Getting started with Mini vMac” documentation.
ua608d descends from the command line version of The Unarchiver, with everything removed except what is needed for these two particular archives. It is also translated to plain C, from Objective-C, and uses only the C standard library. Which made it easy to compile for 17 different platforms, so far.
July 15, 2020 - permanent link
Things are delayed by a plumbing emergency, but after a third week on the extract of The Unarchiver source, it is down to 20K compressed, and more importantly, it is now a plain C program (translated from Objective-C), using only the standard library. Some clean up remains, then compiling for multiple platforms, and then documenting and releasing.
After a second week on The Unarchiver source, it is down to 33K compressed, still able to extract the System 6.0.8 install disks, and the desired program is beginning to emerge. While taking longer than hoped, I might as well finish it, after spending this much time.
June 28, 2020 - permanent link
After a week of work on The Unarchiver source, it is just under 100K compressed, as compared to the original over 2.5M, while still able to extract the System 6.0.8 install disks. To be continued.
June 21, 2020 - permanent link
Since having “permanent links” has worked out pretty well for the Mail Archive, I have changed the News Archive to work the same way, after first reorganizing and splitting the news into ten volumes. I tried improving the navigation a bit, and then did the same to the Mail Archive.
It has been pointed out that the current version of Stuffit Expander no longer can deal with the two System 6.0.8 install disks from Apple. Which breaks the “Getting started with Mini vMac” documentation. Not Good.
I notice that one of my listed alternatives to Stuffit Expander, “The Unarchiver” for OS X, has command line versions for Windows and Linux. So I could change the documentation to make this the first choice, and mention old versions of Stuffit Expander in the alternatives.
But the command line version of The Unarchiver doesn’t seem to me all that well documented. And it deals with a very large number of formats, and so is quite large. Also it has changed location on the web several times, and changed ownership, so I suspect that if I link to it I may have to revisit this issue in not too many years.
But the command line version is open source. So I’m wondering how hard it would be to strip it down to a simple program that only deals with the two System 6.0.8 install disks and nothing else, written in C using only the standard library. I have already gotten it to compile in Linux, and figured out how to remove about half the source. I also figured out how to use the gcov tool to help identify the unused code. The question is whether this is a project of a week or two, or whether it would take months.
June 13, 2020 - permanent link
In the latest Development source snapshot, all of the optional C source files now have preprocessor conditionals, so that all of the files can be compiled and linked together regardless of the user options. With this change and last weeks changes to the setup tool, it is now possible for anyone to implement external ports which support compiling all user variations, without making any changes to the official Mini vMac source and setup tool.
To illustrate and test out this new mechanism for external ports, the source snapshot page has a port of Mini vMac to X11 for Macintosh OS X 10.7, which allows variations to be compiled with command line tools from XCode, without support from the setup tool. Actually, the setup tool does currently support this port with “-t mx64”, but it is candidate for removal since it is obscure and external ports are now possible. (Apple removed the X11 utility a long time ago, though it still seems to be available as a separate open source project.)
The build system has a new option, “-af”. The configuration tool normally arranges that only source files needed for the current user options are compiled. This option causes all files to be compiled, which works because the source files themselves now contain preprocessor conditionals to skip the unwanted code. This option also causes inclusion of all API header files and link libraries that could be needed for any set of user options, rather than only what is needed for the current user options. This option can be useful when creating an external port based off a supported configuration. The files of an external port need to work for any set of user options.
In the latest Development source snapshot, the build system has a new target option, “-t port”.
On further consideration of issues for other people porting Mini vMac, and contemplating how such ports have been done, I think there is an approach to assisting such ports, so that no changes are needed to the setup tool to allow Variations. I have started to split the generated configuration files into files that depend on the current target platform and compiler, and files that depend on user (not developer) options. Ideally there should be no overlap. Then, for “-t port”, the build system does not generate the platform/compiler files. They instead can be supplied beforehand in a new directory, say one named “add” (for “additions”).
Then a fully functional port to a specific platform and compiler, that supports compiling for all user variations, could be implemented without my involvement, and without any changes to the Mini vMac “src” and “setup” folders, by providing an “add” folder, and perhaps a configuration script that compiles the setup code and calls it.
There are a number of issues to work out. I’m thinking that for some platform/compiler combinations which currently have some support in the setup tool, but are not supported by the Variations Service, I could instead use the “add” folder mechanism. This would help develop the new mechanism, and simplify the setup tool.
The specific configuration files split are CNFGGLOB (into CNFUIALL and CNFUDALL), CNFGRAPI (into CNFUIOSG and CNFUDOSG), and EMCONFIG (into CNFUIPIC and CNFUDPIC). While at it, I created three new files OSGCOMUD.h, OSGCOMUI.h, and PICOMMON.h to group together common includes, and which also happen to make it possible to make use of pre-compiled header files, when the compiler supports it. Most of SYSDEPNS in is now in a new file DFCNFCMP (for DeFault CoNFiguration for the current CoMPiler). And MYOSGLUE is renamed to OSGLUAAA.
Tara Keeling, who previously has ported Mini vMac to Nintendo 3DS, has reported she has Mini vMac running on an Espressif Systems ESP32 microcontroller.
On further consideration, I think the new Variations Service (based upon an existing variation) is more useful than how it used to work, but not as good for a beginner, needing a bit more explanation. And making it is easy to start using the Variations Service is a high priority.
So I’ve restored the main Variations Service page to mostly how it worked before (but still leaving the new branch option), labeled it as “intro”, and then replaced the links at the end for advanced/text variation services, to a single link to a new Variations Service Index page. This new page has links to the advanced and text variations, plus a new page for basic variations. All of these pages are in the new style that are based on an existing variation.
In further response to this report, I have merged the stable and alpha Variations Services into a single set of pages, which have a pop up menu to choose the branch compiled. This new Variations Service should make it easier to find where to make alpha variations. And also it is easier for me to maintain.
In response to this report, I have changed the Alpha Variations Service, Basic and Advanced, to allow and strongly encourage entering the options from an existing configuration (using Control-P), as was previously only possible in the Text Based Variations Service.
I think this provides a more natural way of using the Variations Service. The use case is that as you are using a variation, you realize you would like to change an option, so you copy the variation string with Control-P, paste it into the Variations Service, change the desired option, and the press the “make” button. If you realize you want to change another option, repeat. As opposed to going through all the available options to figure out what you really want all at once.
In response to suggestions by Tara Keeling for making it easier to port Mini vMac, in the latest Development source snapshot the source code for the SDL 1.2 and SDL 2.0 ports are merged into one file. Then SDL has been made the "reference implementation", containing comments that apply to all the ports. From Mini vMac version 2.8.0 up to (but not including) version 3.2.0, there was a “gen” (generic) reference port intended to provide a skeleton for porting to new platforms. But since it wasn’t normally used, it tended to get out of date, and so was removed. Instead the comments were move to classic Macintosh port, chosen as being neutral between modern platforms. But these days, SDL is a much more practical starting point for porting. After you get it working with SDL, if you want a more native port, you can merge the source of SDL and Mini vMac, and then step by step clean it up, until almost nothing of SDL remains. The Cocoa port was made way, with no prior knowledge of Cocoa or Objective-C. This technique takes a while but is straightforward.
The SDL port has been further modified so that if it is compiled without including the SDL headers, it will not use SDL, only standard C libraries. Just as the “gen” port used to. This minimal port actually functions, even without screen, keyboard, or mouse emulation. If you prepare a disk with AutoQuit and CopyRoms, it will run and quit, saving a ROM image. Which tests that most of Mini vMac functions, and now you just need to implement the platform specific parts. Which is an alternative approach for target platforms where SDL is not available, or for people familiar with their target platform who don’t want to fuss with SDL.
A consequence of the merge of SDL 1.2 and SDL 2.0 code is that the “-d” and “-n” command line arguments now work for SDL 1.2 too.
Another change, that can be helpful for debugging, is that if dbglog_HAVE is defined to 1 in CNFGGLOB.h, but dbglog_buflnsz is not defined (in CNFGRAPI.h), then buffering is now disabled. Which helps prevent losing the log if Mini vMac crashes or is terminated (at the cost of slower logging).
In the latest Development source snapshot, the choice of development environment is a run time option of the setup tool, rather than configured at the time the setup tool is compiled. Which is a reversion to more how it worked in Mini vMac 3.5, two branches ago. The motivation for this is that while compiling all official binaries with a single version of GCC (compiled into a set of cross compilers) is very nice and very convenient, I’m starting to think it may be too limiting. Making the development environment a run time option for the setup tool should make it easier for the Variations Service to use other compilers for platforms my GCC version doesn’t support. The trade off is in making the setup tool larger and slower, which might possibly slow down the Variations Service a few milliseconds - not expected to be a serious problem.
While I was at it, I converted all other compile time options of the setup tool to run time options. (Again, a reversion to how it used to work.) Because needing to configure a configuration tool is kind of ridiculous.
Tara Keeling has updated her Nintendo 3DS port of Mini vMac.
In other news, this Gryphel Project website now passes the html checks of BBEdit. While figuring out the problems with compiling Mini vMac in XCode 11.4.1, I set up XCode in Catalina, contemplated it a little while, and then installed BBEdit, opened a terminal, and ran the command line versions of the XCode compilers to debug the issue. I expect XCode would be easy to use, once I spent the time to learn it. (I used to use it, but a long time ago, and it’s evolved.) I usually use the free TextWrangler, but it won’t run in Catalina, so I had to install the current BBEdit, which start starts out as a free trial before converting to a TextWrangler replacement. So I tried out the website checking feature, and it found hundreds of errors, which I’ve corrected. Now I may buy BBEdit, so BBEdit’s trial strategy is a good one.
The latest Development source snapshot may fix reported issues on Macintosh retina screens when compiling with recent versions of XCode. It now calls “setWantsBestResolutionOpenGLSurface:NO” when available. A comment found in SDL 2.0.12 explains: “Note: as of the macOS 10.15 SDK, this defaults to YES instead of NO when the NSHighResolutionCapable boolean is set in Info.plist”. This problem occurred because the NSHighResolutionCapable key was added in July 2018 to make the window frame look better on retina screens.
But I also found another issue when compiling with XCode 11.4.1, there was a lot of excess drawing. Every time lockFocus/unlockFocus was called to draw to the window, a call to drawRect got triggered for the entire window. Research indicates that lockFocus/unlockFocus are deprecated, you are never supposed to draw outside of drawRect, and only notify the OS what needs to be drawn. So I tried that, using setNeedsDisplayInRect. No matter what rectangle is passed, drawRect still draws the entire window. It is hard to believe macOS is really that broken. Probably there is something else about what Mini vMac is doing to make the operating system unhappy. But I don’t know what. Before giving up for now, I tried simply removing the lockFocus/unlockFocus, and that seems to work fine. It doesn’t seem correct, but the main thing it is supposed to do is set the drawing context, and Mini vMac is already calling makeCurrentContext with the OpenGL context. So I’ve left it like that for now. A bigger issue is that OpenGL on macOS is now deprecated, and the shiny new thing for drawing is Metal. SDL seems to a have Metal implementation, so I should look into that eventually.
In the latest Mini vMac Development source snapshot, AutoSlow is now enabled by default for Macintosh II emulation, matching the default for emulation other Macintosh models. To try to make this work properly, for Macintosh II emulation it now waits 60 ticks rather 34 ticks for AutoSlow to activate. (This was in response to this report.)
Also this bug is fixed - if Mini vMac is attempting to display a new message overlay on every tick (the kind that says “Type C to continue”), the message would never appear. This was found because I was attempting to use this mechanism for a quick and dirty way show AutoSlow status while debugging its behavior.
April 26, 2020 - permanent link
In the latest Mini vMac Development source snapshot, the emulation of VIA timer 2, used for playing sound, has been modified when running at greater than 1x speed. There is no correct behavior in this case, it is just a matter of picking what has the best compatibility with the greatest number of programs. This change fixes a reported issue with HyperCard, as well as playing alert sounds in the Sound control panel, and the "Try Scale With Sound" command of ResEdit. However it also no longer passes the Clock/Interrupt Test of MacCheck. Which seems a good trade off, unless further issues are found. (A program to test hardware *should* notice that something is strange when run at greater than 1x speed.) The specific change made is that timer 2 now continues to run during extra cycles only for the duration of a short timer interval, rather than continuing to run in this case until the end of the extra cycles. (Normally, the timer is paused for the extra cycles.)
In addition, the recent change to, by default, prevent attempting to mount files that are not Macintosh disk images, would also prevent mounting some disk images that had not been unmounted correctly, and some MFS disk images. The checks have been relaxed a bit.
April 23, 2020 - permanent link
The latest Mini vMac Development source snapshot fixes handling of condition codes in the emulation of the BFINS instruction in the Macintosh II. The N and Z flags should be set from the new value, instead of the old value, unlike the BFSET,BFCLR, and BFCHG bitfield instructions. Thanks to Christophe for this fix, adapted from the same fix in WinUAE. (Some of the CPU emulation code of Mini vMac descends from UAE.)
April 19, 2020 - permanent link
I finally got the latest XCode version running on the latest macOS Catalina version installed in the latest VMware Fusion version (running on a headless Mac Mini controlled by screen sharing). Anyway, compiling and running Mini vMac on that seemed to work fine. Tending to support the idea that reported problems are with retina displays. So I obtained Apple’s Quartz Debug tool to Enable HiDPI display modes (for a virtual display that is otherwise to small for it). And with that, I can finally reproduce a problem.
Next comes looking into how correctly support HiDPI display modes. (Oddly the official binary I provide, not compiled with XCode, seems to work fine with retina displays.)
April 12, 2020 - permanent link
The Mini vMac Variations Service (and Alpha Variations Service) now have a separate “.inf.txt” file with the signed checksum, rather than putting this information in the generated web page. (Similar to what was done last week for Mini vMac standard downloads and Mini vMac extras.)
April 5, 2020 - permanent link
All of the Mini vMac Downloads, and all of the Mini vMac extras, now have a separate “.inf.txt” file with the signed checksum, rather than putting this information in the web page. The link to it in the web page is named “info” and is right after the main download link. Being able to easily download both the main file and the corresponding signed checksum file at the same time makes it easier to check the integrity later. This change also makes updating files and other maintenance easier for me.
March 29, 2020 - permanent link
The latest Mini vMac Development source snapshot fixes the “-lto bpf” option that was recently broken. For the LocalTalk emulation with default “-lto udp”, in the Windows version, it now requests version 2.2 of Winsock rather than 1.0. Upon closer reading of the documentation, it turns out this is supposed to be the highest version the program can support, rather the lowest version it can support.
LocalTalk emulation (with “-lto udp”) is now enabled for FreeBSD. But it does not seem to work. This may or may not be an artifact of my particular VMware image, which was not set up with networking stuff in mind. I should install some more recent FreeBSD and try again.
A typo in a ReportAbnormalID message (“kVidROM_Size to small”) is fixed. This fix was found in a fork on Mini vMac on GitHub by invisibleUp. I would also agree that the prefix “My” is overused in the source code. One intended use for it is to distinguish between identifiers belonging to the OS API and similar identifiers belonging to Mini vMac.
March 15, 2020 - permanent link
The latest Mini vMac Development source snapshot fixes compiling Macintosh II emulation in the Variations Service (that was recently broken). It also supports “-lto upd” for “-t imch” and “-t mach”; that is, the new LocalTalk over UDP implementation by Rob Mitchelmore now works for OS X on x86-32 and PowerPC.
I’ve been a bit distracted by a little travel, a mild cold (really, I’m pretty sure), and too much reading news. Less distractions are expected in the immediate future, sitting at home.
March 1, 2020 - permanent link
In responding to feedback about HFVExplorer or ImportFl, I have revised pages to indicate that ImportFl is preferred, and that HFVExplorer and similar techniques on working with disk images page are no longer recommended.
Realizing that ImportFl is most commonly used for archives that StuffIt Expander can deal with, I have made a new version of ImportFl that sets the new file “creator” code so that double clicking on the file opens it with StuffIt Expander.
Also I realized that it is not very nice to have to put a big warning in the ImportFl documentation about what happens if you try to import a file and ImportFl is not active. So in the latest Mini vMac Development source snapshot, Mini vMac will now check if a disk image that is being mounted looks like a Macintosh disk image format (HFS or MFS), and if not decline to mount it, showing an error message. This helps prevent accidentally corrupting other files, especially when using ImportFl.
But there are some other disk image formats that you might want to mount, such as Fat16 and ISO (which can be used by the emulated Macintosh with additional software). Or, you may be trying to create your own new disk image and want the emulated Macintosh to initialize it. In these cases you can use a version of Mini vMac compiled with the new “-ndp 0” option to turn off this protection.
If a Branch option prior to 37 is chosen for compatibility with an earlier version, the default is “-ndp 0”, and you can use “-ndp 1” to turn on this protection.
February 23, 2020 - permanent link
In the latest Mini vMac Development source snapshot, LocalTalk emulation over UDP now works on Linux and Windows, in addition to OS X. (Or, at least, each worked for at least one test. More robust testing should follow.)
Furthermore, it sets PRAM to boot with AppleTalk enabled, which now works.
February 16, 2020 - permanent link
The latest Mini vMac Development source snapshot continues work on LocalTalk emulation.
February 9, 2020 - permanent link
The Alpha Variations Service is now set up for the new Mini vMac branch 37, including the advanced and text based versions.
I didn’t mention last week that in merging Rob Mitchelmore’s code, I added a new “-lto” option to select between the new LocalTalk over UPD and the previous LocalTalk over BPF. The UPD option is now the default for branch 37. If a prior “-br” (Branch) option is chosen for compatibility with an earlier version, the default is BPF.
February 2, 2020 - permanent link
Today’s Mini vMac Development source snapshot has an initial merge of Rob Mitchelmore’s LocalTalk over UDP code.
January 19, 2020 - permanent link
Today’s Mini vMac Development source snapshot is the start of branch 37. It has a fix from Ryan to a bug where the built in disassembler incorrectly handled the BCHG/BCLR/BSET/BTST instructions.