IBM mainframes are known for very unusual terminals. But IBM made many different things, including the IBM 3151 ASCII terminal, which uses a cartridge to emulate a VT220 terminal. [Norbert Keher] has one and explains in great detail how to connect it to a mainframe.
It had the 3151 personality cartridge for emulating multiple IBM and DEC terminals. However, the terminal would not start until he unplugged it. The old CRT was burned in with messages from an IBM 3745, which helped him work out some of the configuration.
If you’ve only used modern ASCII terminals, you might not realize that many terminals from IBM and other vendors used to use a block mode where the computer would dump a screen to the terminal. You could “edit” the screen (that is, fill in forms or enter lines). Then you’d send the whole screen back in one swoop. This is “block” mode, and some of the terminals the 3151 can emulate are character mode, and others are block mode, which explains its odd keyboard and commands.
[Norbert] gets the terminal running with a virtual mainframe, but along the way, he explains a lot about what’s going on. The video is about an hour long, but it is an hour well spent if you are interested in mainframe history.
Of course, you can always get the real deal to connect. If you don’t have your own virtual mainframe, you are missing out.
csmt shut, yes
Z NET,QUICK
Block mode – 3270 and 5250 especially remind me of web forms, just from the 1970s
This is what a computer made in the US in 2026 will look like
100% locally manufactured with locally sourced parts?
Not a chance. Not even a computer running on valves, using a teletype as I/O.
Maybe a Babbage machine or something like that…
The font reminds me GNU Unifont. I wonder if IBM terminals were an inspiration or if it’s just a coincidence.
There’s only so many ways to draw recognizable characters in 7×14 or 8×16 pixel blocks.
IBM’s block mode 327x terminals did not send or receive whole screens. You could address any character position on the screen and write only there. The screen content would be divided into protected and unprotected fields. The unprotected fields are where you can enter text and usually only the contents of modified unprotected fields are sent back to the host when you press any key that generate an attention, for example Enter or a PF key. You /can/ read and write whole screenfuls but not required and unnecessarily waste bandwidth. A full screen write would for example happen if the user pressed the Clear key and the screen content would need to be refreshed.
I worked on one of the remote terminal controllers for the midrange machines (system 38, AS400, etc.). The documentation claimed they could support something like four user terminals on a 2400 baud connections. So, yes, keeping the bandwidth to a minimum was essential.
Block mode did operate in a 1920 characters per message mode (80 characters x 24 lines) if there were actually a full 1920 characters to display which was rarely the case. The communications protocols (SNA/SDLC) stripped all repeating characters to optimize transmission. This was particularly important over telephone lines (dialup or dedicated). When forms were filled in, only the filled in form data was transmitted back, not the full screen to again optimize performance.
Good article