80-Bus News |
March–April 1984 · Volume 3 · Issue 2 |
| Page 44 of 51 |
|---|
ports. This now gives you parallel processing. The main CPU can pass a character over to the slave CPU saying “deal with this please”, and can then get on immediately with its job of running your program.
I have recently heard of a problem somebody has been having with the Nascom AVC that nicely illustrates the point. He is (was?) writing a communications package to run on his Nascom, and had run into trouble because he couldn’t get incoming characters into the display fast enough. The IVC can suffer from a similar problem, (scrolling takes an appreciable time), but this can be circumvented very easily by implementing a small circular buffer and alternately polling the UART and the IVC [1]. Here one processor is handling the display and keyboard while the other is acting as a postman between it and the UART, and the postman can temporarily hold onto things if the display is busy. However with the AVC the problem is more fundamental as the postman and display driver programs can only run sequentially, not concurrently. Having given the output routine a character to display the AVC driver was sometimes taking so long to return that several incoming characters were lost. This could be circumvented in two ways:
| i) | duplicate the screen driving code, and add “poll UART & buffer” calls to it in the middle of all routines that take an appreciable length of time to execute. (i.e. Combine the ‘postman’ and “display driver” in a single program, interleaving the two like a “riffle shuffle” with a pack of cards.) |
| ii) | Run the UART under interrupts. |
The latter approach needs careful thought if the screen driver is busy paging various parts of the memory in and out! Also it may interfere with any software approach to transparent screen access.
The IVC is basically a small SBC (single board computer) containing the following: A Z80A, 6845 display controller, 2K of shared screen memory, 4k of character generator that may be a mixture of RAM and EPROM (the standard is 2k of EPROM, 2k of RAM), 2k of workspace memory, EPROM program memory (2716 or 2732), and a few I/O ports. To the host 80-BUS system it appears as three I/O ports. One port is a read/write port through which data and commands are passed to/from the IVC, one port is a read-only status byte that holds the full/empty flags for the data port. The final port is a write-only port that resets the IVC’s processor.
Within that hardware context the features of the IVC are provided in software by the on-board monitor IVC-MON. There have been several versions of the monitor, and in the following sections I will cover various aspects of the monitor, finishing off with a description of the differences between each version.
I don’t intend to regurgitate the software manual here – those that are interested should be able to obtain a copy through their friendly Gemini dealer – but table 1 is a copy of the command summary from the manual for those that are not familiar with it.
| Page 44 of 51 |
|---|