I received a question from a reader from which I realized that I wasn't clear enough in talking about the display and buffer side. This post is a quick amplification
The box under the CRT monitor is called the Logic Element. It has a 2000 character buffer inside which I call the regen buffer. The logic element is sweeping the CRT beam across the screen, left to right and stepping down after each sweep until it gets to the bottom of the screen. As the logic does this sweep, it advances the index into the regen buffer as it moves from each character cell to the next.
A character cell is a rectangular group of pixels where the pattern of the desired visible character is painted. My terminal has 80 character cells across a line and 25 lines stacked vertically. The user accessible and programmer accessible area is the first 24 lines, with the final line used for status feedback to the operator.
The logic element begins at the top left corner of the screen, in character cell line 1 column 1. It uses the value of the byte in that first regen buffer position to look up the pixel pattern from the character ROM. Technically, the CRT scans the top row of pixels for all eighty cells then returns to sweep the second row of pixels for all eighty cells and so forth until it finishes the bottom row of the character cell. At that time it moves from line 1 to line 2, the next set of rows comprising the character cells in line 2 and begins with the top row of pixels of that line.
The CRT is completing this sweep from top left corner to bottom right corner 60 times per second. The regen buffer is used to regenerate the pixels every 1/60 second as the phosphor fades rapidly.
The logic element has some register that keep track of state, including the cursor position, an index in the regen buffer and thus a character cell somewhere on the screen. When the CRT sweep is moving through the cell whose position matches the cursor position, extra pixels are painted to show the cursor shape.
A write from the control unit (CU) to the terminal will put the character(s) sent into the regen buffer starting at the current cursor position, then updating that position to just beyond the newly written characters.
One final task for the CRT sweep is to recognize attribute bytes as they are encountered in the regen buffer. They don't cause a visible character to be painted in the cell; it appears blank. However, if the attribute byte signifies an intense field, the brightness of the beam is increased while painting this character cell and all further cells until an attribute further down the buffer sets intensity back to normal.
The 3179 color terminal interprets the attribute byte slightly differently, showing the character cell in red, blue, green or white. Optional features add more colors but use a different attribute memory, not the regen buffer.
WHAT IS INSIDE THE CONTROL UNIT
The CU also has a 2000 character buffer. It should be a mirror of the regen buffer. All read and write operations between the mainframe and the CU occur into the buffer in the CU, but the 3174 then copies them to the regen buffer. The two buffers should always be in sync. The CU addresses its buffer as it needs but its timing is not connected to the CRT sweep going on and the active position in the regen buffer.
It is in the CU where keyboard and display are logically joined. The CU knows what cursor position is set in the terminal, thus it knows the field that is active at any moment. If the attributes of the field limit what can be entered to the field by the operator, it is the CU that enforces it. If a field is marked numeric, the keyboard is considered to be shifted up and the upper character of each keycap is intended when the key is pressed. The operator does not have to Up Shift in this case. If the field is marked protected, then no data can be entered into the field, which is enforced by the CU.
Movement keys are handled in the CU. For simple arrow functions it just updates the cursor position in both its and the terminal's regen buffer. If it is a TAB, the CU looks forward in the regen buffer from the current cursor position until it finds an attribute byte for a field that is unprotected. It sets the cursor position to the next cell after that attribute byte. This can move anywhere from 2 characters to almost 1920 characters depending on how far away the unprotected attribute byte is sitting.
The attribute byte of a field has a Modified bit, which is turned off when the field is received from the mainframe and is turned on if any characters are entered in the field due to operator keypresses. This allows the CU to send back only modified fields to the mainframe, disregarding those fields that were not changed.
Normal keypresses involve only the CU and the terminal, with characters changing on the screen and cursor movement taking place. However, a number of control keys are intended to be sent to the mainframe to indicate various operator choices. For example, the ENTER key causes the CU to respond to the mainframe with a message indicating ENTER was hit. Typically there will be an exchange between mainframe and CU at this point while the operator waits at the terminal.
Other keys can request program actions, keys such as PF3 or PA1. These presses cause the CU to respond to the mainframe with a message indicating which of those keys was struck. This may be the only interaction between CU and mainframe or the program may decide to write some new data into the CU (and regen) buffer.
A minor but important correction to your description: you say "The attribute byte of a field has a Modified bit, which is turned off when the field is received from the mainframe...". In fact, the Modified Data Tag (MDT) is set on or off by the data stream sent from the mainframe. If set, the data in the field is returned in response to a Read Modified command, even if the field hadn't been modified by the user.
ReplyDeleteThe MDT could be set even on a protected field. And when combined with the non-display attribute, this allowed a host program to write an invisible identifying tag to a screen, and get that identifying tag back in response to a Read Modified command, allowing the host program to (for example) correlate the input to a previous transaction.
That is great to know! Thank you Gene.
DeleteI guess it makes sense that the entire attribute byte is simply placed in the buffer by the datastream such that any bit set including MDT would be exactly as transmitted