:
Sent: Wed Jan 16 02:37:59 2019
Hi!
Just a heads up: On your page for Disk Copy, you list version 6.3.3, which doesn't work on US system software on a Plus.
However, Apple also provides an earlier release which works just fine under US system software. Tested with a US 7.5.3.
Here's the link, if you're interested in adding it to the Disk Copy page.
Thanks for pointing this out. In my recipes, I suggest using the British System version. Using this earlier Disk Copy version could be easier.
Sent: Wed Jan 9 08:07:54 2019
Hi,
All the Mac OS classic softwares on your site are provided on HFS disk images, which is great. My problem is with softwares from other sources which are provided in .sit archives, for instance "Cricket Graph 1.3" : [... url ...]
I first tried to transfer directly the .sit file to the MiniVmac :
- either directly by using ImportFl
- or by creating a HFS image with makeisofs
The problem is that Stuffit Expander (4.0, found on your site) won't expand the archive, even with the "trick" of the CMD key to expand the content of a folder... SE is actually doing something (there's a delay of about 1-2 secs where it is occupied) but I can see no expanded file at the end... Do you have any clue ?
I could at the end transfer the application by decompressing the .sit file on macOS 10.12, creating a "arc.zip" file, and using ImportFl and MiniUnZp: this works, but this is a bit tedious...
Other subject : I don't see "Shufflepuck Cafe" on your site. This was a great game, you can get it there if you want to add it:
[... url ...]
Cheers
Pierre
Many abandonware archives that can be found on the web require a later version of Stuffit Expander. Stuffit Expander 5.5, which is offered further down on my Stuffit Expander page, will run in the current Macintosh II emulation of Mini vMac, and can handle many such archives.
Shufflepuck Cafe is not shareware, freeware, or open source, and so unfortunately is not eligible to be included here.
Sent: Thu Jan 3 07:30:49 2019
Hi Paul C. Pratt!
vMac Mini have way save memory dump during emulation? Thanks!
Sorry, no. See this previous message.
Sent: Sat Dec 29 18:20:59 2018
I'm trying to compile Mini vMac 36.04 on my MacBook Pro. Here's my command setup:
gcc setup/tool.c -o setup_t
./setup_t -t mc64 -m II -hres 640 -vres 480 -depth 3 -sound 1 -sss 4 -ta 2 -em-cpu 2 -mem 8M -magnify 1 -speed 3 -bg 1 -n "minivmac-36.04" -maintainer "Holiday Lemmings" > setup.sh
. ./setup.sh
make
Everything compiles except for 2 issues:
After running the command to generate the setup.sh file, I get this message:
unknown switch : -maintainer
Even though I have the "-magnify 1" option included, it doesn't work. Magnify is off still.
Any help/suggestions would be great.
The “-maintainer” switch is now obsolete. It has been replaced by defining “kMaintainerName” in “setup/CONFIGUR.i” when compiling the setup tool, as documented in Setup Tool Configuration.
The “-magnify 1” seems to work for me. What options did you use? (The options you state would not compile because of the “-maintainer” issue.)
Sent: Thu Dec 27 04:51:03 2018
Hi Paul,
I find this whole project nostalgic and amazing.
I am not a programmer, but I was lucky enough to have an SE/30 running System 6 when they first came out.
Do you know what the maximum screen resolution for system 6 is? I cannot find too much documentation on this.
I would like to see if I can do any design work on it, kind of like I used to in 1988.
I have a 27 inch iMac and I'm wondering how big I can make the window without doubling pixels.
I am also considering making a project of getting myself a laptop and having a portable System 6 and System 7 setup.
Do you have any experience with this?
Thanks
Isaac [... last name ...]
[... email address ...]
For Mac II emulation, Mini vMac allows up to 4 Megabytes of Video RAM. For earlier models, Mini vMac allows up to 256K of Video RAM, which equal 2 Megapixels (I see this isn’t documented - thank you for making me notice).
I just verified that the Macintosh Plus emulation with System 6 works with “-hres 1920 -vres 1080”, which is very close to the limit.
Currently my main computer is a small laptop, and I take it everywhere, with all of my files. Previously I had experimented with with keeping Mini vMac disk images on a thumb drive, so that I could use these files with any computer.
Sent: Fri Oct 19 20:16:30 2018
Hey there,
I was trying to build a dedicated 320x224 Pocket PC variation of Mini vMac for my XDA IIs with the Windows CE 5.0 libraries/headers + XP Platform SDK on VC 2005 Express but so far none of the supplied header sets seem to work properly with the OSGLUWIN.c (which appears to handle the system calls) module. The first include to aygshell.h chains to winnt.h and winbase.h, which both generate tons of syntax errors. I assume the Pocket PC-specific source wasn't written for the CE 5.0 library... If that is the case, which SDK would you suggest I use?
Thank you,
[... name ...]
The Mini vMac build system seems to have some support for building the Windows CE version using Microsoft eMbedded Visual C++ 4.0 with Microsoft Pocket PC 2003 SDK.
The official build, as far as I can rembember, is using CeGCC built from source for GCC 4.7.4. You can get this from the Variations Service.
Sent: Mon Oct 15 11:01:20 2018
checksum fail
A few more details would be useful.
Checking website logs, I see that you downloaded the stable standard version of Mini vMac for several platforms, then downloaded the 32 bit Windows version again before posting, and did not view the md5 checksums that I provide. The browser agent string suggests 64 bit Linux.
So my guess is that expanding the zip file for Windows failed for you, giving some message about “checksum fail”. Is that right? If so, what software did you use to expand the zip file? Can you find the md5 checksum of the zip file, and compare it to the md5 checksums that I provide?
Sent: Sat Oct 6 04:36:50 2018
Hi,
https://www.gryphel.com/c/minivmac/extras/cnvtdc42/index.html says it converts "into the simpler format preferred by Mini vMac (discarding tags and checksums)." Although it's pretty much implied, it'd be nice if it explicitly said this was a "raw disk image" or something along those lines, I wasn't 100% sure that's what it was doing.
Thanks very much for all the great software!
I have tried to make this clearer.
Sent: Thu Sep 27 04:13:48 2018
I have a question about device support for MiniVMac.
I have a tablet that works with everything in an 'emulated mouse' mode and indeed works with MiniVmac but only when windowed. Is there something I should edit with my system or is there a compile option that would have the tablet emulate the mouse more properly? Basically what happens is in the middle of the screen moving left or right, the cursor position jumps to the side of the screen the cursor is moving towards; if you're moving the cursor to the right, then when it reaches the middle of the screen, it jumps all the way to the right and vice versa.
Thanks for any help; it's not a super big deal as I can run it in a window and that's fine, I just, you know, like to work without the distraction of the host operating system being visible, it's just a comfort/convenience thing, so it's not a super big deal at all.
Anyway, thanks for a cool emulator. I really like how it's designed and wish some of the other computer emulators (especially the Atari ST) had made the choices you have with Vmac.
Thanks again.
The -emm 0 option may help. “This option disables the more accurate mouse emulation normally used in Full Screen Mode, which looks at the motion of the real mouse rather than its absolute position. This allows Mini vMac to work somewhat better on tablet computers without a mouse. But such computers are still not really supported.”
This option can be used in the Variations Service (Mouse Emulation Accuracy). Or, for Mini vMac 36 in beta, the Advanced Variations Service.
Sent: Tue Sep 25 10:49:15 2018
Hello Paul,
THank you for your reply. I downloaded everything from the Gryphel website (specifically from the variations service page), unless someone has managed to rig up a very convincing fake!
Norton only flags recent color variations, not a black and white version I downloaded 5 years ago (very stable - in fact it works better than the original MacPlus or Classic!
One of my security programs gave me the option to block MinivMac from accessing the Internet, which I did.
On a university PC running Windows 10, Windows Defender just found nothing. Perhaps Norton is working a little too well? I have just come across a post from another user talking about a false positive from an antivirus program.
LMC
Thanks for the further information. My guess is that more likely than not it is a false alarm. But that depends on whether it really is trying to access the internet. If it is, there is a big problem. But maybe your antivirus is just offering to block it from accessing the internet in case it tries, rather than saying it had.
I know that Mini vMac for Windows running in VMWare Fusion does not try to access the internet. But it is not too exotic for malicious software to check whether it is running in VM, and do nothing in that case.
I can’t guarantee your copy of Mini vMac is not compromised. One never can for sure. Some possibilities for how my compiler tools could have gotten compromised start to come to mind. I have some ideas that would result in a more trusted compiler, but that would take a great deal of time to implement.
Sent: Tue Jul 17 22:13:38 2018
I'm very grateful for MinivMac and the possibility to "get back" old Macs and programs.
I haven't seen any particular problems, but Norton keeps insisting that various color versions of MinivMac contain viruses and even deletes them!
One funny thing though: Why in the world does the program try to access the Internet? The Web didn't exist in the days of the Mac Plus and MacII.
Mini vMac does not try to access the internet. If your copy does, something is very wrong, and Norton’s warning may be correct.
Where did you get your copy of Mini vMac? Please get it from www.gryphel.com. The https protocol will insure that is very likely you will get a good copy. This protocol still requres trusting a large number of people, so for greater certainty you can check the signatures with the tools I provide. Then you only need to trust me (and trust my understanding of digital signatures and ability to keep my own computers secure).
What indicated that your copy of Mini vMac is trying to access the internet? On OS X, I use Little Snitch for that.
By the way, it is in fact possible to access the internet with a Macintosh Plus and an external modem, and the right software. But Mini vMac doesn’t support emulating that.
Sent: Tue Jul 17 22:13:38 2018
I would just like to thank you for this project.
I have come to acquire a Mac SE FDHD and this website has helped me learn how it works.
It would have been a lot harder to get it working without MiniVMac and the guides here.
Sent: Fri Sep 14 08:01:52 2018
Hello, thank you for your great emulator.
A question: I have named the virtual hard disk "disk1.dsk". When I start Mini vMac, it boots from that disk.
However, when I restart the Mac using the "Special>Restart" menu entry, it doesn't boot from that disk, instead showing the "disk-with-question-mark" icon - as if it hadn't mounted disk1. I need to open it manually (control mode-o and then select the disk's file, i.e. disk1.dsk).
Is it possible to have Mini vMac mount the disk(s) which it mounts at startup also after a restart?
Have a great day, Karl
When Mini vMac starts, and disk1.dsk is found, it emulates inserting a disk. When you choose the Restart command from the Special menu, that is happening inside the emulation, and Mini vMac doesn’t really know about it.
It might not be impossible for Mini vMac to guess when a Restart command was chosen. When all disks are ejected, it could look if the virtual machine is doing things to the emulated hardware that happen on boot, which don’t happen when the shutdown command is chosen, or when the user has just ejected all disks manually from the Finder.
Alternatively, eventually there might be an option to emulate hard disks, that are not ejectable.
Meanwhile, you might find useful the “-iid 1” compile time option in the Mini vMac 36 beta. With that enabled, you can use Control-1 to remount “disk1.dsk”.
Sent: Wed Sep 12 05:33:16 2018
Hi Paul,
I was previously running the game PowerMonger under Mini vMac version 3.4.1 and it worked fine. I upgraded to 3.5.8 and now (with the exact same machine specifications and settings) the game crashes during startup.
The error from Mini vMac is "Abnormal Situation" with the code 011B.
The Mac system error is "Sorry, a system error occurred .. numeric overflow".
The system I am emulating is the Mac II.
Regards,
Adam
Thanks for the bug report! This seems to be due to a mistake in emulating the TrapCC instruction. The fix should be in the next beta version (36.02).
Sent: Sun Sep 9 12:33:24 2018
Hi Paul,
Prince of Persia runs noticably too slowly on emulators, including Mini vMac.
There is some discussion about that here:
http://forum.princed.org/viewtopic.php?f=63&t=3009&start=15#p24520
Apparently the Mac II had a refresh rate of 67 Hz, instead of 60.14742 Hz. Prince of Persia relies on _TickCount for frame timing, which is incremented at every vertical retrace interrupt. Hence the too slow gameplay.
(Running on Windows x86) I tried changing MyInvTimeStep in OSGLUWIN.C from 1089590 to 987149 (=1000/67*MyInvTimeDiv), and the constant in CyclesScaledPerTick in PROGMAIN.C from 130240UL to 116919UL (=7833600/67). After making these changes, the gameplay speed seems to be correct, although there are some issues. Most notably, sound becomes garbled. I can reduce the number of samples per subtick from 370 to 332 like so in ASCEMDEV.C:
// (22254.54545 / 67) / 16 = 20.75 samples per subtick
LOCALVAR const ui3r SubTick_n[kNumSubTicks] = {
21, 21, 21, 20, 21, 21, 21, 20,
21, 21, 21, 20, 21, 21, 21, 20
};
But, that causes noticable skipping in the sound... I don't know what is the correct fix for this.
Would you be willing to address these timing-related issues in Mini vMac? It would be great to be able to emulate Prince of Persia, and other games, at the intended speed and without sound hitches!
Thanks!
Thanks for the report.
A Macintosh II, unlike previous Macs with built in monitors, can have one or more external monitors, each of which can have its own resolution, color depth, and refresh rate. Furthermore, these values may be changed, and the driver software of each monitor gives information on what values are allowed.
For compatibility, the Macintosh II uses its second VIA chip to generate the same 60.15 Hz interrupt as on previous models, which is used to update the tick count and other tasks. (See the Vertical Retrace Manager chapter of the Inside Macintosh: Processes book.)
My guess is that Prince of Persia is assuming the ability of monitors to use a specific refresh rate, which Mini vMac does not implement. (It pretends to have a single monitor which only supports 60.15 Hz. ) Changing Mini vMac to use 67 Hz for the VIA2 timer, as well as the intended monitor vertical refresh interrupt, would not be accurate, and break compatibility with most other software. In the future, perhaps Mini vMac could have an option for monitor refresh rate. This will complicate things somewhat.
update - Reading more of that thread, it sound like the Macintosh port just runs slower than some other ports, by intention or accident, and so the emulators are correct. If so, changing the monitor refresh interrupt frequency will probably have no effect for this game. There might still be some software where it would be useful.
Sent: Mon Sep 3 06:31:23 2018
Hey, long-time user of mini vMac, here! Really cool to see that this project is still active and being worked on! And, wouldn't you know it, it fixed one of my problems! Now I can play Out of this World on an emulated Macintosh II, and the sound works now! Yay!!!
One question I had for you, though: it appears that AutQuit7 is not working properly. I'm using version 3.5.8 for the Macintosh II downloaded from your site (I did *not* compile it myself), and using System Software 7.5.3 Revision 2. AutQuit7 launches successfully when I put an alias to it in the Startup Items folder, but the associated "app" alias is not automatically launched by AutQuit7. In addition, when I manually launch the "app" alias, and then quit the associated application it launches, AutQuit7 does not automatically shut down mini vMac.
Totally possible I could be doing something wrong, and it's not at all the end of the world. Just wanted to see if it was something I was doing wrong, or if it's a bug.
Thanks for the report. I suspect the issue is with the preferred memory size. I have added the following paragraph to the AutQuit7 page:
If the preferred memory size of “app” is greater than what is available, then AutQuit7 will fail to launch it, even though manually launching “app” would work fine (by giving it what is available, as long as that is greater than the minimum size). To fix this, make sure the application is not running, select the icon of the application (not the alias), choose the Get Info command from the File menu, and edit the “Preferred size” field of the Memory Requirements. To find the maximum size that will work, choose the “About This Macintosh” command from the Apple menu, and look at the Largest Unused Block. (It is safer to use somewhat less than that exact amount.)
(When the launch fails, AutQuit7 quits. It will not notice if you manually launch and then quit “app”.)
Looking at the documentation for the LaunchApplication function, it looks like this behavior can be changed by using launchUseMinimum in launchControlFlags. So this might be fixable, and so can be considered a bug in AutQuit7.
update - I have made a new version of AutQuit7 that uses launchUseMinimum in launchControlFlags.
Sent: Sat Sep 1 15:41:38 2018
Has there been a port of the mini vmac software to raspberry pi? If so, where can I find it?
The Linux for ARM (“larm”) version of Mini vMac, from the Standard Variations page, should work fine on a Raspberry Pi running Raspbian, as far as I know. It would probably also work on other ports of Linux.
Sent: Wed Aug 22 16:32:42 2018
Is sit possible to pass some control characters back to mini vMac? especially the ctrl-c and ctrl-s.
Thanks!
Yes. As mentioned in the keyboard section of the Emulated Hardware Reference, the emulated Control key can be toggled with the ‘K’ command of the Control Mode. So usually, for example, to type ‘cntl-c’ on the emulated keyboard, you can type ‘Control-K’, ‘c’, and ‘Control-K’ again.
Alternatively, in the Mini vMac 36 Alpha, there is a new Keyboard Remap compile time option, so you could map the emulated Control Key to some other key, or else map the emulated Control Key to the real Control Key, and then map the Control Mode to something other than the Control Key. This can be tried out with the new Advanced Variations Service.
Sent: Tue Aug 21 16:45:44 2018
Hello. I am a person that was wondering if I could help mirror some files for The Gryphel Project. I have a website called [... url ...] (which i'm not really doing anything with right now), and was wanting to host some files so Thee Gryphel Project can live on. If you are interested, my discord is [... handle ...], and my steam is [... handle ...].
Thanks for the offer. But currently, bandwidth is not a major issue for the Gryphel Project server, so the overhead of keeping a mirror in sync does not seem worthwhile.
Should I get hit by a bus or something, so that there are no updates to this website for at least several weeks without explanation, then it would be nice if someone would make a mirror of the site, before it disappeared permanently.
If someone wants to do that, using software to automatically download this entire website, they should make sure to limit the bandwidth used by their crawler, to less than, say, 100k a minute, to avoid getting stopped by bandwidth limiting mechanisms of the web server.
(Until such a time, “crawling” this site - using a software tool to automatically download the entire website - is discouraged. If someone feels they must, please do make sure to limit the bandwidth used.)
Most all of the files that can be downloaded from this website are under licenses that permit anyone to distribute them for non-commercial use. Especially for the Software for Macintosh Plus section, people are welcome and encourage to do so. You could, for example, make a web page that gives more detailed information about some particular software that you like.
Sent: Mon Aug 20 14:54:53 2018
[...] Is there any way to compile the windows version to accept the '-d' directory option? [...]
Sorry, that is not implemented in the Windows version. It is possible to get a similar effect by listing all of the disk images in the desired directory on the command line.
The trend of Mini vMac is towards compile time options, and making it easy to generate a version of Mini vMac for each special purpose that is as simple as possible. So perhaps I might add a compile time option to specify a directory, that works like the '-d' command line option currently in the X versions.
Sent: Thu Aug 16 16:58:09 2018
Hi,
I have translated the Mini vMac to "Serbian cyrillic".
More info is in the file.
https://textuploader.com/d7mct
Thank you for the translation! I have added a Serbian Cyrillic page to the Mini vMac website localization pages, with your translation.
As you suggested, I then converted it to Latin script with 3 different online converters (which all gave the same result). I added a Serbian Latin page with this translation.
I have implemented the Serbian Latin translation in Mini vMac 36, to be included in the next development snapshot. Implementing Cyrillic for the cross platform font used by Mini vMac will take much more work. Maybe someday.
Sent: Thu Aug 9 23:24:48 2018
Hi, I'm trying to build mini vmac following the 'Building Mini vMac" guide, and using the options '-t wx86 -m II -depth 2 -ev 15000' (because I want to rum games that require 16 colors) the font looks bad, as you can see in this screenshot: http://es.tinypic.com/r/mjahyg/9
Do you know what is causing this problem? Thanks in advance.
This seems to be the same as a previously reported issue. It is now about the right time in the development cycle of Mini vMac 36 to look into this, i.e. making sure it works with all supported development environments.
Sent: Sun Aug 5 21:07:14 2018
One more question.
Would it be possible for you to put the options that you use for the Standard Variations near each download?
Thanks again Paul
A Standard Variation has only a single option, specifying the Target platform. For example “-t mc64”, for Macintosh OS X (64 bit).
A new feature in the Mini vMac 36 Alpha is the Control-P command, which copies to the clipboard the options used in building the variation.
Sent: Sun Aug 5 20:38:47 2018
Hi
You are the best. Thank you for your work.
I am trying to compile on a Raspberry Pi.
I tet the files well on the "out" directory, but I am not sure what are the next steps.
I did a "make" resulting in an executable, but I get all these errors.
gcc "src/MINEM68K.c" -o "bld/MINEM68K.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/OSGLUXWN.c" -o "bld/OSGLUXWN.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/GLOBGLUE.c" -o "bld/GLOBGLUE.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/M68KITAB.c" -o "bld/M68KITAB.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/VIAEMDEV.c" -o "bld/VIAEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/IWMEMDEV.c" -o "bld/IWMEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/SCCEMDEV.c" -o "bld/SCCEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/RTCEMDEV.c" -o "bld/RTCEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/ROMEMDEV.c" -o "bld/ROMEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/SCSIEMDV.c" -o "bld/SCSIEMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/SONYEMDV.c" -o "bld/SONYEMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/SCRNEMDV.c" -o "bld/SCRNEMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/MOUSEMDV.c" -o "bld/MOUSEMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/KBRDEMDV.c" -o "bld/KBRDEMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/SNDEMDEV.c" -o "bld/SNDEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc "src/PROGMAIN.c" -o "bld/PROGMAIN.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Os gcc \
Is there a tutorial (for newbies like me) or something I should do to get rid of those errors?
Thanks Paul
Those aren’t errors, but the normal progress reports of the make tool.
For people who are not programmers, and not interested in how Mini vMac works and in modifying it, but just want a compiled variation of the program, it is usually much simpler and faster to use the Variations Service.
Sent: Tue Jul 24 14:14:10 2018
Hello,
I can’t use the gryphel site with my SE/30 (Netscape 2) anymore :-(
What happened?
Sincerly,
Kristian Möller
As mentioned in recent news, www.gryphel.com now follows current recommendations to always use encryption. (In particular, due to strong “encouragement” by Google.)
If you want to access this website with very old web browsers, there is now www.gryphel.org, which has the same content, hosted by the same web server, but it works with unencrypted HTTP.
Sent: Sat Jul 21 23:08:34 2018
Paul,
To explain why my patch to use "printf" instead of "echo -n" was necessary, the shell builtin "echo -n" does not suppress a newline, but instead prints a literal "-n", on Mac OS X 10.5 and later. This change came as part of Apple's effort to gain POSIX certification for Mac OS X 10.5. (The shell builtin "echo -n" does suppress the newline on Mac OS X 10.4 and earlier, which were not POSIX certified.) There is also a separate /bin/echo executable which unlike the shell builtin echo does honor the "-n" flag on all macOS versions. You can see the difference by comparing the output of "sh -c 'echo -n hello'" and "sh -c '/bin/echo -n hello'".
"man echo" on Mac OS X 10.5 and later explains:
The following option is available:
-n Do not print the trailing newline character. This may also be
achieved by appending `\c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `\c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.
Some shells may provide a builtin echo command which is similar or
identical to this utility. Most notably, the builtin echo in sh(1) does
not accept the -n option. Consult the builtin(1) manual page.
-Ryan
(This is not for the default bash shell, but the sh shell, which seems in OS X seems to be also be bash, but invoked differently to enable a compatibilty mode. Presumably this is used in MacPorts for more compatiblity across different operating systems?)
Sent: Tue Jul 17 22:13:38 2018
The latest Alpha package does not seem to have the build image to bring into Mini vMac. Am I missing something?
See the news for July 15, 2018.
Sent: Tue Jul 17 22:13:38 2018
Paul,
I know you want people to use your variations service, but I wanted to let you know that MacPorts now also offers custom variation building:
https://github.com/macports/macports-ports/blob/master/emulators/minivmac-devel/files/README-custom.md
-Ryan
Sent: Sat Apr 5 11:26:42 2014
Paul,
Thanks for converting the build system back to a standard C program! This is much faster and easier to use.
I had to apply these patches to get it to work for me on macOS:
https://github.com/macports/macports-ports/blob/6410c31b87a9ecb924a4f023065057d88ea03086/emulators/minivmac-devel/files/echo-n.patch
https://github.com/macports/macports-ports/blob/6410c31b87a9ecb924a4f023065057d88ea03086/emulators/minivmac-devel/files/newline.patch
I found that the -maintainer, -homepage, -e and -ev build options didn't seem to exist, so I had to add corresponding values to setup/CONFIGUR.i instead, which worked fine.
When I compiled tool.c with clang, several warnings were emitted; perhaps these represent issues that should be corrected:
In file included from tool.c:45:
./WRTEXTFL.i:59:17: warning: format specifies type 'unsigned int' but the argument has type 'ui5r' (aka 'unsigned long') [-Wformat]
printf("%08X", v);
~~~~ ^
%08lX
In file included from tool.c:55:
./SPBLDOPT.i:1980:22: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if ((cur_MenuBlink < 0) || (cur_MenuBlink > 3)) {
~~~~~~~~~~~~~ ^ ~
./SPBLDOPT.i:2022:26: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if ((cur_AutoKeyThresh < 0) || (cur_AutoKeyThresh > 15)) {
~~~~~~~~~~~~~~~~~ ^ ~
./SPBLDOPT.i:2064:24: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if ((cur_AutoKeyRate < 0) || (cur_AutoKeyRate > 15)) {
~~~~~~~~~~~~~~~ ^ ~
./SPBLDOPT.i:2097:21: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if ((*cur_HilColV < 0) || (*cur_HilColV > 65535)) {
~~~~~~~~~~~~ ^ ~
./SPBLDOPT.i:2488:23: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if ((cur_SpeakerVol < 0) || (cur_SpeakerVol >= 8)) {
~~~~~~~~~~~~~~ ^ ~
In file included from tool.c:62:
./BLDUTIL3.i:696:10: warning: no case matching constant switch condition '8'
switch (cur_ide) {
^~~~~~~
./CONFIGUR.i:14:17: note: expanded from macro 'cur_ide'
#define cur_ide gbk_ide_xcd
^~~~~~~~~~~
./CNFGOPTS.i:32:21: note: expanded from macro 'gbk_ide_xcd'
#define gbk_ide_xcd 8 /* Apple XCode */
^
7 warnings generated.
-Ryan
Thanks for the patches. But after a few hours trying to look into the portability and performance of printf vs. echo, I’m starting to remember some other reasons for making the configuration code for Macintosh 680x0 only. I conclude that printf is better defined than echo, but it is not clear whether it is more or less available on all unix like command shells. So I’ve changed it to use printf, but still have a compile time option to use echo.
Maybe using printf instead of echo will take care of whatever it is that required your second patch. (It is not be needed in any shell I’ve seen. But for that matter, “echo -n’ works in all shells I’ve seen. Maybe there is something a bit strange about what MacPorts is doing.)
As I said, the new setup code is yet to be documented. But you seem to have found the intended use.
I’ve corrected the warnings.
Sent: Wed Jul 11 03:15:24 2018
Is there any plans on adding Save states to Mini vMac? It seems like you could save the current state of the ram in a dump reasonably easily.
It would be easy enough to save the state of RAM. But there is also other hardware that has state. A further complication is that there are many variations of Mini vMac, which can emulate different hardware, and so have different states. And even more complicated is how to handle the attached disk images. Saving a link to a disk image can not be done in platform independent manner. Another concern is what if the disk image was used by a different instance of Mini vMac and modified. A further concern with that is the image may have been in an inconsistent state when the state was saved, so if someone else modifies it, it may get hopelessly corrupted. All in all, this may be too complicated for “Mini” vMac.
A workaround is to run Mini vMac inside some virtualization software which can save snapshots, like VMWare, Parallels, or VirtualBox. You can save the state of the entire virtual machine including Mini vMac and its disk images.
Sent: Sat Jul 7 05:26:10 2018
Hi Paul,
Thanks for the "-svd 0" build system option in Mini vMac 36. I had been using a patch in MacPorts to do something similar. It's great to be able to just use this flag now.
There's a small bug: If running on Mac OS X 10.6 or earlier, it doesn't work unless I manually create the mnvm_dat/out folder manually first. This patch fixes the problem:
https://gist.github.com/ryandesign/a7fdea794e1b84a01f15536fabe7f9ff
-Ryan
I’ve merged in this fix.
Sent: Mon Jul 2 20:15:20 2018
Along with helping implement the 68881 FPU, I am also interested in implementing the 68851 PMMU.
1) Is Mini vMac's HMMU hardwired into the code or is it modular as to eventually easily support 68851? I'm planning to use Shoebill's incomplete source code.
2) I'm assuming that once a basic PMMU is added, Mini vMac will need to run with more RAM. How easy is it to implement -mem 16M?
3) I'm assuming that we can achieve maximum RAM of 68MB without the need for MODE32 nor need the FDHD ROM upgrade. Is this right?
(1) That depends on your definition of modular.
(2) Trivial compared to implementing a PMMU.
(3) With MODE32, it is said that 128MB of RAM is usable. Without it, 8MB is the maximum that the non 32 bit clean ROM can support. (Where did you get 68MB from?)
Sent: Sat Jun 30 18:33:21 2018
Paul,
The Xcode template for a Cocoa app's main() function just calls NSApplicationMain(). NSApplicationMain will read the NSPrincipalClass Info.plist key to decide which class to instantiate to run your app. Since Mini vMac doesn't use NSApplicationMain but instead does its own initialization of NSApplication in InitCocoaStuff, that explains why it still worked for me even when I set NSPrincipalClass to a nonsense value, since NSPrincipalClass isn't actually used, and I agree that setting NSHighResolutionCapable would be a clearer way to indicate Retina support.
-Ryan
Sent: Fri Jun 29 21:23:54 2018
Paul,
When Mini vMac is launched on a MacBook Pro with two graphics cards, it always switches to the high-power discrete GPU. This is undesirable because switching GPUs takes time and the system is unresponsive during the switch (it shouldn't take long, but on my Mac with many open programs and windows it takes over a second which is noticeable), and of course the discrete GPU takes more power which shortens battery life. Mini vMac works fine on the low-power integrated GPU, so it would be nice if it wouldn't force the use of the discrete GPU. Doing that requires supporting switching GPUs while the app is running.
Apple has some documentation on how to do this:
https://developer.apple.com/library/archive/qa/qa1734/
https://developer.apple.com/library/archive/technotes/tn2229/
The idea is:
1. Set the NSSupportsAutomaticGraphicsSwitching Info.plist key to true
2. Add an attribute when creating your OpenGL context that indicates that you're OK with the GPU being switched while running
3. Add a handler to respond to GPU change notifications to reconfigure as needed
Here is my patch that implements parts 1 and 2 for both Cocoa and Carbon APIs:
https://gist.github.com/ryandesign/6072766bdb0d74e895bd59826a2fb51c
Even though I didn't implement part 3, this works for me on a 2012 MacBook Pro with Retina Display running macOS Sierra -- the app is now happy to launch regardless which GPU is active at launch time, and it continues to work if the GPU is switched while running. I'm not sure if I'm just getting lucky with my particular Mac model or if Mini vMac's graphics needs are so modest that any OpenGL capabilities it asks for are present on all GPUs and so reconfiguration wouldn't change anything.
The UseAGLfullscreen codepath did not work well for me, but I didn't find a way to activate that codepath other than manually #defining UseAGLfullscreen 1, and then I got an error that DisplayIDType was undeclared, so I had to typedef UInt32 DisplayIDType. Given this, I wasn't sure if this codepath was perhaps old unused code, or else new unfinished code, so I didn't spend a lot of time trying to debug this.
-Ryan
This seems to be a reasonable thing to include. I would want to figure out the change notification handler. It reminds me of CGDisplayRegisterReconfigurationCallback, lack of which definitely caused occasional problems.
If I remember correctly, UseAGLfullscreen in the Carbon port was for testing out the full screen mode of AGL, but it turned out to be preferable to just have a large window covering all the screens and drawn to in the usual fashion.
Due to travel this week and next, the next development snapshot will probably not be until next Sunday.
Sent: Fri Jun 29 17:58:41 2018
Paul,
Regarding why most of Apple's apps support Retina displays despite not using the NSHighResolutionCapable Info.plist key, according to the documentation you found, "Most existing Cocoa apps are scaled automatically." It also says "Make sure your Cocoa app has a Principal class setting" (that's the NSPrincipalClass Info.plist key); Apple's apps have this, but Mini vMac doesn't. Indeed setting NSPrincipalClass (to any string!) seems to have the same effect as setting NSHighResolutionCapable to true. Most apps seem to set NSPrincipalClass to "NSApplication". Some set it to a custom class name, but I think Mini vMac is just using NSApplication and not a custom subclass of it.
-Ryan
Thanks for figuring this out. I’m thinking it may be better to use NSHighResolutionCapable, since Mini vMac doesn’t actually have a standard NSApplication class. I think this had something do with being a nibless application. Or else maybe from needing to have its own event loop.
Sent: Fri Jun 29 01:03:27 2018
How does one go about tracking down the culprit of a misbehaving (i.e. crashing) program? On a PC one would use a debugger like SoftIce. Run the program thru MacsBug? It would be nice to implement a control-key to stop Mini vMac and dump the memory/registers for inspection.
Yes, MacsBug is probably best (or some other debugger such as TMON). Displaying memory and registers is is unlikely to be helpful, more sophisticated tools are needed, such as displaying disassembled code.
Mini vMac actually does contain various logging infrastructure, including a disassembler, which is helpful for me in developing Mini vMac. But MacsBug or similar is much more likely to be useful to you.
You will need to use Mini vMac 36 Alpha. Mini vMac 3.5 has a bug that prevents debuggers from working correctly.
Sent: Thu Jun 28 17:40:06 2018
Paul,
When Mini vMac is launched on a Mac with a Retina display, its entire window, including the title bar, window frame and shadow, are drawn in an unattractive pixel-doubled compatibility mode. It would be great if the window could use Retina mode on a Retina display.
For the Cocoa API, this seems to be simple to do. Just add the key NSHighResolutionCapable to the Info.plist with the Boolean value true, as in this patch:
https://gist.github.com/ryandesign/32437746b7d23aa1d9583406d1da13e9
I have not noticed any ill effects from doing this. The title bar, frame and shadow are then drawn in Retina mode, and the window contents are still pixel-doubled as they should be. I didn't notice any problems on macOS Sierra or High Sierra when dragging the Mini vMac window between a Retina and a non-Retina display.
Retina mode is possible using the Carbon API too, but it is more complicated. In addition to the Info.plist key, kWindowHighResolutionCapableAttribute must be specified when calling CreateNewWindow. This attribute has no effect unless kWindowCompositingAttribute is also specified, but this attribute requires that Mini vMac implement its Carbon drawing with HIViews, which as far as I can tell it doesn't currently do, and I'm not sure if changing the code to do so would reduce compatibility with older systems, or how far back you want Mini vMac to work.
Is there any reason anymore why a macOS user (or at least a modern macOS user) should run the Carbon version of Mini vMac? Carbon is of course wildly deprecated by now, and since it's 32-bit only, it won't be usable in future versions of macOS which will remove 32-bit support. It seems like it might be ok to just focus on the Cocoa version and not bring Retina support to the Carbon version, or even deprecate or remove the Carbon version entirely. The Cocoa version is working fine for me back to Mac OS X 10.4; I haven't tested earlier versions.
-Ryan
Thanks for the report and patch. I think I should be able to get access to a computer with Retina screen to try this on.
This doesn’t seem to be documented very well by Apple. I finally found reference to it at High Resolution Guidelines for OS X which is an old document that is in a section of the website that Apple excludes search engines from. I notice that modern applications from Apple included with the OS don’t use NSHighResolutionCapable, so I wonder what the current recommended technique is?
The Cocoa port was new to Mini vMac 3.5.8, so I didn’t encourage every Mac user to use it then. Now that it’s been out for a while without problems, I’ll probably encourage all Mac users who aren’t using historical computers to use the 64 bit Cocoa port, at least for Mini vMac 36. I don’t think I’ll bother to support 32 bit Cocoa. It has been over a decade since a Mac has been made that can’t use 64 bit applications. I would probably keep the Carbon version available, but not bother supporting Retina, which wouldn’t be supported by those historical computers.
Sent: Wed Jun 27 11:51:52 2018
Paul,
When I specify "-t imch -all-src 1" in the build system for 36.00alpha180610, I get the error message that the disk is full. Would it be possible to distribute the source on a larger disk so that exporting all source is possible? Thanks.
-Ryan
Thanks for the report. I’ll fix this in the next snapshot.
(I didn’t notice this because I use “System Folder:Preferences:Gryphel:Build:output” to redirect the output, as mentioned in the build documentation, and keep the source image locked.)
Sent: Wed Jun 27 08:15:34 2018
Hi Paul,
After I submit feedback here, I see a message: "If you expect a reply, check later in the Mail Archive" where "Mail Archive" is a link to http://www.gryphel.com/c/mail/latest.html#latest. When I checked that URL a couple weeks ago, before you set up the new web server, it wasn't actually the latest mail, but I forgot to report it to you at the time. When I checked it today, I get an http redirect loop.
-Ryan
Thanks, I think I have this fixed now. (Though a bad redirect can linger in a broswer cache, you may need to clear it to get the fix.) Apparently I somehow missed that the previous fix didn’t work.
Sent: Wed Jun 27 08:05:32 2018
Paul,
Sorry this message is long but I wanted to be thorough. I'm seeing a problem that may be a bug in Mini vMac when not emulating a Macintosh Plus. A system error occurs when booting System 7.0.1 (with System 7 Tuner) or System 7.5.5, when AppleTalk is on and CPU speed is greater than 8 MHz.
AppleTalk is off when Mini vMac is first launched. I boot System 7, open the Chooser and click the Activate radio button, which requires a restart to actually activate. I restart and reinsert the startup disk, and a system error (divide by zero) is encountered. The Restart button in the system error dialog box usually does not work.
The system error dialog suggests that extensions may be disabled by pressing the shift key at startup. Doing so does not prevent the system error.
I've tested Mini vMac version 3.5.8 and 36.00alpha180610, both compiled by me using MacPorts *without* the "-lt" build system option, running on macOS Sierra or High Sierra. I see the problem when emulating a Macintosh Classic, II, SE or SE FDHD. I don't see the problem when emulating a Macintosh Plus.
For all but the Macintosh II emulation, if I first change the CPU speed to 1x, the system boots normally. For the Macintosh II emulation, 1x speed is 16 MHz and the system error still occurs. If I patch the Mini vMac source code to change kMyClockMult from 2 to 1 for the Macintosh II emulation, then it boots successfully at 1x speed. Increasing the CPU speed again after startup is complete doesn't seem to cause any problems.
Earlier System versions don't require a restart to activate AppleTalk and don't exhibit this problem. I didn't test System 7.1.
-Ryan
Thanks for the report. Unfortunately, since the AppleTalk emulation stuff is complex, and not much software uses it, this is a low priority for the Gryphel Project. It was years ago that I tried to get it to work well in Mini vMac, and wasn’t really satisfied. And since then I’ve mostly forgotten the details.
update - now I notice you said without the “-lt’ option. That might be a bit higher priority.
Sent: Wed Jun 27 03:40:27 2018
Very nice project. Works great for running System 7 on my Intel PC with Debian Linux. It's very simple to use, just drag and drop. I really appreciate this application.
Thanks.
Sent: Wed Jun 27 02:01:11 2018
1. Is there a Dev mailing list to make communication easier?
2. Do you envision 100% emulation of the FPU? Because SANE and 68881 could yield slightly different results in some cases. Also see below:
"* Improved FPU emulation, originally written for Mini vMac by Ross Martin. This code was modified to use SoftFloat, by John Hauser (as found used in the Bochs emulator), plus some extensions to SoftFloat by Stanislav Shwartsman (also found in Bochs). Though using SoftFloat is slower than using native floating point, it ensures consistent results on different computers, and makes it easier to compile with different development environments. There's still a lot of work to do on the FPU emulation, but it already allows much more software for the Mac II to run without crashing."
(1) No.
(2) Actually, I’ve been thinking of having the FPU emulation return the same answers as SANE does, since the algorithms can be studied in detail, 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: Wed Jun 27 02:00:24 2018
1. How does one build a Mac 512K from source? (Not the enhanced version)
2. Why does Space Quest 1 (256 color version) crash on the Mac II emulation? (I'd like to tackle that problem)
(1) Use build options “-m 128K -mem 512K ”. (A Mac 512K is just a Mac 128K with more memory.)
(2) Thanks for the report. In emulation, and in programming generally, once you know why it crashes, you are most of the way there to fixing it. (And most of the rest is testing and documentation.)
Sent: Mon Jun 25 19:54:38 2018
The options documentation says the default speed is 8x:
http://www.gryphel.com/c/minivmac/options.html#option_speed
Could you update that to show that for Macintosh II emulation, the default speed is 4x?
Thanks,
-Ryan
Thanks for pointing this out. I have tried to explain it in the options documentation.
Sent: Sat Jun 23 05:44:03 2018
Hi. First off, great work. This is a wonderful emulator.
Second. I donated [... amount ...] via PayPal on [... date ...], but didn't receive an email with a Sponsor Code. Probably because my PayPal is not connected with my current email. Anyway, I'd love to get it. My preferred email is [... email address ...]
Thanks so much.
Cheers,
[... name ...]
Sorry for delay. Thanks for the current email addres. [... thank you for donation ... access key ...]