[Just some quick notes from memory - after all, describing several related terminal families spanning over several decades might be a bit broad :))]
That sounds similar to the IBM 3270, where the idea was to offload some of the work from the mainframe, so that instead of interrupting the mainframe on every keystroke, you only present it with a complete form. Was it the same idea?
Exactly. Same idea, similar workings. Although complete different hardware and even more different software structure. But essentially all features of 3270 style terminals were present. Even function encoding was quite similar. It may be safe to assume that control codes were defined with more than just one eye on the IBM spec.
What were the differences?
The main hardware difference would be that these terminals are compete self contained unit, so no need for a cluster controller, but there were multiplex controllers to operate up to 32 terminals over a single line.
What did the Siemens terminals have by way of resolution,
They were all text terminals.
The very first model of the 810 family was the 8150 showing 21 lines (20 + Status) of 54 characters each.
(8150 Picture taken from a 1969 Brochure)
Soon replaced by the 8160, able to do 25 lines (24 + Status) by 80 character. There were several different 816x models for different use cases.
(8160 Picture taken from a 1979 Brochure)
All were vector displays, that is, characters were not made up from a fixed pixel raster, but drawn as real lines, thus giving a quite great readability.
The fine line character set is shown a bit larger on this picture of an intermediate (prototype) model of 1976 already featuring 80 characters per line but still using a blueish-white phosphor
(Taken from a 1976 news show)
Hardware wise they were based on on what was called a micro programmed controller. No, not a microcontroller, but a set of several euro card sized boards with discrete TTL forming a processor, running a kind of an emulator, executing the display instructions as it's code.
Ca. 1980 a new family called 970 was introduced with the 9750 as base unit.
(9750 Picture taken from this Tweet)
Hardware support was exactly like for the 8160 (*1) Software wise it behaved exactly like a 8160, but now microprocessor based (8085) and using a dot matrix display. VDC was an Intel 8275 compatible (*2) operating handling a 9x14 character cell, so basic resolution was in the range of 720x350. Given, it was a real great display for using pixel clouds, still, not even close to its predecessor.
character set,
Basically 7 bit ASCII. Like anywhere else in the mainframe world (at the time) when it was about terminal or communication line I/O.
connection speed?
Depending on interface. For single terminal lines speeds between 4,800 and 64 kbit were available. Usually they were connected to a multiplex controller, as companies/departments rarely had just one terminal. Here a BAM interface was used. BAM was a proprietary standard (*3) operating at 288 kbit (*4) over standard 4 wire telephone wiring up to 4km in length.
Keep in mind this is early 1970s tech, at a time when 1200 would be a fast connection. 288 kBit is 240 times that :))
Further transmission speed depended on how the multiplex controller was connected to the mainframe (*5). A locally connected one (MSN *6) would interface to the CPU via Byte-Mux-Channel, which can do roughly 1 MByte/s, big enough to feed all 32 terminals at full speed.
Of course, remote lines weren't as fast, so MSF (*7) were available with interfaces from 4,800 to 19,200 for classic modem lines and 64 kbit on GDN lines (*8). Also available with dual interface, doubling the capacity by using a second line.
What languages were they programmed in?
Err, Cobol, Assembler? The terminals itself weren't programmed in sense of a programming language. They got their output message like any other terminal. A sequence of control/escape codes defining field and output properties intermixed with text to be displayed.
Going into detail would be quite out of scope here, but in general it works much like an ANSI terminal with
- Commands to position the output mark (aka cursor)
- Text to be outputted
- Attributes to mark up the Text
What differs is additional markup to define fields, like start and end of a field and it's attributes regarding handling, like
- User editable or not
- Cursor can be positioned into or not
- Can be marked (e.g. with a lightpen)
- Read in special data (like credit card numbers from a magnetic stripe reader)
The other addition are generic output and input commands, for example
- Output modes
- Output whole screen (complete redraw)
- Output only fields (the form would be kept and only fields defiend as such would receive the content)
- Other modifications
- Input Modes
- Send whole screen (anything visible gets send back)
- Send only editable fields (default mode)
- Send only modified fields (delta mode)
- Send only field with cursor in it
- Send only addresses of modified fields (great when using a lightpen to mark entries)
All of this is basically meant to reduce transmission data. On the output side clever compression logic using positioning commands and repeating characters and alike can dramatically reduce output. Even more if only data field but not the form has to be send on consecutive outputs - after all, users usually handle the same form many times in a row. Also text fields are usually left adjusted, so having a field definition allows to only send the new text as far as there is some and a 'clear to end of field' command
Input wise it's alike. With 'Only editable fields' only the form data gets returned, not the whole form, regardless if fields have been modified or not. Works almost like reading punch cards, doesn't it? :))
With 'Only Modified' the program has to keep an image of what has been send to regenerate the whole record, but since users usually modify only a few fields, this will save quite transmission time - which is a lot more than a faster CPU ever could.
And so on.
What computers did they connect to?
/370ish mainframes.
*1 - Early models still supported the 8160 device bus, so floppy stations, printer, OCR reader, magnetic stripe readers, etc. could be used as well. Later models dropped the connectors while still supporting the software side.
In my opinion the keyboard was the only real advantage here, and lucky for me, compatibility included the keyboard, so I got me a new 9750 keyboard (best keyboard EVER) to use it with my 8160 terminal. Nothing beats a vector screen.
*2 - Siemens did licence all Intel chips for its chip division (now Infineon), all the way up to the 386.
*3 - Kinda typical example of how proprietary standards always fail. It was great, and it could have had great impact due quite high speed (we're talking early 1970s and up to 4 km distance) and comparable simple hardware. But Siemens was quite keen on keeping it closed - including sueing anyone trying to build a compatible interface card.
*4 - Technically full duplex, but basic protocol echoed every byte for error detection. Then again it wasn't much of a limitation, since it's usually block transfer anyway.
*5 - It could also switch between terminals, so sending messages, or forwarding a print to another station or alike did run local at full speed.
*6 - MSN -> MehrfachSteuerung Nah literally multiple controller near
*7 - MSF -> MehrfachSteuerung Fern literally multiple controller far
*8 - GDN is kind of 50mA on steroids. It needs physical switched, non amplified phone lines. Good to connect even large installations remote at high speed (remember, that's early 1970s here). Just not exactly SOHO price range :))
