To send mail to me, use the feedback form.
( - latest - )
Sent: Thu Jun 7 11:57:23 2018
Hi Paul! Thanks for all the hard work put in the emulator :)
I think I found a bug: I tested the latest alpha source (180527) code under Windows 7 both in my own build and using your variations service and the Control menu doesn't display at all when pressing either the default "Ctrl" key or a remapped one, with or without using the -km keyboard remap option.
Thanks for the report! It was definitely a bug. I should test the development branch on non OS X systems more often. Anyway, I think I have a fix for this, to be in the next snapshot. (Macintosh key codes are now represented with unsigned bytes instead of signed.)
Sent: Fri Jun 1 18:56:20 2018
Hi Paul, I thoroughly enjoy your work and wish to help out on the Mac II emulation side. I hear that the FPU is incomplete and I'd like to finish it. How best to do this? I would rather work with traditional UNIX tools (gcc, emacs, make, diff, patch, etc.). I could generate the Linux GCC source files and work from there... Thanks, Ellery
How best to complete the FPU emulation is certainly the question. Writing code isn’t the issue, knowing what to write is. I have a plan of how to proceed, but it is rather involved.
But in the meanwhile, if someone created a test case where the current implementation gives clearly wrong results, along with a patch to fix it, I’d probably merge the patch. (Assuming the patch is cross platform, not depending on libraries, even the standard c library.) That would be of practical value.
If you want to do this, yes, use the build system to generate source code for a particular variation of Mini vMac, and work on that. I can merge in your work to my version if you just send me the changed files (that is easier for me to deal with than diff output).
Sent: Wed May 30 16:30:31 2018
Hi Paul, I am not a tech heavyweight but back in the 80's I wrote some basic code using ZBasic for Mac Plus. The hard drive for my Mac Plus still works and the original programs I wrote are still operational. I have successfully used Mini vMac on Windows XP .
My question is : what is the best way to get ZBasic & my code from a Mac Plus hard drive to a Mini vMac folder in Windows XP ? I have copied the software to a 25 year old floppy but this may not be stable.
Mark [ ... last name ... ]
The simplest method may be to buy a Floppy Emu disk emulator from BMOW.
Otherwise it depends on what other old hardware you have available or can find for sale. From my CopyRoms page: “The easiest solution is to use a slightly less old Macintosh that can use 800k disks, and that has ethernet or other communication options to talk to more recent machines. Some other possibilities are an AppleTalk/Ethernet converter, an external SCSI drive (though modern Macs can't use external SCSI drives without 3rd party hardware), a null modem cable, or connecting to the internet with a modem.”
Sent: Fri May 25 18:12:43 2018
I'm experimenting with the advanced variations feature, and I am trying to make a build that suppresses the control menu. I entered the -UseControlKeys 0 into the field, but it came back with a compile error.
Does it only recognize the explicitly documented options, or did I enter it incorrectly? If the former, what is the benefit of using the advanced variation menu?
The new “key mappping option” should mostly do what you want. You can say that the Control key should be mapped to the emulated Macintosh Control key, and not the Mini vMac control mode. You can also set some other key to map to the control mode, which would usually be a good idea.
For the future, I could make it check if no keys are mapped to the control mode, and in that case define UseControlKeys to 0 in a configuration file. Without this check, currently it may leave unused code in the compiled program.
Yes, the Advanced Variations Service will only accept the documented options. You can not set arbitrary compile time defines in the configuration files. This service passes the options to the Mini vMac build program. The intent of the build system is to take any input, and either generate a valid set of configuration files, or generate a useful error message.
The reason for the Advanced Variations Service is that having a separate control for every option was getting unwieldy as more and more options were added. So the Basic Variations Service will eventually be reduced to only the mostly popular options.
The advantage of using either the Advanced or Basic Variation service over compiling it yourself is that is faster and easier. First, to compile it your self you have to download the source code and read instructions and set things up in your development environment. (And you had better know how to use your development environment, because I’m not much interested in teaching you.) Second, even after you have done it a few times, compiling your own version is still likely to be much slower than using the Variations Service, unless you spend a lot of time optimizing like I have done. Third, a version you have compiled yourself is likely to run much slower than a version produced by the Variations Service, unless you spend a lot of time figuring out how to tweek things for your particular compiler.
Sent: Sat May 19 05:03:00 2018
With the Macintosh II emulation, I'm encountering Abnormal Situation 1106 if I press Control-R to reset the emulator. If I press Control-I to interrupt (and then Y to confirm), I see Abnormal Situation 0113.
This happens whether using your binaries of 3.5.8 (Mac 32-bit or 64-bit), or 36 alpha 180506 (Mac 32-bit) compiled with MacPorts, on macOS Sierra.
The earlier Mac models don't exhibit these Abnormal Situations.
Just wanted to let you know!
Thanks for your continued work on Mini vMac,
Thanks for the report. I hope to make the Macintosh II emulation more complete eventually.
Sent: Sat May 19 04:09:01 2018
Thanks for the new "-ef 1" Mini vMac build option to save the error message to a file instead of displaying it. That's very helpful. I'm using it in MacPorts now.
Is there a way to get the error message file to be automatically exported to the host machine that's running Mini vMac (like the source code archive already is), rather than being saved to the emulated Mac disk? Reading an HFS disk to extract the error file from it is difficult on some host OSes.
This is now implemented. Just like the source archive, it will be export unless the ‘-nex’ option is used.
Sent: Wed May 16 13:34:48 2018
Hi Paul, re the new build system options “-hcr, -hcg, and -hcb”: This works as advertised. Thank you very, very much! Kind regards, Karl
Sent: Sat Apr 5 11:26:42 2014
I see you removed the ";" build system option for the 180513 snapshot. I was using this option in MacPorts to create universal binaries. For example I would use the options "-m Plus -t mach -n 180506_0-plus-mach ; -m Plus -t imch -n 180506_0-plus-imch", which would create two tarballs of source code, and I would build them both and then lipo the results together. Do you have a recommended alternative for this? I would like to avoid running the build program more than once, if at all possible. I didn't understand the reasoning given in your news entry about why the ";" option had to be removed.
Running the build program twice should work fine, that is how the Variations Service works.
Sent: Mon May 14 12:28:51 2018
Thanks Paul, for your very excellent work I have followed over years now. My specific question is put below some good experience maybe of interest to you.
My favorite is todays MacII emulation on Linux (Lubuntu, LX64), which even works very well within a VirtualBox (vMac in Lubuntu in VB on Win7).
I have been successful with printing into PS or PDF, both formats directly being accessible in Lubuntu.
I had some issues with the "keyboard issue" as mentioned in your good documentation. I see this kind of "trouble" and found PopChar to be workaround for me to easily get german and more characters.
There is no issue to transfer disk images from a real Mac (Performa 5300, 7.5.5) to any vMac using ZIP100MB drives on both ends.
My question today is, transfer back (vMac -> real Mac, both 7.5.5) seems not to work: when trying to mount an image (used with vMac before) via DiskCopy 6.1.2, an error "-39 end of file" is displayed from DiskCopy on the real Mac. Up to now I have not found the difference in the image-files which vMac always mounts fine for read and write.
This bidirectional image-transfer is of course not necessary, its more an academic interest of what could be the reason and how could it be managed.
Thanks in advance,
my very best regards from germany,
[... email address ...]
Disk Copy 6 saves information about the image in the resource fork, which might get lost when transferring images between computers. But on the other hand, when I try Disk Copy 6.3.3 on one of my Blanks (By dragging the icon of the image file into the application, in Macintosh II emulation), it seemed to work fine, even though there is no resource fork.
I’m not sure what "keyboard issue" you are refering to. The new Keyboard Remap build time option in Mini vMac 36 alpha might be useful.
Sent: Sat May 12 04:58:55 2018
Compile in recode 9.3 gives me this error.
clang: error: -fobjc-weak is not supported on the current deployment target
options I used :
-tmc64 -ev 8210 -m II -hres 512 -vres 394 -depth 3 -em-cpu 2 -mem 8M
Checking on Google, this might be fixed by changing the Deployment Target setting in XCode. Anyway, I’ll try setting up the latest XCode and supporting it before Mini vMac 36 enters beta.
Sent: Wed May 9 16:10:32 2018
Any plans to support -ev for Xcode 9.x?
I usually add support for the then latest Xcode and Microsoft Visual Studio shortly before a branch of Mini vMac goes to beta.
Last time, no changes were needed besides changing version numbers, and very little changed the time before that. So you should try a project for the lastest supported Xcode (“-ev 8210”) and see if the current Xcode can convert the project without problem.
update - follow-up message
Sent: Sat Apr 28 03:34:41 2018
Thanks for fast answer question about debugger, great service! Please tell how use logger. Mac mini documentation not tell about it and I not see it in Control Mode. Thanks!
“Logging” basically just means the debugging technique of inserting print statements to help figure out a problem, which are removed when done. Mini vMac provides some utility code in assisting with this. The “-log 1” option enables code to support printing to a log file. Nothing actually gets printed without creating code to do so. The “-dis 1” option enables code for writing out disassembled Mac 68k instructions that were executed around the time of the event you are logging.
This is for programmers working on Mini vMac (mostly me), so on the developer options page, not on the user options page. Logging is a primitive technique, but can be quite effective if you know what you are doing. And if you have fast compile/debug cycle. Mini vMac is small, so on a modern machine the cycle is a few seconds.
If you just want to study the execution of Mac 68K programs, most of the time you would be better off using a debugger running inside the emulation, such as Macsbug or TMON, which are much fancier than any debugging options that could feasibly be added to Mini vMac. (Some of the other times include boot time code, and programs that have copy protection code that tries to disable debuggers.)
Also, if you want to study a particular Mac 68K program very closely, my FDisasm tool, a disassembler, might be useful.
Sent: Fri Apr 27 04:29:02 2018
VMac mini have way see Mac memory or debugger mode like MAME/MESS? Let people step through old Mac programs?
Not currently. And I probably would not add this. It would be a large amount of code that only a very small percent of Mini vMac users would find useful. And even when it would be useful, there are only a few circumstances where a debugger running inside the emulator, such a Macsbug or TMON, would not work at least as well. Such as during booting.
It could be worth doing if it would speed up development of Mini vMac. But I don’t think it would. I personally don’t use debuggers much, and prefer logging. Mini vMac has various logging infrastructure, including a disassembler that can display code leading up to an event, by keeping a buffer of recent instruction addresses.
update - follow-up message
Sent: Sat Apr 5 11:26:42 2014
Hey, mini vmac is awesome! Until you can’t run it because Apple decides to drop support for 32bit applications on the Mac with the upcoming release :(
Any plans to create a 64 bit compatible version?
[... email address ...]
There already is a Macintosh 64 bit (x86-64) version, as of Mini vMac 3.5.
But it is probably time to change the Download page to list the Macintosh 64 bit version first, before the 32 bit version.
Sent: Sun Apr 22 07:17:55 2018
I notice that in SimCity 2000 when you look at the map of surrounding cities, the population sizes do not calculate properly. They show up as huge 22 digit numbers. Also, in the "Word at War" games (i.e. Operation Crusader, Stalingrad, D-Day America Invades) the odds calculation box remains empty, so you cannot calculate odds of attacks.
Would this be something to do with Mac II emulation being incomplete? Or a FPU issue?
It seems likely. (The main way the Mac II emulation is incomplete is in the FPU emulation)
Sent: Fri Apr 20 22:58:26 2018
It looks like trace support might be broken in 3.5.8. Tracing in Macsbug works as expected in 3.3.3, but appears to skip multiple instructions in 3.5.8. I have screenshots showing the difference. Happy to provide whatever information is needed to verify.
Thanks for your hard work!
[... email address ...]
Thanks for the report. Yes it is broken. I had already learned of this bug, but only recently. I think it is now fixed in Mini vMac 36 Alpha. From the Mini vMac 36 Changes page:
"Using Macsbug to step through code (with Command-S or Command-T) did not work properly in Mini vMac 3.5.x. An optimization to the main cpu emulation loop was not valid when the trace flag gets set, so the interrupt could happen one instruction later. I found a way to fix it which doesn’t change the optimized main loop, but just the code before and after. But it can change the timing of other kinds of interrupts by one instruction, potentially causing subtle differences in behavior anywhere."
Because of those possible subtle differences, I don't plan to fix this in Mini vMac 3.5. More testing is needed.
Sent: Thu Apr 12 02:08:37 2018
I did not find an answer in the docs or FAQ.
Both folders that I created by dragging a disk image onto Mini vMac were locked. Are folders always locked in Mini vMac? I need my System Folder to unlock so I can save a prefs file, otherwise my app won't work. The app folder is locked too. The usual way to disable locked files with Get Info doesn't work.
If the disk image file is locked, the emulated disk in Mini vMac will be locked. In that case, you would need to unlock the disk image file.
Another possibility is that the image file could be in Disk Copy 4.2 format, which by default Mini vMac will mount as read only. In that case, the utility CnvtDC42 converts Disk Copy 4.2 format images to a new image without the tags and checksums and header, that Mini vMac can write to. Alternatively, Mini vMac can be compiled with full read/write support for this format, with the options “-sony-sum 1 -sony-tag 1”. With the Variations Service, use the “full” option for “Support for Disk Copy 4.2 disk image format”. I’m starting to think that this should be the default in some future version of Mini vMac, even if it is somewhat large and slower, to avoid this sort of problem for people.
Sent: Sat Apr 7 11:00:38 2018
The documentation for FDisasm says that (1) "It makes it possible to distribute the means to create an annotated disassembly of copyrighted code (such as Macintosh ROM images), without distributing that code or files derived from it." and (2) "This listing file is derived (in terms of copyright law) from the Macintosh Plus ROM, and so may not be redistributed." Does this seem contradictory to you?
[... email address ...]
No, the format files that can be redistributed only contain annotations about a ROM image, they do not contain any of the ROM image. FDisasm combines the the ROM image (that can not be redistributed) with the format files (that can), to create a listing file. The listing file is derived from the ROM image, and so can not be redistributed.
Sent: Fri Apr 6 15:38:08 2018
Hi Paul, excellent work on Mini vMac, it's impressive, tough it crashes when launching "WARGLE!" which is dated 1988 and is supposed to be run under System 4.3. I tried with various other early Mac OS versions and it always crashes the emulator. Wanna see if you can overcome the illegal instruction by patching Mini vMac?
[... abandonware url ...]
The person to ask is whoever posted that screenshot showing it working in Mini vMac for Windows. How did they get it to work? I suspect the disk image provided is not what they were using. For one thing, the System Folder on it is not “blessed” (so not bootable).
On second thought, I see the screenshot is labeled “Early advertising for the game”, so this may not be the game itself, and perhaps it never did work. In which case, it could just be something copied from a copy protected disk, and therefore unusable.
Sent: Thu Apr 5 08:23:13 2018
First thank you for providing such an amazing piece of software. I've compiled vMac both for Windows and OS X and I have a great time using Hypercard.
I have a question about the amount of RAM. A Mac SE, according to wikepedia, could handle 128 Mb of RAM. Mini vMAc seems to be limited to 8 Mb.
Is there a way of getting more memory ?
A Macintosh SE/30 can handle up to 128 MB of RAM. A Macintosh SE is actually an entirely different computer and can only handle up to 4 MB of RAM.
A Macintosh SE/30 is much closer to the Macintosh II than to a Macintosh SE. The ROM from a Macintosh SE/30 can be used in the Macintosh II emulation of Mini vMac. The Macintosh II emulation is limited to 8MB because the Macintosh II ROM, and the Macintosh SE/30 ROM, are not “32 bit clean”. According to the Macintosh II article on Wikipedia, the software “MODE32” will allow a Macintosh II to use more memory, but only if the optional PMMU is installed, which Mini vMac does not emulate yet.
Sent: Sun Apr 1 07:06:30 2018
Hi - I have the source code to an former commercial early 90s mac word processor called wordmaker, with the permission to GPL it. Would like to take care of it and make sure it's released in a repo somewhere? I have no big interest in mac preservation atm, my focus is on preserving amiga software source code and I got this code with a batch of other stuff.
[... email address ...]
I would be happy to host it on the Gryphel Project, in the Software section. Assuming it runs on a Macintosh Plus, which seems likely for that time.
An example of formerly commercial commercial software that is already hosted there, with source code, is MacPaint.
Sent: Fri Mar 30 09:24:17 2018
thanks for your work on Mini vMac, I love it.
I have a problem building the sources on Visual Studio 2017 version 15.6.4 under Windows 10. The build is successful (with 2 warnings, you can check the output here: https://pastebin.com/Pw8Nw3FU) but when I boot Mini vMac using MinivMacBootv2.dsk (a System 7.5.5 Boot Disk with some utilities) the text on screen is not shown correctly: https://imgur.com/a/hGLcu
Do you have an idea of what I'm doing wrong?
My guess is there is some issue with the CPU emulation, perhaps the bitfield instructions (which might be used for drawing and not much else). Either the compiler has a bug, or more likely Mini vMac has a bug that doesn’t show up with a different compiler.
What build options are you using?
Sent: Fri Mar 30 05:42:27 2018
Can I ask for a custom MAC at a time?
So how long will it be valid?
To remove the demo option.
You can request non demo variations with a Sponsor Code. The Sponsor Code page describes how to obtain and use one. With a donation to the Gryphel Project, you can use the Variations Service to request any variation, and usually receive it in 30 seconds. Without the Sponsor Code, you can try out the Variations Service and request demo variations.
The Sponsor Code is good for one year. The Variations that are obtained with it can be used forever, and given to anyone. (The demo versions have no time limit either. For both regular and demo versions, not preference files are created, no registry keys are set, or any other change made to your computer.)
Sent: Thu Mar 29 13:09:21 2018
Hi Paul, I'm using custom variation 180327_075418_257.html (version 36.00). This is to let you know I just ran across an exception 040F. This happened while an AfterDark 2.0 based "Peanuts" screen saver was active and sound was playing. Other than the dialogue announcing the exception covering part of the screen there were no adverse effects (the screen saver continued to run, sound continued playing, and after I pressed "C" for "continue" everything went on smoothly. Thanks for your great work, kind regards, Karl
Thanks for the report. I happen to have AfterDark 2.0, bought used. But I can't find a "Peanuts" module for it.
040F indicates setting a flag in the VIA 1 interrupt enable register that was not expected to ever be set. Abnormal situation reports often seem to be due to bugs in Macintosh software causing access to random locations in memory. But the access is usually harmless (otherwise the bug would have been noticed and fixed). so I'm thinking that maybe in the future most such reports should be disabled by default.
Sent: Sun Mar 25 12:12:45 2018
I was just wondering what's been changed in the Mini vMac 3.6.0 Alpha? I couldn't find any notes anywhere listing the changes. Thanks for this amazing software. Been playing a bunch of Dark Castle & Beyond Dark Castle.
The Alpha Changes list is now available. It went live apparently soon after you sent your message.
The version numbering scheme has just changed, it is now Mini vMac 36.00 instead of Mini vMac 3.6.0.
Sent: Thu Mar 22 12:00:36 2018
Question for you regarding getting started. I don't have access to a functioning machine anymore but I wanted to get setup on System 7.5.5 but I only wanted to use system disks and other software that I've downloaded from apple.com or here on Gryphel since I don't know how much I should trust the integrity of the stuff on abandonware sites.
I can extract and boot the System 6 images on the System Software page here on Gryphel. After booting System 6 I thought I could then run the System 7.0.1 or System 7.5.3 installers also linked from the System Software page. However, once I get those running they exit with an error code saying then can only run on System 7.0.1 or later. Seems like a chicken-or-the-egg problem since I need to boot System 7 before I can install System 7.
After some searching I found the Network Access disk hosted from apple (http://download.info.apple.com/Apple_Support_Area/ Apple_Software_Updates/English-North_American/Macintosh/Utilities/ Network_Access_Disk_7.5.sea.bin). This seems like what I want since it's System 7.5 and hosted from Apple so I assume clean and trust worth. The disk supposedly boots any Macintosh but it crashed Mini vMac in Mac Plus mode. It does work in Mac SE thought which is enough to let me get the data extracted and boot strap my entire system from Scratch using just the known-source software.
So my question, do you think the crash is due to an issue with Mini vMac or would it also crash a real Mac Plus? I guess "every Mac" doesn't apply here since the Mac Plus couldn't read the 1.44 MB disk so it couldn't boot it anyway under normal circumstances.
Either way, seems like the Network Access disk is useful for other variations of Mini vMac and as far as I can tell the only way to make use of the System 7 links on the page. I'd suggest also linking to that disk image on the System Software page to help other folks like me in the future.Thanks!!
I don’t think the Network Access disk would work on a real Macintosh Plus either. One source on the web says “It was designed for starting up all Macintosh computers (newer than the Macintosh Plus)”. It does work in the Macintosh II emulation of Mini vMac.
To get started with Mini vMac, see the Getting started with Mini vMac page, which concludes by linking to the Using Mini vMac page, which begins by linking to the Recipes for Mini vMac page, which has step by step instructions for getting working System 7 install images.
I see I should put a link from my System Software 7.0 page to the appropriate recipe page.
As mentioned on my Software for Macintosh Plus page, “the nice thing about an emulator such as Mini vMac is that you can try out programs without risk. Software running within the emulated machine can only affect mounted disk images. So when trying out software, you can work with copies of your disk images, and then throw out these copies when you are done. No harm is possible (unless there is a serious bug in Mini vMac).”
Sent: Sun Mar 18 04:09:37 2018
I just realized after reviewing the documentation pages to do another round of builds that they don't actually have the -t mc64 option listed for 64-bit OS X yet. Would you be able to add this to http://www.gryphel.com/c/minivmac/options.html#option_t ?
Thanks! It gets me every time I wait too long between builds and then have to resort to viewing the source code on the Variations page to get the right value.
Oops! Thanks for pointing this out. I have added it.
Sent: Tue Mar 13 05:11:05 2018
Dear Paul: Just a quick question - is it possible to make a virtual Hard Drive in Mini vMac? I know that you can put in as many Floppies as allowed, but I'm just curious because you can put in Hard Drives in another Mac emulator, PCE.
Mini vMac doesn’t have the ability to emulate a SCSI Hard Drive. But its replacement driver for floppy disks allows using any size disk image. Also, it can automatically mount images on launch. (See the Floppy Drives section of the Emulated Hardware Reference.) So emulating SCSI drives would not make too much difference for most uses.
Sent: Sat Mar 10 16:11:11 2018
can you give me the sponsor code for mini vmac emulating macintosh se
The Sponsor Code page describes how to obtain and use one. With a donation to the Gryphel Project, you can use the Variations Service to request any variation, and usually receive it in 30 seconds. Without the Sponsor Code, you can try out the Variations Service and request demo variations.
Sent: Mon Mar 5 19:14:08 2018
There is a neat guide here to getting an upgraded OS and colour going,
I get lost about step 12. I think some stuff has been dropped. Possibly a block got deleted by selection while the author was transferring it to web. If you have any thoughts, maybe we could get a tidied up version of that info onto gryphel.
Thanks for the link.
These days it isn’t necessary to compile your own variation to get started with Mac II emulation. I provide a basic set of Macintosh II variations (with 640x480 display with 256 colors). You can request other variations with the Variations Service.
I wouldn’t recommend starting with System 7.5. Earlier Systems are much smaller and simpler, and work better on the earliest Macs. In Recipes for Mini vMac, I show how to set up some earlier Systems. The instructions are illustrated with Macintosh Plus emulation, but the installed Systems will work on a Macintosh II. (I say to choose the “System software for any Macintosh” option.)
Anyone getting started with Mini vMac should start with the Getting started with Mini vMac page. It is about Macintosh Plus emulation, but I think people should first understand using the default emulation of Mini vMac before trying other variations, such as Macintosh II emulation.
Sent: Mon Mar 5 19:13:09 2018
Seeking to build macpaint from source under vmac. You referred to this on hacker news.
Stuck: have not been able to install MPW. I can download the bin file,
[... url ...]
Not sure what to do with it once it is down. The bin file does not mount as a disk within my mini vmac.
Thanks for the site.
[... email address ...]
One way that works is to, in the Macintosh II emulation with System 7.0.1t, use Stuffit Expander 5.5 (not 4.0) to extract MPW-GM.img from MPW-GM.img.bin, and use Disk Copy 6.3.3 to mount the image.
Sent: Sun Mar 4 20:20:53 2018
Hello Paul, a quick question. My apologies if its answered elsewhere on this site but I haven't found it.
On the compile options page (http://www.gryphel.com/c/minivmac/options.html#option_m) it says that the Mac II emulation isn't complete and it won't be complete for the remainder of the 3.3.* version. There are also other references scattered around graphel.com that Mac II emulation isn't ready or isn't complete yet. Finally, I recall reading a page (can't find it again) that said pretty explicitly that Mac II isn't ready for prime-time so don't use it for real work.
So, my question is if all of this is still correct? Is the Mac II variant "safe" for real-work in 3.4.* or in 3.5.*? I ask because I used a 3.4.1 Mac II variant last year to do some preservation work creating archives of old files and software for real preservation and later use. I'm just wondering if I should be suspect of the quality or veracity of those archives now compared to if I had use the standard Mac Plus or another variant to do the work?
Thanks for pointing out that the warning on the options page should be updated. A more recent version is on the Download Mac II Variations page: “Macintosh II emulation in Mini vMac 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.”
So the Mac II variation is still not recommended for real work. With that said, if the results seem correct, it is probably ok, as long as floating point arithmetic is not involved.
Any time you make an archive, with any software or hardware, it is a good idea to verify the archive. Make sure you can extract files from the archive, and that the results match the original.
Also, it is a good idea make a checksum of an archive (such as MD5) after making it, so you can check later that the archive you have is actually the archive you have verified, and hasn’t gotten corrupted accidentally. So the steps are: make archive, make checksum, and then verify the archive. (One way to make an MD5 checksum is with my Md5Im tool.
And to be really thorough, you can sign the checksum, to guard against malicious corruption. Such as by using my new SigWrite tool.
Sent: Mon Feb 19 23:46:27 2018
The MPW link on the "compiling" page doesn't work anymore. My browser couldn't find the server "ftp.apple.com"
Yes, that link is gone. Most all of the links on the page are gone, so I have removed them all. My plan would be to eventually port a subset of the gcc version now used for official builds to Mac OS in Mini vMac, so that anyone could compile an exact match of the official builds.
Sent: Mon Feb 19 19:41:58 2018
Good morning Paul,
I have something to tell about the build page of this site. The link to
the lcc-win32 program forbids anyone from going to the page with
lcc-win32. You can still build Mini vMac for Microsoft Windows, one of
the programs to build it is the Dev C++ program, but you need to get the
most recent version, which is on SourceForge. To make it easier, here is
the link to the updated Dev C++ page:
Since most all of the links on the page are gone (and I haven’t used and can’t vouch for more current compilers) I have removed them all. My plan would be to eventually port a subset of the gcc version now used for official builds to Mac OS in Mini vMac, so that anyone could compile an exact match of the official builds.
Sent: Fri Feb 16 20:46:26 2018
Is the Mac OS 9 and earlier PPC build still supported?
The Macintosh Plus and Macintosh II versions of minivmac-3.3.3 that I compiled with MPW-GM 3.5 on a PowerPC G3 (Blue & White) running Mac OS 9.1 work really well.
Today, I decided it was time to update, so I compiled minivmac-3.5.8 in the same environment, using the option '-t mppc'. When I ran it, I immediately began experiencing seemingly random crashes, freezes, and bombs in the emulated computer.
Here is a repeatable test case:
1. Launch minivmac-3.5.8.
2. Drag the System 6.0.8 System Startup disk to minivmac.
3. Double-click the System Startup drive icon (if minivmac hasn't already frozen).
4. Double-click the System Folder.
5. Click the System Folder close box.
6. Repeat steps 4 and 5 up to 15 or 20 times. The number of tries is random, but eventually the emulated computer will stop responding to keyboard or mouse input. However, the mouse can still be used to drag the minivmac window around the screen, and the host computer will still respond normally to other keyboard and mouse input.
7. Use CTRL-Q,Y to quit minivmac; the minivmac interface does not appear to be affected.
More randomly, the emulated computer will sometimes refuse to boot. This behavior is not predictable, and therefore not easily repeated, but I have seen at least two different things happen upon dragging a boot disk to minivmac-3.5.8:
1. A grey screen with a watch cursor stuck at 9:00.
2. The following bomb dialog:
"Not enough memory is available while using"
"" [blank line]
"To temporarily turn off extensions, restart and hold down the shift key."
Clicking Restart freezes the emulated computer.
Again, in each situation, the real computer is still responsive and CTRL-Q,Y can be used to quit.
Just in case there was some software change causing the problem, I recompiled minivmac-3.3.3 with the optopn '-t mppc', then tested it. I also compiled and tested the beta version, minivmac161023-3.5. Both of these worked fine, so it seems that something is different with 3.5.8.
Can you look into this?
Thanks for your many years of work on this immense and important project.
I seem to remember that there are some issues with the final version of the C compiler for MPW, and that older versions worked better. The difference in Mini vMac 3.5.x compared to earlier versions is that the assembly language code has been removed, and it is now relying on the C compiler for the CPU emulation. Unfortunately the version of GCC that I’m using doesn't support classic Mac OS, and I didn’t have luck getting Retro68 to work when I tried it. But I would like to eventually add classic Mac OS support to my version of GCC.
Sent: Tue Feb 13 23:41:42 2018
Your project is is important. And I do enjoy it, But I’m having problem with high sierra. Is there a fix?
What kind of problem? Something different from what is documented on the OS X notes for Mini vMac page?
Sent: Mon Feb 12 19:18:08 2018
I used PowerClicks years ago and it was wonderful. Is there any way it can be adapted or recreated for the current line of Macs. I have a wonderful Mac mini, circa 2014, but using mouse is becoming a problem. The current Mouse Keys business is just awkward. Using #5 to click the mouse is a real pain. I Used F1 LEFTHANDED to click the mouse in PowerClicks.
If you know of anything else that might help, please let me know.
[... email address ...]
Sorry, software for current OS X is outside my area of interest and expertise.
Sent: Tue Feb 6 16:00:41 2018
Prince of Persia 2
The game uses the "control" key for swordfighting.
Is there a workaround?
Yes, the game uses the "0 ins" key for swordfighting too :)
But I've noticed another problem:
Many screens during game's introduction are distorted (not visible). Is there any solution for that?
The current plan is to provide a compile time option to choose some other key besides “Control” to control the emulator.
Prince of Persia 2 is a game for Macintosh II, and the Macintosh II emulation is not yet complete. As you have found out (and described elsewhere), it does work in some other screen resolutions. It appears to treat a set of common resolutions differently, probably to optimize drawing in these cases, which isn’t working in the current emulation.
Sent: Fri Feb 2 07:37:19 2018
this is a follow-up to my message from Mon Jan 29 on colour / greyscale Settings. I downloaded three variations from your wonderful Service, one with 4, one with 16, and one with 256 bit Color depth. When I run the 4 bit one and set it to greyscale, then shut it down, then open the 16 bit one, it actually opens in 16 bit greyscale (all on the same Mini vMac Hard Disk, with System 7.1.2). I assume that System 7 stores the greyscale / Color Switch on ist hard drive somewhere, as I can think of no other means by which this Setting might survive between different Mini vMac versions.
Plus, I took your advice and ignored Windows Defender's warnings, to no ill effect. Thank you very much!
I advise checking the checksum and signature I provide before ignoring such warnings. Anyway, it is good there were no ill effects.
For earlier mail, see the mail index.