SCOPE OF EFFORT
I own several 3179 terminals and have potential uses for them, but I don't have the control unit that drives and supports them, thus have no way to connect to them. Three possible uses are:
- I own a P/390 system, which is an IBM PC with a special board that implements the S/390 (and earlier 360 and 370) instruction sets and functionality. It comes with support software running under OS/2 that configures and controls the entire system. With it, I can boot up systems such as MVS or VM that work well with 3179 terminals attached.
Barring the real terminals, I have to open windows on OS/2 to run 3270 emulator sessions, which is just not as satisfying. - Eventually a team of us will recreate an entire 360/50 system. A 3270 terminal is a bit of an anachronism for this mainframe, but I think with a bit of work we can back port support to OS/MFT or DOS operating systems. We will be creating bus & tag channels for the recreated 360/50 and thus if I can create a control unit it could be attached.
- A mainframe emulator called Hercules can run on a PC and also give me an MVS or VM system, but has the same dependence on 3270 emulator windows on the PC rather than using a real glass screen.
Andrew Kay has recently attacked this problem and developed a control unit to drive his 3278 (monochrome) terminal for attachment to Hercules. He has made the code and hardware open source, sharing it with the community.
I am building the interface hardware using his design and PCB layout. This is a shield that mounts atop an Arduino Mega 2560. The shield hosts a coax connector allowing a cable to be connected between the shield and the controller box on a real 3270 type terminal. A USB cable serial stream connects the Arduino to a host system of some type where Python code provided by Alexander will implement the control unit functionality.
His code makes a TCP/IP connection from his Python code to a TCP socket in Hercules, thus allowing use of his 3278 for software running in an emulated mainframe on Hercules. While this is sufficient for my purpose number 3 above, it may or may not work properly with the color support of the 3179 since he has not tested it with a color terminal.
To implement my first two purposes from above, I will be modifying the controller. Eventually I would migrate this into an FPGA based hardware device since I will be implementing a bus and tag channel in that hardware to hook to the recreated 360 system.
I am not yet sure how I will hook into the P/390 system. Some research is required to design the right approach.
These were a part of the IBM 3270 family of CRT terminals first released with S/360 in the late 1960s and used with mainframes for decades after. The 3179 is a newer version of the 3279 which first brought color to this family; the original 3270 line were monochrome green screens.
The terminal itself consists of a monitor, keyboard and controller box. Their is relatively little intelligence in the terminal itself, with an external control unit such as 3274 or 3174 providing the majority of the functionality. One control unit would handle multiple terminals typically, as an example 16 3179 terminals might be connected to one control unit. The connection between terminal and control unit is a 93 ohm coaxial cable.
The control unit itself is connected to the mainframe by one of several methods ranging from local attachment to a bus & tag channel through various telecommunications link types. The programmer communicates with a terminal by sending streams of commands, orders and data to the control unit.
Inside the terminal's controller there is essentially just a large buffer with one location for every character position on the screen. A typical 3179 would have 24 lines of 80 characters plus a 25th bottom line that indicated the status of the terminal. Thus the controller would have a buffer with 2000 locations which was continually drawn on the screen as the terlable for update. Some presses would send a special code instead, for example a Program Function button.
The terminal controller waits for the control unit to send it a query, for example polling it to see if any key was pressed. The terminal can't signal the control unit or mainframe on its own, it has to wait as a slave device. If a key was pressed, the terminal controller sends codes to identify which key was pressed, as well as status and other information.
The control unit can ask the controller to send part or all of its buffer, which is used to satisfy the commands and orders coming from the programmer. If the terminal user has typed in data at various locations on the screen and then hit the ENTER key, the response showing the ENTER key is followed by the control unit reading any modified part of the buffer; these are the fields where the user typed in content.
Writing to the terminal is done by sending updates to the buffer from the control unit to the terminal controller, after which the new data and formatting is visible on the screen.
So are you putting together a real mainframe or an emulator. 360/50 was good size at the time.
ReplyDeleteMarc Verdiell owns a 360/50 front panel, a 3803 tape control unit, some 3420 drives, and a plug compatible printer.
ReplyDeleteWe have access to the ALDs (in Switzerland) thanks to Lawrence Wilkinson, although the current pandemic has delayed us getting them scanned.
Therefore we intend to build a gate accurate, timing accurate recreation of the entire 360/50 using FPGA. Essentially everything from the rear of the panel to the bus and tag connectors.
This will allow us to use the full panel, step through code and microcode, and run the machine as if it were physically present.
We will restore a 1053 console printer and use an 026 keypunch keyboard to make a physical recreation of the operator console.
We do have some anachronisms to deal with. The 360 operating systems knew 2803 control units, 2420 tape drives and printers of the era, not 3803, 3420, and the 3211 printer. Probably means some back porting of code to handle differences, but all of the OS was available in source code so imminently achievable.
Marc also has access to a 2501 card reader, which is historically accurate. That and the console are the devices that don't need OS mods.
ReplyDelete