[superice]

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?

[dijit]

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.

[bombcar]

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.

[IcePic]

This even applies to remove-viewing software that wants to "follow" the resolution changes, flipping your remote window size around a lot. Super annoying.

[jcalvinowens]

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.

[bpye]

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

[kotaKat]

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?”

[autoexec]

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.

[cyberax]

> 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.

[immibis]

Actually it's the device that supports both PS/2 and USB mode. The host doesn't.

[cyberax]

Sure. It is also a possibility, but a lot of PS/2 devices predate the USB.

[hxorr]

This is also my understanding too

[tracker1]

Wonder if this is part of why my unicomp keyboards don't work for going into the bios on my current desktop, it doesn't work until inside the OS.

[autoexec]

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.

[cyberax]

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.

[Galanwe]

> 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.

[db48x]

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.

[Galanwe]

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?

[db48x]

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.

[toast0]

How would a CRT scale the vertical height? Maybe you get a bit more space between lines, but the beam is only as tall as it is, right?

I would think the scaling would come horizontally ... you can put as many pixels horizontally as your RAMDAC can manage, but screen width per pixel depends on the pixel time vs the line time.

[superice]

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'.

[db48x]

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.

[tracker1]

Except that still locks you to 1920x1080 which a LOT of displays, laptops etc already break... 16:10 aspect, 3440x1440p, etc. are already outside that ratio you outline. The thing with 80x25 VGA text modes was it was both fast and consistent in a lot of ways. You just cannot have a predictable full screen text interface today in the same way as you could.

That said, there were differences back when... you had the original CGA and EGA as precursors to VGA. I used an EGA 386 system for several years and have similar fondness for that, especially in that it was the native for RIPterm/RIPscrip in the early-mid 90's. Which was still different from the much more common VGA modes.

Hell, my biggest niggle to this day is that so many terminal apps don't match the DOS colors you got with CGA/EGA/VGA default. I often will configure that, so I can at least output classic ANSi art to my terminal and have it look closer to correct. I keep working through ideas for a "modern" text mode BBS that worked well in modern terminals. On the flip side, I'm thinking of adapting a door server model that will map CP-437 output to UTF-8 and map the colors to rgb color codes for modern terminals to show the right colors.

[account42]

> 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.

[burnt-resistor]

Chill out and stop judging people with such unnecessary histrionics.