Oh, looks like Yars' Revenge has seen a regression to a much earlier bug where the sprites constantly move left to right? That's at least not M1 related.

In both cases the vertical banding is something as-yet unknown. Likely some sort of latent Metal misuse if it shows up with or without Rosetta? I don't know offhand.

Alas, the earliest I will have an M1 Mac of my own is this Thursday, and I'm travelling for just more than two weeks from Saturday so I may not get to look at this properly until virtually January. But it's a bug, so it's immediately top of the list.

Notes on this, at long last: it seems to affect luminance phase machines only (i.e. the Vic-20 and Atari 2600), but is independent of NTSC vs PAL. There seems to be some element of phase dependence and the effect persists regardless of output mode, suggesting it's something to do with the input.

So there seems to be some sort of disparity between the colour phase tagged to scans (i.e. runs of PCM output data) and those recorded at line ends, and I think this is causing the phase luminance encoder improperly to encode composite video.

Specific clues:

• the Metal encoder for phase luminance uses the scan values but the decoder uses the line values, suggesting a disparity; and
• output of e.g. the Apple II, which doesn't use an encoder at all, is displayed correctly, suggesting that the line values are probably correct.

That's subject to the specific relative frequencies of the Atari and the Vic-20 not happening to create a problem that the Apple II by luck avoids, of course.

A lucky side effect of the separate Metal and OpenGL backends is that the target for phase information is provided via dependency injection. So the proper path forward here is formal CRT unit testing, I think. That wasn't a realistic option when I first wrote the thing because it was welded much more directly to OpenGL.

Screenshot for later self below; it's the raw composite feed from an emulated Vic-20. Note the obvious phase discrepancies in the left border on the first pixel line. Though the right border looks fine, so there's obviously some nuance here.

Further notes to self on this:

The same issue is seen on a 2019 MacBook Pro, but remains absent on my previous development machine — the 2015 Retina MacBook.

So a random guess might be just that I've underspecified precision for my phase? It's currently a half, which has only 10 bits of mantissa so it would indeed get spotty over on the right-hand side of the display. As a relevant data point I should try upping SourceInterpolator::unitColourPhase and ::colourPhase to full floats and see what difference that makes.

It was a two-line test, so I've taken a 15-minute work break to verify. That does indeed seem to have been the problem. Before and after pictures attached; will test this evening with a wider array of software.