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

Gryphel Project Mail

Volume 8


To send mail to me, use the feedback form.

( - latest - )

permanent link

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”.


permanent link

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).


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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?)


permanent link

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.


permanent link

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

permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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?)


permanent link

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

permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.)


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.


permanent link

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.)


permanent link

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.


permanent link

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 ...]


:
:
:

For earlier mail, see the mail index.

:
:
:


www.gryphel.com/c/mail/v8 - feedback
copyright (c) 2018 Paul C. Pratt