PowerPC does not work with 256 colours

[UTMDiscordBot]

<@519200220026896395> The only difference I noticed (apart of that graphics corruption bug when changing colors in OS9) was, in UTM newer versions when I start the PPC machine the screen shows the message "guest hasnt initialized the display yet" seconds before loading OpenBios firmware to boot OS 9. Prior versions and even QEMU 7 does not show that, they go straight to a black screen for 2 seconds before loading OpenBios & OS 9. I am using the exact same configuration for both QEMU and UTM, -device VGA. The only difference is that on QEMU command line I call -device VGA,edid=on

In case you want to check it, heres the gist of the commands I use to boot in QEMU 7.0.0: https://gist.github.com/brunocastello/6fd067621196d74d758faf95f98e8e0e

Created using UTMbot

Questioner: 🇪🇸 Bruninho#9075
Moderator: osy#9440

[osy]

https://gist.github.com/brunocastello/6fd067621196d74d758faf95f98e8e0e

[brunocastello]

When changing to 256 colors in MacOS 9.2.2

[brunocastello]

When changing to Thousands of colors in MacOS 9.2.2

Operating system works fine when using Millions of colors

[brunocastello]

The expected output would be:

[Waitsnake]

I see the same Issue on my M1 MBA with UTM 4.0.0, 3.2.4, 3.2.3, 3.2.2, 3.2.1 and 3.2.0 when running macOS 9.2.1. The modes 256 grays, 256 colors and Thousands of Colors did not work. Only the mode Millions of Colors works.

In contrast the version UTM 3.1.5 works perfect with all different color modes (256 Grays, 256 Golors, Thousands of Colors and Millions of Colors).

[cat7]

This is a regression that already slipped into Qemu 7.0. Patch is on the way: https://lists.nongnu.org/archive/html/qemu-devel/2022-08/msg02329.html

[brunocastello]

@cat7 I dont doubt you, in fact I'd be more than happy to see it fixed by qemu devs now, but if its a regression, then why I am able to use it properly in a vanilla qemu 7.0 four days ago but not in UTM? What (piece of information) am I missing here?

Either way, thanks for the patch and also thanks to osy for looking at it.

[cat7]

I wouldn´t know. The issue was introduced at: cb8962c146b2633a4b04562281de9b2703bba849 is the first bad commit
Date: Tue Feb 15 00:13:37 2022 +0400
So well before 7.0.0 was released. When I reported it to the Qemu devs back in June, I had to go back to 6.2 to get a build that was not affected. I just downloaded/compiled the 7.0.0 tarball and the issue is there alright.

[osy]

@brunocastello I tested the build artifact https://github.com/utmapp/UTM/actions/runs/2871051302 and it appears to fix the issue.

[brunocastello]

In two or three hours, right after my work shift, I'll be able to test the build artifact. Thanks!

[brunocastello]

@osy I went to test the artifact, and...

What am I doing wrong?

[osy]

You probably didn't run package_mac.sh. Anyways, if you're not familiar with the process, just wait for the next update next week. I've already confirmed this bug is fixed.

[brunocastello]

@osy I actually understood it and tried again, this time I ran the script. Anyway, it showed me an alert about a problem with the vmnet, not sure why, since it work on current versions. So, I switched from Bridged to Emulated VLAN and I was able to test it. I can confirm, it was fixed. Thanks.