Those that have some git status information in their shell prompts should probably make sure they are not bitten by the same git issues. I currently have to following (zsh syntax) setup for that:
git=(git -c core.hooksPath=/dev/null)
fsmonitor=$($git config core.fsmonitor)
if [[ -n $fsmonitor && $fsmonitor != true && $fsmonitor != false ]]; then
git+=(-c core.fsmonitor=false)
echo "Worrying git core.fsmonitor setting: $fsmonitor"
fi
This seems interesting, but I got stuck fairly early on when I read "all 32,385 possible input combinations". There are two 8 bit numbers, 16 totally independent bits. That's 65_536 combinations. 32_285 is close to half that, but not quite. Looking at it in binary it's 01111110_10000001, i.e. two 8 bit words that are the inverse of each other. How was this number arrived at, and why?
Looking later there's also a strange DAC that gives the lowest resistance to the least significant bit, thus making it the biggest contributor to the output. Very confusing.
There's probably a lot of other memory bugs though. The first thing I looked at was the shell, and almost immediately I spotted an out of bounds write (input[n] = '\0' where n could be sizeof(input)).
The C= 1084S he uses is a more a (very good) PAL TV than a computer monitor, even if it was sold as a monitor. So "576i" in your terminology. (It was also sometimes sold with a TV tuner, or at least the earlier 1084 (same picture tube AFAIK) was.)
I have a related complaint about modern consoles: They are frequently unreadable, because they just have to use all the pixels. I booted Debian (IIRC) on a laptop with a 13" 4K screen and got something like 426x135 characters. No chance for me to read them, but there sure were a lot of them. My eyes aren't the best, but I think most people would find that unreadable.
Defaulting to 80x25 (or anything else reasonable) in an almost infinitely ugly font would be a vast improvement.