Simulator for the VT100 hardware. Running inside Gardi's 3D model.
To make the experience fit your profile, pick a username and tell us what interests you.
The model compared to a real VT100.
I'm getting a real VT100, which will be a boon for my work on the simulator and 3D model. It's in transit, but expected to arrive next week.
The model is ready for painting, but which color? I haven't found exact color codes for the VT100 colors. I will try to get a match against the real terminal.
Spraying with filler primer.
Filling in joints with epoxy putty.
48 hours later, after curing and sanding.
It doesn't seem to fit. The board layout seems slight different from other pictures I have seen. Maybe it's a mismatch?
I have now finished printing all the pieces of the VT100 body.
It's now finally time to start gluing the pieces together!
As you can see, it's a bootstrapping process.
I think I managed to get the pieces aligned quite well. But this is only the raw material from which the final model will be furnished. I have lined up epoxy putty and filler primer to smooth out visible joint lines.
A rare glimpse into the hardships of terminal emulation development. Here is my office... erhm... living room. The first thing you may notice is that I have a real VT220 to compare against. To the right of the terminal is a Raspberry Pi 4 running the VT100 simulator.
I previously mentioned PDP-10 and ITS. On the far right is an emulator for the Knight TV, a very early bitmap display system attached to the MIT AI lab PDP-10 running ITS.
Not pictured: Datapoint 3300 emulator displaying Guy Steele's CROCK.
As I mentioned in a previous log, the visual appearance of the simulator took a step back. But now it's about to take two steps forward. I'm adding the use of OpenGL shaders to mimic a CRT. This includes effects such as characters built from smooth scanlines, a soft glow around text, and a subtle curvature as a CRT should have.
Since the shader code runs in the GPU, it's not too heavy on the hosting computer. It still runs fine on a Raspberry Pi 4, but a Pi 3 may now be too slow. It could still fall back on the previous renderer though.
A caveat though! At this point, the shaders will probably wear down your GPU if you try to run in full screen mode.
Michael Gardi reported dropped characters, even though software flow control using XON and XOFF was enabled. As a heavy Emacs user, I abhor XON/XOFF since XOFF is the same as Control-S which is search in Emacs. But still if you enable it, it should certainly work!
Looking into this, true enough the VT100 does send an XOFF when it's being overwhelmed. But the remote side didn't seem to care about this and kept sending data to the terminal. Why that is, I don't know! My best guess at this point is that there may be a operating system buffer still emptying even though the host received the XOFF and stopped sending characters.
Rather than banging my head against that wall, I applied a quick band aid. The simulator will now intercept XON/XOFF internally and do the flow control. It's not pretty, but it seems to work. Maybe there will be a better solution in the future.
I wanted to add an icon to my simulator application. It will show up when you cycle between window applications, e.g. with Alt+TAB. What better icon than a photo of a VT100?
I searched for photos online and came across some high quality images by Chuck Hutchins: https://blog.hutchins1.net/2020/02/vt102.html
I contacted Chuck and got his permission to use his photos in the simulator project. He even sent me higher resolution photos. Thanks!
I cropped and resized one of them to use as an icon.
Become a member to follow this project and never miss any updates
By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies. Learn More