This is a detailed software simulation of the VT100 hardware. The original firmware ROM is built in and executed by an 8080 emulator. Other components include video display with character generator ROM, settings NVRAM, Intel 8251 USART, a keyboard matrix scanner, and a sound circuit for beep and key click.
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.