I’m writing a VT100 terminal simulator running the original firmware: GitHub - larsbrinkhoff/terminal-simulator: Simulation of VT52 and VT100 terminal hardware.
I will put it in a 3D printed case by Michael Gardi: https://www.instructables.com/23-Scale-VT100-Terminal-Reproduction/
How accurate is your emulation? Does it include a “beep” when the BEL (0x07) ASCII code is received. And, most importantly, does the terminal “quack” if you send a BEL followed by a FF (0x0C)?
I remember accidentally discovering the “quack” sound when someone typed a binary file to the screen that had those characters in it. (I seem to recall that the quacking sound only occurred if smooth scrolling was not enabled). One of us made a file called DUCK.TXT which included several BEL / FF pairs, followed by an ASCII art rendition of a duck.
That’s really cool looking.
Building a serial terminal is on my list of projects although I’d probably put it in a small case and attack it to a larger monitor just to maximize space.
That PiDP-8/I kit looks interesting too.
It would be nice to have other terminal emulations than a VT100. It it all just software at this point.
Teletype machines come to mind, and IBM punch cards.
Mike,
I believe it’s quire accurate, although not everything is fleshed out yet. I’m working on simulating the RC circuit that generates the click and beep.
Very interesting to learn about the BEL+FF! I’ll have to check that.
It would be nice to have other terminal emulations
I’m kind of planning ahead for this. Other terminals in the VT1xx series would not be too hard, and then there’s the VT220 and up. Also other manufacturers using 8080/8085/Z80 etc.
Teletypes and card readers are outside the scope of my project.
Regarding video rendering, it might be nice to implement variable contrast. E.g., raise the “activation” flanks according to the contrast settings and top out at a certain threshold level of the virtual phosphor. This way, type will be bolder with high contrast levels and thinner with low contrast.
(Similarly, brightness settings may be emulated by adjusting the general bottom level / the minimum, we’re starting at.)
Compare: https://www.masswerk.at/nowgobang/2019/dec-crt-typography
(This would suggest to lower the top threshold level as seen in the above image for high contrast settings and render the projected brightness level. Emulating brightness settings would mean to add a certain, general bias to this, anywhere on the screen, e.g. in the range of -0.1…+0.1.)
Thank you @NoLand, that’s a good suggestion. I have read your article several times before with great interest. I do want to model the CRT phosphor response to some degree. I have a real VT220 and I assume its CRT is similar to what a VT100 has.
By the way, I have it conformed from a few real terminals that the VT100 really does dot stretching before character widening. This means the wide character details visible on a VT220 is not on a VT100.
Thanks! 
The information on the differences in the VT100 and VT220 is interesting – I’ll add an update regarding this.
I’ve been planning to do a somewhat accurate emulation in JS for years, but I get always distracted. What I would do was to generate activation values for the first two pixels of any stretch of “on” pixels and similarly an “off” flank of two pixles for any trailing stretches of pixels that are off, anytime the settings are changed. This way, there’s no additional load on the rendering process and we would still be adding simple pixel levels to the canvas. (E.g., add a ramp like 0.5, 0.95, 1.0, 0.34, 0.05, 0.0 for 1, 1, 1, 0, 0, 0.)
Here’s some pseudo code:
// adjust these on contrast change
ramp_on = [0.5, 0.95];
ramp_off = [0.35, 0.05];
// adjust this on brightness change
brightness_bias = 0.025;
// counters (int), reset on the beginning of each scan line
px_counter_on = 0;
px_counter_off = 0;
function getPixelValue(boolean: on) {
real: r;
if (on) {
if (px_counter_on > 1) {
r = 1.0;
}
else {
if (px_counter_off) px_counter_off = 0;
r = ramp_on[px_counter_on++];
}
}
else {
if (px_counter_off > 1) {
r = 0.0;
}
else {
if (px_counter_on) px_counter_on = 0;
r = ramp_off[px_counter_off++];
}
}
r += brightness_bias;
// return clamped value (0.0 <= r <= 1.0)
//return max( 0.0, ( min( 1.0, r ) );
if (r > 1.0) return 1.0;
if (r < 0.0) return 0.0;
return r;
}
(Edited to avoid possibly expensive calls to min and max.)
Thanks for the code! Pull requests accepted. 
I will probably do these effects with GPU shaders. I want to have a basline bare-bones version supporting the Raspberry Pi 3 as a low-end target, with optional eye candy for more powerful computers.
I guess, this should work with a Pi 3 without any issues. (Even a Pi 2B does render arcade game emulation without issues and this a fairly lightweight task in comparison to that.)
Edit: calls to min and max for clamping may be substituted by two if–clauses, depending on the implementation. (If min and max accept more than two arguments, these may be significantly more expensive. Otherwise, these may be just macros, anyway.)
VT340 with its color and graphics capabilities would be ambitious. (Trying to nerdsnipe you here.)
I updated the code to avoid min and max. This should be really lean on the processor.
Also, you could already include up-scaling, e.g. for a scale factor of two, have the ramps double the length and and advance counters by two and return a double of pixel values (two consecutive pixel values).
@jhi, I kind of nerdsniped myself. I wasn’t supposed to do this, but the combination with the 3D printed model won my heart over.
VT340 firmware ROM images are available, so it’s a possibility.
While historically not correct, I’m musing over a VT20b or VT52 case…
(VT52 – well, where do I get the key caps from?)
It’s always the keyboard that’s the biggest problem in these replica projects! I’d like a Knight and/or SAIL keyboard myself, and not just for the looks. Some applications expect those nonstandard keys.
While researching the VT1xx series I found many weird and wonderful DEC terminals under Index of /pdf/dec/terminal
How about the VT02! Some kind of ARDS or other storage CRT?
Especially SA keys are a problem nowadays, which are, of course, the nicest ones…
(A few years ago, you could get SA keys in about any color with IBM Selectric-type double-shot glyphs, but these are now gone, too. And, of course, I missed out on those.)
Non-standard layouts, are a problem anyway.
Regarding the VT02, that made me actually laugh.
@Mike_Shawaluk, I haven’t been able to reproduce your qack effect but will continue to look into this. Do you think anyone else might remember this? Any copy of that duck.txt file?
