I am using Paul C. Pratt's Variations service to compile builds of Mini vMac, making use of this service while it lasts..
Anyway, I have found that when I compile Mac II systems with support for thousands, or millions of colors, the resulting executable displays graphical corruption when launched.
I am compiling for Windows x86_64 and running it in Windows 11 (22H2) with a Radeon Pro Vega 48.
Interestingly, the executable will still go onto boot the Mac OS - i.e. System 7.5.5 and seemingly run normally. However, if I try to then change the bit depth in the Monitors control panel, severe graphical corruption of the entire screen will result, and it will also corrupt the system disk and render it non-bootable.
Has anyone else experienced this issue?
https://www.dropbox.com/scl/fi/z5n0ysf7 ... 3k9oe&dl=0
Mini vMac - corrupted 16 and 24 bit graphics
Moderators: Cat_7, Ronald P. Regensburg
- adespoton
- Forum All-Star
- Posts: 4284
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: Mini vMac - corrupted 16 and 24 bit graphics
I haven't experienced this, but I do my own compiles and don't use the variations service, and my target is macOS not Windows 11.almeath wrote: ↑Sat Jul 29, 2023 7:21 am I am using Paul C. Pratt's Variations service to compile builds of Mini vMac, making use of this service while it lasts..
Anyway, I have found that when I compile Mac II systems with support for thousands, or millions of colors, the resulting executable displays graphical corruption when launched.
I am compiling for Windows x86_64 and running it in Windows 11 (22H2) with a Radeon Pro Vega 48.
Interestingly, the executable will still go onto boot the Mac OS - i.e. System 7.5.5 and seemingly run normally. However, if I try to then change the bit depth in the Monitors control panel, severe graphical corruption of the entire screen will result, and it will also corrupt the system disk and render it non-bootable.
Has anyone else experienced this issue?
https://www.dropbox.com/scl/fi/z5n0ysf7 ... 3k9oe&dl=0
Since the variations have hard-coded PRAM values and the graphics actually patch the ROM to handle graphics outside of guest system memory, there's a number of places that could be at fault here.
Re: Mini vMac - corrupted 16 and 24 bit graphics
Hi,
please open a bug report over at https://github.com/minivmac and include as many information as possible on how to exactly reproduce the issue. I'm currently maintaining this repository until Paul (hopefully) resurfaces.
With kind regards,
Egon
please open a bug report over at https://github.com/minivmac and include as many information as possible on how to exactly reproduce the issue. I'm currently maintaining this repository until Paul (hopefully) resurfaces.
With kind regards,
Egon
-
- Master Emulator
- Posts: 394
- Joined: Tue Aug 14, 2007 4:32 pm
- Location: People's Republic of China
Re: Mini vMac - corrupted 16 and 24 bit graphics
Confirmed there will be a crash upon switched to color mode with
Visual Studio 2005 and 2010 AMD64 compilers and mingw-w64 with Mac II, -api win and #define vMacScreenDepth 4 or 5, with -O2 optimizing for all modules.
Visual Studio 2019 compiler generated an executable that don't crash but with glitched graphics.
Edit: It's my fault that I forgot to change kVidMemRAM_Size when I changed vMacScreenDepth.
Visual Studio 2005 and 2010 AMD64 compilers and mingw-w64 with Mac II, -api win and #define vMacScreenDepth 4 or 5, with -O2 optimizing for all modules.
Visual Studio 2019 compiler generated an executable that don't crash but with glitched graphics.
Edit: It's my fault that I forgot to change kVidMemRAM_Size when I changed vMacScreenDepth.