Arbitrary resolutions, multiple monitors, Thousands of colors

About Qemu-system-m68k, a m68k Mac emulator for Windows, macOS and Linux that can run MacOS 7.1 to 8.1, AUX 3.x and NetBSD

Moderators: Cat_7, Ronald P. Regensburg

User avatar
adespoton
Forum All-Star
Posts: 4368
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by adespoton »

mabinogian wrote: Mon Jun 03, 2024 10:42 pm 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
Student Driver
Posts: 15
Joined: Thu May 30, 2024 5:22 pm

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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?
User avatar
Cat_7
Expert User
Posts: 6247
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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
User avatar
Ronald P. Regensburg
Expert User
Posts: 7885
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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
Student Driver
Posts: 15
Joined: Thu May 30, 2024 5:22 pm

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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.
User avatar
adespoton
Forum All-Star
Posts: 4368
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by adespoton »

mabinogian wrote: Tue Jun 04, 2024 1:45 pm 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.
User avatar
SolraBizna
Inquisitive Elf
Posts: 36
Joined: Mon Sep 27, 2021 1:39 am

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by SolraBizna »

mabinogian wrote: Mon Jun 03, 2024 7:25 pm 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
Student Driver
Posts: 15
Joined: Thu May 30, 2024 5:22 pm

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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.
User avatar
SolraBizna
Inquisitive Elf
Posts: 36
Joined: Mon Sep 27, 2021 1:39 am

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by SolraBizna »

mabinogian wrote: Sun Jun 16, 2024 9:56 pm 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
Student Driver
Posts: 15
Joined: Thu May 30, 2024 5:22 pm

Re: Arbitrary resolutions, multiple monitors, Thousands of colors

Post by 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.
Post Reply