Embedded systems are a hot topic in high performance/cost sensitive applications in the design community today. Many of the applications performance are not realized by the user, but they are very necessary. Certainly, as designers, the tools we use come to our most immediate mind set. On that note, we used to be connected to hosts through dumb terminals that had very little capability. The inexpensive ones had no ability for direct curser addresses, character attributes, multiple line sizes, and other features that all of us now take for granted.
The next step added those features, but all of us time shared one system. Today, the power of hosts can now be divided through the advent of the X Terminal.
“X” allows a single user to be connected to a network and use any host on that network that suite that application. The user can open a window, or a section of the display, assign it to a particular host, and posts jobs to that host, where other windows can each have its own job ongoing. One X Terminal has greatly expanded the amount of work an engineer can easily perlorm based on this sharing concept. Additionally, consider this advantage while debugging a system. In one window, the source code of the input fIle, another window can
be the development system, in another, the logic analyzer, and so on. The existing tool set is greatly enhanced because X brings many tools to one display.
This paper is targeted at explaining the development of an X terminal. The details will include the CPU architecture, development tools to debug code and the hardware, the actual debug process, and many of the pitfalls that can occur during the development of the system. Also, we will explain in more detail the actual workings of “X” in a working environment.That will include how “X” posts events, handles window mapping and redrawing, keyboard interrupts, mouse interrupts, and the network.