To send mail to me, use the feedback form.
( - latest - )
Sent: Fri Jun 29 21:23:54 2018
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:
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:
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.
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 up 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
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.
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
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:
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
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.
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
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.
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
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.
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.
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."
(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:
Could you update that to show that for Macintosh II emulation, the default speed is 4x?
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.
[... name ...]
Sorry for delay. Thanks for the current email addres. [... thank you for donation ... access key ...]
For earlier mail, see the mail index.