I did sort of the opposite of this by buying a real VT100 on eBay, restoring it to working order, and mounting a Raspberry Pi Zero W inside it that emulates a PDP-11. So instead of an emulated terminal with a real computer, it’s a real terminal with an emulated computer.
(In case you’re wondering, I had no sane reason to do this.)
I bought a vt510 and hooked it up to my raspberry pi. My intention was to get some kind of VAX VMS OS on there, but as i played around on linux i realised something.
It really really sucks.
I had been dreaming of such a set up since i had been at the centre for computing history[1] and got so much nostalgia for the old DEC VMS setup they had. There is so much emotion brough back from just touching those machines, from the way your muscle memory kicks in as soon as you put your hands over the keyboard.
I was so damn excited for this.
but it was awful, the lag was the big one, but this wasn't from my set-up, this actually was how it was, the previously suppressed memory came back, sat in the computer lab at college, that lag was there - but yeah after years of iterm2, tmux and the advancements in the cli space - going back to vt510 really really sucked.
But it was a pretty horrible experience[2], and really affected me actually, it made me think a lot about nostalgia and how we remember the past.
I was lucky in that I went through my nostalgia phase when old computers were simply obsolete. That is to say, I was comparing spinning rust to spinning rust. Then modern spinning rust may have been significantly faster than obsolete spinning rust, but other factors partially compensated for the difference (such as leaner software that was written much closer to the hardware).
While I still maintain an interest in computer history, i.e. in a literary sense rather than maintaining hardware, it is from an entirely different perspective. I like thinking about how things would have been different if we, say, focused upon energy efficiency or if we minimized the number of layers of abstraction of if main memory was non-volatile. Of course these all involve trade-offs. The interesting thing is how these trade-offs would change the path of technological development.
Of course, it is entirely possible that there was only one viable path. It is nearly impossible to sell operating systems based upon technical improvements, so the emphasis is upon a bunch of end-user visible ephemeral trash. Similarly, it would have been nearly impossible to sell more energy efficient computers so the emphasis was on performance. (Even today, a laptop battery that lasts a day and a mobile phone battery that lasts two is considered good enough.) And, of course, the sale of those high performance processors financed the development of improved fabrication processes that enabled the development of even higher performance processors - and more energy efficient ones. It is unlikely that pursuing energy efficiency would have financed the development of processes to perpetuate itself.
It's prerelase and I haven't pushed the experimental graphical interface yet but you can actually use it, configure it and run everything using a TUI mapper that renders the text framebuffer on your terminal.
There's one or two memory mapper bugs that seem to break multi session mode but those are somewhat obscure and will probably require some experimentation with real hardware to solve.
Oh man, that brought a memory! I learned C and made my first "bigger" steps in programming on VT320 and VT420 connected to one of the Sun boxes. I'm still fond of that amber glow.
I wasn't even born back then but I love those amber crts. I had the luck of finding a Zenith ZVM-1220-EA composite display in pristine condition on ebay (I live in Germany where it's way harder to find nice amber crts) and it looks fantastic.
But there is one thing, the noise. I very much hear that super high pitched sound and it makes running it just as a 2nd monitor almost impossible.
Also I haven't quite found a good way of integrating it into my setup yet, raspi+tmux+ssh is the easiest but it'd be much cooler having it as an actual 2nd display.
Do you have more literature on the SSU? Do you know if the roms tolerate more than two sessions being available (or can be trivially patched to support more?)
The SSU feature is woefully underdocumented and the patent gives you _some_ information, but it's missing all of the details. I hope to break this part out into a project of its own.
I am 100% certain a VT420 will never be able to support more than two sessions, as the ROM explicitly has a ton of checks that look like "if session1 { ... } else { ... }". Unfortunately your best bet here would be putting a more advanced terminal multiplexer behind your VT420 and then making the F4 key a full passthrough (disabling the native session switcher).
I had a bunch of these VT100 animation files and found those and more on this site. Things like Star Trek and fireworks. I first saw them in 1991 but modern terminals play them too quickly and instead of going on for 15 seconds it instantly finishes and you just see the final scene.
Is there any way to slow things down in a terminal?
Ahh the reassuring amber glow, the faint smell of burning dust, a gentle patter of keystrokes, punctuated by the occasional muted bell tone and the gentle rustle of fanfold papers. The night before project submission in terminal room 11B6.
I'd love a fork from the one of XScreensaver, which shared a bit of code with XanalogTV I'd guess for the CRT effects fading in and out.
Please, no GL shaders. XanalogTV did it fine without any video acceleration.
I'd love to have TTF support, DEC graphics and colour fonts. (VT340 at least?).
xanalogTV and the like run CRT effects even under an Athlon 2000 back in the day.
WIthout something bound to GL => 3.3 you can run a terminal emulator anywhere, even under legacy systems with no OpenGL support at all.
On the emulator from Lars in the below comment, that's a good approach; but for the physical CRT effects, as I said, XanalogTV did a great job.
But kudos for allowing a GL-less option for legacy systems.
> xanalogTV and the like run CRT effects even under an Athlon 2000 back in the day
Because it wasn't doing much else.
> even under legacy systems with no OpenGL support at all
If it's as legacy as all that, it probably doesn't have graphics that are particularly enjoyable to use. Are you trying to run it on a Sun IPX or something?
Considering that MAME's shaders run fine on a 2011-era laptop with the positively primitive Intel iGPU of the Sandy Bridge era, I can only assume they're intending to run this on something extremely ancient that would end up being less power efficient for the task.
Even a Raspberry Pi can handle this stuff at low power consumption today.
CRT simulation didn't run well on Intel iGPUs for a very long time. While they could run the effects, they couldn't run them fast enough. There was longstanding advice in the emulation scene to not bother using shaders unless you had a dGPU; that only changed around Sandy Bridge, where the performance became sufficient.
>Sadly, so far as I know, there is no such detailed documentation or test-suite for terminals and terminal emulators. Because they’re fundamentally about visual output, it’s quite difficult to properly test them.
>A special shout-out to vttest which does try to exercise a bunch of corner-cases of VTxxx emulation. Unfortunately, it can only really be used interactively, so it's not useful for automated testing.
>Vttest was written in 1983-1985 by Per Lindberg at the Stockholm University Computing Center. The last version was 1.7b (1985-04-19). Per Lindberg later distributed 1.7b via the Usenet mod.sources group (Volume 7, Issue 16, September 2, 1986). It became an established part of the Unix source archives, e.g,. as noted in these postings from 1988.
It even tests for obscure commands like ESC # 8: video alignment test-fill screen with E's
/hash-prefix {
56 eq {
test-pattern
} if
reset-termulator
} def
/do-hash {
/termulate-char //hash-prefix def
} def
/test-pattern {
Columns 0 ne Rows 0 ne and {
Columns string
0 1 Columns 1 sub {
1 index exch 69 put
} for
0 1 Rows 1 sub {
Lines exch get 1 index exch copy pop
} for
pop
} if
slow-refresh
} def
It would detect that it was being tested with vttest by noticing undefined erroneous escape codes, and contemptuously changing the cursor to a hand flashing "the finger" 20 times to anyone who insisted on testing it (Hugh Daniel and Nick Turner at Wedge Computer Inc, all RIP):
I did sort of the opposite of this by buying a real VT100 on eBay, restoring it to working order, and mounting a Raspberry Pi Zero W inside it that emulates a PDP-11. So instead of an emulated terminal with a real computer, it’s a real terminal with an emulated computer.
(In case you’re wondering, I had no sane reason to do this.)
Would love it if you could write about this and post it.
I did something similar.
I bought a vt510 and hooked it up to my raspberry pi. My intention was to get some kind of VAX VMS OS on there, but as i played around on linux i realised something.
It really really sucks.
I had been dreaming of such a set up since i had been at the centre for computing history[1] and got so much nostalgia for the old DEC VMS setup they had. There is so much emotion brough back from just touching those machines, from the way your muscle memory kicks in as soon as you put your hands over the keyboard.
I was so damn excited for this.
but it was awful, the lag was the big one, but this wasn't from my set-up, this actually was how it was, the previously suppressed memory came back, sat in the computer lab at college, that lag was there - but yeah after years of iterm2, tmux and the advancements in the cli space - going back to vt510 really really sucked.
But it was a pretty horrible experience[2], and really affected me actually, it made me think a lot about nostalgia and how we remember the past.
---
[1]https://www.computinghistory.org.uk/
[2] please, these things are relative, it wasn't that bad, it just kinda sucked
I was lucky in that I went through my nostalgia phase when old computers were simply obsolete. That is to say, I was comparing spinning rust to spinning rust. Then modern spinning rust may have been significantly faster than obsolete spinning rust, but other factors partially compensated for the difference (such as leaner software that was written much closer to the hardware).
While I still maintain an interest in computer history, i.e. in a literary sense rather than maintaining hardware, it is from an entirely different perspective. I like thinking about how things would have been different if we, say, focused upon energy efficiency or if we minimized the number of layers of abstraction of if main memory was non-volatile. Of course these all involve trade-offs. The interesting thing is how these trade-offs would change the path of technological development.
Of course, it is entirely possible that there was only one viable path. It is nearly impossible to sell operating systems based upon technical improvements, so the emphasis is upon a bunch of end-user visible ephemeral trash. Similarly, it would have been nearly impossible to sell more energy efficient computers so the emphasis was on performance. (Even today, a laptop battery that lasts a day and a mobile phone battery that lasts two is considered good enough.) And, of course, the sale of those high performance processors financed the development of improved fabrication processes that enabled the development of even higher performance processors - and more energy efficient ones. It is unlikely that pursuing energy efficiency would have financed the development of processes to perpetuate itself.
Related, I'm working on a VT420 emulator that's about 90% there...
https://github.com/mmastrac/blaze
It's prerelase and I haven't pushed the experimental graphical interface yet but you can actually use it, configure it and run everything using a TUI mapper that renders the text framebuffer on your terminal.
There's one or two memory mapper bugs that seem to break multi session mode but those are somewhat obscure and will probably require some experimentation with real hardware to solve.
Oh man, that brought a memory! I learned C and made my first "bigger" steps in programming on VT320 and VT420 connected to one of the Sun boxes. I'm still fond of that amber glow.
I wasn't even born back then but I love those amber crts. I had the luck of finding a Zenith ZVM-1220-EA composite display in pristine condition on ebay (I live in Germany where it's way harder to find nice amber crts) and it looks fantastic.
But there is one thing, the noise. I very much hear that super high pitched sound and it makes running it just as a 2nd monitor almost impossible.
Also I haven't quite found a good way of integrating it into my setup yet, raspi+tmux+ssh is the easiest but it'd be much cooler having it as an actual 2nd display.
I still use https://github.com/emacsmirror/orangey-bits-theme
Nice! I still have a real VT520 here. This would be cool for when it dies eventually
Cool.
Do you have more literature on the SSU? Do you know if the roms tolerate more than two sessions being available (or can be trivially patched to support more?)
The SSU feature is woefully underdocumented and the patent gives you _some_ information, but it's missing all of the details. I hope to break this part out into a project of its own.
I am 100% certain a VT420 will never be able to support more than two sessions, as the ROM explicitly has a ton of checks that look like "if session1 { ... } else { ... }". Unfortunately your best bet here would be putting a more advanced terminal multiplexer behind your VT420 and then making the F4 key a full passthrough (disabling the native session switcher).
Cheers.
I haven't had a VT420 in a few decades, but I remember wondering about its built-in multisession support (I never saw it in action)
The emulator supports it, though there's a few bugs in it so you can try it out. The animated GIF in the README demonstrates it too :)
I would call the splitscreen multisession... gimmicky at best? The two-session version is alright, but juggling windows is not great in general.
That's pretty neat. I look forward to the graphical version, though: love those double-sized characters.
I just pushed the graphical driver and they really do look great!
I had a bunch of these VT100 animation files and found those and more on this site. Things like Star Trek and fireworks. I first saw them in 1991 but modern terminals play them too quickly and instead of going on for 15 seconds it instantly finishes and you just see the final scene.
Is there any way to slow things down in a terminal?
http://artscene.textfiles.com/vt100/
EDIT:
I just found this command from here and it's awesome to see these after 30 years!
https://www.reddit.com/r/commandline/comments/cbp3eo/playing...
cat "/path/to/file.vt" | pv -q -L 2000
(2020) Popular in:
2024 (40 points, 16 comments) https://news.ycombinator.com/item?id=40590353
2020 (117 points, 30 comments) https://news.ycombinator.com/item?id=23662907
Ahh the reassuring amber glow, the faint smell of burning dust, a gentle patter of keystrokes, punctuated by the occasional muted bell tone and the gentle rustle of fanfold papers. The night before project submission in terminal room 11B6.
VT102 specs, e.g., 8085A 6MHz CPU [1]
[1] http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=vt1...
Maybe `pv` with the `--rate-limit` option can be used for the buffer problems?
Now how about a luxurious Ann Arbor Ambassador?
https://terminals-wiki.org/wiki/index.php/Ann_Arbor_Ambassad...
https://vt100.net/annarbor/aaa-ug/section1.html
http://madrona.ca/e/aaa/index.html
I'd love a fork from the one of XScreensaver, which shared a bit of code with XanalogTV I'd guess for the CRT effects fading in and out. Please, no GL shaders. XanalogTV did it fine without any video acceleration. I'd love to have TTF support, DEC graphics and colour fonts. (VT340 at least?).
A full terminal emulator including firmware and 8080 emulation but with small trivial GL shaders that can be disabled exists here: https://github.com/larsbrinkhoff/terminal-simulator
> Please, no GL shaders.
Why not? On anything made in the last 20 years it's going to be faster to render and simpler to implement.
You could do it in software if your processor didn't have anything better to do.
xanalogTV and the like run CRT effects even under an Athlon 2000 back in the day. WIthout something bound to GL => 3.3 you can run a terminal emulator anywhere, even under legacy systems with no OpenGL support at all.
On the emulator from Lars in the below comment, that's a good approach; but for the physical CRT effects, as I said, XanalogTV did a great job.
But kudos for allowing a GL-less option for legacy systems.
> xanalogTV and the like run CRT effects even under an Athlon 2000 back in the day
Because it wasn't doing much else.
> even under legacy systems with no OpenGL support at all
If it's as legacy as all that, it probably doesn't have graphics that are particularly enjoyable to use. Are you trying to run it on a Sun IPX or something?
Considering that MAME's shaders run fine on a 2011-era laptop with the positively primitive Intel iGPU of the Sandy Bridge era, I can only assume they're intending to run this on something extremely ancient that would end up being less power efficient for the task.
Even a Raspberry Pi can handle this stuff at low power consumption today.
> I can only assume they're intending to run this on something extremely ancient that would end up being less power efficient for the task.
I don't think I've owned anything PC-like that didn't have hardware OpenGL acceleration since the late 90s.
CRT simulation didn't run well on Intel iGPUs for a very long time. While they could run the effects, they couldn't run them fast enough. There was longstanding advice in the emulation scene to not bother using shaders unless you had a dGPU; that only changed around Sandy Bridge, where the performance became sufficient.
>Sadly, so far as I know, there is no such detailed documentation or test-suite for terminals and terminal emulators. Because they’re fundamentally about visual output, it’s quite difficult to properly test them.
>A special shout-out to vttest which does try to exercise a bunch of corner-cases of VTxxx emulation. Unfortunately, it can only really be used interactively, so it's not useful for automated testing.
https://en.wikipedia.org/wiki/Vttest
https://invisible-island.net/vttest/
>Vttest was written in 1983-1985 by Per Lindberg at the Stockholm University Computing Center. The last version was 1.7b (1985-04-19). Per Lindberg later distributed 1.7b via the Usenet mod.sources group (Volume 7, Issue 16, September 2, 1986). It became an established part of the Unix source archives, e.g,. as noted in these postings from 1988.
It even tests for obscure commands like ESC # 8: video alignment test-fill screen with E's
http://www.braun-home.net/michael/info/misc/VT100_commands.h...
(I know that because I wrote a VT100 emulator in PostScript for NeWS that passed vttest.)
https://donhopkins.com/home/archive/news-tape/utilities/term...
It would detect that it was being tested with vttest by noticing undefined erroneous escape codes, and contemptuously changing the cursor to a hand flashing "the finger" 20 times to anyone who insisted on testing it (Hugh Daniel and Nick Turner at Wedge Computer Inc, all RIP):