To send mail to me, use the feedback form.
( - latest - )
Sent: Sun Jul 5 13:00:48 2020
thank you for creating Mini vMac and especially taking on the challenge of upgrading it to Macintosh II. What is the status on completing the Mac II emulation? Is it on your road map for the foreseeable future?
The one thing that bugs me most is floating point calculations. It breaks some software in very subtle ways, so one doesn't know whether it's broken or not.
Keep up the great work,
Pierre from Germany
status : responded
As noted on the Download Mac II Variations page and on the Model option documentation, “The Macintosh II emulation is incomplete, and should not be relied on to give accurate results, particularly numeric results. (Emulation of the Floating Point Unit is the main incomplete part.) It does seem suitable for games, many of which appear to work perfectly well.”
Completing the Macintosh II emulation is on the road map. As it has been for over a decade.
The current plan is having the FPU emulation return the same answers as SANE does, since the algorithms can be studied in detail (given lots and lots of time, using FDisasm), rather than what an actual FPU would return, as there is no clear way of matching its results. Compatibility should be pretty good, and I remember reading documentation from Apple that SANE is a bit more accurate.
Sent: Tue Jun 30 02:50:57 2020
<Would you be willing to have your simulator added to the Software for Macintosh Plus section, to help preserve it? Helping to preserve such software is the primary goal of the Gryphel Project.>
Paul, sorry I am late in responding. I have no objection to adding my simulator to the software section, but I need to figure out how to do that. A friend built my .dsk file from an old Mac 3.5 inch floppy disk I sent him, and I need to get familiar with the emulator utilities for creating .dsk files so I can do it myself. When I figure out that stuff, I'll submit it.
I was so excited to get this old software running that I went out and bought a Win7 laptop just to run it on!
status : responded
That is good news.
For most all of the Software for Macintosh Plus section, I provide downloads in two formats: the orginal archive by the original author, and a repackaged zipped disk image format I make which is more convenient for Mini vMac. I have an elaborate process for ensuring that the zipped disk images are accurate, and that the format is consistent for all the zipped disk images.
So any format your simulator is in would be fine for including here.
As long as copyright issues are all in order. I see that Apple’s Technical Note PT22 says that “Interfaces to MacinTalk were published and Apple Software Licensing allowed it to be included with developers’ products.”
Sent: Sat Jun 27 05:33:49 2020
Whenever I try to run ImportFI in Mini vMac it fails, and says that the Disk Extension is Too Old. Also, the mail archive link at the bottom of this page 404's.
status : awaiting information
Thanks much for mail archive bug report. This should be fixed now. (It broke when, while trying to fix a complaint from Bing Webmaster Tools, I did a search and replace on all the html files and uploaded them all to the web site with sftp. It turns out I should make a tar archive first and upload that, to preserve symbolic links.)
I’m not seeing the issue with ImportFl. Make sure to use Mini vMac 3.0 or later, preferably the current stable version from the official Download page. If you are using the official current version, what is the variation string? (use Control-P to copy it to the clipboard.)
Sent: Mon Jun 22 11:06:02 2020
Hi. About latest StuffIt expander for Windows not being able to extract from .bin-files: Which version is that? I am using what I believe is the last version of StuffIt Deluxe for Windows (188.8.131.52 AKA 2010), and I have no problems extracting .bin files.
status : responded
The current version for Windows at www.stuffit.com is “StuffIt Expander 2011 15.0.8”.
Sent: Sat Jun 20 06:50:15 2020
The documentation says that the keyboard emulation is designed such that you can type in any Mac special character (even on Windows). However, I'd like to type in the high ascii characters in sequence and I can't figure out how to do that. If I import a txt file with those characters and open it in MacWrite 1.0, I can see all the special characters (at least those that aren't boxes). But if I script my host OS to send keystrokes of ascii 33-255, it mostly just repeats the "a" character (past 128 or so) into it. Not always, I guess your emulation logic recognizes some but not others.
I'm attempting to screenshot the characters (one at a time) in the hopes of turning them into TTF fonts. While others have done it, they've only done so for the regular (not styled) fonts, which misses the algorithm MacWrite uses to make them bold/italic/etc. I was hoping I could create versions that also have the styles. While it would be easy to screenshot all 220 characters at once after loading the text file, I can't figure out a way to crop the letters out individually. If I could "type" them, it would greatly simplify things.
Honestly, I'm not sure how anyone ever typed the characters from high ascii into a Mac Plus with an original keyboard.
If you could help, it would b greatly appreciated.
status : responded
You can type most Macintosh special characters by holding down the option key. For example, holding down the option key and pressing the 'g' key will result in '©' (the copyright symbol), usually.
The Key Caps desk accessory, included with the operating system, illustrates what pressing on keys will do. Alternatively, the ASCII Chart desk accessory can tell you what to press to get the desired character.
I have added a sentence about this to the Keyboard section of the Emulated Hardware Reference. Thanks for pointing out that it is needed.
The emulated hardware knows nothing about ASCII, it deals with key codes, which the Macintosh operating system translates to ASCII, depending on the keyboard layout and script settings.
I’m not sure what is happening when you scripted Windows to send characters to Mini vMac, since Mini vMac itself doesn’t know anything about characters, only key codes.
Sent: Sat Jun 20 00:36:10 2020
Stuffit Expander doesn't recognize the bin files on Windows 10 as something that can be extracted. Not sure how to handle this.
status : documentation change pending
Thanks for pointing out that the current version of Stuffit Expander no longer handles this format.
The Stuffit Expander Alternatives page has some other possibilities.
I now notice that the The Unarchiver has command line versions, for other operating systems besides OS X, including Windows. It is not very clear how to use it, but "unar SSW_6.0.8-1.4MB_Disk1of2.sea.bin -i 1" seems to work.
I think I will change the documentation to first suggest The Unarchiver, and mention in the Alternatives page that old versions of Stuffit Expander also work.
Sent: Thu Jun 18 16:32:53 2020
you did a great job, thanks. I just wanted to support you, but why is not just a credit card number (number, name, exp. date, and security code) enough to do so? Why am I required to give PayPal my address, my telephone number, my email address, etc.? I don't want to do so. I don't like this unnecessary collection of info. Thus, I canceled my transaction, sorry.
If I can help in any other way, please tell me.
status : responded
Thanks for the feedback. One reason for PayPal to collect such information is to make sure that you know it. That is, to make sure it really is you that is trying to use your credit card.
So I expect that most any other online payment processor would require the same information. But I can assure you that PayPal does not send this information on to me. I only get name and email address.
I have thought sometimes that I could provide other ways for people to donate who don’t like PayPal for various reasons. Perhaps such as accepting bitcoins through Coinbase. Is there some way that you would prefer?
The Ways You Can Help page lists some other ways beside donations to help the Gryphel Project.
Sent: Mon Jun 15 04:21:14 2020
Paul, this is Don Shepherd in Louisville Kentucky. I used Mini vMac to resurrect an air traffic controller simulation I wrote in 1988 for the original 512K Mac. My old Macs themselves are long gone, but I saved the floppies with the source code and compiled (Mac MS BASIC compiler) programs, fortunately. I used Macintalk to do speech synthesis in the program, and it is so nice to hear those old pilots and controllers talk after 32 years of silence. Thank you so much for your work, you have made an old man very very happy. My simulator works great on both Win 7 and Mac platforms.
status : responded
That’s good to hear.
Would you be willing to have your simulator added to the Software for Macintosh Plus section, to help preserve it? Helping to preserve such software is the primary goal of the Gryphel Project.
Sent: (via email) Mon, 15 Jun 2020 11:06:21
Just tested the new variations service, copying and pasting my previous build options and making some quick manual changes to the build, and it worked perfectly, producing an accurate result -- just as requested. :)
I feel the new build system is a lot more user friendly.
Being able to copy and paste your previous configuration and having the additional form/customisation options take precedence over them (modifying the original options), is very intuitive (easy to understand and use).
status : responded
I’m glad you find it easy to use. That is good news.
Sent: (via email) Mon, 15 Jun 2020 10:55:58
> > Mini vMac 36.01, Mini vMac 36.02, Mini vMac 36.03, > > and Mini vMac 36.04, are versions. All together, Mini vMac 36 > > is a branch.
Usually the numbers following the dot in a main software version number are called minor versioning, sometimes a revision (Mini vMac 36 rev 04).
Mini vMac version 36 is a main/major release. 36.04 is (minor) version 04 of Mini vMac (major) version 36.
A branch, as it pertains to software release, at least in Git terms, is an altogether different release of the software that stands apart from the main branch in its design and/or development focus.
Mini vMac 37 is a continuation of the development of Mini vMac 36 with the same design and development focus, by the same author/developer, so in Git terms both major versions belong to the same main branch of the software (as well as all minor versions).
See here for more information about conventional software versioning,
including major and minor releases:
An example of a branch for Mini vMac in Git terms would be a release of the software for a completely different computer architecture (requiring rewriting) or, say, a release of the software with an entirely different design or development focus, out of the scope of the main project -- such as modern Mac emulation or certain specialised rewrites and/or applications.
status : responded
Thanks for explaining your usage of versioning terms.
I notice that some people use the term “branch” rather differently in relation to Git. A branch seems to be the name of a specific feature of Git, and it is encouraged to create a new branch for every new feature and bug fix. ( 1 2 3 4 )
Which is definitely not how I’m using the term “branch”. But, again, the way I’m using it does seem consistent with the Wikipedia article: Branching (version control).
The way that you are using Branch seems similiar to how many people use the word Fork. Though that now seems to mean something a bit different for GitHub.
It seems that some other projects are using the terms “Channel” or “Train” similar to the way I use Branch, but I hadn’t heard of these before. Maybe I could use one of them if they become more common. I’d rather not use the word “version”, because it used for too many different things. There can “Windows”/“Mac” versions, there can be the “release”/“debug” versions, there can be the “English”/“Spanish” versions, and so forth.
The Wikipedia article on Software Versioning doesn’t mention “branch” at all. But it does describe “Release train”.
Sent: Sun May 31 04:29:35 2020
Thanks to your SDL template, Mini vMac is a thousand times easier to port and it takes very little to get it to actually run.
With external ram Mini vMac can run on the Espressif Systems ESP32 microcontroller: https://www.youtube.com/watch?v=sKVGKtVH5bk
I was planning on cleaning up the sources and giving a small writeup of the porting process.
status : responded
That’s good news. And the new port looks neat.
I’ve been thinking it might be possible to change the Mini vMac setup code to be more useful for ports that I’m not supporting myself. Like how the “-t” option chooses among supported targets, which automatically selects the CPU, but you can also manually choose choose the CPU with the “-cpu” option. This allows you to compile for ARM on FreeBSD, for example, which is not a supported target. So manual options could also be added in other places where choices are made according to the target.
Sent: Thu May 28 07:12:36 2020
when I copy the parameters from minivMac (ctrl-P) and paste them into the variations service in Safari (in my case: -br 37 -t mc64 -lang ger -magnify 1 -speed z -mem 2.5M), I the service responds with "Sorry, the Base Options need to consist of letters, numbers, spaces, hyphens, or asterisks, and be 1024 characters or less. Please press the back button on your browser and correct this."
What am I doing wrong?
Kind regards, Karl
status : fixed
Thanks for the bug report. I forgot that a period (as in “2.5M"”) needs to be allowed. This should be fixed now.
Sent: (via email) Tue, 26 May 2020 10:28:19
> The first line of the Download section, after the title, > has a link to other branches. I guess that is too easy to miss?
Oh, "other branches" in the context of open-source usually means versions of the software developed by other people, that differ from the trunk (main branch).
A newer or older version of the same software isn't usually a branch as such, but versioning.
This is likely why I didn't pay attention to that link.
> The main page of the Gryphel Project has a news section which regulary > links to "the latest Development source snapshot". Or maybe you are > talking about the Mini vMac main page. I could add a Branches link > next to the Changes link. That really should be there, it is mistake > that it is missing.
By the site's index page, I meant the Mini vMac homepage.
> I'm not sure about putting a link to Branches in the Variations > Service page, that page I really want to keep as simple as possible. > Perhaps in the directions page.
I think a clearer link in the Downloads section to the current in-development version of the software is completely sufficient. If anyone's looking to download a newer version of the software, Downloads is where they will first be looking for it.
status : responded
Mini vMac 36.01, Mini vMac 36.02, Mini vMac 36.03, and Mini vMac 36.04, are versions. All together, Mini vMac 36 is a branch. The Branching (version control) article on Wikipedia is consistent with this usage, particularly the section on “Development branch”. The common concept with how you are thinking of the term is that there can be new versions of different branches of Mini vMac at the same time. Because there could be a bug fix to the Beta or even Stable branches as the Alpha branch is being developed.
I have tried to clarify this usage on the Download page, by explicitly saying “alpha, beta, and old” branches, instead of just “other” branches.
Sent: (via email) Sun, 24 May 2020 10:50:31
Thanks. I'll give it a whirl in the coming days.
> Where did you look for it? I could consider putting links there.
I was looking for it in the "Download" section:
And in the Variations Service:
(The pages I've used and am familiar with from before.)
I've also checked the site's index page for anything that may signal a new build.
status : change made in documentation
The first line of the Download section, after the title, has a link to other branches. I guess that is too easy to miss?
The main page of the Gryphel Project has a news section which regulary links to “the latest Development source snapshot”. Or maybe you are talking about the Mini vMac main page. I could add a Branches link next to the Changes link. That really should be there, it is mistake that it is missing.
I’m not sure about putting a link to Branches in the Variations Service page, that page I really want to keep as simple as possible. Perhaps in the directions page.
update 5/25/2020 - I have put in a link to the Branches page page from the Mini vMac main page and from the Variations Service Directions page.
update 5/27/2020 - 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.
Sent: (via email) Sun, 24 May 2020 10:44:58
> Do you mean that it would not go full-screen by default, or > that the toggle command (Control-F) was not there? The > default variation very deliberately does not start full > screen, to avoid getting beginning users into a situation > they can’t easily get out of.
Both the default build and the variations service default build started with fullscreen off, but when using CTRL + F to switch to fullscreen mode, the default configuration would use the 2x setting, while the variations build would have the 2x setting disabled by default -- therefore creating an inconsistency in relation to user expectations (expecting the standard build's settings to be the default).
> In your previous message you > mentioned using "-br 36 -t lx64 -fullscreen 1 -magnify 1 > -drives 16 -bg 1 -as 0 -svl 5". So my guess is that you > forgot this is not the standard variation.
This is after I've figured out how to replicate the settings/behaviour of the standard build in the variations service, and customised them to fit my needs.
> To avoid this sort of situation, I’m thinking I could change > the Basic Variations Service to allow and strongly encourage > entering the options from an existing configuration (using > Control-P), as in the current Text Based Variations Service. > And then, by adding a text field at the bottom for > additional options, a separate Text Based page becomes > unnecessary.
This a good idea, so long as the HTML form recognises the values entered through the text input and checks/fills out those settings in the form. As the user ticks/changes new settingsin the form, the changes should be reflected in the text options (real-time).
Having just the text options makes it difficult to further customise the emulator, seeing as one needs to know what the text equivalent of those form options are.
I still think keeping the default settings for the standard build and the variations build the same is the most important aspect of making the variations service more user-friendly.
I can deal with having to manually re-assign the same values again from memory (and using the text options as reference) in the web form.
status : work pending
The reported behavior, no automatic magnify when first using CTRL + F, would be a new bug. But I can’t reproduce it. Could you give details of what variation you observed it in (i.e. the options string, and the md5 checksum of the downloaded archive)?
There is however a known similar bug, where a variation built with “-fullscreen 1” to start in fullscreen mode does not automatically magnify. It is on the list of things to fix, a bit down in the stack. Are you certain the variation you were using was not built with the “-fullscreen 1” option?
It really should not be possible for a Standard Variation to behave differently from the corresponding one generated by the Variations Service with a target platform and no other options, because they are bit by bit identical. You can test this. If you download “minivmac-36.04-lx64.bin.tgz” from the 36.04 (Stable) Standard Variations page, and then create a sponsored variation from Mini vMac 36 Variations Service (Basic), choosing only “Linux - x86-64” and no other options, you will get identical binaries, with an md5 checksum of 499827d3defee725c1decddc4497e637.
Sent: (via email) Sat, 23 May 2020 13:58:52
Regarding the variations service, what made it more difficult to adopt primarily was the inconsistency in behaviour between the latest standard build I first tried, and the latest variations build by default.
As a user, what I expected is that the variations service will build the standard configuration without my customising/modifying anything. But instead I got a build where Mini vMac did not go full-screen and double-sized as in the standard build. I had to hunt down and figure out why my variations build wasn't behaving as the default build out-of-the-box.
So this inconsistency is what really threw me off and caused some confusion and difficulty grasping how the variations service works. That, and the fact that there are a lot of customising options in the advanced variations service, and too few in the default one. Thankfully your good documentation and resource links on the option titles helped me relatively quickly figure it out.
To make it more user-friendly, the variations service should follow the standard build configuration, with extra options to change things to the user's needs/liking, starting with the most common/obvious changes, and going into finer details down the line.
This way it feels less like building, and more like customising -- and requires less (potentially unnecessary) effort to learn.
Hope this user insight helps.
Kind Regards, Bryan
status : change made in Alpha
Thanks for the feedback. It is helpful.
The variation service should in fact “build the standard configuration without my customising/modifying anything ”. Anything else would be a bug.
Do you mean that it would not go full-screen by default, or that the toggle command (Control-F) was not there? The default variation very deliberately does not start full screen, to avoid getting beginning users into a situation they can’t easily get out of. In your previous message you mentioned using “-br 36 -t lx64 -fullscreen 1 -magnify 1 -drives 16 -bg 1 -as 0 -svl 5”. So my guess is that you forgot this is not the standard variation.
To avoid this sort of situation, I’m thinking I could change the Basic Variations Service to allow and strongly encourage entering the options from an existing configuration (using Control-P), as in the current Text Based Variations Service. And then, by adding a text field at the bottom for additional options, a separate Text Based page becomes unnecessary.
update 5/23/2020 - I have made this modification to the Alpha Variations Service. Except on second thought, I think the Text Based page for specifying additional options should remain separate.
Sent: (via email) Sat, 23 May 2020 13:42:09
How do I get the updated build? I can't seem to find it on the website. Would I need to build it from source myself?
status : responded
It is available from the Download Mini vMac 37 Alpha page.
That page has a link to the Mini vMac 37 Alpha Variations Service page. (While Mini vMac 37 is in Alpha, and therefore frequently changing, the set of compiled standard variations is not provided.)
Where did you look for it? I could consider putting links there.
Sent: Thu May 14 23:23:39 2020
Hello, I donated 10 dollars via a Debit card. It said the card was declined but when I looked on my account, the payment said I only had 3 dollars left (I originally had 13 dollars). I can still get the code right? Or can I get a refund? Thanks!
Email me back at [... email address ...]
status : responded
Thank you for trying to donate, and sorry for this problem. Searching on Google, I found:
It sounds like the charge should disappear within a few days (not including weekends).
Sent: Thu May 14 17:42:04 2020
I think a style guide would be very helpful.
Something that goes over your naming conventions and typedefs and why you used them.
Another thing might be including a file called OSGLUskeleton.
It would only contain what the emulator core needs and stubs for things that the porter would need to emulate.
It's not strictly necessary though; I pulled the 3DS version together from the SDL and XWIN versions.
status : work pending
The problem with a skeleton port is that since it is not used, it tends to rot. Mini vMac actually had such a port, "gen", from version 2.8.0 until version 3.2.0. After that the classic Macintosh port, "mac", was designated as the "reference" implementation, containing all comments about what platform dependent code is supposed to do, not repeated for each platform. That port was chosen to be neutral to the modern supported platforms. But at the current time, make the SDL port the "reference" implementation would be more practical. Because the easiest way to port Mini vMac to a new platform is to port it to SDL on that platform. Then if a more native port is desired, the source code for SDL can be merged with Mini vMac, all SDL code not used for that platform can be removed, and then a lot of cleaning up. I did the Cocoa port this way, without ever having used Cocoa or Objective C before.
One issue with this idea is that there are two SDL ports, for SDL 2.0 and SDL 1.2, and they are both still useful. I could merge the ports, even though there are significant differences (by testing whether SDL_MAJOR_VERSION is 1 or 2). And then put all comments about porting into it.
I could go further and say that if SDL_MAJOR_VERSION is defined to 0, then the SDL API is not used at all, and that would be the skeleton port again, useful when SDL does not exist for a platform.
Clearly, I should create a page that documents porting. People are otherwise may not have noticed that "mac" was supposed to be the reference platform.
For a style guide, I could start by a least documenting what rules are being enforced automatically by scripts of mine. I don’t require that code follow these rules before I would merge it into my version of Mini vMac. But I will rewrite the code to make it follow these rules. I don’t mind this rewriting, it helps me learn how the code works. I won’t merge code without feeling I understand it pretty well.
update 5/21/2020 - The source code for the SDL 1.2 and SDL 2.0 ports are now merged into one file, and it has been made the reference implementation, with comments that apply to all ports. 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, making a skeleton port.
Sent: Tue May 12 17:23:07 2020
The new repo for the 3DS port is at: https://github.com/TaraHoleInIt/minivmac-3ds
It also contains my hacky changes to the setup tool, but I still need to figure out how to generate a Makefile that devkitPro likes.
For the time being I've been doing the Makefiles manually.
Thank you again for Mini vMac. It's been a real treat to port, and I have learned a lot from it :)
status : responded
Thanks, I have updated the Ports page, and added an item to the Latest news section.
I would be interested if you have any suggestions for making Mini vMac easier to port.
Sent: (via email) Fri, 8 May 2020 14:10:05
I'm working on an ARG and was wondering what the best way to package up a version with preinstalled files and folders would be?
files would be clues and image files related to the ARG.
Love your work! thank you so much!
status : responded
Sorry, I’m not sure what ARG means in this context.
Generally, I now try to discourage people from downloading Mini vMac from anywhere but gryphel.com. Malware masquerading as Mini vMac has happened before. Also legitimate copies elsewhere would tend not to get updated, and become old.
And of course, including ROM images and system software violates copyright law.
Sent: (via email) Tue, 5 May 2020 10:22:26
Sorry, personal troubles got in the way of my response. I will test the new build (and interface) and answer your letters soon. Thank you for looking into this, and (from what I understand) this solution sounds right. One of the main reasons people would be emulating the old System these days is precisely because of HyperCard. If this solution doesn't work out in the wider sense, it would be worthwhile considering creating a build specifically for HyperCard.
HyperCard may have been abandoned -- due to a now obsolete personal feud between Steve Jobs and Bill Atkinson -- but it is still the best multimedia/hypermedia concept testing software, still relevant to-date! And in many ways it still outshines what the Internet can do these days in terms of creative possibilities. Not to mention its historical-cultural significance.
Apple lost an unparallelled creative tool when they left HyperCard behind in the transition to OS X. They've been trying to recreate its success, without getting even close, ever since.
status : received
Sent: (via email) Mon, 27 Apr 2020 09:56:14
I am tinkering with Alpha 37 here-specifically the Mac II. I saw some notes about supporting greater than 4MB of RAM running in to ROM addressing problems. I notice that virtual memory isn’t an option in System 7.
For the Mac II would it be possible to emulate real memory as virtual memory? Increasing the usable memory well above the ROM and physical limits?
I don’t have the technical information on System 7 or the Mac II but I gather that the Mac II had a MMU coprocessor to handle memory and System 7’s virtual memory was actually a copy of main memory + the extra memory. This made it pretty awful when writing to a disk but if it was implemented to RAM behind the scenes it might work great?
status : responded
The Macintosh II emulation is currently limited to 8MB because the ROM isn’t 32 bit clean. It could easily emulate more memory, but the software would not work.
If Mini vMac had a working PMMU implementation, you could just use MODE32. It is possible that MODE32 might be gotten to work with a partial PMMU emulation, that it might only require supporting switching between a few simple memory mappings. While getting virtual memory to work would make much more extensive use of the PMMU.
Older Mail (Index)