(News Archive Index)
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.
July 5, 2020 - permanent link
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.
June 6, 2020 - permanent link
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.
May 31, 2020 - permanent link
Tara Keeling, who previously has ported Mini vMac to Nintendo 3DS, has reported she has Mini vMac running on an Espressif Systems ESP32 microcontroller.
May 28, 2020 - permanent link
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.
May 27, 2020 - permanent link
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.
May 23, 2020 - permanent link
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.
May 21, 2020 - permanent link
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).
May 17, 2020 - permanent link
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.
May 13, 2020 - permanent link
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.
May 9, 2020 - permanent link
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.
May 3, 2020 - permanent link
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 “-npd 0”, and you can use “-npd 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.
Older News (Index)