80-Bus News

Over the years I have waited for a review of the Gemini IVC to appear in the pages of 80-BUS News. As nothing has appeared to date, I have decided to put pen to paper to rectify the situation. What follows is not a review, but an insight into the IVC (GM812) and the SVC (GM832). Why an insight? Well I had some influence on the specifications for the boards, and I am the author of the IVC and SVC monitors. As such I am unlikely to be an un-biased reviewer, but hopefully this article will give you a deeper understanding of the whys and wherefores of the software, and the capabilities of the boards.

Background

Back in the dark ages, when there were only Nascoms, and the Nascom 2 was stuck in that black hole of Receivership from which only a trickle emerged, the Gemini system was born. (The demand was there, and the dealers needed something to sell.) After much discussion Gemini decided that in their system the video section should be separate from the CPU card, and that it should have its own dedicated processor. Although this was a more costly approach than that of the Nascom 2 it had various advantages:

Item (3) needs some further explanation as, on first examination, one would think that nothing could be faster than a memory-mapped display. After all, with a memory-mapped approach, the CPU is putting the characters directly into the display, so why take any other approach? The reasons for doing this are many, and I’ll try and give the pros and cons.

Loss of CPU memory space I. A memory mapped display eats up CPU address space, (c.f. the 32k BBC. Put it into hi-res graphics and you are only left with 12k), although this could be got round by switching the display memory into the normal address space only when it is required (as done by the Nascom AVC).

Loss of CPU memory space II. A memory mapped display requires software to drive it, and the more sophisticated the software the more space it takes up. Once again the software could be contained in ROM on the video card, being paged in along with the display memory (Not done by the Nascom AVC).

Speed. Unless the video driver is incorporated within the applications programs (which would ensure they were non-portable), there is the overhead of the driving software to consider, and the case of “transparent access”. The screen memory is usually shared between the CPU and the display controller. If the CPU updates the screen memory whenever it wants to without regard to what the display controller is doing, the result is visible interference on the display. This can be very irritating and most systems aim to provide an interference free display by synchronising the CPU and display controller. In general this is most easily achieved by only allowing the CPU access to the shared memory during the intervals when the display is blanked, and the resultant “waiting” wastes a certain amount of the CPUs time. Similarly scrolling a full screen takes an appreciable amount of time, although this could be reduced with specialised hardware. Anyway, by the time you have a paged display card including on-board software in EPROM, it is only a small incremental cost to give it its own processor, and to talk to it via a few I/O