qemu-system-m68k, vsync and Lemmings audio (trying to understand...)

[atreyu.ac]

Hi there!

I am happily using qemu-system-m68k on GNU/Linux, built from latest Qemu GIT sources, to emulate a Quadra 800.

But there's something I don't get about qemu-system-m68k, and about Macintosh classic systems in general.
Let's begin by setting some terms: original B/W Macintosh systems with built-in displays had an screen refresh of 60.14742Hz (they ran at [email protected] Hz).
Then, Mac II was [email protected] Hz. And after that, it seems that VGA modes started to be the norm, so there were many display modes to chose from on the display control panel. Fine.

So, what's with the video synchronization of the Mac II games like Lemmings on original Mac II hardware?
If, using qemu, I force VSYNC on the host, and even if I use a custom 66.662467 Hz video mode, the sound has constant dropouts, which indicates that the game is hindered by the limited vsync refresh rate of the host.
How did games work around the fact that several Mac models had different video refresh rates? Did they sync at all? Did the Mac games like lemmings simply have tearing because they ignored the computer's display refresh rate?

(NOTE: Yes, I can set any video mode I want on Wayland using wlr-ranrd and I do it all the time to emulate other non-60Hz like Amiga, Virtual Boy, etc)

[adespoton]

Hi there!

I am happily using qemu-system-m68k on GNU/Linux, built from latest Qemu GIT sources, to emulate a Quadra 800.

But there's something I don't get about qemu-system-m68k, and about Macintosh classic systems in general.
Let's begin by setting some terms: original B/W Macintosh systems with built-in displays had an screen refresh of 60.14742Hz (they ran at [email protected] Hz).
Then, Mac II was [email protected] Hz. And after that, it seems that VGA modes started to be the norm, so there were many display modes to chose from on the display control panel. Fine.

So, what's with the video synchronization of the Mac II games like Lemmings on original Mac II hardware?
If, using qemu, I force VSYNC on the host, and even if I use a custom 66.662467 Hz video mode, the sound has constant dropouts, which indicates that the game is hindered by the limited vsync refresh rate of the host.
How did games work around the fact that several Mac models had different video refresh rates? Did they sync at all? Did the Mac games like lemmings simply have tearing because they ignored the computer's display refresh rate?

(NOTE: Yes, I can set any video mode I want on Wayland using wlr-ranrd and I do it all the time to emulate other non-60Hz like Amiga, Virtual Boy, etc)

Well, there's a few things going on here. One is, audio emulation (in Mini vMac II and in QEMU-system-m68k) aren't fully functional; so under emulation, you're going to have audio sync issues. This has more to do with the audio buffer not being flushed at exactly the right time than it does with vsync.

As far as Macs and video refresh: for early Macs, games were usually slaved to the actual hardware performance. This means that a game written for the 128k when run on a Quadra would have the video out of sync with the audio, and both playing way too fast -- and depending on what the reference points were for various objects, the display could be really garbled too.

With the switch to VGA-style displays and 32-bit QuickDraw, Apple slaved both the audio and the video to the hardware clock, with the understanding that software would no longer be directly addressing the hardware, but would instead use the toolbox calls, which would in turn sync everything up for the hardware the OS was running on.

Lemmings runs on top of 32-bit Quickdraw, so shouldn't experience any tearing. Older games such as Alice, Dark Castle and the original Load Runner however, could exhibit tearing and audio glitches on more recent hardware.

But a LOT of work went into the toolbox to make hardware timing across hardware configurations "just work" on Mac OS. So you'll find that some OS/hardware combinations work just fine, while others don't work at all.

And that's why I spun up https://docs.google.com/spreadsheets/d/ ... edit#gid=0 - to track what works and what doesn't, both under real hardware configurations and under emulation.

[atreyu.ac]

Thanks, adespodon!

So there are multiple factors operating here: incomplete audio emulation, video synchronization, and the toolbox inner workings to make the games run well on Quadra 800 hardware.
Too many factors to be sure. I will try MAME for Mac 128K-level hardware emulation, and forget about color Mac emulation for now...

[mcayland]

Hi there!

I am happily using qemu-system-m68k on GNU/Linux, built from latest Qemu GIT sources, to emulate a Quadra 800.

Just to confirm this is the latest QEMU upstream sources at https://gitlab.com/qemu-project/qemu rather than my personal fork at github? Currently all outstanding QEMU 68k patches have been merged upstream.

But there's something I don't get about qemu-system-m68k, and about Macintosh classic systems in general.
Let's begin by setting some terms: original B/W Macintosh systems with built-in displays had an screen refresh of 60.14742Hz (they ran at [email protected] Hz).
Then, Mac II was [email protected] Hz. And after that, it seems that VGA modes started to be the norm, so there were many display modes to chose from on the display control panel. Fine.

So, what's with the video synchronization of the Mac II games like Lemmings on original Mac II hardware?
If, using qemu, I force VSYNC on the host, and even if I use a custom 66.662467 Hz video mode, the sound has constant dropouts, which indicates that the game is hindered by the limited vsync refresh rate of the host.
How did games work around the fact that several Mac models had different video refresh rates? Did they sync at all? Did the Mac games like lemmings simply have tearing because they ignored the computer's display refresh rate?

(NOTE: Yes, I can set any video mode I want on Wayland using wlr-ranrd and I do it all the time to emulate other non-60Hz like Amiga, Virtual Boy, etc)

Are you saying that the sound has constant dropouts in normal use, or only when you force VSYNC on the host? And how are you doing this? Internally QEMU used an internal OS high-res timer to generate the 60Hz interrupt and so the emulated machine framebuffer update rate is completely independent of that of the host.

You'll need to provide details of your OS and QEMU command line and if the sound issue persists without fiddling with VSYNC options, please provide a disk image so I can take a look.

[mcayland]

Well, there's a few things going on here. One is, audio emulation (in Mini vMac II and in QEMU-system-m68k) aren't fully functional; so under emulation, you're going to have audio sync issues. This has more to do with the audio buffer not being flushed at exactly the right time than it does with vsync.

Audio emulation under qemu-system-m68k is working fine as well as I know? There are issues with the qemu-system-ppc screamer patches which is why they haven't yet been merged upstream, but those aren't relevant here. If you do find a problem with the qemu-system-m68k audio emulation, please provide a test image for me to take a look at.

[atreyu.ac]

Are you saying that the sound has constant dropouts in normal use, or only when you force VSYNC on the host? And how are you doing this? Internally QEMU used an internal OS high-res timer to generate the 60Hz interrupt and so the emulated machine framebuffer update rate is completely independent of that of the host.

You'll need to provide details of your OS and QEMU command line and if the sound issue persists without fiddling with VSYNC options, please provide a disk image so I can take a look.

Hi, mcayland!

I'm saying that Lemmings sound has constant dropouts only when I force VSYNC (other games like Prince of Persia or Dungeon Master II are NOT affected).
I force VSYNC by passing SDL_RENDERER_PRESENTVSYNC to the SDL_CreateRenderer() call in QEMU's code.
I'm using upstream QEMU github code, not a fork. I'm on Debian 12, using latest stable SDL2 manually built from sources, with both X11 and Wayland backends. The results are the same on both backends.

I supposed that qemu-system-m68k generated it's own 60Hz interrupt for video, so my idea was to have video synchronized to the host if I set a physical video mode on the host that matches the guest refresh rate AND force VSYNC.
That should be possible. Problems would arise if I go and force VSYNC without having the exact same refresh rate on the host and the guest, but having the exact same refresh rate it should be possible. MAME does that' for example.