80-Bus News |
March–April 1984 · Volume 3 · Issue 2 |
| Page 47 of 51 |
|---|
In general, there is a suprisingly small impact on performance in taking this approach. This can be seen by considering the usual practical overheads in displaying a line of text on the screen. To do this an application program loads a byte from memory into a register, updates and saves the pointer into the character string, and then calls the operating system to output that character. The operating system then determines where to send the character, (e.g. checking the IOBYTE in CP/M), and finally sends it on its way. A simple assumption that can be made in this scenario is that the IVC can put characters into the screen display at a maximum rate of one per displayed line, i.e. one every 64uS during the line blanking interval. (A remote-terminal would have to work at a line rate of 156k baud to match this!) This display rate of one byte per 64uS is likely to be of the order of the Host system’s overhead, if not a bit faster, and so the display rate is actually limited by something other than the internal display technique of the IVC. (Note that once the IVC has accepted the character for display the Host system is free to go off and collect the next character. Thus the IVC’s ‘average’ waiting time of 32uS to get that character into the display is not wasted time, as the Host is not held up by it.)
The one time that the display technique does have an impact on the performance of the IVC is in the scrolling rate. Don’t get me wrong – the IVC doesn’t scroll exceptionally slowly – it’s just that it could go faster! I did briefly experiment with using a hardware feature of the display controller that resulted in a scroll rate of over 1000 lines/sec but dropped it for various reasons:
| i) | It was far too fast and would require another escape sequence to let users define the scroll rate they wanted. |
| ii) | It complicated the monitor software in various places. |
| iii) | It made the implementation of the ‘non-scrolling’ lines more complicated, and if a significant number of lines were ‘locked’ on the screen the situation returned to the original problem. (Either ‘locked’ lines are left alone and the rest of the screen memory contents moved, or the main screen stays in place in the display memory and the “locked” lines have to be moved to the new display start address!) |
The IVC includes a port to which a keyboard can be attached. This makes sense as it effectively turns the IVC into a terminal which is then connected to the Host 80-BUS system. (The connection is via the 80-BUS backplane rather than a conventional RS232 link.) The IVC continually monitors the keyboard port and passes all characters from the keyboard to the Host via an internal 64-character buffer. Thus, whenever a key on the keyboard is pressed, the character is read and stored in the buffer from whence it is extracted when and if the Host system asks for it. Thus a fast typist can hammer away secure in the knowledge that nothing will be missed. In fact it is quite useful to be able to ‘type ahead’ with some programs, although this should be done with caution until you are sure that the program will accept it. (Some programs poll the keyboard often, and ‘swallow’ characters they don’t recognise. Others stop polling as soon as they receive a single character that is not immediately applicable, but they hold onto it for later.)
The point I’m trying to make is that once you are familiar with certain programs you can improve your throughput by typing in responses before the next prompt appears. For example you can speed up the time taken to load a Wordstar file and to get to a certain position within it. Having typed WS to
| Page 47 of 51 |
|---|