Monochrome Monitor

I want to make my laptop or cell phone look like those old green monochrome monitors; is there anyway I can do that?

Other urls found in this thread:

bugs.launchpad.net/ubuntu/ source/console-setup/ bug/1565542),
twitter.com/AnonBabble

cool-retro-term

I'd use a theme for your terminal that changes the text colors. See if whatever you're using can change colors.

Amber masterrace.

/thread

set red and blue gamma to zero, or as close as possible.

The other recommendations are correct, although it will never be quite the same as the real deal.

I used to have a car with a green phosphor touchscreen, shit was so cash...

Never touch a computer again in your life.

Wow, cool and edgy

black on light grey master race.

...

Should be possible with xrandr or xgamma.

On a more technical, if perhaps no less hipster note… Is there any way to use true VGA text mode (NOT framebuffer mode) in a fullscreen virtual terminal with modern Linux? Maybe it's just placebo effect, but it feels really smooth and lag-free (under, e.g., Windows XP).

Apparently Linux TTYs use it.

So I've heard, but how can I do this? When I go to fullscreen virtual terminal TTY (by hitting control+option+F#) I get a framebuffer console, not a text-mode one.

Note that I'm using Linux Mint with a Radeon R7 hooked up to two monitors (one an actual CRT).

Write 12,000 lines of code for NetBSD like I did...

Frame buffer suport is a kernel module. Don't load/include it, and you get the pure BIOS goodness you crave.

TIME TO GET OFF THAT PENTIUM 1 THEN

Well, given that Ubuntu (Server) still had an active problem related to character generator defaults for non-latin locales (bugs.launchpad.net/ubuntu/ source/console-setup/ bug/1565542), I guess all the old tubes and valves are still in place. Just disable the framebuffer and see what happens. I don't think console apps will have any problem, as they work with consoles and not the output devices directly. It's just that development has been focused on setting one resolution and keeping it all the way from grub to X desktop.

The bigger problem is that “native” modes are not really native today, when incentive to support text modes and low resolution graphical modes is diminished and digital output devices not really caring about them. Native 80x25 text mode (on pre-UEFI BIOS system) shows as 1280x1024 on my DVI monitor. Has a video card manufacturer decided to scale it to most common resolution LCD monitors are likely to support? Is that a standard? What will happen if I connect an old 1024x768 panel? I am also not sure about ability to sync old games to refresh rates of 72 Hz and alike properly.

IIRC, framebuffer can be slow because it redraws the full screen on scrolling instead of changing the start address of hardware output window (ywrap, ypan) as a safety measure. There was some work on implementing and porting stuff from uvesafb, but I didn't check the results. There were also some tests of console output speed on various real and emulated configurations by some people that were mad log output was the only thing limiting their program performance, but I've seen that way too long ago. You still shouldn't wipe screen with unreadable dumps that way, though.

It is possible that graphical terminal on OpenGL-accelerated compositor system is actually the fastest option today. It is just as possible that they still implemented everything in software because of reasons, and you can't change it.

(You)

>UEFI

I forgot about that shit. You actually need a mainboard with real a BIOS, rather than just emulation, and a graphics card that is still fully SVGA compliant, if you want pure text mode.

My guess is that in 's case, it's the graphics card having its own, non standard, interpretation of text mode.

So the Linux kernel has the same design as old versions of Dwarf Fortress?

What does kernel has to do with synchronous/asynchronous console presentation (apart from ability to accidentally hang the process with XOFF, lel)?

VBE doesn't provide much accelerated hardware functionality to software, it's basically a standard to change video modes and access part of video memory through a dedicated address region and do whatever you want with it. Even manipulations with output buffer width, height, and offsets that are used for hardware scrolling just happened to be proposed before VESA modes became irrelevant due to appearance of proprietary driver standards, and became almost all “hardware acceleration” that exists in the standard.

I'm not sure that emulation that follows the required hardware initialization steps is not enough. After all, modern BIOS is partially an SMM emulation itself.

Video BIOS routines could be just manufacturer-provided pieces of code that talk to hardware. Well-known UniVBE driver does that in their stead. Also, see what v86d from uvesafb does.

...