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.
Also 80x25 has a lot of history, and some things work better at that size.
I don't know if you've ever tried using a non-graphical display on linux recently, but if you have say a 4k display, you get unreadably tiny text.
It also breaks a lot of text-mode stuff.
If you've ever tried to FIX this on your system, you'll find a bunch of roadblocks.
You can't just use an easily available font for the console. Console fonts have to be created or converted into a non-standard .pfs or .pfsu format.
most linux distributions have at most a 16x32 font available if you take the time to do the override properly. Even that font is pretty small on 4k.
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.
ITX-Llama and its clone called Pixel x86 are new, not noisy. Based on modern Vortex86 CPU that has real functioning ISA DMA bus, something ceased to exist in 2000 in other conventional CPUs and motherboards
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.
> 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.
> 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.
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.
Readit News
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.
Also 80x25 has a lot of history, and some things work better at that size.
I don't know if you've ever tried using a non-graphical display on linux recently, but if you have say a 4k display, you get unreadably tiny text. It also breaks a lot of text-mode stuff.
If you've ever tried to FIX this on your system, you'll find a bunch of roadblocks.
You can't just use an easily available font for the console. Console fonts have to be created or converted into a non-standard .pfs or .pfsu format.
most linux distributions have at most a 16x32 font available if you take the time to do the override properly. Even that font is pretty small on 4k.
https://wiki.archlinux.org/title/Linux_console
When terminals were common, they pretty much all were 80 or 40 columns and 25 rows, not a lot of choice, most were about the same size.
I actually like modern emulated terminals, with all the bells and whistles.
Deleted Comment
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.
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.
And this even matches the way PC CRT monitors worked - each displayed "pixel" lights many different phosphors.
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 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.
Had to get a CRT to see what the hell was going on.
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.
I think serial mice should still work as well - https://wiki.alpinelinux.org/wiki/Serial_mouse
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?”
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.
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.
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.
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.
Unfortunately, the patch is not frequently updated to new kernel versions.
https://public-inbox.gentoo.org/gentoo-user/2316312.ElGaqSPk...
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.
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. :(
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Could you please name a single model of SFF PC that exposes a serial connection via RJ45 port?