5

An answer to a recent question https://retrocomputing.stackexchange.com/a/22332/4274 referred to the Siemens 8160 and 9750 terminals, which struck me as interesting enough to ask about separately in more depth.

The 8162 is a block mode terminal, there is no real 'free form'. These terminals (the whole 8160 and 9750 line) handle forms essentially in hardware - much like a webbrowser does so for HTML forms - except, it's of course not graphics, but character orientated.

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? What were the differences? What did the Siemens terminals have by way of resolution, character set, connection speed? What languages were they programmed in? What computers did they connect to?

I have tried a Google search, but there is curiously little information available on these machines. About the best I have found so far is this, which does little more than confirm that such things existed: https://documentation.softwareag.com/natural/nat426mf2/ops_mf/bs2k_term.htm#_975n_series

1 Answer 1

12

[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.

Siemens 8150 Terminal

(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.

Siemens 8160 Terminal

(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

enter image description here

(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.

enter image description here

(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 :))

23
  • 1
    What sort of display controller system could render a 64x21 vector text screen for real-time editing? If a font used ten vectors per character, rendering such a screen at 30fps would require drawing 403,200 vectors/second, which would seem impractically high.
    – supercat
    Nov 19, 2021 at 21:39
  • 5
    10 vectors per character would be a rather high average plus screens fill rarely more than half of all positions. More relevant, why should it do 30 fps at all? Text display isn't exactly a video game. Selecting an appropriate phosphorescent screen may lower refresh rate quite a lot. Last, but not least, what's so hard in drawing 400k vectors per second? It doesn't need much memory access (max 4 k per refresh). translate them in a (ROM based) sequence of relative coordinates, turned into voltage levels to be added/subtracted to the beam position and forwarded to the deflecting amplifiers.
    – Raffzahn
    Nov 19, 2021 at 22:28
  • 2
    @supercat Even more so, the follow up 8160 did the same for 80x25 :)) Serious, it isn't a big deal to find a redraw rate fitting a text display low enough for a stable display but high enough to work with usual type rates and or new screen content. And all of that isn't even less an issue by using dedicated controllers and the right amount of analogue components :)) Keep in mins, it's a development independent of today's of the shelf components.
    – Raffzahn
    Nov 19, 2021 at 22:33
  • 1
    I would expect a text display terminal to be able to show a flicker-free image even when the screen is filled with eights, and I wouldn't regard a vector-drawn eight as superior to even a 5x7 dot matrix one if it had fewer than ten vectors. As for the difficulty with outputting that many vectors per second, video deflection coils don't behave as perfectly linear devices; unless one re-homes the beam between characters, I don't see how one would avoid having changes to a character displayed early in a line cause subtle shifts in characters drawn later, and if one does re-home the beam...
    – supercat
    Nov 19, 2021 at 22:56
  • 1
    ...moving the beam quickly to all the places it would need to go would require higher deflection voltages than would be needed for a conventional raster scan display. Maybe there would be ways of getting around that, but I would think that for trying to achieve any particular quality of text display, a raster scan would be easier.
    – supercat
    Nov 19, 2021 at 22:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .