\chapter{Design and Implementation} \section{Introduction} To make {\rm oggin} more informative is the main purpose of the simulation. Only when more information is given in an effective way, can users understand more at the same time. Thus it makes the CAL tool effective and efficient. \\ \\ \noindent The CAL tool is what the topic of this report has disclosed. It is an interpreter interfaced with {\bf curses}. It first reads in a file of a sequence of octal constants, one per line and each of length six characters. The whole file would be saved in an array representing the main memory. Each time the user inputs a character, the program executes one instruction cycle and displays the results on the screen. The screen is the only output. It is crucial to make the best use of the limited screen size so that more information can be given to the user impressively. \section{Appearance of the Screen} The size of the screen generally in our department is 23 lines and 80 columns. It is allocated as figure 4.1 \newpage \dspaceoff \vspace*{60mm} \begin{verbatim} pc= instr= acc= sp= index= CNZV= pc<- 000000 000000 000000 000000 000000 0000 000000 INSTRUCTIONS : 0000000000000000 EXPLANATION : previous instruction current instruction OCTAL CODE : 000000 next instruction FUNCTION CODE : xxx OPCODE GROUP : group 0 ADDRESSING MODE : xxxxxxxxx MAIN MEMORY OPERAND : 0000 ACCESS LOCATION : 0000 0 000000 000000 000000 000000 4 000000 000000 000000 000000 block of five lines reserved 10 000000 000000 000000 000000 for displaying comments for 14 000000 000000 000000 000000 each instruction. 20 000000 000000 000000 000000 24 000000 000000 000000 000000 30 000000 000000 000000 000000 34 000000 000000 000000 000000 block of three lines for 40 000000 000000 000000 000000 displaying user instructions. 44 000000 000000 000000 000000 Fig 4.1 Screen layout \end{verbatim} \newpage \dspaceon \section{Description of the Output} At the top of the screen, there is a line of register names : ``pc= inst= acc= .......", the second line is the octal values corresponding to each register above, with the binary values of the psw bits. \\ \\ \noindent The sixteen digits following the word "INSTRUCTION :" is the binary code of the current instruction. Below the binary code are shown the previous instruction, the current instruction and the next instruction. The three instructions are in {\rm oggin} assembly language and the current one is highlighted. \\ \\ \noindent It would be beneficial for study to have the three instructions on screen. The current one is for checking the results; the previous one for comparing with the current one and the next one is for estimating the possible results. \\ \\ \noindent On the bottom left is displayed the memory. Numbers in the first column have one to four octal digits only. This is the location address of memory. The other four columns of six octal digits are the contents of the memory. The display always shows ten lines of four locations of memory. Location addresses will change when a different area of memory is displayed. Which area of memory will be displayed depends on which location is accessed during the instruction cycle. The ten lines displayed cover a range which includes the location accessed; and the accessed location is highlighted. \\ \\ \noindent At the right side are messages about the current instruction : the octal code of that instruction, which group, the addressing mode, the operand and the memory location accessed which can be used to check with contents of memory highlighted. \\ \\ \noindent Below that explanation part are lines of comments for the current instruction. It can display five lines to the maximum. Comments are helpful for understanding and learning in a faster way; so it is rewarding to design comments deliberately. For those instructions executing arithmetic or logical operations, comments will include the binary values of the old acc, the source and the operation results for the user to check or exercise the operation. \\ \\ \noindent The bottom right of the screen is a window of three lines, in which instructions for user are displayed and through which the program gets a character to continue its operation. \section{Implementation } \subsection{Program part} The tool is implemented by six files: \begin{itemize} \item glovar.h contains all global variables, including an array of integer representing the main memory; main components of the cpu and windows used for displaying output. \item newm.c contains a function for decoding and routines used to help with handling ALU functions and a main routine which holds the top algorithm to invoke and control the whole program run. \item newg1.c contains a function for further decoding function codes of group 1 and package of routines to execute each function code of group 1. \item newg2.c contains a function for further decoding function codes of group 2 and package of routines to execute each function code of group 2. \item newg3.c contains a function for further decoding function codes of group 3 and package of routines to execute each function code of group 4. \item newa.c contains a routine which acts as a controller for executing each instruction cycle, and all curses user interface, including a mapping function which was produced for displaying the part of memory required for the pad in the main memory window. \end{itemize} \subsection{Display part} The screen is divided into sixteen windows, one of which is used to display part of the memory. The screen is divided into sixteen windows rather than being used as one because this makes it easier to modify small areas of the screen without disturbing the rest. \\ \\ \noindent Originally, each window except those for registers was going to have a border around their contents. But thinking about the limited space of the screen, it was better not to since each part looks quite clearly separate from the others. Consequently, from the appearance of the screen, it cannot be recognized that the screen is divided into sixteen windows. \\ \\ \noindent The job of displaying output on screen is implemented by the screen handling package---Curses, supported by $<$curses.h$>$ in the C library. The tool used {\bf curses} instead of {\bf X windows}, the latest software, because the tool was designed to use a vt100 terminal connecting to a mainframe, while {\bf X windows} is more suited to workstation. \subsection{Curses} \subsubsection{Purpose of Curses} {\bf Curses} is a versatile cursor and screen control package that has many capabilities. It is designed to efficiently utilize terminal screen control and display capabilities, thus limiting its demand for computer CPU resources. It can create and move windows and subwindows, use display highlighting features, and support other terminal capabilities that enhance visual interaction with display terminal users. All interaction with a given terminal is tailored to the terminal type which is obtained from the environment variable TERM. \subsubsection{Output Data Structure} {\bf Curses} uses data structures called windows to collect display text, then transfers the data structures to the terminal display screen during execution of {\bf refresh} routines. Each window contains a two-dimensional data array for storing text and character highlighting attributes. Other data structures associated with the window contain the current cursor position and various pointers, and fill other {\bf curses} needs. \\ \\ \noindent Two windows are always present when curses is active. {\bf Current screen } is named curscr for programming purposes, and represents the current screen. It is used as a reference when optimizing output operations to the CRT screen. The {\bf standard screen} window, named stdscr, is the default destination for all text output operations that are not directed to a window specified in the function. Both curscr and stdscr have the same row and column dimensions as the physical display screen. \\ \\ \noindent Additional program-definable windows can be created and dimensioned as programming needs dictate. Such windows can be any size, provided they do not exceed the row and/or column capacity of the physical display screen. \\ \\ \noindent When a program requires a window that is larger than the available display screen, pads are used. Pads have the same structure and characteristics as a window, but they can be any size within the limits of reasonable memory usage (each pad requires two bytes per character position plus data structure overhead). So a mapping function is always required to display part of the pad on the screen. \subsubsection{How to Use Curses} Curses offers a vast amount of functions to create and manipulate the windows, accept input and proffer output, and is compatible with the C languages on input/output routines. \\ \\ \noindent All programs using {\bf Curses} should include the file {\it $<$curses.h$>$}, and the option {\bf -lcurses} must be used at compile time. \\ For example : \\ \hspace*{20mm} {\it cc $<$filename.c$>$ {\bf -lcurses }} \\ To use Curses within our program, we need to initialize Curses using : \\ {\bf initscr()} -- This will determine the terminal type and initialize Curses data structures. It will also arrange that the first call to {\it refresh()} will clear the screen. And when exiting the program, to restore the terminal to its normal self, we need : \\ {\bf endwin()} -- This function will restore tty modes, move the cursor to the lower left corner of the screen, reset the terminal into the proper nonvisual mode, and tear down all the appropriate data structures. >From here it is just a matter of including the necessary functions to create, manipulate and move windows on the screen. A small example of a simple Curses program is shown below : \newpage \begin{verbatim} # include main() { initscr(); move(LINES/2,COLS/2); printw("Hello World !"); refresh(); endwin(); } \end{verbatim} This simple program will clear the screen and print {\it Hello World !} at the middle of the screen. This is determined by the Curses variables LINES and COLS, which respectively hold the number of lines and width of the current screen in use. {\it printw(..)} is the Curses version of C's {\it printf(..)}, and {\it refresh()} clears and redraws the screen with any data since the last refresh, that is {\it Hello World !}. \section{Routines Used for the Implementation} There are many commands and functions in the Curses Package (as explained in the UNIX manual pages). But a few that are frequently used in the project are introduced here. \\ \\ {\bf newwin(num\_lines,num\_cols, beg\_row, beg\_col)} \\ \\ Create a new window with the given number of lines and columns. The upper left corner of the window is at line {\bf beg\_row},column {\bf beg\_col}. \\ \\ \begin{bf} doupdate() \\ wnoutrefresh(win) \\ \end{bf} These two functions allow multiple updates with more efficiency than {\it wrefresh}. To use them, it is important to understand how curses works. In addition to all the window structures, curses keeps two data structures representing the terminal screen : a physical screen, describing what is actually on the screen, and a virtual screen, describing what the programmer wants to have on the screen. The {\it wrefresh} function works by first copying the named window to the virtual screen {\it (wnoutrefresh)} and then calling the routine to update the screen {\it (doupdate)}. If the programmer wishes to output several windows at once, a series of calls to {\it wrefresh} will result in alternating calls to {\it wnoutrefresh} and {\it doupdate}, causing several bursts of output to the screen. By calling {\it wnoutrefresh} for each window, it is then possible to call {\it doupdate} once, resulting in only one burst of output, with probably fewer total characters transmitted. \\ \\ \begin{bf} refresh() \\ wrefresh(win) \\ \end{bf} This function must be called to get any output on the terminal, as other routines merely manipulate data structures. The {\it wrefresh} function copies the named window to the physical terminal screen, taking into account what is already there in order to do optimizations. The {\it refresh} function is the same,using {\it stdscr} as a default screen. \\ \\ \begin{bf} waddch() \\ wprintw() \\ mvwprintw(win,line,column,format,argument) \\ \end{bf} These functions correspond to {\it printf}. The characters which would be output by {\it printf} are instead output using {\it waddch} on the given window. \\ \\ {\bf wclear(win) } \\ This function arranges that the screen will be cleared on the next call to {\it refresh} for that window. \\ \\ {\bf wattron(win,attrs)} \\ This function turns on the named attributes without affecting any others. \\ \\ {\bf wattroff(win,attrs)} \\ This function turns off the named attributes without affecting any others. \\ \\ {\bf wstandout(win)} \\ The function turns on all attributes on the given window. \\ \\ {\bf wstandend(win)} \\ The function turns off all attributes on the given window. \\ \\ For a description of the other routines available, please see the UNIX manual pages. \section{Limitations of the Display Output} \subsection{Deviations of the Actual Results} The actual result is not exactly as was expected. It was expected that only those windows which needed updating were redrawn. But in reality, the whole screen was redrawn. Thus the changes were not as obvious and striking to the user as was expected. Alternating calls to {\it wnoutrefresh} and {\it doupdate}, causes several bursts of output to the screen. Consequently, the output will be in a mess due to the heavy burden of calling {\it wrefresh} frequently. To make the output neat and proper, the program calls {\it wnoutrefresh} for each window requiring updating first, and then calls the {\it doupdate} once to reduce the data transmission. The whole screen, however, will be redrawn for each instruction cycle. \subsection{Network Routing Constraints} The program cannot be displayed properly on those terminals which join to the {\rm forth} machine. But it works properly on workstations of {\rm forth} and on terminals connected to {\rm crown}. The problem might be due to the transmission procedure of the networks which are different for each end machine. The vt100 terminals connect through a PAD (Packet Assembler Disassembler) and the PAD characteristics are different on each network.