AnInsight into the GeminiIVC and SVC By D. W. Parkinson
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.
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:
(1) Those requiring a CPU card for dedicated control applications need only
buy a CPU card (GM811).
(3) Increased performance.
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 Ill 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