The trick was pretty easy to guess but still a lot of fun to see put into practice. The EGA monitor bits, and more broadly just the idea of trading color bit depth to multiplex signals for multiple monitors into a single framebuffer and physical output is pretty cool. The Windows display driver idea actually implemented on real hardware would be tons of fun. I could have seen products actually doing this "back in the day" to do multi-head setups. I'm kinda surprised examples don't exist.
Since everyone is vibe coding everything anyway I fully expect there to be a Windows 3.x display driver that works this way soon. I'm sure people in the retro computing hobby feel a certain way about this, but it's definitely also hard to deny the amount of "Project Structure" in README and "// ---- Input Handling ---------------------------------------------" snippets I've been seeing lately in a lot of new homebrew and other projects. (Another fun one: comments that are justified to a specific column but off by one in only one of them. I'm sure humans do this too, but AI does it more.) I don't really care that much personally although it's silly that people kind of have to be wink-wink-nudge-nudge about it for the foreseeable future.
It used to be a big thing in the nineties: I've got old .asm source code of mine where I used to do that.
But somehow LLMs love to insert dashes everywhere: dashes in source code an em-dashes in prose. Just why?
Did they parse lots of early code and thought it was cool to insert, in modern programming languages, comment lines full of dashes?
> Another fun one: comments that are justified to a specific column but off by one in only one of them.
Oh yes, all the time. And besides the fact that there are the off-by-ones errors, it of course looks horrible in Claude Code CLI seen that what you see is not what the LLM did output (because they vibe-coded their "real time game engine" that changes characters, for no reason, on the fly).
It's 2026 and we've got "intelligent" machines doing this:
My guess is that the humans they had in the loop for RLHF just simply preferred the code because it looked superficially tidier. I have the strangest feeling that they didn't always have top notch engineers in the loop at all steps.
I suspect this is also how LLM prose gets so utterly bad.
Of course, for indentation and ASCII graphics, it would be less prone to breaking constantly in this way if it were not a next-token predictor.
Would be the kind of product you see demoed on The Computer chronicles from Eagle New Global Tech corporation, you gander at it thinking "Wow, one day I will get that" and then you never hear from the company again as they only sold 4,000 units.
I'm sure that was a factor. As much as certain job roles today love multi-head (I'm particularly thinking head spreadsheet users) I could still have seen it being a possibility. Certainly, multi-head for AutoCAD was "a thing" pretty early, albeit the paradigm there was one monitor for graphics and another for text.
Multihead for debugging full screen apps is/was pretty sweet. Now we just use ssh or a remote debugger. I haven't finished the video, fingers crossed that he hooked 4 joysticks for multiplayer pong.
Didn't realize how wholesome 8bit guy is, great channel.
Id soft folks were using 2 graphics cards, an EGA/VGA and an MDA one to do multihead debugging. It was possible because the two card technologies actually mapped their frame buffers onto two separate address ranges. Cool stuff.
It is unclear what you are asking. What you are asking sounds more like using something to add color to the monochrome on the screen, like the Magnavox Odyssey [1] or the Vectrex [2]. But that would be orthogonal to what this is doing.
I think they mean that rather than have the RGBI splitter hardware, have a full-signal splitter that displays the same full color image on each monitor, then put a color filter sheet on each monitor to only pass a specific color.
It would have the benefit of working with NTSC, PAL, composite, and other output signals that don't breakout RGBI components on separate pins. But it would have the downside of only supporting 3 monitors instead of 4 (can't color filter on intensity). And of course each monitor would look red, green, or blue according to their filter.
Spoilers:
The trick was pretty easy to guess but still a lot of fun to see put into practice. The EGA monitor bits, and more broadly just the idea of trading color bit depth to multiplex signals for multiple monitors into a single framebuffer and physical output is pretty cool. The Windows display driver idea actually implemented on real hardware would be tons of fun. I could have seen products actually doing this "back in the day" to do multi-head setups. I'm kinda surprised examples don't exist.
Since everyone is vibe coding everything anyway I fully expect there to be a Windows 3.x display driver that works this way soon. I'm sure people in the retro computing hobby feel a certain way about this, but it's definitely also hard to deny the amount of "Project Structure" in README and "// ---- Input Handling ---------------------------------------------" snippets I've been seeing lately in a lot of new homebrew and other projects. (Another fun one: comments that are justified to a specific column but off by one in only one of them. I'm sure humans do this too, but AI does it more.) I don't really care that much personally although it's silly that people kind of have to be wink-wink-nudge-nudge about it for the foreseeable future.
Yes what's with that in LLM output?
It used to be a big thing in the nineties: I've got old .asm source code of mine where I used to do that.
But somehow LLMs love to insert dashes everywhere: dashes in source code an em-dashes in prose. Just why?
Did they parse lots of early code and thought it was cool to insert, in modern programming languages, comment lines full of dashes?
> Another fun one: comments that are justified to a specific column but off by one in only one of them.
Oh yes, all the time. And besides the fact that there are the off-by-ones errors, it of course looks horrible in Claude Code CLI seen that what you see is not what the LLM did output (because they vibe-coded their "real time game engine" that changes characters, for no reason, on the fly).
It's 2026 and we've got "intelligent" machines doing this:
Which they'll probably "fix" by adding the following vibe-coded tool, of course hidden in their pipeline: What an era.My guess is that the humans they had in the loop for RLHF just simply preferred the code because it looked superficially tidier. I have the strangest feeling that they didn't always have top notch engineers in the loop at all steps.
I suspect this is also how LLM prose gets so utterly bad.
Of course, for indentation and ASCII graphics, it would be less prone to breaking constantly in this way if it were not a next-token predictor.
Yes, they’re trained in lots of old code.
Would be the kind of product you see demoed on The Computer chronicles from Eagle New Global Tech corporation, you gander at it thinking "Wow, one day I will get that" and then you never hear from the company again as they only sold 4,000 units.
So like most of the gadgets from the 90s.
I think it's just that monitors were so much more expensive then, especially those capable of the 350-line EGA mode.
I'm sure that was a factor. As much as certain job roles today love multi-head (I'm particularly thinking head spreadsheet users) I could still have seen it being a possibility. Certainly, multi-head for AutoCAD was "a thing" pretty early, albeit the paradigm there was one monitor for graphics and another for text.
Multihead for debugging full screen apps is/was pretty sweet. Now we just use ssh or a remote debugger. I haven't finished the video, fingers crossed that he hooked 4 joysticks for multiplayer pong.
Didn't realize how wholesome 8bit guy is, great channel.
Id soft folks were using 2 graphics cards, an EGA/VGA and an MDA one to do multihead debugging. It was possible because the two card technologies actually mapped their frame buffers onto two separate address ranges. Cool stuff.
"Every mathematician wants to discover a mathematician's lemma."
It might have been easy to guess, but you didn't really think of it in the past 51 years since the Commodore 128 was introduced, did you?
The C128 was introduced in January 1985 at the CES in Las Vegas, so 41 year. Read your post and thought, "I am not that old!"
I went from a VIC20 to C64 then to a C128D in 1987. Then moved a 486DX50 running OS/2 in 1990.
I started seeing LED displays on store fronts in the late 80s (the ones that scroll text horizontally).
This would have been quite the product then. TVs were expensive, but B&W TVs not so much.
Could you accomplish something similar with just colored foil? Like, red foil makes red and white look the same.
You could generate sweet stereoscopic images with two differently colored foils placed in an eyeglasses frame: https://en.wikipedia.org/wiki/Anaglyph_3D
It is unclear what you are asking. What you are asking sounds more like using something to add color to the monochrome on the screen, like the Magnavox Odyssey [1] or the Vectrex [2]. But that would be orthogonal to what this is doing.
[1]: https://youtu.be/Lc8swrtGer4?t=211
[2]: https://www.youtube.com/watch?v=uz3QAj7I3MQ
I think they mean that rather than have the RGBI splitter hardware, have a full-signal splitter that displays the same full color image on each monitor, then put a color filter sheet on each monitor to only pass a specific color.
It would have the benefit of working with NTSC, PAL, composite, and other output signals that don't breakout RGBI components on separate pins. But it would have the downside of only supporting 3 monitors instead of 4 (can't color filter on intensity). And of course each monitor would look red, green, or blue according to their filter.