These types of things always make me chuckle. There are many aspects of '80s and '90s computing for which I'll wax nostalgic, but the monochrome CRTs are not among them. One could hardly have designed a better instrument for destroying eyesight, and I wince every time I need to pull out my lone remaining VT420 for anything.
Yes, one absolutely could! In the eighties Amstrad sold their home computers as combo with colour "monitors" (really, TV sets w/o receiver). Monochrome monitors (sharp, due to lack of shadow mask) with long persistence phosphor and hence flicker-free were balsam for the eyes in comparison.
Mind, other home computers were typically connected to the families tv set at that time ...
Good RGB monitors would have higher resolution (finer mask), higher quality, faster electronics for better signal fidelity and higher bandwidth (for higher resolution) and (depending on intended application) phosphors with longer persistence to avoid flicker.
That wasn't really a thing back then. The Amstrad CPC home computers had a tube with a finer shadowmask than the "proper" PC monitors of the day, after all.
Domestic TV shadowmasks were way way way finer than the 320x240ish resolutions common at the time, and indeed could be finer than 640-pixel horizontal resolution. Bear in mind that a broadcast-spec camera at that time ought to resolve 800 horizontal lines.
OpenVMS on VAX. There are plenty of terminal emulators out there that are 99% VT420 compatible. On *nix it's rare to notice that remaining 1%, but on VMS it's noticable.
Try xterm. Guy who develops it has a VT compatibility test suite, which most terminal emulators fail because they're mainly crappy xterm emulators. Xterm was/is written to actually emulate terminals.
In all seriousness though... sorry, friend - that's a negative re: xterm vt420 compatibility.
Quoting from the [current] author's own website at invisible-island.net/xterm/ :
"[xterm] also implements most of the control sequences for VT220, as well as selected features from other DEC terminals such as VT320, VT420, and VT520."
That "selected features" bit is why I keep the real glass one around. Paging is probably the most deficient area that I really notice.
Yep, sadly CRT is missing a lot of the fun stuff of cathode e.g. I don't think CRT supports adjustable bitrates (baud rates), or all the mechanical sounds Cathode came with, or the hilarious "degaussing" feature.
I think cathode also had reflection using your webcam, but I may just have invented that. And I don't remember whether it had burn-in.
Either way, it was an absolute joy, so many nice details, such a shame it died.
I used to use Cathode on my iPhone. It was really nice for SSHing. Sadly it has been unusable (and at some point unavailable) for a long time now on iOS.
In my terminals I use #7fff7f for green and #daa520 (X11 color "goldenrod") for amber. The matches, to me, are pretty close (my brain's reference for the green is a TRS-80 Model 16 with the brightness up).
I guess I am that old: I started computing on a green-on-black Apple ][, and later moved to unix on a VT320 terminal. I have stuck with green-on-black in my terminal ever since. I love to work in a darkish room, and thus also like my desktop dark to avoid getting blinded by my screen. I'm pretty happy with the "dark mode" movement of the last few years!
Also, I wear glasses and find that white-on-black suffers quite a lot from chromatic aberration; green-on-black does not have this problem and results in crispy sharp text on any brightness level.
Amber on black makes me feel really comfortable, so that's how i set up mine
When I was 6 to 8 years old, the library at my school had monochrome terminals with amber text, and the library back then was so comfortable and quiet, so I have always associated amber on black with that nostalgic comfy feeling
Slightly OT, I remember a non-crt, the Toshiba 5200 (which was more than a laptop a transportable as it needed mains connection), plasma screen that had a distinctive (slightly darker than amber CRT's) orange that was very readable.
I tried to coax all elements in VSCode to use only two colors (background and foreground) with the foreground in only a few different intensities. It might give a CRT-vibe to some.
The theme is due for an update since newer VSCode has elements that aren't styled correctly.
Pretty sure your confusion and why people are confounded by your comments is because you're calling the layout WBGR but it seems to be RWBG.
There are no only red or green pixels in your image. The red and green sub pixels are just far apart within a pixel. Greens just happen to be close to the reds of the neighboring pixel.
The issue is that the display is trying to correct for the sub-pixel layout by interpolating over it. Users are insisting this isn't the case and that there is instead a static phase offset (ie that the red channel is from the pixel to the left and the green channel is from the pixel to the right). This might be the result in practice in the one case of yellow-gray transition, but it is not the fundament cause.
Anyway, all of this nuance isn't of interest to reddit posters. They're more interested in being the smartest person in the room and shouting down any intellectually stimulating discussion. I was just hoping the high exposure forum might draw out some hidden trick to fixing this issue.
I think they keep saying the opposite and you keep talking past them and insulting them.
Seems like the posters are saying every pixel is showing yellow but the sub pixel layout (not any artificial sub-pixel sampling) produces the artifact you're seeing.
Not sure how that shows its WBGR vs RWBG. Besides, your claim is that something is doing sub-pixel operations so using other color patterns would be just as inconclusive as the yellow you're posting about, no?
Remember, Brightness adjusts the black level, and Contrast adjusts the drive.
Picture Line-Up Generation Equipment (PLUGE) : https://en.m.wikipedia.org/wiki/Picture_line-up_generation_e...
Edited to add stuff