Arbitrary resolutions, multiple monitors, Thousands of colors

[adespoton]

Sorry, but I'm not understanding what you're suggesting I should try. That Memory setting is stored in the PRAM file. Further details would be appreciated.

When you make a memory change, drive image change, or move from a more recent OS version to an older version, always remove the XPRAM file and have the emulator generate a new one. Possibly also if you're messing around with different screen resolutions.

[mabinogian]

Sorry, still not following; hope you'll bear with me. By "XPRAM file" do you mean the "pram-macos-qfb.img" file that came with the experimental download? Because it was named to match this build, I thought maybe there was something in it that the build depends on. Are you saying to supply a blank pram file instead, by initializing a brand new one using the qemu-img utility, per the Guide?

[Cat_7]

Indeed the addressing mode is stored in pram, as is the scsi id from which Mac OS boots.

When I tested the arbitrary resolution builds when they started to become available, I noticed they had some issues when using the pram from a regular build or when starting with a empty one. To make life that bit easier, I include a known-to-work version to start with in the downloads. That version already has some monitor settings included.
Your mileage may vary when you start the arbitrary resolutions build with an empty pram, or when you mix them up. However, if you try please let us know what happens. My knowledge may be rusty

Best,
Cat_7

[Ronald P. Regensburg]

On real 68k Macs "Zapping PRAM", resetting/clearing the PRAM by holding the option-command-P-R keys during startup until the startup chime has sounded twice, used to be a much used solution for various issues. In an emulator like BasiliskII the equivalent is simply deleting the pram file. A new file will be created at next startup with pram-saved settings reset to defaults. Does a similar procedure not work with QEMU?

[mabinogian]

Not rusty, Mr. Cat_7!
Just tried what I had asked about, and it didn't work. Starting up with a fresh, blank pram file hung the emulation from the get-go.

[adespoton]

Not rusty, Mr. Cat_7!
Just tried what I had asked about, and it didn't work. Starting up with a fresh, blank pram file hung the emulation from the get-go.

Looks like we may need a "zap pram" script then that replaces the PRAM image with a default one :\ Either that, or someone files an issue against QEMU (to include a built-in feature to zero the PRAM? to track down the bug that prevents writing default values? to just investigate and see why qemu-system-m68k Q800 is behaving differently than other classic Mac emulators WRT PRAM?)

I'm curious now what MAME does for Q800 PRAM handling.

[SolraBizna]

A follow-up caveat (running System 7.5.5, on a MacOS host):
When I restarted after turning off 32-bit addressing in the Memory Control Panel, the emulation hung after opening its window.

It should work in 24-bit addressing mode, but I didn't actually test it outside of A/UX. There are currently no virtio drivers for A/UX, but your 24-bit application might run in its compatibility mode, if you don't mind a lot of extra work and some UNIX quirkiness.

(I should try to fix my driver in 24-bit addressing mode but I am very short of time lately.)

[mabinogian]

I decided to take up your suggestion and give A/UX a try.

The good news: my experience confirms that the qfb modification does indeed still work with 32-bit addressing turned off in A/UX.
The bad news (for me): the 24-bit program I am using, ReflexPlus, has a problem with A/UX unrelated to qfb. In particular, although ReflexPlus launches and initially seems to work fine, it hangs the emulator when Quit. And this still happens running A/UX in the regular stable builds of QEMU-68k, both v8.2 and v9.0. So the problem is not the fault of the qfb modification.

And here's an added wrinkle of interest regarding qfb:

During my vain attempts to avoid the ReflexPlus problem, I tried turning off the Cache Switch (Control Panel) to see if that sacrifice of speed for compatibility would help. It didn't. But it reminded me of something I had long forgotten. When the Cache Switch is off, the startup sequence always includes a reminder message to the user of this status. More importantly here, this message is accompanied by an attention-grabbing "honk" sound. So, I went back to my original QEMU-m68k-qfb configuration, running System 7.5.5, and turned the Cache off there. And this time when I tried to start up with 32-bit addressing off, the screen still stayed blank, but I also still heard the honk.

Long story short: it may be that the qfb conflict with 24-bit addressing in System 7.5.5 is not actually hanging the emulation but just preventing it from being displayed?

Hope this is a helpful clue if you or someone else is ever in a position to take another look at this qfb conflict with the 24-bit memory mode.

[SolraBizna]

Long story short: it may be that the qfb conflict with 24-bit addressing in System 7.5.5 is not actually hanging the emulation but just preventing it from being displayed?

Hope this is a helpful clue if you or someone else is ever in a position to take another look at this qfb conflict with the 24-bit memory mode.

This is indeed useful to know.

[mabinogian]

I really like the pristine magnification that the qfb build makes possible in full screen mode, so I've been using it a lot lately for System 7.5.5 with 32-bit addressing ON. And it had been rock-solid running many different applications until I ran into a problem that it seems to be causing with the installer for "Default Folder" v3.1.5.
(See 1st download at: https://macintoshgarden.org/apps/default-folder)

In the qfb build, trying to run the installer (in Easy mode, or any Custom mode except Uninstall) produces this error message:
--> The application "unknown" has unexpectedly quit, because an error of type 1 occurred.
Yet the installer runs just fine in the stable QEMU v8.2 build (and in v9.0, too). In fact, once installed that way, the qfb build hasn't shown any problem yet with the control panel itself.

Hoping someone can make use of this reproducible behavior if the code ever gets reexamined.

[TacitMac]

I am leaving this here in case anyone bumps into the same problem I had.

If anyone wants to apply the arbitrary resolutions patch to Qemu upstream, you can reference SolraBizna's Dec. 26 commit here:
https://github.com/SolraBizna/qemu/comm ... 5c323d9303

The only catch is that one has to change one line in hw/display/mac_qfb.com. Qemu doesn't compile with the original line 887 (dc->reset = qfb_nubus_reset;), and it has to changed to

Code: Select all

device_class_set_legacy_reset(dc, qfb_nubus_reset);

mac_qfb.c and mac_fb.c are very similar, and the above line is a modification of the reset line from the equivalent function in mac_fb.c. Qemu compiles (and works) with the above change.

Relatedly, it's also possible to apply Elliot Nunn's virtio-vga patch to upstream Qemu. I realize it's been deprecated/removed, but the patch (https://github.com/elliotnunn/classicvi ... in/patches) still works for PPC Mac OS 9 VMs and can be combined with the m68k arbitrary resolution patch.

The patches have been tested on Apple Silicon macOS 15.3.1 and arm64 and amd64 Debian 12, and would AFAIK work on Windows.

[Cat_7]

Thanks for writing that up. The reset function was rewritten and applied Qemu-wide some time ago and of course files that were not in the repo missed out
Our "qfb" download already contains that patch.

You have no issues with the virtio-vga device, no intermittent lockups?

Best,
Cat_7

[TacitMac]

Thanks for writing that up. The reset function was rewritten and applied Qemu-wide some time ago and of course files that were not in the repo missed out
Our "qfb" download already contains that patch.

You have no issues with the virtio-vga device, no intermittent lockups?

Best,
Cat_7

Do you keep your patches somewhere publicly available? When I checked GitHub I didn't see anything Qemu-related.

Regarding the virtio-vga device, my PPC VM has been quite stable. I wait to fullscreen the Qemu (Cocoa UI) window until after Mac OS 9 is fully booted, as it seemed Qemu and/or Mac OS 9 didn't like the automatic resolution changes during boot-up. Running BBEdit for LaTeX, Microsoft Word for coauthored manuscripts, and Adobe Acrobat for PDF-reading I don't get any lock-ups. I didn't apply the screamer patches as I wanted a quiet work area, so maybe not having sound makes a difference for stability?

I realize that QFB is the future, but having a high-resolution Mac OS 9 VM already now is quite useful to me. How is the porting of QFB to PPC going? I haven't seen any (public) activity, and I would like to follow the progress if I could.

[Cat_7]

Do you keep your patches somewhere publicly available?

No, for the qfb I just keep a copy of the file I patched. I brought the issue to the attention of the developer, but there has been no new release. I believe the qemu frame buffer patch was never sent to the qemu development list.
Other patches/repos on which our "experimental" builds are based are available on github. Just a few days ago someone expressed an interest to add gamma correction to qemu-system-ppc. It is not clear which direction that might take. https://lists.nongnu.org/archive/html/q ... 00029.html

Best,
Cat_7