There's something to be said for not having a dumb VGA controller.
Some years ago, I had a headless system running QNX in a control application. About 30% of the CPU time was being consumed by something. It turned out that the system had a very minimal VGA controller, not connected to anything. The QNX boot image was capable of running with no console at all, which was the intent. But it found the VGA controller and launched a screen saver. The screen saver worked by shifting the entire screen one pixel at a time, which, with this minimal VGA controller, was a very slow read from VRAM, one byte at a time. This was so slow that it ate up a huge amount of CPU time.
This being QNX, it wasn't at high priority, so the real time stuff preempted it.
I don't get the intention of the author. No, I mean, I get that he wants a 80x25 terminal "eventually" but I don't get how exactly. He says it himself that he has multiple different displays, so even if he did manage to get his text only terminal, it will be microscopic on one of the displays, giant on another etc. For me personally, the whole point of terminal rendered by graphic pipeline is that I can get terminal the same size, same font size, and same everything regardless if I use 1080p scaled to 150%, or native 4K or some ancient LCD display on some old laptop (remember 1024x600?). Ok, maybe it is not religiously pure way and maybe it is not as robust and stable way as pure text, but we do get usable terminal in return at least.
"Well, the old vga= option that you are used to doesn't work when you booted from UEFI or on non-x86 platforms."
This is one reason I appreciate older computers; I prefer VGA textmode
But, for today's computers, kmscon and libtsm, and frecon from a trillion-dollar advertising services company, are interesting.^1 For example, being able to zoom in and out using keyboard shortcuts is useful
When I used computers with only VGA textmode running NetBSD, I always wished for a console that could possibly display images, like a Linux framebuffer, perhaps; vesafb on NetBSD was still a WIP. I was tired of switching back and forth from textmode to X11. Eventually I gave up on X11 and began using separate computers on same local network but with not gateway to the internet in order to view graphics
As a Linux user today, it's funny to read the complaints about framebuffers
I am not "either/or" when it comes to BSD v Linux. I use both. Each has its merits. But I think NetBSD may be the nicest OS for people who prefer the console. At least it is for me
Making it easy for mortals to run the OS on older computers^2 is important
This also lets you run QEMU over SSH, if you want. I use this in my assembly language course; towards the end I give an assignment to write Hello, World! as a 16-bit real mode MBR bootloader. Students can do the whole thing on our SSH server, including testing in QEMU (and even attaching GDB to it to debug) not needing to install anything locally.
While some people might not see the need for it, the author lists several reasons why it'd be nice to have. The article mentions that there are multiple old (and no longer working) workarounds and tricks that used to allow for 80x25 and presumably those existed and were shared online because others also wanted it.
I don't see why it shouldn't be possible? It seems like a reasonable thing to want to be able to change and even force resolutions to whatever your hardware will support, especially if there's a large amount of old software out there which expects a certain resolution. Old computers are very nice to have, but increasingly difficult to find and find working parts for. They also tend to come with some pretty big trade offs in terms of size, noise, and energy inefficiency. It'd mean a lot of less than ideal hardware just to get back something that people already had.
He wants to use a display mode with rectangular pixels. No matter what he does in software, that’s going to require specialized hardware. It’ll take a real CRT. No LCD ever made can change the shape of its own pixels.
More importantly, VGA text modes cannot be exactly simulated with standard VGA/VESA graphics modes. The people who wrote fake Blue Screen of Death joke programs for Windows NT discovered this years ago.
The article author is explicitly looking for 720 by 400, not 640 by 400, and is trying to obtain that using Linux mechanisms that select graphics modes and do not configure the hardware to be in an actual text mode. i.e. fbcon rather than vgacon.
Untrue. Even cheap-ass imported HDMI monitors support aspect-corrected scaling from 720x400 (80x25 x 9x16) to their native resolutions, even if not all of them support fill to screen.
Yes, and I want FireWire. Oh, and I'd really prefer 16 bit real mode CPUs. While we're at it, why not go for support for serial connection mice?
This reads like such an arbitrary wish without a reasoning WHY you would want this. I'm sure OP has a reason for preferring it, but what makes the 80x25 superior in their opinion?
I think the author is making the argument for consistency.
I actually always disliked the modeset that the author remembers fondly, but it is always sad to lose part of our history for arbitrary reasons and especially so if it breaks a ungoverned consistency.
To use your example: Real mode still exists and you can use it, and firewire is effectively the father of Thunderbolt (and granddaddy to Thunderbolt 3-4); so its removal really does feel unnecessary without additional context.
Serial mice is masochism, but people do dislike that PS/2 is gone, for good reasons.
One reason it could be nice is what I experienced a decade or so ago, the damn machine kept changing video modes during boot and the LCD couldn't keep up so an important screen was missed when diagnosing a boot issue.
Had to get a CRT to see what the hell was going on.
This even applies to remove-viewing software that wants to "follow" the resolution changes, flipping your remote window size around a lot. Super annoying.
I don't really get the 80x25 thing, but using dumb terminals to write code is great. Zero distractions.
More than half the code I've been paid to write in the past 2-3 years has been written in vim running on a vtty with no X and no mouse. It's my favorite way to work, although occasionally it's impractical.
Apple has finally depreciated Firewire with macOS 26, sadly.
Serial mice still also just work in Windows, too! If you attach a serial mouse to a USB-serial adapter, then attach the adapter, Windows should pick up and load sermouse.sys. On the flipside, if you’ve got a weird serial device attached screaming garbage out the wire, Windows might pick THAT up and load the mouse driver, too… “hey, why is my cursor freaking out?”
The author listed several reasons why they want it.
Also, it should still be possible to connect a serial mouse to a modern system thanks to adapters. I still have serial to PS/2 and PS/2 to USB adapters floating around in a tackle box.
> The author listed several reasons why they want it.
To be fair, they listed reasons to need a 80x25 terminal, but not reasons to need a 80x25 console. I'm a bit unclear as to why they could not use a regular 80x25 term in their graphical session.
They specifically want 8×16 characters in 9×16 character cells on a 720×400 display that has an overall 4:3 aspect ratio. There’s no way to achieve that on anything other than a real hardware CRT. No amount of fiddling with fonts in either X11 or Wayland or any other display manager will change the size of the pixels on your LCD.
There may be something I don't get then. What can you _not_ do in a graphical terminal that you can in a pure HW console?
Why would you not setup your graphical terminal to be full-screen on whatever column/row count, what's the difference ? Surely the rasterizable screen size is the same whatever mode your screen is in?
See my longer reply <https://news.ycombinator.com/item?id=45275565>, but the short version is that 720×400 has a 5:9 aspect ratio, but the CRT display was 4:3. The CRT compensated by scaling the vertical height of each line by 135%. An LCD simply cannot do that. The best anyone can do is to scale the 400 lines up by the same non-integer scaling factor to 540 lines. This gives you an ugly image where some lines are 1px tall but others are 2px. It does get less ugly if you scale to 1440×1080 (on an HD display), or to 2880×2160 (on a 4K display), but the artifacts are still obvious and undesirable.
That still really isn't a reason. I think I can extrapolate where they are going with this, which will be something like 'I have a ton of 720x400 hardware CRTs sitting around that I need to use/support/deal with'. But that is never explicitly stated, you can completely read it as 'oh it's neat that 80x25 matches up with the number of image lines on old CRT displays and here is the math to show it'.
Perhaps you don’t know that on a CRT the number of lines that can be displayed is variable. Any CRT can display 400 lines or 399 lines or 1000 lines or however many lines you need or want. On an LCD there is always a fixed number of pixels, no more and no less. You can leave some of those pixels blank if you don’t need them but that’s about it.
720 pixels by 400 pixels is a 5:9 aspect ratio, but the monitor is a 4:3 aspect ratio display. On a CRT the result was an image made up of pixels that were taller than they were wide. 35% taller, to be specific.
To reproduce this on an LCD you need to scale the image up to 720×540 pixels which results in every line being drawn as either one or two lines of LCD pixels. Some lines are literally double the height of others. This is super ugly! Of course you could scale it up to 1440×1080, but now you’re just scaling the lines up by a factor of 2.7 instead of 1.35. Some lines are 2 pixels tall and others are 3, which still makes some lines 50% taller than the rest. On a 4K monitor you could scale it up by a factor of 5.4 to 2880×2160 making some lines 5 pixels tall and others 6. This is certainly better but you’ll still be able to tell the difference and it’s still ugly.
When you scale an image taken from the real world, such as one from a television program or a movie, then nobody will notice the artifacts. But when you scale pixel graphics, and especially text, then the artifacts spoil the whole thing.
There are two other routes you could take.
You could scale the text display instead. You could have an 80×33 text display using the 9×16 character cell. This gives you 720×528 pixels, which is close enough to the right ratio that you can just scale it up by a nice integer ratio and just ignore the few wasted pixels at the top and bottom of the screen. But now you’ve squashed the aspect ratio of the characters!
Ok, so you could stretch the character cell to 9×22 pixels, redrawing all of the characters by hand to approximate the original shapes. You’ll only have room for 80×24 characters in 720×528 pixels, but that’s much less disappointing than mucking about with the original font. People _grew up_ with that font. They _like_ it.
Of course neither of these options can take advantage of real VGA hardware. One of the advantages of VGA was that the CPU only had to manage a 2 kilobyte text buffer while the VGA hardware composited the character data from the font and created the video signal that went to the display. It could do this in real time, meaning latency was actually lower than a whole video frame. If you emulate this on a CPU it’ll be much, much slower than that. If you farm it out to a GPU instead then it’ll be far more expensive. A modern GPU needs tens of billions of transistors to run the shader that emulates what probably took a few thousand transistors on original VGA hardware.
A completely modern take on a console would lean into the new ratios and might have a 120×30 text display and a 16×36 character cell, creating a 1920×1080 pixel display that doesn’t need any scaling on most LCD panels. Instead of trying to support the original VGA character set (CP437 as it is sometimes called) and disappointing its fans, it would support Unicode, text shaping, combining characters, BiDi text, emoji, etc, etc. And the compositing would be done in hardware, but not in a shader on a $500 GPU. Or even a $100 GPU.
> Perhaps you don’t know that on a CRT the number of lines that can be displayed is variable. Any CRT can display 400 lines or 399 lines or 1000 lines or however many lines you need or want.
This isn't true. Besides there being only a finite number of distinct phosphors / grid holes, the electronics and logic driving the display can also only handle a limited range of frequencies.
As LCD pixel densities increase the situation becomes effectively the same.
> PS/2 to USB adapters floating around in a tackle box.
Heh. [Most] PS/2 to USB adapters aren't.
They don't actually adapt the PS/2 protocol to USB, they just adapt the pins. The USB _hardware_ on the host does the emulation. However, the new generations of USB chips stopped bothering with the PS/2 emulation so these adapters are now useless.
Damn, in that case I'm certain that the ones I have gathering dust, all of which came from various packaged mice/keyboards, won't be up to the task. I've got enough old hardware they might still come in handy one day, but I'm pretty sure they're now just relics.
If you want a custom resolution in Linux drm.edid_firmware= works well with the right EDID.
For me, the worst things about the Linux graphical console are lack of scrollback and horrible performance. Linux still has scrollback in VGA text mode, and of course it is super fast because each character is only 2 bytes. In graphics mode you can only fix this by running a program that provides its own graphical terminal, like kmscon or fbterm.
The best thing about the graphical console is ability to use bigger fonts, so your characters can be smooth and not pixelated. I like the Terminus fonts. As long as performance isn't a problem it's better to increase font size than to decrease the resolution.
Dumb question: when I boot a modern systemd-based distro installer in terminal mode, am I using "VGA text mode" or "graphics mode"? Do I have to be literally using VGA to use VGA text mode?
EDIT: I read TFA and it seems like the answer is that I probably have never used VGA text mode.
Depends. A UEFI boot is going to put you in graphics mode; I don't think you can get into VGA text mode from an UEFI boot, without some serious dark arts. UEFI has a text mode console API, but it's part of bootservices and those are exited somewhere on the way to starting the Linux kernel.
If you're doing a BIOS boot, you might be using VGA text mode, if you haven't loaded a framebuffer driver. VGA text mode works over BNC, DVI, HDMI, DP, etc, if that was your question, you don't need a VGA connector. EGA text mode might be similar enough to also work, but that's outside my depth.
I'm not sure that Linux uses it, but VGA has nice things to accelerate scrolling. You can set the top of the screen down into the buffer, and then set a line number where it resets to the top of the buffer. If you set the line stride so that it evenly divides the buffer (typically wider than the line width), it makes scrolling and wrapping around the buffer very simple and elegant.
UEFI GOP doesn't provide any mechanism for a buffer larger than what's displayed, so scrolling requires copying. :(
Booted a Dell mini PC with debian, but without X11 and attached a video projector. The old StackOverflow answers to fix overscan problems failed to do anything. Editing sshd configuration files with the first six text columns off screen is quite a unique experience.
What's notable about the text modes is that they are fully done in hardware, so scrolling and writing lots of text is extremely fast and consumes very little CPU. Unfortunately on the hardware side, the allegedly-VGA-compatible part of newer GPUs is increasingly not as compatible as it should be. The "extended text modes" of earlier VGA cards supporting 132 columns or more have become nearly nonexistent, although even the original IBM VGA hardware API should be able to handle a 100 x 75 text mode, if not more, albeit with a reduced refresh rate. I remember almost 2 decades ago trying to get an Intel 900-series integrated GPU to display more than 80 columns in text mode, to challenge the datasheet claim that it was "not supported" (the original IBM VGA had an unofficial 90x60 mode at 720x480), and was unsuccessful; the hardware seemed to be deliberately restricting the settings, and triggered a hard lockup whenever I tried.
If the kmscon project wasn't dead, they'd be able to get whatever number of cells and rows they'd like as it doesn't use now-obscure built-in display device modes by setting the font settings.
On the other hand, kmscon is just a graphical terminal emulator and display server built into one. Running `cage foot` (i.e., the very minimal "foot" terminal emulator running under the single-app "cage" display server) and setting foot's settings to whatever you'd like would get you a better (and importantly, fully maintained) experience.
The SGI Irix boot console was 80 characters wide and kind of elegant. It worked on different resolutions and looked like a floating window where the margins could be of arbitrary size.
i got an sbc running recently and the font was so small on my monitor i had difficulty reading it. i wouldn’t be surprised if it was 100+ rows and many, many columns.
It probably is impossible unless you actually have a VGA device and a CRT. There’s no way your LCD is going to distort its pixels so that they’re rectangular.
Is it just me or is this a misunderstanding of computer architecture? The computer can only output what the screen can support (native resolution), the screen can only display what the video card gives it, the video card can only display what the video card driver tells it to do. They all have to work in tandem.
If the system you're using (ARM??) doesn't have a particular fbdev driver, it still works thanks to the simpledrm weirdness. But if you want very particular results, you're gonna need to ship a driver for your card, to tell the card what to do, to tell the monitor what to do. The complaint seems to be that architectures change? I dunno what to tell you man. I hate technology too, but it do be changin'.
AFAIK, no, the most common standard for console size is 80x24, which came from the VT100 and is used by default on terminal emulators like xterm or the GNOME terminal.
No. It's the standard CGA/MCGA/EGA/VGA/SVGA int 10h mode 3, where on VGA/SVGA cards it was a 80x25 console comprised of 9x16 glyphs (8x16 really, where the right-most bit is duplicated) for an analog effective resolution of 720x400 in 4:3 aspect ratio.
Historically, when processors, motherboard buses, and video cards of physical machines were much slower, text modes were accelerated ways to write text such that they were much faster than writing and scrolling text graphically in a video framebuffer. Interestingly, on VGA/SVGA cards, it's possible to do double buffering of text by page flipping but it's pretty pointless even on real hardware.
Emulated hardware generally doesn't suffer from tearing effects that happen on real hardware where large updates (mostly in graphics modes rather than text modes) aren't synchronized with the raster scan and end up looking bad by showing partial portions of the previous frame and current frame while an update is happening. In graphic modes, this was mostly eliminated by double- and triple-buffering with precisely-timed page flipping on video cards that had enough memory to have 2 or more whole frames..
(B800:0000 and A000:0000 are permanently etched in my brain.)
And let's chuck into the dustbin of history fiddling with IRQ dipswitches to disambiguate your mouse, video, disk, and audio controllers; the "turbo" button; "It is now safe to turn off your computer"; CGA/EGA/VGA/HGA/MCGA/SVGA/XGA, RLL/MFM/SCSI/IDE, and while we're at it, TSR programs like sound drivers, mouse drivers, etc. Let's not even discuss OS/2.
You know what sucked? Booting up into CGA and not being able to figure out how to escape that abomination. Why not pine for that?
All of this trash is behind us and frankly I think we're better off for it. If you want to go play with obsolete computers, then finding some old computers and some old computer junkies who still enjoy that junk is the right way to go. Personally, I had my fun, but I like our modern machines so much more than those old smokey capacitor poppers. But I have to admit, I almost miss compiling my own kernel. Almost.
This is from an era when you could still make the computer do what you want. Those days are long gone now; incidentally, that's why "It is now safe to turn off your computer" does not belong in this list, because it still exists, just not under that name. Windows (or whatever OS) decides when you can turn it off. Just like it now decides when it's time to upgrade.
Actually there _is_ a lot to be missed about those times, in spite of all the "progress" we've made since then.
"It is now safe to turn off your computer" was a kludge for running Windows 95 on PCs with a physical on/off switch (as opposed to newer ATX power supplies, which have a pushbutton to turn them on and can be switched off via software). I guess it's theoretically possible to build a modern PC with a 30+ year PSU, and then you would see this screen again - or, more realistically, you could disconnect the PS_ON line (https://electronics.stackexchange.com/questions/394414/how-d...) from the mainboard, preventing the system from turning off the PSU.
My 3D printer has a physical off switch. And it runs Linux - debian - on an embedded ARM board, so I can ssh into the printer etc. (I can even hook up a keyboard and HDMI monitor)
I fear about my filesystem every time I notice the printer is running at night (after a long print job) and I just turn it off without going over to my pc, ssh in and shut down the OS.
Still, it hasn't eaten my filesystem, yet ... ext4 journaling DOES seem to work.
I won't lament the loss of giant, stretched-out consoles that flash by too fast to do anything useful with either, but on the other hand I don't see why "there should be a way to make the text bigger" is a problematic request.
There are all sorts of disabilities that might necessitate a console with large text, and setting a specific size (in this case 80x25 because it used to be a standard) isn't such an outrageous demand.
The author knows a solution: set a specific resolution and select a specific font. The problem is that they can't pick that resolution, even though they could before, because on UEFI and non-amd64 the common GPU configuration parameters don't work in Linux.
We should default to a modern system, but the kernel should have a standard way of configuring the boot console. For every person who wants 80x25 mode, there's someone with a weird device that outputs three pixel high fonts because the default resolution is bugged, and both need the same override to fix their issues.
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.
And in 80x25, there’s so much text that it zooms past you with no chance to ever read it, and Scroll Lock won’t work. Can’t have it both ways, I suspect the truth is somewhere in the middle.
Thank you, 100 times this. There was literally nothing fun about it.
I remember desperately trying to put drivers in high memory, because Wing Commander 2 needed more memory if I was to get the precious images of the joystick moving. Slowly removing items, one by one from my autoexec.bat file, desperately hoping it was going to work, but then the creeping realisation that I would have to unload my soundcard drivers if I wanted a chance.
Or the time our bios randomly wiped its memory and my dad was convinced I had destroyed the harddrive. Thankfully I was told by a family friend that I would only have to turn on the BIOS and set it to # 31 (because somehow hard disk sizes, sectors, et cetra were all standardized) in order to access our precious 95 megabyte hard disk.
Ah, yes, and I also remember what a relief it was when the newer generation of games (starting with Doom IIRC) used "DOS extenders" to switch the CPU into protected mode and be able to use 16 MB or more without any fiddling...
Another anecdote from around that time (or a bit later): some friends were alarmed that their PC was not booting Windows as usual. Turns out they had forgotten a bootable CD in the CD-ROM drive, which was showing some cryptic text mode menu on startup. Easy fix: remove CD, restart, works...
SimCity CD-ROM edition was the greatest. It needed sound card drivers, mouse drivers, CD-ROM drivers and MSCDEX, and it required 605kB of free conventional memory.
Oh, and only some hard drives were standard like that. For others, you needed to set sectors, tracks and landing zone manually. Happy fun times if your CMOS battery ran out.
I do find it funny that there are so many people on HN who work in a rapidly advancing cutting edge industry, but are also absolute stuck-in-the-mud curmudgeons who want everything to stay exactly as it was 4 decades ago.
Another example is dropping support for 32-bit x86. "But how will I run Linux on my PC from 2001?". Or the resistance to Rust in Linux because LLVM doesn't support the PDP-8 architecture.
There's something to be said for not having a dumb VGA controller.
Some years ago, I had a headless system running QNX in a control application. About 30% of the CPU time was being consumed by something. It turned out that the system had a very minimal VGA controller, not connected to anything. The QNX boot image was capable of running with no console at all, which was the intent. But it found the VGA controller and launched a screen saver. The screen saver worked by shifting the entire screen one pixel at a time, which, with this minimal VGA controller, was a very slow read from VRAM, one byte at a time. This was so slow that it ate up a huge amount of CPU time.
This being QNX, it wasn't at high priority, so the real time stuff preempted it.
I don't get the intention of the author. No, I mean, I get that he wants a 80x25 terminal "eventually" but I don't get how exactly. He says it himself that he has multiple different displays, so even if he did manage to get his text only terminal, it will be microscopic on one of the displays, giant on another etc. For me personally, the whole point of terminal rendered by graphic pipeline is that I can get terminal the same size, same font size, and same everything regardless if I use 1080p scaled to 150%, or native 4K or some ancient LCD display on some old laptop (remember 1024x600?). Ok, maybe it is not religiously pure way and maybe it is not as robust and stable way as pure text, but we do get usable terminal in return at least.
"Well, the old vga= option that you are used to doesn't work when you booted from UEFI or on non-x86 platforms."
This is one reason I appreciate older computers; I prefer VGA textmode
But, for today's computers, kmscon and libtsm, and frecon from a trillion-dollar advertising services company, are interesting.^1 For example, being able to zoom in and out using keyboard shortcuts is useful
When I used computers with only VGA textmode running NetBSD, I always wished for a console that could possibly display images, like a Linux framebuffer, perhaps; vesafb on NetBSD was still a WIP. I was tired of switching back and forth from textmode to X11. Eventually I gave up on X11 and began using separate computers on same local network but with not gateway to the internet in order to view graphics
As a Linux user today, it's funny to read the complaints about framebuffers
I am not "either/or" when it comes to BSD v Linux. I use both. Each has its merits. But I think NetBSD may be the nicest OS for people who prefer the console. At least it is for me
Making it easy for mortals to run the OS on older computers^2 is important
1.
https://github.com/dvdhrm/kmscon/raw/master/src/kmscon_conf....
https://chromium.googlesource.com/chromiumos/platform/frecon...
https://chromium.googlesource.com/chromiumos/platform/frecon...
2.
For example, computers that are unsuitable for delivering today's internet ads
Related to this, the other day I learned that QEMU will render VGA mode text to your terminal using curses:
What a lovely feature, if you can get it to boot something with a VGA mode.This also lets you run QEMU over SSH, if you want. I use this in my assembly language course; towards the end I give an assignment to write Hello, World! as a 16-bit real mode MBR bootloader. Students can do the whole thing on our SSH server, including testing in QEMU (and even attaching GDB to it to debug) not needing to install anything locally.
It is very cute. It doesn't take much to use a serial console though, or even enabling SPICE for a fully featured (and detachable).
While some people might not see the need for it, the author lists several reasons why it'd be nice to have. The article mentions that there are multiple old (and no longer working) workarounds and tricks that used to allow for 80x25 and presumably those existed and were shared online because others also wanted it.
I don't see why it shouldn't be possible? It seems like a reasonable thing to want to be able to change and even force resolutions to whatever your hardware will support, especially if there's a large amount of old software out there which expects a certain resolution. Old computers are very nice to have, but increasingly difficult to find and find working parts for. They also tend to come with some pretty big trade offs in terms of size, noise, and energy inefficiency. It'd mean a lot of less than ideal hardware just to get back something that people already had.
He wants to use a display mode with rectangular pixels. No matter what he does in software, that’s going to require specialized hardware. It’ll take a real CRT. No LCD ever made can change the shape of its own pixels.
A high enough resolution LCD can however emulate much larger CRT pixels.
And this even matches the way PC CRT monitors worked - each displayed "pixel" lights many different phosphors.
More importantly, VGA text modes cannot be exactly simulated with standard VGA/VESA graphics modes. The people who wrote fake Blue Screen of Death joke programs for Windows NT discovered this years ago.
The article author is explicitly looking for 720 by 400, not 640 by 400, and is trying to obtain that using Linux mechanisms that select graphics modes and do not configure the hardware to be in an actual text mode. i.e. fbcon rather than vgacon.
Untrue. Even cheap-ass imported HDMI monitors support aspect-corrected scaling from 720x400 (80x25 x 9x16) to their native resolutions, even if not all of them support fill to screen.
Have you worked out yet how ugly that’s going to be?
Most LCD displays will do hardware scaling when given a resolution lower than the native resolution.
Yes, and I want FireWire. Oh, and I'd really prefer 16 bit real mode CPUs. While we're at it, why not go for support for serial connection mice?
This reads like such an arbitrary wish without a reasoning WHY you would want this. I'm sure OP has a reason for preferring it, but what makes the 80x25 superior in their opinion?
I think the author is making the argument for consistency.
I actually always disliked the modeset that the author remembers fondly, but it is always sad to lose part of our history for arbitrary reasons and especially so if it breaks a ungoverned consistency.
To use your example: Real mode still exists and you can use it, and firewire is effectively the father of Thunderbolt (and granddaddy to Thunderbolt 3-4); so its removal really does feel unnecessary without additional context.
Serial mice is masochism, but people do dislike that PS/2 is gone, for good reasons.
One reason it could be nice is what I experienced a decade or so ago, the damn machine kept changing video modes during boot and the LCD couldn't keep up so an important screen was missed when diagnosing a boot issue.
Had to get a CRT to see what the hell was going on.
This even applies to remove-viewing software that wants to "follow" the resolution changes, flipping your remote window size around a lot. Super annoying.
I don't really get the 80x25 thing, but using dumb terminals to write code is great. Zero distractions.
More than half the code I've been paid to write in the past 2-3 years has been written in vim running on a vtty with no X and no mouse. It's my favorite way to work, although occasionally it's impractical.
You can still plug in a FireWire PCIe card and have it work - I still use one for an old 35mm film scanner.
I think serial mice should still work as well - https://wiki.alpinelinux.org/wiki/Serial_mouse
Apple has finally depreciated Firewire with macOS 26, sadly.
Serial mice still also just work in Windows, too! If you attach a serial mouse to a USB-serial adapter, then attach the adapter, Windows should pick up and load sermouse.sys. On the flipside, if you’ve got a weird serial device attached screaming garbage out the wire, Windows might pick THAT up and load the mouse driver, too… “hey, why is my cursor freaking out?”
The author listed several reasons why they want it.
Also, it should still be possible to connect a serial mouse to a modern system thanks to adapters. I still have serial to PS/2 and PS/2 to USB adapters floating around in a tackle box.
> The author listed several reasons why they want it.
To be fair, they listed reasons to need a 80x25 terminal, but not reasons to need a 80x25 console. I'm a bit unclear as to why they could not use a regular 80x25 term in their graphical session.
They specifically want 8×16 characters in 9×16 character cells on a 720×400 display that has an overall 4:3 aspect ratio. There’s no way to achieve that on anything other than a real hardware CRT. No amount of fiddling with fonts in either X11 or Wayland or any other display manager will change the size of the pixels on your LCD.
There may be something I don't get then. What can you _not_ do in a graphical terminal that you can in a pure HW console?
Why would you not setup your graphical terminal to be full-screen on whatever column/row count, what's the difference ? Surely the rasterizable screen size is the same whatever mode your screen is in?
See my longer reply <https://news.ycombinator.com/item?id=45275565>, but the short version is that 720×400 has a 5:9 aspect ratio, but the CRT display was 4:3. The CRT compensated by scaling the vertical height of each line by 135%. An LCD simply cannot do that. The best anyone can do is to scale the 400 lines up by the same non-integer scaling factor to 540 lines. This gives you an ugly image where some lines are 1px tall but others are 2px. It does get less ugly if you scale to 1440×1080 (on an HD display), or to 2880×2160 (on a 4K display), but the artifacts are still obvious and undesirable.
That still really isn't a reason. I think I can extrapolate where they are going with this, which will be something like 'I have a ton of 720x400 hardware CRTs sitting around that I need to use/support/deal with'. But that is never explicitly stated, you can completely read it as 'oh it's neat that 80x25 matches up with the number of image lines on old CRT displays and here is the math to show it'.
Perhaps you don’t know that on a CRT the number of lines that can be displayed is variable. Any CRT can display 400 lines or 399 lines or 1000 lines or however many lines you need or want. On an LCD there is always a fixed number of pixels, no more and no less. You can leave some of those pixels blank if you don’t need them but that’s about it.
720 pixels by 400 pixels is a 5:9 aspect ratio, but the monitor is a 4:3 aspect ratio display. On a CRT the result was an image made up of pixels that were taller than they were wide. 35% taller, to be specific.
To reproduce this on an LCD you need to scale the image up to 720×540 pixels which results in every line being drawn as either one or two lines of LCD pixels. Some lines are literally double the height of others. This is super ugly! Of course you could scale it up to 1440×1080, but now you’re just scaling the lines up by a factor of 2.7 instead of 1.35. Some lines are 2 pixels tall and others are 3, which still makes some lines 50% taller than the rest. On a 4K monitor you could scale it up by a factor of 5.4 to 2880×2160 making some lines 5 pixels tall and others 6. This is certainly better but you’ll still be able to tell the difference and it’s still ugly.
When you scale an image taken from the real world, such as one from a television program or a movie, then nobody will notice the artifacts. But when you scale pixel graphics, and especially text, then the artifacts spoil the whole thing.
There are two other routes you could take.
You could scale the text display instead. You could have an 80×33 text display using the 9×16 character cell. This gives you 720×528 pixels, which is close enough to the right ratio that you can just scale it up by a nice integer ratio and just ignore the few wasted pixels at the top and bottom of the screen. But now you’ve squashed the aspect ratio of the characters!
Ok, so you could stretch the character cell to 9×22 pixels, redrawing all of the characters by hand to approximate the original shapes. You’ll only have room for 80×24 characters in 720×528 pixels, but that’s much less disappointing than mucking about with the original font. People _grew up_ with that font. They _like_ it.
Of course neither of these options can take advantage of real VGA hardware. One of the advantages of VGA was that the CPU only had to manage a 2 kilobyte text buffer while the VGA hardware composited the character data from the font and created the video signal that went to the display. It could do this in real time, meaning latency was actually lower than a whole video frame. If you emulate this on a CPU it’ll be much, much slower than that. If you farm it out to a GPU instead then it’ll be far more expensive. A modern GPU needs tens of billions of transistors to run the shader that emulates what probably took a few thousand transistors on original VGA hardware.
A completely modern take on a console would lean into the new ratios and might have a 120×30 text display and a 16×36 character cell, creating a 1920×1080 pixel display that doesn’t need any scaling on most LCD panels. Instead of trying to support the original VGA character set (CP437 as it is sometimes called) and disappointing its fans, it would support Unicode, text shaping, combining characters, BiDi text, emoji, etc, etc. And the compositing would be done in hardware, but not in a shader on a $500 GPU. Or even a $100 GPU.
> Perhaps you don’t know that on a CRT the number of lines that can be displayed is variable. Any CRT can display 400 lines or 399 lines or 1000 lines or however many lines you need or want.
This isn't true. Besides there being only a finite number of distinct phosphors / grid holes, the electronics and logic driving the display can also only handle a limited range of frequencies.
As LCD pixel densities increase the situation becomes effectively the same.
> PS/2 to USB adapters floating around in a tackle box.
Heh. [Most] PS/2 to USB adapters aren't.
They don't actually adapt the PS/2 protocol to USB, they just adapt the pins. The USB _hardware_ on the host does the emulation. However, the new generations of USB chips stopped bothering with the PS/2 emulation so these adapters are now useless.
Damn, in that case I'm certain that the ones I have gathering dust, all of which came from various packaged mice/keyboards, won't be up to the task. I've got enough old hardware they might still come in handy one day, but I'm pretty sure they're now just relics.
You can buy real PS/2 to USB adapters. E.g. this one from StarTech: https://www.amazon.com/dp/B00028OP2Y
I bought a used slideable rack-mounted LCD last year for my home server rack, and its keyboard with touchpad use PS/2. That's how I found that out.
Actually it's the device that supports both PS/2 and USB mode. The host doesn't.
Sure. It is also a possibility, but a lot of PS/2 devices predate the USB.
This is also my understanding too
Chill out and stop judging people with such unnecessary histrionics.
If you want a custom resolution in Linux drm.edid_firmware= works well with the right EDID.
For me, the worst things about the Linux graphical console are lack of scrollback and horrible performance. Linux still has scrollback in VGA text mode, and of course it is super fast because each character is only 2 bytes. In graphics mode you can only fix this by running a program that provides its own graphical terminal, like kmscon or fbterm.
The best thing about the graphical console is ability to use bigger fonts, so your characters can be smooth and not pixelated. I like the Terminus fonts. As long as performance isn't a problem it's better to increase font size than to decrease the resolution.
Alan Mackenzie from Gentoo mailing lists wrote a scrollback patch for the kernel that also supports gpm mouse select/copy from the scrollback buffer.
Unfortunately, the patch is not frequently updated to new kernel versions.
https://public-inbox.gentoo.org/gentoo-user/2316312.ElGaqSPk...
> Linux still has scrollback in VGA text mode
Dumb question: when I boot a modern systemd-based distro installer in terminal mode, am I using "VGA text mode" or "graphics mode"? Do I have to be literally using VGA to use VGA text mode?
EDIT: I read TFA and it seems like the answer is that I probably have never used VGA text mode.
Depends. A UEFI boot is going to put you in graphics mode; I don't think you can get into VGA text mode from an UEFI boot, without some serious dark arts. UEFI has a text mode console API, but it's part of bootservices and those are exited somewhere on the way to starting the Linux kernel.
If you're doing a BIOS boot, you might be using VGA text mode, if you haven't loaded a framebuffer driver. VGA text mode works over BNC, DVI, HDMI, DP, etc, if that was your question, you don't need a VGA connector. EGA text mode might be similar enough to also work, but that's outside my depth.
I'm not sure that Linux uses it, but VGA has nice things to accelerate scrolling. You can set the top of the screen down into the buffer, and then set a line number where it resets to the top of the buffer. If you set the line stride so that it evenly divides the buffer (typically wider than the line width), it makes scrolling and wrapping around the buffer very simple and elegant.
UEFI GOP doesn't provide any mechanism for a buffer larger than what's displayed, so scrolling requires copying. :(
Sorry, might be dumb question (at work on windows now), but when did shift+pgup stop working?
About five years ago.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Booted a Dell mini PC with debian, but without X11 and attached a video projector. The old StackOverflow answers to fix overscan problems failed to do anything. Editing sshd configuration files with the first six text columns off screen is quite a unique experience.
Last time I dealt with this I launched tmux and started working on the right side of the screen with a vertical split.
You can still have a console on a serial port with a dumb terminal. Plenty of SFF PCs have them via RJ45 ports.
I haven't heard of any apart from industrial PCs.
> Plenty of SFF PCs have them via RJ45 ports.
Could you please name a single model of SFF PC that exposes a serial connection via RJ45 port?
Look at the CWWK/Topton boxes.
[dead]
What's notable about the text modes is that they are fully done in hardware, so scrolling and writing lots of text is extremely fast and consumes very little CPU. Unfortunately on the hardware side, the allegedly-VGA-compatible part of newer GPUs is increasingly not as compatible as it should be. The "extended text modes" of earlier VGA cards supporting 132 columns or more have become nearly nonexistent, although even the original IBM VGA hardware API should be able to handle a 100 x 75 text mode, if not more, albeit with a reduced refresh rate. I remember almost 2 decades ago trying to get an Intel 900-series integrated GPU to display more than 80 columns in text mode, to challenge the datasheet claim that it was "not supported" (the original IBM VGA had an unofficial 90x60 mode at 720x480), and was unsuccessful; the hardware seemed to be deliberately restricting the settings, and triggered a hard lockup whenever I tried.
If the kmscon project wasn't dead, they'd be able to get whatever number of cells and rows they'd like as it doesn't use now-obscure built-in display device modes by setting the font settings.
On the other hand, kmscon is just a graphical terminal emulator and display server built into one. Running `cage foot` (i.e., the very minimal "foot" terminal emulator running under the single-app "cage" display server) and setting foot's settings to whatever you'd like would get you a better (and importantly, fully maintained) experience.
The 24x32 Terminus font is my favorite. It's exactly 80 columns wide at 1080p, just over 33 rows. I run it on 4K screens though.
80 x 24 is the original teletype size.
Personal preference are tautological.
This isn't just about an 80x25 console, is it? It feels like another layer of abstraction piled between me and the actual hardware.
The SGI Irix boot console was 80 characters wide and kind of elegant. It worked on different resolutions and looked like a floating window where the margins could be of arbitrary size.
i got an sbc running recently and the font was so small on my monitor i had difficulty reading it. i wouldn’t be surprised if it was 100+ rows and many, many columns.
It probably is impossible unless you actually have a VGA device and a CRT. There’s no way your LCD is going to distort its pixels so that they’re rectangular.
Is it just me or is this a misunderstanding of computer architecture? The computer can only output what the screen can support (native resolution), the screen can only display what the video card gives it, the video card can only display what the video card driver tells it to do. They all have to work in tandem.
If the system you're using (ARM??) doesn't have a particular fbdev driver, it still works thanks to the simpledrm weirdness. But if you want very particular results, you're gonna need to ship a driver for your card, to tell the card what to do, to tell the monitor what to do. The complaint seems to be that architectures change? I dunno what to tell you man. I hate technology too, but it do be changin'.
Sorry, but I don't understand why you even need an 80x25 console instead of a standard one.
Maybe I don't understand something, so please explain?
80x25 is by far the most common standard for console size
AFAIK, no, the most common standard for console size is 80x24, which came from the VT100 and is used by default on terminal emulators like xterm or the GNOME terminal.
No. It's the standard CGA/MCGA/EGA/VGA/SVGA int 10h mode 3, where on VGA/SVGA cards it was a 80x25 console comprised of 9x16 glyphs (8x16 really, where the right-most bit is duplicated) for an analog effective resolution of 720x400 in 4:3 aspect ratio.
Historically, when processors, motherboard buses, and video cards of physical machines were much slower, text modes were accelerated ways to write text such that they were much faster than writing and scrolling text graphically in a video framebuffer. Interestingly, on VGA/SVGA cards, it's possible to do double buffering of text by page flipping but it's pretty pointless even on real hardware.
Emulated hardware generally doesn't suffer from tearing effects that happen on real hardware where large updates (mostly in graphics modes rather than text modes) aren't synchronized with the raster scan and end up looking bad by showing partial portions of the previous frame and current frame while an update is happening. In graphic modes, this was mostly eliminated by double- and triple-buffering with precisely-timed page flipping on video cards that had enough memory to have 2 or more whole frames..
(B800:0000 and A000:0000 are permanently etched in my brain.)
Thanks
Getting an old machine is the way. I can’t think of why I would want this and I’m old so I don’t think it’s coming back.
Honestly, good riddance.
And let's chuck into the dustbin of history fiddling with IRQ dipswitches to disambiguate your mouse, video, disk, and audio controllers; the "turbo" button; "It is now safe to turn off your computer"; CGA/EGA/VGA/HGA/MCGA/SVGA/XGA, RLL/MFM/SCSI/IDE, and while we're at it, TSR programs like sound drivers, mouse drivers, etc. Let's not even discuss OS/2.
You know what sucked? Booting up into CGA and not being able to figure out how to escape that abomination. Why not pine for that?
All of this trash is behind us and frankly I think we're better off for it. If you want to go play with obsolete computers, then finding some old computers and some old computer junkies who still enjoy that junk is the right way to go. Personally, I had my fun, but I like our modern machines so much more than those old smokey capacitor poppers. But I have to admit, I almost miss compiling my own kernel. Almost.
This is from an era when you could still make the computer do what you want. Those days are long gone now; incidentally, that's why "It is now safe to turn off your computer" does not belong in this list, because it still exists, just not under that name. Windows (or whatever OS) decides when you can turn it off. Just like it now decides when it's time to upgrade.
Actually there _is_ a lot to be missed about those times, in spite of all the "progress" we've made since then.
"It is now safe to turn off your computer" was a kludge for running Windows 95 on PCs with a physical on/off switch (as opposed to newer ATX power supplies, which have a pushbutton to turn them on and can be switched off via software). I guess it's theoretically possible to build a modern PC with a 30+ year PSU, and then you would see this screen again - or, more realistically, you could disconnect the PS_ON line (https://electronics.stackexchange.com/questions/394414/how-d...) from the mainboard, preventing the system from turning off the PSU.
My 3D printer has a physical off switch. And it runs Linux - debian - on an embedded ARM board, so I can ssh into the printer etc. (I can even hook up a keyboard and HDMI monitor)
I fear about my filesystem every time I notice the printer is running at night (after a long print job) and I just turn it off without going over to my pc, ssh in and shut down the OS.
Still, it hasn't eaten my filesystem, yet ... ext4 journaling DOES seem to work.
I won't lament the loss of giant, stretched-out consoles that flash by too fast to do anything useful with either, but on the other hand I don't see why "there should be a way to make the text bigger" is a problematic request.
There are all sorts of disabilities that might necessitate a console with large text, and setting a specific size (in this case 80x25 because it used to be a standard) isn't such an outrageous demand.
The author knows a solution: set a specific resolution and select a specific font. The problem is that they can't pick that resolution, even though they could before, because on UEFI and non-amd64 the common GPU configuration parameters don't work in Linux.
We should default to a modern system, but the kernel should have a standard way of configuring the boot console. For every person who wants 80x25 mode, there's someone with a weird device that outputs three pixel high fonts because the default resolution is bugged, and both need the same override to fix their issues.
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.
And in 80x25, there’s so much text that it zooms past you with no chance to ever read it, and Scroll Lock won’t work. Can’t have it both ways, I suspect the truth is somewhere in the middle.
No, you can make large text (and GUI) much easier today. The author is just obsessed with one particular grid size.
To the trash heap you snappy applications. Thank god for electron based IDEs.
Needless complexities have simply crept in other parts of the machine.
Thank you, 100 times this. There was literally nothing fun about it.
I remember desperately trying to put drivers in high memory, because Wing Commander 2 needed more memory if I was to get the precious images of the joystick moving. Slowly removing items, one by one from my autoexec.bat file, desperately hoping it was going to work, but then the creeping realisation that I would have to unload my soundcard drivers if I wanted a chance.
Or the time our bios randomly wiped its memory and my dad was convinced I had destroyed the harddrive. Thankfully I was told by a family friend that I would only have to turn on the BIOS and set it to # 31 (because somehow hard disk sizes, sectors, et cetra were all standardized) in order to access our precious 95 megabyte hard disk.
Ah, yes, and I also remember what a relief it was when the newer generation of games (starting with Doom IIRC) used "DOS extenders" to switch the CPU into protected mode and be able to use 16 MB or more without any fiddling...
Another anecdote from around that time (or a bit later): some friends were alarmed that their PC was not booting Windows as usual. Turns out they had forgotten a bootable CD in the CD-ROM drive, which was showing some cryptic text mode menu on startup. Easy fix: remove CD, restart, works...
SimCity CD-ROM edition was the greatest. It needed sound card drivers, mouse drivers, CD-ROM drivers and MSCDEX, and it required 605kB of free conventional memory.
Oh, and only some hard drives were standard like that. For others, you needed to set sectors, tracks and landing zone manually. Happy fun times if your CMOS battery ran out.
I do find it funny that there are so many people on HN who work in a rapidly advancing cutting edge industry, but are also absolute stuck-in-the-mud curmudgeons who want everything to stay exactly as it was 4 decades ago.
Another example is dropping support for 32-bit x86. "But how will I run Linux on my PC from 2001?". Or the resistance to Rust in Linux because LLVM doesn't support the PDP-8 architecture.
> Or the resistance to Rust in Linux because LLVM doesn't support the PDP-8 architecture.
Tbf I don't even think Unix was ever ported to the PDP-8 :D
I guess you never got you a GUS, Iiyama monitor, or Courier 56K V.92 modem for Christmas.
One of my uncles worked at Hayes back in the day. Those were truly happy years!