Live dithering

[osresearch]

It would be amazing to have live dithering of the HDMI input signal. The usual F-S algorithm requires (X,Y), (X+1,Y), (X-1,Y+1), (X,Y+1) and (X+1,Y+1) to be read from the framebuffer, which might be complex to do in real time. Maybe a different alogirhtm would work better?

[osresearch]

Two excellent articles about dithering:

• https://surma.dev/things/ditherpunk/
• https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742

[osresearch]

"Blue Noise" (ordered void-and-cluster) dithering doesn't use error diffusion from adjacent pixels, so it could use a block RAM for the tile and then read it as part of the drawing function. 32x32x8 fits in two 4Kbit blocks, or 32x32x4 in one block. This works for monochrome, such as driving the Mac crt.

[osresearch]

although we might be able to implement F-S as the pixels stream in by maintaining an buffer of quantizations to be applied to the next pixel and to the next row

[osresearch]

although even a 32x32 blue noise looks decent!

[osresearch]

Mac Plus connections:

Need Video, Hsync, Vsync, Gnd. Can later power the pixel wrangler via the +5V line. Pinout from https://www.vintageapple.org/gamba2/images/plus_analog.PDF

[osresearch]

dither noise array is going into LUT ram! fixed in https://github.com/osresearch/pixel-wrangler/commit/a0a4dc88b1f1517187c4418fc7b090791bcb1336

[osresearch]

can the same dither matrix be used for R/G/B separately? if so each channel could use a different rotation, which would maybe mask the size of the matrix.

the three channel alogirhtm also needs work. should it be the sum of R+G+B or the average of them? or something else entirely?

[osresearch]

works as part of v0 merge once all three channels were correctly decoded. maybe too bright; algorithm could use some tweaks but otherwise ok