Denial

This should be fairly straight forward to implement.... you can ignore all the details about VIA if all you are after is keyboard input (just assume port 1 is all output, port 2 is all input). Then as you noticed, the logic is low-active (you will see that at many other places). One thing to conside...

Tried another PSU? (If they are rolling slowly - most certainly a power problem of some kind)

Have been trying to do the same with GTK VICE 3.8 but I cannot find that option anymore and could not get the .bin to start easily. Maybe there is a good reason to remove support for these files, since they seem to have no starting-address, but this seems to break some software-downloads out there....

Here is a snap shot for Vice vic20

... which apparently was made in a decades old VICE - and doesn't work in a recent one.

Making a .crt out of it would make a lot more sense

Isn't it using the remote monitor protocol do it's stuff? In that case it should be totally possible to use the linux version of VICE - at least i don't see why not.

It works if the composition does mainly consist of fast alternating notes which are all of the same length - not as a generic technique that doubles the channels

It should be noted that most (if not all) of this is still broken in the C64 too

I'd be very careful about associating colors with whatever here. It could be completely random and different in the next device. There is no standard for this, and everyone can build the thing however he wants.

Not for VIC20 - but the "PC64" userport cable (for the C64) worked like this, ie bidirectional, 4bit per direction. I don't know if this was ever adapted to the VIC20 - but there is quite some code around for it that you could look at. Eg the "over5" utility supports it

https://en.wikipedia.org/w/index.php?title=YMMV

Because one cannot build anything in a Wiki and you can't take it to places with no Internet could be cons.

Not sure what you are trying to say, but "code snippets" cant be "built" anyway. And "no internet" seems more of a theoretical than a practical limit to me. YMMV.

Why not use a wiki (like codebase for c64) instead? Works better for such things, IMHO

If needed I can do a new capture - in theory I could also measure the phase offset between light and dark colors with my oscilloscope, although how exactly I haven't yet found out. If you could talk that Tobias guy on F64 to do the same analysis for the NTSC colors that he did for the PAL colors, t...

Yes, macOS requires binary signing, which we can not do automatically. (You can use homebrew to install the svn-head revision though)

The 'normal' colors (2-8) have a phase error on NTSC compared to their lighter variations (9-15) - this is due to how the color signal is generated on the chip. Can you quantify that phase error? I am experimenting a bit now... i added 30 degrees to colors 0-8, the result seems close to your captur...