www.gryphel.com/c/mail/v10 - feedback

Gryphel Project Mail

Volume 10

To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Sat Mar 28 18:39:19 2020

thank you for Mini vMac! I use it a lot.

Unfortunately your variation service seems to have a problem at the moment. Every time I try to generate one I get "Sorry, I failed to compile this variation"

I'm just trying to make pretty much standard variation, just running in 800 x 600 resolution.

status : believed fixed

Thanks for the report. I’ve confirmed that Macintosh OS X PowerPC builds were broken. I think it is fixed now.

I believe I broke this while recovering from a drive failure in the build server in the beginning of February. I verified the integrity off the cross compilers and their supporting files, but the Macintosh builds use some files from the host system. And one wasn’t adjusted for a change I made in how the replacement drive was configured.

permanent link

Sent: Thu Mar 26 16:59:18 2020

[previous message]

One user wrote:

"I'm curious as to the behavior of fullscreen mode when invoked by ctrl-f versus the compile option. I have a 13" MacBook air and use macports to build mini vmac with screen size option -hres 704 -vres 450 (exactly half the vertical screen height)."

Doesn't HRES and VRES have to be a multiple of 32? In this case 450 isn't and may be the source of the problem.

status : responded

Thanks for the suggestion. But only “-hres” has this constraint, not “-vres”, so that is not the issue in this case.

I believe the issue is as previously stated, and a fix is pending.

permanent link

Sent: Tue Mar 17 08:15:41 2020

Hi Paul,

please stay healthy. And thanks for your wonderful work.

- Karl

status : responded

Thanks. Sneezing with no fever for a few days, which is over now, almost certainly means cold. And at age in low 50s, with no known condition, I’m not at that high risk. But living with people at much higher risk means trying now to stay healthy at all costs.

Please try to stay healthy yourself, and same to other readers.

permanent link

Sent: Tue Mar 17 04:12:16 2020

A question? Can this virtually also operate on Android mobile?please send answer to [... email address ...] appreciated thank you for your time.

status : responded

There is a port of Mini vMac to Android, though I am not involved with it. See the Ports page.

permanent link

Sent: Sun Mar 15 21:18:59 2020
Sent: Sun Mar 15 22:54:09 2020
Sent: Mon Mar 16 00:15:02 2020

Hi Paul,

I've been working with building the Mini vMac source from scratch. I'm emulating a Mac 128k. The Mac's screen on the version I build seems blurry compared to the standard 128k variant I can download from your site, almost like the version I'm building isn't optimized for my Retina MacBook Pro. Is there an option in the code somewhere that will fix this low-res issue?


status : work pending

See the disclaimer recently added to the Building Mini vMac page.

But I do intend to look into a number of different issues reported with recent XCode. A hold up is that it requires a recent version of OS X, that won’t run on the version of VMWare that I have set up on my main computer. I do now have a spare computer for doing this, but some set up is needed.

permanent link

Sent: Fri Mar 13 20:46:09 2020

Hi, there, Mr. Pratt. I've read the FAQ and trawled through the boards without finding my answer. Here's what's happening on my MacBook Pro (2015 model) under OSX 10.13.6

Launch Mini vMac OSX UB 3.0.4 or Mini vMac (imch) 3.4.1 -- doesn't matter which, result is the same: black window with white "Unable to locate ROM".

Type C to clear the notice, drag my vMac.ROM onto the window. Result: Nothing. Window remains black.

Drag vMac.ROM onto the window again. Result: "Disk Image in use. I can not mount the Disk Image because it is already in use by another application or already open in Mini vMac."

Type C to clear the notice. Window is plain black from then until forever.

Any idea what I might be doing wrong?

Thanks kindly.

status : responded

Dragging the ROM image onto the Mini vMac window to recover from an “Unable to locate ROM” situation is a feature added in Mini vMac 36, the current stable version.

Mini vMac 3.4.1 and 3.0.4 are really old versions, and not available from www.gryphel.com. Downloading Mini vMac from somewhere else is not recommended and not supported.

So please get the current version from the Download Mini vMac page.

permanent link

Sent: Sun Mar 8 18:07:32 2020


I'm curious as to the behavior of fullscreen mode when invoked by ctrl-f versus the compile option. I have a 13" MacBook air and use macports to build mini vmac with screen size option -hres 704 -vres 450 (exactly half the vertical screen height). Using ctrl-f automatically magnifies it to the vertical screen height of the MacBook. When I include the '-fullscreen 1' option at compile time, it does not magnify the window at boot up. I have to add the '-magnify 1' option. I was wondering why the two methods are seemingly inconsistent?


Great emulator btw. Enjoy using my classic software that has been collecting dust.

status : work pending

Thanks for the bug report. This happens because the code that automatically chooses whether to magnify or not is located in the code for the Full screen toggle command, and so doesn’t get called for the initial boot up in Full screen mode.

permanent link

Sent: Sun Mar 8 10:26:58 2020


I noticed that recent versions of "mini vMac" built with Xcode 11 toolchain on macOS Catalina doesn't support "retina displays" properly - with screen crop 1/4 inside the window and some artifacts. Switching app to "low res mode" in Finder info panel fixes the issue. Build was made with magnification turned on by default.

Here's screenshot: https://imgur.com/a/yuM7kV4

Official build available to download or the ones from "build service" seems to be ok, so I assume there's something in recent versions of Xcode.


Konrad Kołakowski

status : received, reply pending

permanent link

Sent: Sat Mar 7 06:59:08 2020

I have my sisters tablet and its running Android 7.0 I will give you the details of it:


Okay I will tell you a problem with minivmac
when I load a 896k named disk with Mac OS system 6.0.2 It didn't work!
That was the problem so bye!

status : responded

I am not involved with the Android port of Mini vMac. If you have access to a Macintosh, Windows, or Linux computer, you could first try using Mini vMac there. Once you are familiar with Mini vMac, that may make it easier to figure out the Android port.

permanent link

Sent: Fri Mar 6 16:42:31 2020

"I have not previously merged in serial port code into Mini vMac because of concern that the emulation is the easier part, that the platform specific code for every platform for talking to every kind of serial hardware would likely be an enormous amount of work to develop, maintain, and support. One person getting it to work for their own particular hardware is just the very beginning. And since I’m not sure that very many people would make use of it, it has been a low priority so far."

I don't think we need to develop host-specific hardware, instead, create a PPP connection through the serial port via a TUN interface on the host machine.


Another solution would be to write a simple host-side terminal application (maybe in Python as to use standard libraries) to connect to the emulated Mac for file transfers using the old kermit, xmodem, ymodem, and zmodem protocols!

status : received, reply pending

permanent link

Sent: Tue Jul 17 22:13:38 2018

Hello there, I am Avedis Ghazarian and I have enjoyed your Mini Vmac program and has opened to me a whole lot. I was wondering since you are working on a Mac II version, will there be scsi disk support rather than adding floppies on startup? Thank you.

status : responded

It would be nice to add working SCSI emulation at some point (which would also be for a Macintosh Plus too). But it would not seem to greatly advance the primary goal of preserving early Macintosh software, and so hasn’t been a high priority yet.

permanent link

Sent: Thu Mar 5 00:54:03 2020

Why re-invent the wheel?

Found out that "Previous", a NeXT computer emulator, has available a complete debugged 68030 MMU emulation code based off Hatari and indirectly, WinUAE. PCE/macplus also has a functional serial port emulation.

All that needs to be done is "borrow" their code and merge it into Mini vMac! Easier said than done but the ingredients are all there... a Macintosh IIx with a IIfx ROM upgrade, 128MB RAM and serial port is totally possible! (IIfx emulation is not possible because it has different hardware from II/IIx)

We can leave FPU as SoftFPU via F-line opcodes at this time since it is already quite fast. I'm hacking my brain just trying to figure out your 68020 emulation code... my only experience in emulation is writing an Apple ][ emulator in Python! Only the 6502 CPU, disk drive, keyboard, and video... it beeps too! I don't emulate clock at all... always full speed ahead!




status : responded

Thanks for the links.

Since different programs have different architectures, it is not as simple as copy and paste, but it can still be helpful to look a their code.

Licenses must be considered, but both are GNU General Public License version 2, same as Mini vMac, so it is not a problem here.

I have not previously merged in serial port code into Mini vMac because of concern that the emulation is the easier part, that the platform specific code for every platform for talking to every kind of serial hardware would likely be an enormous amount of work to develop, maintain, and support. One person getting it to work for their own particular hardware is just the very beginning. And since I’m not sure that very many people would make use of it, it has been a low priority so far.

For MMU emulation, one concern is that it might take a major reworking of the CPU emulation to emulate bus errors properly (aborting mid instruction), and it may be difficult to do without being significantly slower. At the very least, the code has to be structured so that it is not slower than it currently is when compiling a version where bus error emulation isn’t needed.

permanent link

Sent: Tue Mar 3 02:35:45 2020

Hi Paul,

I assume you wrapped the CJ-Classics download for Cliff Johnson? When I open the app I noticed the disks are locked so I can't save a game in progress. I took a peek inside the package and it looks like you're running an AppleScript to select which mini vmac build (Intel or PPC) to open, but the disk files themselves are not locked. Have any idea how they are being locked?

status : responded

No, that isn’t mine. In general, if it is not on “www.gryphel.com”, I can’t vouch for it.

(There is also “www.gryphel.org”, with the same content from the same web server, but using http instead of https, for very old web browsers that can not handle https. But no one else should use it, because it is less secure.)

After looking at the current download files, I have removed the links to these games from my website, for not complying with copyright law (by including System Software and a ROM image). Also, I would prefer that other people don’t distribute a copy of Mini vMac, when that copy won’t be kept up to date. (And though it is probably not the issue in this case, I would generally prefer that people don’t download Mini vMac from other websites, when it might actually be malware, which I have received complaints about in the past.)

Anyway, the disk image “disk2.dsk” seems to contain the games, and when using my own copy of Mini vMac and System Software, I don’t see that it is locked. (And I’m certainly not about to run the included copy of Mini vMac.)

permanent link

Sent: Sat Feb 29 12:26:07 2020

I found a minivmac II project for Windows RT and Windows 10 on ARM:


Please add it to your ports page.

What is the ETA on ARM Windows being on your variations service?

status : responded

Thanks for the link. While the Ports page does have a disclaimer that I take no responsibility for these ports, nonetheless I would prefer that the author of pages I link to at least say what it is supposed to be.

Official support for a platform, including being in the Variations Service, requires existence of a portable cross compiler for it, such as GCC.

permanent link

Sent: Sat Feb 29 05:50:21 2020

Hi Paul,

When running LucasArts adventures games, namely Monkey Island 2 and Indiana Jones and the Fate of Atlantis, everything seems fine at first, but then the iMuse midi music tends to get bogged down - i.e. the instruments go slowly out of sync and/or stutter and skip.

Is this due to the specific drawbacks of emulating a Mac II, or is it something that I could address with some settings adjustments?

Similar issues occur in SheepShaver with all LucasArts games, and I put it down to enforced virtual memory in that environment.



status : open bug report

Thanks for the bug report. Next time I’m fiddling with the ASC emulation code, I can test if changes have an affect on this. (Regressions in emulation, thing that used to work and now don’t, can always be fixed. For things that never worked, there is no straightforward path to a fix. Often, one isn’t even sure it ever worked on the real hardware. I have a real Mac II, but not conveniently accessible.)

permanent link

Sent: Fri Feb 28 00:16:16 2020

Hi there I followed the windows method of using HFVExplorer to add files to a new blank disk image. The files are adding to the disk image fine but when I open the disk image and try to execute the files in minivmac that I added to the new disk image the files have become corrupted and won't open..Why so? It doesn't matter whether I add a .sit image or if I add a .dsk image to the new blank disk no matter what kind I add when I go to open the files in minivmac they have been corrupted once they have been transferred using HFVExplorer to a blank disk. Trying to figure out what is wrong and why the files are becoming corrupted once I transfer them to a new blank disk image with HFVExplorer. I am using a 24MB blank disk image and transferring files to it that are smaller. Thanks

Sent: Fri Feb 28 02:37:36 2020

If I use HFVExplorer or ImportFl no matter what kind of file I import I can't open the file in Minivmac and I get the message "The application is busy or missing" everytime even if I just import a .dsk file. What's wrong? Thanks

status : responded

I have revised documentation to say that HFVExplorer is no longer recommended. And I have revised documentation for ImportFl to try to make these issues clearer. And further, I have made an update to the ImportFl application so that it will set the creator type to “SITx”, so that double clicking on the imported file will open it with Stuffit Expander, which is most often what is desired.

permanent link

Sent: Thu Feb 27 04:06:46 2020

"For Macintosh II emulation, the hardware can accept more ram than 8M, but the operating system can not handle it. (The ROM is not 32 bit clean) The additional software MODE32 is said to allow use of more RAM, but a PMMU is required, that Mini vMac does not emulate yet."

How feasible is it to load a clean ROM (i.e. a 512K ROM from a IIfx) into the emulated II and then do a simple patch to the System Software 7.5.5 to boot up correctly? I've read people successfully using this system patch on real hardware replacing their dirty ROM with a clean ROM.

"Following are methods for installing OS 7.0.1, 7.1, 7.5.3, 7.5.5, 7.6.1, 8.0, or 8.1 on an SE/30 with a IIsi or IIfx ROM SIMM. With these ROM SIMMs Mode 32 is not required and should not be installed. Minimum hardware requirements: 16 MB RAM, 44 MB free space on hard drive."

I've also read that MODE32 v7.5 works on a II without a PMMU.

"Mac II without a 68851 PMMU running System 7.1 or newer won't hang on restart."

Sent: Thu Feb 27 15:03:50 2020

Going back with the idea of using a IIfx clean ROM (version 4147DD77), I did some hex search and compare for Sony_DriverBase and found it to be at offset 0x06c3e0. I am going to edit the source to load your patch at this location and also bypass the ROM checksum routine for the IIfx ROM. I am hoping that the 512K ROM (instead of II's 256K ROM) will load up just fine... is this going to work? Do you have any other thoughts to make Mini vMac IIfx ROM compatible? It just occurred to me that IIfx ROM may actually have 68030 code embedded because the 30/SE and IIx has a 030 CPU... vMac may need 030 emulation which I believe it doesn't, which also brings to mind that the 030 also has an internal MMU but since I'm not expecting more than 16MB RAM it shouldn't be necessary to emulate yet. The 030 has almost the same instruction set as the 020:

(CALLM) Removed

PFLUSH Invalidates specific entry in the address translation cache (ATC)

PFLUSHA Invalidates all entries in the address translation cache (ATC)

PLOAD Load an entry into the address translation cache

PMOVE Load an entry into the address translation cache

PTEST Get information about a logical address

(RTM) Removed

(*) Almost forgot... I also have to find the location for the video driver patch as well...

status : received, reply pending

permanent link

Sent: Wed Feb 26 09:23:45 2020

Hi Paul,

Just f.y.i, I've downloaded a 3.7 branch alpha mac II using the text variations service with these parameters:

-br 37 -t mc64 -lang ger -m II -vres 400 -magnify 1 -sony-sum 1 -hcr 39321 -hcg 52428 -hcb 65535



... on start, it begins to load the OS (7.1.1 German) and then crashes with an error 4 (division by 0).

Thanks for your great work!

Have a great day,


status : work pending

Thanks for the bug report. I will look into it.

update 3/15/2020 - I can reproduce this issue. The options that matter are “-m II -lt” with System 7. Booting with System 6 does not have this problem. But there is the same problem when boot with System 6, turn on AppleTalk in the Chooser, restart and boot with System 7. Can have same problem even without the “-lt” option by turning on AppleTalk and restarting. The last path can be done in Mini vMac 36 with the same result. The only relevant change in Mini vMac 37 is that the “-lt” option now enables the AppleTalk setting in PRAM, making the problem immediately obvious.

permanent link

Sent: Wed Feb 26 08:24:23 2020

Hi there. How can a place .sit files onto the hard drive disk image so I can open them with Stuffit? I can't open them in the emulator to add them to the hard drive image using the open in either file menu, so I am trying to figure out how I would possibly add to or edit the hard drive .dsk file so I can add the .sit images to the hard drive so I can see them and open them with Stuffit in the emulator and not loose their forks. Thanks

status : responded

The Mini vMac extra ImportFl allows you to import files into the emulated computer from the real computer.

permanent link

Sent: Tue Feb 25 20:57:21 2020


I'm trying to get mini vMac to automatically load disk1.dsk which has System 7.5.5. According to the docs "In the Mac OS X version, if the mnvm_dat folder exists it will look there, in the same way it looks for the ROM image." I placed the MacII.ROM in /Users/[UserName]/Library/Preferences/Gryphel/mnvm_rom/ and disk1.dsk in /Users/UserName/Library/Preferences/Gryphel/mnvm_dat/. The ROM loads fine but not disk1. Is this a bug or should it be placed somewhere else?

status : responded

Mini vMac will only look for a “mnvm_dat” folder inside the “Contents” folder within the application bundle (control click on the application and choose “Show Package Contents”). It does not look for a “mnvm_dat” inside the Preferences folder.

The Preference folder applies to all copies of Mini vMac on the computer, which makes sense for ROM images. It does not make sense for all copies of Mini vMac to open the same disk images.

permanent link

Sent: Tue Feb 18 23:07:17 2020

Hi Paul,

Tried to run the latest Alpha (2 times) on Windows computer..but the two doesn't seem to "see" each other. Tried it some time ago on Macos and it worked. Is there no LocalTalk on Windows?

Regards MacTjaap


status : responded

First, Mini vMac needs to be compiled with the “-lt” option to enable LocalTalk emulation. This option is available in the Advanced Variations Service and also the Text Based Variations Service.

Second, if you attempt to enable this option for Windows in previous versions of Mini vMac, you will get an error, that it is implemented only for OS X.

However, the very latest Alpha version now implements this for Windows. It is not at all well tested yet.

permanent link

Sent: Fri Feb 14 01:46:56 2020


I'd like to verify that Adam's reply to my initial query about "the mouse behavior and other oddities in full screen mode on macOS 10.14+" does appear to work.

Amusingly enough, signing the app took me a few tries so I thought I'd show everyone the command line that worked for me. This needs to be run in the same directory as minivmac.app.

I suspect that a majority of users are not paying for a developer's license. However, as long as they have a Developer Account they can still sign. I was able to find the right command line by using Keychain Access. The user@domain.com is your Developer account (often your AppleID) and the YXXXYFSGN4 is from my Apple Developer cert, found using Keychain Access -> My Certificates -> Apple Development.

sudo /usr/bin/codesign --verbose --deep --force --sign 'Apple Development: user@domain.com (YXXXYFSGN4)' minivmac.app

While this appears to resolve the crazy mouse syndrome, it does not seem to help the graphical issues. Redraw is still very laggy; in particular window closing/opening highlights the difference. I've built the same release (36.04) on both 10.12 and 10.14 with the exact same options. The graphical performance of the 10.12 build is considerably faster. If you would like binaries I can provide them, but I suspect that since you have a newer Mac you don't need them.

I still find it rather strange that the compilation OS makes a difference. Since the libraries are dynamically linked the behaviour should be the same, regardless of the compilation host. Perhaps this is something as trivial as a bug in clang...


Sent: Fri Feb 14 02:10:45 2020


This is a follow-up to my last message at 'Fri Feb 14 01:46:56 2020'. I've discovered even more oddities regarding the compiles and signing. While building on macOS 10.12 resolves poor graphical performance on 10.14+, it does not help the crazy mouse issue. The mouse is still randomly jumpy with the 10.12 build. Furthermore, if I sign the 10.12 build on the 10.14 machine it actually makes the mouse even worse (really). It's so bad that you pretty much cannot use it - but only in full screen mode, oddly enough. This is probably starting to get confusing so I've made a small chart:

build  OS |  mouse    | graphics | sign | fullscreen


10.12        jumpy      fast       no     yes

10.12        unusable   fast       yes    yes

10.12        OK         fast       yes    no

10.12        OK         fast       no     no

10.14        jumpy      slow       no     yes

10.14        OK         slow       yes    yes

10.14        OK         slow       yes    no

10.14        jumpy      slow       no     no

I suspect as more users move to 10.14 and later the issue will become more noticeable.


status : work pending

I suspect the issue with the jumpy mouse could be a problem with CGWarpMouseCursorPosition. This can be tested by trying the “-emm 0” option.

Real Soon Now, I should set up a recent version of XCode to look into this myself.

permanent link

Sent: Wed Feb 12 12:25:26 2020

What about Mini vMac in Polish?

status : responded

There is a Polish translation of the Mini vMac user interface, by Przemysław Buczkowski. It is a compile time option, so the easiest way to use it is with the Variations Service.

permanent link

Sent: Tue Feb 11 17:00:01 2020

[previous message]

there is a Windows RT build found here:
Please add it to your 3rd party ports section.

I tested it and it works but it is based on a non-FPU build so seems pretty useless for modern use. It also has some issues on tablets in full screen mode. There is no minivmac II yet so I will try compiling one.

If you'd like, I can take some screenshots. This kind of software is desperately needed on this platform as the only productivity software for it is Office 2013.

status : responded

Thanks, I have added the link to the Ports page.

permanent link

Sent: Mon Feb 10 11:47:57 2020

I need more native resolutions for the variations service like 400x240, 240x400,480x272, Why can't you add on the fly resolution switching?

Also, ImportFl does not import on Pocket PC anymore.

How soon can we expect Appletalk on Windows?

status : work pending

You can type in other resolutions in the Advanced Variations Service (and also the Text Based Variations Service). There are some constraints, such as the horizontal resolution being a multiple of 32 (so 400 and 240 are out, but 480 is fine).

Changing the resolution while the emulated computer is running can not work before the Macintosh II, the software is really not set up for that. For the Macintosh II, the video driver has a list of supported modes, so it would be possible to support multiple resolutions. But I feel this would add too much complication for too little benefit for “Mini” vMac.

Thanks for the ImportFl bug report.

Rob Mitchelmore states that his code ought to work on Linux, so I plan to try that sometime. If that works then sometime I could try to take a look at what is involved for Windows. If someone else who knows actually knows something about networking, and about Windows programming, took a look at it, it might happen faster.

permanent link

Sent: Mon Feb 10 08:44:36 2020

Can you please add more RAM options to your variations service like 16, 32 or 1GB?

status : believed answered

Other than Macintosh II emulation, Mini vMac by default emulates the maximum RAM the computer can handle.

For Macintosh II emulation, the hardware can accept more ram than 8M, but the operating system can not handle it. (The ROM is not 32 bit clean) The additional software MODE32 is said to allow use of more RAM, but a PMMU is required, that Mini vMac does not emulate yet.

By the way, I looked into altering the Macintosh Plus ROM so it could be moved in the address space to allow more than 4MB of memory, but it wasn’t feasible, because operating systems, specifically ROM patches, rely on the exact location of the ROM.

permanent link

Sent: Sun Feb 9 20:57:45 2020

update - follow-up message

[previous message]

Please don't take away my ability to compile with the newer and older Visual Studios.

You already support Windows CE ARM. You just need to modify the Windows CE project file (vcw/vcp) to have more processors to cross compile to. A few years back I went through your involved project file generation process and successfully compiled minivmac for x86 Windows CE and others. MIPS and SH4 should be the same simple process. Must I provide the binaries I compile myself for you to host as official versions?

As for Windows RT, you can purchase a Microsoft Surface RT or Microsoft Lumia 950 for around under $50-$69 on eBay. The Raspberry Pi 3 also works. Use WoA Deployer for Raspberry Pi and find an ARM64 Windows 10 1909 on pastebin to install.

If you need help, I can maybe provide binaries too but I'd really like to see an option for this and more CE architectures on your variations service.

Thanks to your variations service, I just got Word 6.0 working on my Pocket PC at 800x480 and Millions of colors. I thought I'd have to compile a new one manually again to get this working.

Some suggestions: Please always set Mouse Emulation Accuracy to "Less" on Windows Mobile/Pocket PC/Windows CE builds because it is impossible to click anything with it enabled.

Can you tell me why the color MacII is slower than Black and White mode?

status : work pending

There is no plan to remove the ability to compile with Visual Studio.

To clarify there are two different kinds of “supported” here. There are compiled binaries that I provide, both the standard variations and the Variations Service, using my chosen set of compilers. And then there is the ability for people to compile their own variations with their own compiler, using the Mini vMac build system.

Both are supported, but they are not supported quite the same. The variations I provide are much better tested, and much better optimized. Compiling your own is not recommended, unless you already are a programmer familiar with the C language and your chosen development environment. For all other compiler besides the set I use, the build system just tries to configure it for maximum chance of working correctly, and not for performance. If you want reasonable performance, you will need to try out various compiler options and then thoroughly test.

Thanks for offering to send compiled versions. But I prefer to only host versions I’ve compiled myself. I do though link to other people’s ports of Mini vMac.

re: Windows RT. I do have a Raspberry Pi 3. Finding a cross compiler is still an issue. I could at least look at properly supporting it in the build system compiling with Visual Studio.

re: Mouse Emulation Accuracy to "Less". Ok, I will look into that.

re: color MacII is slower. Pushing around up to 32 times more information (for millions of colors) is slower. That was also true running on the real hardware.

permanent link

Sent: Thu Feb 6 18:45:23 2020

Hello Paul,

is there a way to change the Control Mode key from "ctrl" to something else?



status : believed answered

Yes, this can be done with the “-km” (Keyboard Remap) option, which can be used with Text Based Variations Service.

There is also the simpler “-ccs” option, which just swaps the emulatated Control and Command keys. This is available in the Advanced Variations Service (and also the Text Based Variations Service).

permanent link

Sent: Thu Feb 6 02:02:19 2020

Hi! I'm trying to get Galax to run but am failing to get Stuffit Expander to funcion. Any ideas? :)

[... url at abandonware site ...]

status : believed answered

Like many archives on that site, it can not be opened with Stuffit Expander 4.0.1. It can be opened with Stuffit Expander 5.5 in the Macintosh II emulation of Mini vMac. (Version 5.5 can be downloaded from my Stuffit Expander page.)

permanent link

Sent: Thu Jan 30 05:14:21 2020

update - follow-up message

Please add Pocket PC or Windows CE MIPS, SH3, SH4 and Intel to your next compile list. If you need more processors, use the Windows CE Standard SDK 4.20 or 5.0

I would also suggest you add Windows RT ARM32 Windows NT versions. It already compiles with our Visual Studio. Use Visual Studio 2017 or 2019. We just need an official build.

The Microsoft hardware vendors are already selling new hardware with this OS like the Microsoft Surface Pro X. Compile ARM32 so the ARM32 and ARM64 users can benefit with the same binary.

status : responded

Thanks for the suggestions.

But there are a couple issues. The official builds of Mini vMac for all of the currently supported platforms are built with cross compilers, from a single version of GCC. One advantage is that this helps to avoid compiler bugs, and Mini vMac bugs that only some compilers trigger, on platforms that I don’t test myself all that much.

For a future version of Mini vMac, I’d be willing to give up that advantage and use a different compiler to support an additional platform. But I’d still require that it be a command line cross compiler, that can at least run on OS X. (And preferably runs on Linux too, and open source.) There does seem to be a Visual Studio for Mac, but it doesn't support compiling for Windows in C.

Another issue that to officially support a platform, I need access to that platform, at least in emulation. Apparently Windows 10 for ARM will run in QEMU, but I don’t know if it works well enough and accurately enough to test running Mini vMac. Microsoft Surface Pro X looks too expensive for me to buy at this time.

permanent link

Sent: Mon Jan 27 03:38:51 2020

Hello, I want to participate in the localization of vMac. I can handle both Simplified Chinese and Traditional Chinese translations. My email is: [... email address ...]

status : responded

Thank you for offering to translate the Mini vMac user interface strings to Chinese. Unfortunately, as mentioned on the Mini vMac Localization page, displaying Chinese characters is not currently feasible for Mini vMac.

It is possible that some future version could make use of a Chinese translation. If a pinyin romanization of a Chinese translation would be useful to anyone, that could be handled by Mini vMac now.

There is currently a Serbian Latin translation, by SerbXenomorph, and also a Serbian Cyrillic translation for possible future use.

permanent link

Sent: Sat Jan 25 19:08:55 2020

"For more emulated disk space, you can get a new blank disk image from the “Blanks” archive. I suggest using the “003M.zip” archive. Unzip it to get “003M.dsk”, and drag this onto the Mini vMac window to mount it. Once you import your “.sit” file into the new blank disk image, you need to expand it, with Stuffit Expander."

Brilliant. That worked perfectly. Thank you. Last question (at least for now :) I was wondering if it is possible to save a configuration of MvM so next time you launch it has the same setup as when you quit? In the case of doing some development (DH is a dev environment) I suppose I could look into exporting stuff before quitting and then importing after (as the process may require several sessions)?



Follow up sent: Mon Jan 27 16:46:12 2020

Hi Paul, not sure if I send something like this or not... kudos on the Mini vMac. Brilliantly done. I followed your instructions and everything worked perfectly. I did have a question about "losing" work after shutting down but have since discovered that it appears all disks are mirrored to the real computer and everything is stored. Again, absolutely brilliant and amazing. I am still just "discovering" these features as I mess with it, but so far fantastic. PS I have seen suggestions of contributing to Gryphel as that is what supports Mini vMac development. I'll be looking further into how to do that.



status : received

permanent link

Sent: Fri Jan 24 17:30:24 2020

Hi Paul, I dloaded an old piece of Mac software I wanted to revisit from [... abandonware site ...]. The page says if emulating it should run fine on Mini vMac. So, downloaded v36.04, SS 6.0.8, roms of course, and installed, all works well. Dloaded and installed ImportFl-1.2.1 which is a disk image, very lovely. Launched ImportFl. Now, when I drag the Double_Helix.sit file on to it, it provides an option to save (not sure if this means it reads and processes the .sit properly or not) and when I click Save I get a "Disk is full" error. Ahhhh, so close :) Wondering if there is some other route I should be going down. The .sit file is about 1.1 MB. Thanks so much. [... email address ...]

For more emulated disk space, you can get a new blank disk image from the “Blanks” archive. I suggest using the “003M.zip” archive. Unzip it to get “003M.dsk”, and drag this onto the Mini vMac window to mount it. Once you import your “.sit” file into the new blank disk image, you need to expand it, with Stuffit Expander.

permanent link

Sent: Thu Dec 12 18:06:31 2019


I'm the person who emailed you ... 9 months ish ago about LocalTalk over UDP. Apologies it's taken me so long to get back to you, life happened in large quantities and I had to work out how to do the paperwork to release the code.

I can now send you some code, if you would still like it. My email address is [... email address ...] [obviously please redact if this is put on the mail archive!], as it's probably easier to send code and stuff via email than a web form :-).

I've documented the protocol here:



Sure, I would be interested in merging in your code. I have sent you an email.

update 1/14/2020 - received code Archive.zip (info)

update 2/4/2020 - initial merge of code into latest Mini vMac Development source snapshot

permanent link

Sent: Fri Dec 6 16:31:47 2019


I'm trying to build Mini vMac on a MacBook Pro running Catalina. Everything works well except the display is messed up (image hosted here https://ibb.co/2Yhhhpr). This can be fixed by opening the app in low res mode but your pre-built versions don't use this 'hack'. So I was wondering I you could tell me what arguments you typically use for your builds... Here is mine: -t mc64 -lang eng -m Classic

I get the same problem with any model.

Thanks in advance!

Regards, LD

I wonder if it is related to this previous message. If so, signing might help.

I’m thinking of buying a Mac Mini to test recent Mac OS versions. (Or actually, buy a Mac Mini to replace an older computer in use, and then use the older one for testing.)

permanent link

Sent: Wed Dec 4 00:23:07 2019

Hi Paul,

There's a bug in the Mini vMac 36.04 disassembly function (build with "-dis 1"), specifically for the BCHG/BCLR/BSET/BTST instructions. The disassembly shown by Mini vMac when running ROM code doesn't match the disassembly of the ROM file itself.

For example, this is the actual code in the Mac II ROM from 12/1987, according to fdisasm:

E87A   082E 0005 0016            BTst.B    #$5, $16(A6)

I see the same when disassembling using MacsBug within Mini vMac, so I think that's correct. But Mini vMac's own disassembly shows the wrong register:

4080E87A  BTST #5, 16(A4)

Another example: the ROM disassembly is:

6C00   0929 0004                 BTst.B    D4, $4(A1)

But what Mini vMac claims it ran is:

40806C00  BTST D4, 4(A4)

Again, wrong address register. As far as I can tell, this fixes it:




Thanks for the bug report and fix. I should figure out how to merge the code for this disassembler in Mini vMac with the code of FDisasm, which by now is fairly well tested, and testable. The disassembler in Mini vMac is not so easily testable.

permanent link

Sent: Sun Nov 24 13:41:36 2019

how,s the mac II doing, i,m looking up to a complete mini vMac II, or at least one with the floating point

status : received


For earlier mail, see the mail index.


www.gryphel.com/c/mail/v10 - feedback
copyright (c) 2019 Paul C. Pratt