ms-dos memory resident transputer graphics server

MS-DOS memory resident transputer graphics server

PC-hosted transputers running under the standard server program are limited to textual interaction. ]on Vaughan describes how in this

arrangement PC graphics capabilities can be added without costly additional hardware

The implementation of a PC-hosted transputer graphics server is described, which allows a program running on the transputer to produce displays using the graphics adapter card installed in most PCs. It was decided to avoid any changes to the standard transputer development system (TDS) server, and to use an additional server installed in the memory of the PC, which could be called upon when requested by the transputer. The protocols developed follow the pattern of the standard server protocols and their description provides an insight to the TDS harness, under which a transputer OCCAM program is executed.

microsystems personal computers transputers graphics

Typically, transputer systems run under the control of a host computer, usually an IBM PC or equivalent, under the Transputer Development System (TDS) software package. Unfortunately, the standard server program, that part of TDS which runs on the PC itself, is rather limiting providing only textual interaction with the user and not allowing any form of graphical display through the PC screen. To produce graphical output, the standard approach is to use a separate transputer graphics card, such as the Inmos BOO7, which includes a memory- mapped frame buffer and the hardware to drive a display device.

This paper describes an alternative approach called the Transputer Graphics Server (TGS) which utilizes the graphics capabilities of the host PC and involves no costly external hardware. The package interfaces neatly with the TDS environment and OCCAM programming model, and has been designed to avoid changing the server program which runs on the host PC by using a separate server resident in the PC memory, but called only when graphics are required.

The system has been implemented under the D7OOd

Department of Computer Science, University of Hull, Hull HU6 7RX, UK Paper received: 18 April 1989. Revised: 6 October 1989

release of TDS2 and tested on a number of BO04- compatible cards using a Victor VPCIII (IBM PC-AT compatible) as the host. The package has been used in a variety of graphics programs from simple three dimen- sional wireframe function plots to Mandelbrot set displays.

DESIGN CRITERIA

The complexity and resolution of images possible with a host-based system depend on the capabilities of the host's graphics adapter, which in turn influence the functionality built into the package. The likely applications for such graphics devices range from the drawing of graphs, diagrams and charts to the display of simple 3D images. Therefore the graphics primitives included were simple pixels, lines and polygons, with the option of changing colours, fill patterns and line styles.

To ensure complete compatibil ity with existing TDS- hosted programs, changes to the standard server were avoided as far as possible. The UK company Sension's version of the TDS server contains a small modification which allows an OCCAM program running on the transputer to instruct the host PC to perform a software interrupt, as described in Reference 1. This allowed a separate TGS to be used which could install itself into the PC memory as a terminate and stay resident program, and wait to be called via an interrupt from the TDS server.

Consideration was also given to the ways in which the graphics should be accessible from an OCCAM program. It was decided that the model should resemble the standard TDS model whereby the user communicates with the screen and keyboard through channels which follow set protocols, with a library of higher level functions implemented by means of procedure calls. Initially two extra channels were used, called 'to.graph' and 'from.graph' to communicate with the TGS, with a third channel called 'fast.graph' added later for more efficient transfer of large numbers of graphics instructions. A set of procedures (Table 1) in a graphics library completed the user model. Thus the TGS system was implemented in two parts

0141-9331/90/02083-06 © 1990 Butterworth & Co. (Publishers) Ltd

Vol 14 No 2 March 1990 83

Table 1. Graphics library procedures

Procedure Function

clear.screen draw.ellipse draw.poly draw.to

fast.flush

fill.style

finish.harness

get.aspect get.current

get.image

get.max

get.pixel

gharness init.graph image.size

line.style

move.to pie.slice

plot.point put.image

set.colour stop.graph

write.full.string etc

Clears the graphics screen Draws an ellipse or circle Draws and possibly fills a polygon Draws a line from current point to

specified coordinates Sends all the commands buffered

in the fast.graph channel Sets the current fill pattern and

colour Used to terminate the graphics

harness process, gharness Returns the screen aspect ratio Returns the current point

coordinates and current line colour

Reads a specified block from the screen

Returns the maximum screen coordinates and colour value

Returns the colour of the specified pixel

The graphics harness process Initializes the graphics system Used with read.image - - returns

the size of the specified block Sets the current line drawing

pattern and width Changes the current point Used to fill segments and whole

circles Plots a single point Places a block read with get.image

at a specified position Sets the current line drawing colour Stops the graphics and returns the

screen back to text mode Used to write text and numbers

to the graphics display

• The TGS running on the host PC, called by software interrupts generated from the normal (Sension) TDS server

• an OCCAM harness process running on the transputer, through which the user's program communicates with the PC. The harness provides the required channel- based user model, with an OCCAM library providing the higher level graphics functions.

THE HARNESS

Overview of the harness operation

The purpose of the harness is to provide a friendly OCCAM interface between the user's process and the graphics server. The harness must sit under the standard TDS harness and communicate through it by adding dummy tokens to messages to make them appear to have come from the standard keyboard and screen channels. Conversion between the various message formats and

multiplexing is performed by tile variou,~ i ) t (~ , , (1 running in parallel within the harness. The ~.~.{, r:,,~y communicate with the graphics server hy ~,{'r~{li11~, messages down either of the channels l,'>!ll~H~ :~ fast.graph. The harness generates the software interrupl lo run the graphics server and then passes these messages m a set format to it through the TDS harness and onto the hardware link, where it is read by the graphics ~erw, r program running on the PC. Responses are read back through the harness and passed to the user through the from.graph channel. The TGS harness also provides the standard screen and keyboard channels as for a c~n- ventional TDS EXEcutable program.

The implementation of the harness is complicated by the fact that any EXE communicates with the host PC server through a single link (Figure 1). Down this link the TDS must multiplex all the channels that the TDS provides, such as the screen, keyboard and filer channels. This is done by a TDS harness which must think that the messages passing through it are normal messages for the standard TDS sewer, and not for the graphics serverwhich uses a different protocol. The standard TDS server protocols are defined in the TDS reference guide 2.

Harness to graphics server protocol

The TGS harness routines must also communicate through the screen and keyboard channels, and so must follow the same protocols as the TDS. In reality, the user's process (a compiled OCCAM PROCedure) is executed in parallel with the TGS harness process which itself is run below the TDS harness which normally provides the protocol conversion when talking to the TDS server, as shown in Figure 2. The harnesses provide both protocol conversion and the multiplexers and demultiplexers for the various channels, as well as a certain amount of checking to ensure that the messages passing through are legal. All communications to the TGS are passed through the TDS harness as if they were messages destined for the standard server. Packets sent from the TGS harness to the PC are sent as strings, i.e. the token tt.out.string followed by the string length, followed by the message. Since the TDS harness will only accept strings of up to 256 byte, longer messages are broken up into a number of 256 byte strings, terminated by a short string.

Before any messages may be sent to the PC-resident graphics server it is necessary to instruct the standard server to perform the appropriate software interrupt. This is done by sending the token tt.out.int to the screen channel, followed by the interrupt vector number shifted left by 8 bit. The Sension version of the TDS server receives this and because it is out of range for display executes the appropriate interrupt. The TGS harness can now send messages to perform the graphics as a sequence of strings as described above. The TDS harness receives these strings and multiplexes them down the hardware link to the PC as a screen channel message by prefixing the correct channel identification token for the screen on to the message, which is read from the port to which the transputer link adapter is connected, by the now active graphics server.

All information sent back from the PC takes the form of integers, prefixed by the correct keyboard channel identification token in order to fool the TDS harness that the message has arrived from the keyboard.

84 Microprocessors and Microsystems

PC Host Transputer

Figure 1. TDS process model

to.link from.link PAR gharness(keyboard, screen, new.keyboard, new.screen,

to.graph, from.graph, fast.graph, stop.ch) SEQ

... user process code here finish.harness(new.keyboard, new.screen, stop.ch)

The user process is presented with three extra channels, two out to the TGS server called to.graph and fast.graph and one back from it for responses called from.graph. These channels are passed to the library routines which perform the graphics operations. A set protocol is

to.server from.server

Occam EXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TDS runnlng on Transputer

.........................................................................

Figure 2. The harnesses

Harness processes

The TGS harness procedure is run in parallel with the users' code within a normal OCCAM EXE and consists of five processes, running in parallel under an OCCAM PAR statement. Figure 3 shows a process diagram for the harness. It is used in an EXE as follows. Figure 3. Process diagram for the TGS harness


followed down these channels which is understood by the library routines and the TGS program. The processes graphics.output and fast.output receive the messages sent to them down the channels to.graph and fast.graph respectively and package them into a byte array, suitable for sending to the output multiplexer, mux.out. This process uses the OCCAM ACT construct to wait for an input on either of the graphics channels orthe screen channel. If the message is for the TGS program then the TDS server is sent the instruction to perform the software interrupt, the message is broken up into segments and each segment has the tokens which the TDS harness expects prefixed onto it before being sent. Any message from the screen channel is sent unaltered for the TDS server to deal with.

The input multiplexer process, mux.in, has a simpler task to perform. It receives messages from the PC via the TDS harness and must determine whether it was for the normal keyboard channel or a response from the TGS. If from the graphics server, the message is read in as a sequence of integer values and packed into a byte array for passing on to the graphics.response process. This determines if the message was an instruction to stop the harness (as a response to the stop.graph command) or a genuine response to be passed on to the user down from.graph. Appropriate action is taken in each case.

fast.graph and to.graph channels

There are two channels which are used for sending messages to the graphics server, to.graph and fast.graph. All commands sent to the to.graph channel are passed on immediately to the graphics server, unlike those sent to fast.graph. These are packaged up in the process fast.output until the command fast.flush is sent, when the entire package is sent to the PC. The intention is to reduce the overheads of repeated interrupts on the host by sending many messages separately, especially when drawing some complex object which involves many line segments and points. Commands which use fast.graph may not receive responses from the server as this would lead to deadlock in the library routines.

TGS harness protocols

These protocols define the format of messages which are sent between the various routines in the graphics library and the TGS harness. Messages sent from the graphics server running on the PC to the harness are of two possible types, depending on the value of the first byte. First, that the TGS program has performed the stop.graph command and is an instruction to stop the input demultiplexer within the harness, in which case the rest of the message is ignored. Second, that the remainder of the message should be passed on to the user PROC down the channel fromgraph.

The protocols to the TGS program are more complex. Each command is identified by a 1 byte token. This is followed by a sequence of bytes which depend on the command and specify the parameters for the action required. Some commands, such as init.graph, do not send any values to the PC, whereas others such as put.image may send large amounts of data,

With commands sent to the channel to.graph, the message sent to the PC will contain only the one

command and its parameters. Commands which us~ ~ d~, fast.graph channel are stored in the message as received, following exactly the same format as if sent to the to.Or a!~ channel in sequence. The first byte of the message i~ given the token tg.fast.graph and only upon receiving the, token tg.sendfast as the next command is the entire message sent.

THE GRAPHICS SERVER

The graphics server installs itself on the host PC and then halts, staying resident in the PC memory. It may then be called by means of a software interrupt, whereupon it reads messages from the transputer hardware link. The messages are interpreted to perform some graphics output, or a response to the instruction is generated and returned to the transputer.

Self installation

When executed from MS-DOS the graphics server must install itself as a memory resident program on the PC host. It is also necessary to set up the vectored interrupt table so that the appropriate software interrupt will resume execution of the program. All these operations are performed using standard function calls into the MS-DOS operating system.

So that the graphics server can return control to the standard server upon completion, it is necessary to restore all the processor's internal registers before the return from interrupt instruction is performed. Thus, on entry the program must push all registers to the stack, in order that they may be pulled off again when the graphics server finishes operating on the current message. On initial execution it must also set up an entry to itself in the interrupt vector table, so that when the standard server performs the appropriate 8086 INT instruction, the code to operate on the graphics message sent by the transputer will be called.

Once these operations have been performed the TGS program must utilize the terminate and stay resident feature of MS-DOS in order to leave itself in memory. This is achieved by doing a software interrupt INT21 h with the AH register set to the value 31 h, as described in Reference 3. The choice of the language TURBO-C in which to write the server ensured that all these low-level functions could be easily performed using standard library routines, avoiding the need to resort to assembly language.

Communicating with the transputer

The graphics server receives messages from the transputer as a series of bytes, read from the hardware I/O port on to which the transputer link adapter is mapped. The link adapter chip converts between the parallel port and the serial Inmos link, and is mapped onto the PC ports as follows:

Function Port address

link in data base__address link out data base__address ~ 01 h link in status base address+O2h link out status base._address 4- 03h


The value of base_address may be entered as a third command line parameter when the TGS is installed into the PC memory, or else a default value is assumed.

The purpose of the link status ports is to ensure that the appropriate link is ready to be read from/written to; the least significant bit of the status port goes to I when the link is ready for use. Code was written to read a single byte from and write a single byte to the transputer using these ports. It is necessary to remove all the tokens added to a message by the harnesses before it may be interpreted and also to combine all the message segments (created because the total message length exceeded 256 byte) back into one array.

Messages back to the transputer are sent as integers according to the harness-graphics server protocol. The server must send each integer value as a sequence of 4 byte, and also send the dummy integers needed to fool the TDS harness into thinking that the message came from the TDS server. Again functions were written to send a complete message using the protocols described earlier.

Interpreting the messages

Messages which have been sent through the to.graph route will consist of a single command and its parameters. Once the dummy bytes have been removed the command token will occupy the first byte of the message and can be used in a switch statement for selection of the necessary actions. The length of the message is also known and may be used to determine the number or size of the command's parameters, for example the number of points for the draw.poly instruction.

The routines which perform the appropriate graphics instructions obtain any parameters necessary from the message and call the TURBO-C graphics library. If the command involves a response then this is formed into a byte array and sent back to the transputer using the method described above.

Those commands which have arrived via the fast.graph will be packaged into one large message. A special command token, tg.fast.graph causes the switch statement to branch to the function which deals with fast channel commands. These are interpreted by looping through the message, moving a pointer to the start of the next command after the current one is dealt with. A switch statement is used to call the appropriate library function in order to perform the graphics operation.

Graphics mode selection

There are currently many different graphics adapter cards available for a PC or compatible and therefore the graphics server was written to be able to operate with most of the commonly used ones. TURBO-C provides the facility for automatically detecting the graphics adapter in use and can also select the best (highest resolution) mode available. If the program is executed with no parameters then automatic mode selection occurs and the program will select the best mode it can (if any) for graphics. The user is notified of the choice made.

It is also possible to supply one or two parameters to the program which will select an adapter and possibly a mode for use. For example, some adapters such as the EGA card may be used as a CGA card by running the TGS

program with the first parameter value of 1. There are five possible modes available within a CGA card, each with a different colour palette which may be selected using the second parameter. Similarly, other cards allow many modes, providing different resolutions and number of colours. Confirmation of the mode chosen is echoed back to the user once the server has installed itself in the memory, and is also available to the user's OCCAM program using the get.max graphics procedure call.

OCCAM GRAPHICS LIBRARY

The graphics library consists of 22 procedures, as listed in Table 1, which have been linked together into a library using the OCCAM program development utilities. The purpose of the library is to allow the programmer to use a simple procedure call with parameters to specify the graphics operation required, avoiding the need to remember the exact protocols used on the graphics channels. It also fits in with the keyboard and screen channel models and the use of library procedure calls for functions such as read an integer or write a hexadecimal number. With each function in the graphics library it is necessary to specify any channels used (i.e. to.graph or fast.graph, and from.graph if a response is needed) in the list of parameters. For example, to plot a point at the coordinate (100, 100) we would use the procedure call

plot.point (to.graph, 100, 100)

The call to enquire of the graphics server the maximum values for the x and y coordinates, the maximum colour value and the graphics driver number would be

get.max (to.graph, from.graph, max.x, max.y, max.col, driver.hum)

All the library routines are detailed fully in Reference 4, but as an example consider the routine get.image. The purpose of this routine is to read from the screen memory a sequence of values which correspond to the contents of screen memory in the area defined by the parameters. The image format is dependent upon the graphics driver and mode selected, and in some cases follows a non- trivial pattern making it hard to decode. However, the image read is useful as the procedure put.image may be used to replace the image back on the screen at some other position. The specification of this library procedure is

PROC get.image(CHAN OF ANYto.graph, from.graph, VAL INT x.left, y.top, x.right, y.bottom, INT size, []BYTE image)

Th~ifirst two parameters are of type CHAN OF ANY, i.e. they are channels through which any value may pass, and are used to communicate with the harness. The next four parameters are integers specified for passing by value. This allows the actual parameters in the procedure call to be constant values or variables, which is useful as the four values specify the rectangular box on the screen from which the image is to be read. The next parameter is not specified to be passed by value, and so pass by reference will be used, allowing the procedure to pass a value back. This value is the size in bytes of the image which is read from the screen in the area specified. The image itself is returned in the BYTE array image.


The procedure operates as follows. First it sends the appropriate command token, tg.get.image to the harness followed by the four coordinate values specifying the image position. The harness receives these values, packages them with more tokens and message lengths etc., and passes them to the graphics server. Meanwhile the procedure is waiting on an input from the channel from.graph, allowing any other parallel processes to proceed.

After a short time the graphics server will read the image in byte format from the screen and have sent it back to the harness. From here it is returned back down from.graph, again in the format defined by the protocol, i.e. the size of the image (in bytes) sent as a 32-bit integer, followed by the image itself sent as an array slice of the size specified. The procedure reads these values from the channel from.graph and then exits, returning the values in its parameters.

All the other procedures operate in a similar manner. They convert their parameters to the form expected by the harness and send them in the correct order. If a response is expected then the procedure waits for an input from the harness and returns it in the appropriate parameters.

FUTURE WORK

As it stands the TGS system described in this paper is a useful tool which has found many applications within the university department, particularly for student projects where graphics are required but insufficient transputer graphics cards are available. However, in many cases it is not desirable to use OCCAM and the TDS environment on the transputer, and languages such as c or FORTRAN may be required. These languages communicate with the PC through a different server, the 'alien' file server, which uses a different protocol to the TDS server. A rewrite of the graphics server to use the alien file server protocols, and translation of the graphics library to another language would provide a graphics capability for these languages. In this case the harness functions may need to be replaced with separate library function calls since not all alien languages allow parallel constructs.

Work is in progress to implement the graphics server on the newer Inmos B008 and Sension Parallax Interface cards, which support DMA '~etween the transputer link adapter and the PC memory. This would allow the fast.graph channel and the get.image and put.image procedures to operate as fast as the transputer is able to get/send the data, thus increasing the overall speed and usefulness of the package.

Other enhancements being considered include a method of removing the TGS from the PC memory without rebooting MS-DOS and reducing the large memory requirements of the server, in order to allow other memory-resident routines and disc caches to be used at the same time.

CONCLUSIONS

This report has outlined an inexpensive alternative ~, transputer graphics cards for the display of simple irnage~, graphs and diagrams, utilizing the graphi(s facilitie~ already available in the host PC. The method follows closely the existing TDS model of communication with the host whilst avoiding the need to rewrite the standard TDS server program. A library of graphics procedures allow the programmer to easily produce and manipulate an image whilst hiding the complex underlying protocols.

It should be noted that using a PC-based display adapter through a graphics server, could never match the speed of directly-mapped transputer frame buffers, due to the communication overheads and the slower processor used in the PC. Applications such as realtime animation will never be possible with the TGS package, although the development and use of the algorithms may still be performed and assessed, before the investment in a dedicated transputer graphics card is made. In a teaching environment, it allows every student to experi- ment with parallel graphics algorithms instead of sharing a B007 graphics card. The implementation shows that communication between the transputer and a memory- resident host program is possible and useful.

REFERENCES

1 Access to PC-DOS~MS-DOS Host Machine Facilities Sension Ltd., Northwich, UK (January 1987)

2 Inmos Ltd. Transputer Development System Prentice Hall, Hemel Hempstead, UK (1988)

3 Duncan, R Advanced MS-DOS MicroSoft Press (1986) 4 Vaughan, I TGS User's Guide Dept. of Computer

Science, University of Hull, UK (1988)

BIBLIOGRAPHY

Inmos Lid OCCAM2 Reference Manual Prentice Hall, Hemel Hempstead, UK (1987) Hoare, C A R 'Communicating sequential processes' Comm. ACM Vo121 No 8 (August 1978) pp 666-676; also Hoare, C A R Communicating Sequential Processes Prentice Hall International (1985) IMS 7-800 transputer, preliminary data Inmos Ltd., Bristol, UK (April 1987)

After graduating with a BSc in computer science from the University of Hull in 1987, Ionathan Vaughan has remained within the Department of Computer Science in Hull, researching parallel architectures and microprocessor systems. His current research interests include transputer-based realtime image synthesis and parallel graphics algorithms.


ms-dos memory resident transputer graphics server

Documents