Using "--mon_id Multiscan20in" option results in multiple windows where only one is useable

[fdanapfel]

Describe the bug
When adding the --mon_id Multiscan20in option to list of options when starting dingusppc it opens two separate windows, but only one is useable. The one labeled "640x489 200%" always stays black.

To Reproduce
Steps to reproduce the behavior:

1. add --mon_id Multiscan20in to list of options when starting dingusppc
2. See screenshot

Expected behavior
There should only be a single window showing the display of the VM.

Screenshots

Device Information (please complete the following information):

• Device Type: Desktop
• Host OS: macOS 13.7.8 (Ventura)
• Host Processor: 4,2 GHz Quad-Core Intel Core i7
• Host RAM: 48 GB
• Guest OS: Mac OS 9.1
• Guest Processor: PowerPC 604
• Guest ROM: Power Mac 8500
• Guest RAM: 256 MB]
• Build Date [e.g. 11/5/2026
• Version current pull from github repo

Additional context
Without adding the option I only get the small 640x480 black window and the VM doesn't boot.

[fdanapfel]

In addition to the bug report I also have a feature request related to the "--mon_id" option: it would be helpful if the available values for this parameter were shown when running "dingusppc list properties" instead of just mentioning "Any" and the default value:

% ~/Source/dingusppc/build/bin/dingusppc.app/Contents/MacOS/dingusppc list properties
...
          mon_id    specifies which monitor to emulate
                    Valid values: Any, 'AppleVision1710' (default)

I had to actually search in the source code to find the supported values:

dingusppc/devices/video/displayid.cpp

Line 50 in 2a85161

static const std::map<std::string, MonitorInfo> MonitorIdToCode = {

Also the manual doesn't mention all options (even though there are not that many):

dingusppc/zdocs/users/manual.md

Line 155 in 2a85161

mon_id

Would also be nice if the manual provided a list of the supported resolutions for each monitor type.

[dingusdev]

This one is more of a quirk as there are two video controllers in these Macs - sixty6 and control.

[fdanapfel]

This one is more of a quirk as there are two video controllers in these Macs - sixty6 and control.

Is there an option to disable the video controller responsible for the small window?

[dingusdev]

Go into machinetnt.cpp and remove "Sixty6Video" from:

static std::vectorstd::string pm8500_devices = {
"Hammerhead", "Bandit1", "GrandCentralTnt", "Chaos",
"Sixty6Video"
};

See if that works.

[fdanapfel]

Go into machinetnt.cpp and remove "Sixty6Video" from:

static std::vectorstd::string pm8500_devices = {
"Hammerhead", "Bandit1", "GrandCentralTnt", "Chaos",
"Sixty6Video"
};

See if that works.

Yepp, that worked.

After removing that line from machines/machinetnt.cpp so that the entry for the PowerMac 8500 looks like this

static std::vectorstd::string pm8500_devices = {
      "Hammerhead", "Bandit1", "GrandCentralTnt", "Chaos"
};

the second small, unuseable window no longer appears when starting the emulated PowerMac 8500.

[fdanapfel]

Did some further research, and now realized that this is related to the "has_svideo" and "has_composite" settings:

Device Sixty6Video Settings
------------------------------------
           has_composite : off
              has_svideo : off

If I add "Sixty6video" back in machines/machinetnt.cpp, recompile, and then start dingusppc with the option "has_composite=1" then there is output in the second smaller window as well. In fact the emulated Mac then used this as the boot screen.

But for some reason the boot then hangs. Seems like some of the Extensions enabled on the disk image don't like that composite display.

Would it be possible to change it so that the second window only appears if either "--has_composite=1" or "--has_svideo=1" are specified?

[joevt]

If you don't want Sixty6Video then use pm7500 or pm9500.
pm9500 doesn't have built in video (ControlVideo) so PCI GPU needs to be specified.

Regarding the mon_id property, I think we can create a single list of all possible values which can be reused anywhere this property exists.

pm6100 has a limited set of supported mon_id values (see PDMBuiltinMonitorIDs). We would leave this one unchanged.

Other GPUs may just have a default value (Platinum, Valkyrie, and pm6100 has HiRes12-14in; ControlVideo has AppleVision1710). We would add the list to those.

In my fork, mon_id can be specified as hex numbers, either a single sense code [0-7], or a sense code/extended sense code [0-7].[0-3][0-9A-F]).

We definitely want to add code to hide (or not create) display windows for GPUs that don't have a display connected. This code needs to be careful to not hide all display windows even if no display is connected to the machine because a window might be needed to handle some user input. Or maybe some code can handle this situation (no displays) as well.

We'll want to be able to hot plug a display window while the machine is running. Some OS's may have a "Detect Displays" button that can detect newly connected displays or changes to EDID or Apple sense code.