Why is the CPU Involved During Keyboard Echo?

Question

I'm currently studying for a computer science exam, and I've come across a concept that has me somewhat stumped.

When one types a key on the keyboard, an ASCII character is transmitted to the CPU. Upon reception of this character, the CPU outputs the same character to the screen. This process is called echoing. Instead of having the CPU involved, why don’t we simply have this echoing process done within the keyboard/screen unit so that the CPU is free to do other useful work?

Now, intuitively, I feel like this is because there is no defined keyboard/screen unit, and the CPU is the device which is responsible for communicating between the screen and the keyboard, through the interconnection network. However, I feel like the fact that a keyboard/screen unit is mentioned may mean I'm missing an important concept. Is this the case? Why do we involve the CPU in the echo process?

Answer 1

Letting the computer see each character as it is typed allows programmers to make the user interface more dynamic.

Back when a serious computer was the size of several upright refrigerators and computers operated on user input a line at a time, terminal input was handled as you described. You typed a line of text on a terminal which displayed it locally (often on paper). Only when you pressed the ENTER or RETURN key was the text sent to the mainframe or minicomputer to be processed.

But even back then, the advantage of letting the computer see the user input early was realized by the engineers of the time. Command completion, where you type the first few letters of a command and the computer fills in the rest, was invented in the mid 1960's. This feature was copied and improved through the years to where it stands today, available in all modern UNIX shells and under Windows as well.

Allowing the CPU to see each character as it is typed also allows shells to offer command line editing and history features well beyond what a dumb terminal could provide. A key can allow you to step back through a list of commands you've previously typed, choose one, and then edit it slightly before pressing RETURN to have it executed. Text can be cut and pasted between command lines, possible because the CPU has access to previous commands while the terminal does not. Filenames as well as commands can be completed based on partial input, again possible because the CPU has access to the names of files in the filesystem and the terminal does not.

Answer 2

Letting the computer see each character as it is typed is NOT NECESSARILY NEEDED to make the user interface more dynamic.

Old ASCII terminals came usually as one keyboard+screen package, or keyboard+printing head (called then often a teletype). So local echoing was possible. Input was sent as whole lines, and that is what the enter key was for (it was also called carriage-return). This was convenient when your terminal was connected through slow telephone lines to a distant computer. I still have a 300 bauds modem I used then, which is a bit less than 300 bits/second. And that was not the slowest I used. You did not want to wait for the echo.

Kyles Jones gave you a few good reasons to have the echo controled by the computer. Such as history and command line editing. But even these reasons could be overcome with local echoing. My old ascii screen terminal (bought in 1980 and which I no longer dare connect to an outlet as the capacitors must be in a sorry state) had (still has) about 12 screens (a screen is 24 lines of 80 characters) worth of history, and local editing facilities: the terminal had its own local CPU ... I am not sure that is what you had in mind. This is all from memory, so I hope it is close to truth, but searching for the manual would take me some time.

So, basically I had a user-interface computer connected to another computer. Actually, there always will be some hardware to handle the echoing, so your question is more whether it is appropriate to have sophisticated hardware to do that with a CPU or with simpler hardware (not able to do sophisticated work). The builders of my terminal thought it was appropriate, and made it a sophisticated terminal, with the dumb communication protocol with the computer that was then standard.

I first thought of saying that a good reason to go through the CPU would be that applications now use windows with all kinds of features and differents fonts, and that that requires the power of the computer to get the appropriate flexibility, that a simple screen-keyboard cannot offer.

But I recalled in time (memory is hard to recollect) that this is false. In the early 1980, people were developing bitmap graphics (that was the name for the kind of screen you are now using, though it was CRT rathed than LCD). Some of the work followed the traditional terminal view, making very sophisticated graphic terminals with multiple windoes and fonts, etc. One of these was the BLIT, that was the subject of many experiments, such as Cardelli's infamous crabs.

That does not necessarily mean that the CPU running the application did not see the characters. But it did not have to. The terminal was powerful enough to do very complex work on its own.

Computer architecture has been testing many solutions, especially as faster networks became available. You are concerned with the terminal, but at some points, it was the disk that was an issue (mostly price, I think, and also management). So we had for a time diskless work-station (i.e. personal computers). They would include CPU, screen, keyboard and RAM, but no disk. Disk space was on the network, and you just requested file space from the network. Even virtual memory swapping was done through the network.

So the conslusion is: sophisticated interface (for example), using windows, various fonts, programmable keys, command-line editing, synchronisation between input and output, and what not, does require some real processing power. Even with very weak capabilities, some hardware is needed. Then this computing power may be attached to the computer and its CPU, or may be independent from it and connected more or less remotely. The same may be true of other resources.

But everything is very relative.

Last remark. The first alphanumeric screen terminal I ever used was a Tektronix in 1974, that came with its keyboard. The screen and the keyboard were so tightly connected, that we had to pay someone to modify it by changing the circuitry with a soldering iron so that it would behave as needed. But I should stop my endless stream of stories.

Answer 3

How could the CPU not be involved? How would the computer know whether to print anything at all to the screen without the CPU being involved? How would it know where to print the character? How would it know what font to use? How would it know how to render that font?