I found this GUI software HeavyMetal aka Heavy Metal used when attaching an old TTY to a modern PC (WIN/Linux).
Interesting are the many settings. Most are obvious, other maybe not.
Baud rate, different amount of data bits and stop bits and different parity.
Also different ITA codes, Baudot code settings and some more.
I searched for that because I have an uncommon parity setting (mark parity, not like the DIN standard) and at 110 baud there’s (as usual) 2 stop bits.
I first wondered if the original data is stored differently with mark parity bit (or even with 110 bauds). But I learned that data remaining as it is. (Who knows if it’s different on strange devices like mine).
I considered taking a closer look at that (although I don’t have a physical TTY), but I eventually found my text. The 2012 version still works on 64 bit Win.
Mark parity was quite common up through the 1970s, and I’m not sure why. All of my 7-bit terminals (Tektronix, Teletype, and DEC) are either mark parity or support it as an option. In fact, mark parity seems to be possibly more common than 7-bits-and-a-space (space parity, I guess?), joined by even parity as the usual options. Then, for whatever reason, it disappeared almost entirely and is very poorly supported today.
This is one of those: “I don’t understand why you need this” scenarios - and I genuinely don’t.
Possibly because I know Linux supports serial terminals and has done since day 1 - as does the various Unixes, etc. That often published photo shows the 2 heroes of the day standing over a Teletype in-front of a PDP11, so what changed?
It looks like the (perl - eh gads, brain!) program just takes a text file and sends it to a serial port. And part of it does it via some sort of client/server means (you can telnet into it!)
But you can configure a login on a serial port and go from there. You can configure the baud, stop bits (2 because it’s slow, mechanical) as well as line feed and carriage return delays too - all standard part of the Unix/Linux serial drivers.
You can even configure a Teletype as a serial printer and print to it - and modern systems will even print PDFs to it too.
Or has this all gotten lost this millennium and the newbs are re-inventing wheels that already exists…
I think HeavyMetal is doing something a bit like what PuTTY does - a GUI program to manage connection settings and provide a glass TTY output. The sort of thing which makes sense as a GUI tool, which you might arguably not need if you had a command line and a suitable client program. (Even linux has more than just telnet: it has minicom, and other clients.)
Caveat lector, in that I haven’t looked at the details of this script.
Sort of.
agetty allegedly supports all of this stuff, and the Linux kernel allegedly does, as well, but my experience with actually getting old terminals working on Linux has been unfortunate. In particular, agetty doesn’t have any way to configure the terminal directly, it relies on figuring out the terminal’s (in particular) byte width and parity requirements from the incoming text. In my experience, while the manual page explicitly states that it will handle “even, odd, none, or space parity,” even parity is hit-and-miss – and note that mark parity isn’t on the list. It also allegedly detects uppercase-only ASCII '63 terminals and does case conversion, but I have never been able to get that to work at all.
In practice, I’ve had to spend some time with stty to get 7-bit terminals that can’t handle mixed case and space parity working reliably.
I lucked out recently and got a VT320 at a reasonable price. It’s currently hooked up to my PiDP-8 (a Raspberry Pi with a blinky-light front panel) as a terminal. It took me only a little while to get the agetty setup - mostly getting the default terminal type set correctly.
All of the VT[1-5]xx terminals (to my knowledge) play very nice in an 8-bit world, and happily send and receive 8-bit characters with the upper bit normally zero (as a 7-bit ASCII stream would have). They are also capable of both upper- and lower-case in both directions, and have normal support for the usual bevy of control characters (e.g., ASCII tab, newline, carriage return, and tabs don’t inexplicably take three character timings or anything like that). They’re normally quite approachable to hook to very modern computers. The only trouble point is software flow control; some of the newer terminals have hardware flow control, but all of the older terminals expect C-s and C-q to be flow stop/restart signals in both directions, which is hard on, among other things, Emacs users.
I also had hooked up a TI Silent 700 to my Altair-duino. For that one, I had to loop back the serial control lines because the terminal looked for them. Of course, the Altair-duino and USB-Serial cable didn’t supply those signals.
Maybe it depends on the country.
In Germany there are DIN standards for everything.
According the manual the usual DIN used (in ~1979) was DIN 66022. And that didn’t have mark parity.
And at 300 bauds there were additional 6 NIL (LF) added.
Unfortunately old DIN standards can’t be freely read.
The Code is 7-Bit ASCII (DIN 66003).
The PIN layout (V.24) is DIN 66020 (illustrated in my manual).
As my machine has a 12 bit CPU the text encoding previously was unknown.
Quite possibly! 1979 is late for mark parity, though, at least from what I can tell from the equipment I have. By that time, things seem to have settled on even or space parity, or were even 8-bit clean. The Tek 4010, for on the other hand, defaults to mark parity and requires cutting a trace on the I/O board to change it, but that dates to 1972. Perhaps Germans either did not have Tek 4010s or cut the trace. The Teletype Model 35 (early to mid 1960s) defaults to even parity, but can produce either mark or space parity as a configuration option.
In Germany there were probably mainly or only devices used by the state regulated post Deutsche Bundespost. DBP. And the devices were produced by Siemens. I think up to the 90s.
The software of my device is from 1981. And that was indeed late for paper tapes and octal code. But that is because of the CMOS PDP-8 CPU.
Another possibility was the export to audio cassette. Maybe a custom method as well.
