It was about 4 months ago when I was over at the Liverpool
Nascom Club that I saw for the first time this superb board in
operation. The board had started off as a private project but
when completed it was in such demand that it became very
commercial. The main designer was Stuart Holes and most of the
Software was produced by Joe Savlini.
For my money I got a 12x8 board, an I/O decode PROM,
reasonable design and construction notes and a cassette
containing some short programs which test the different features
of the board and also give an insight into how ta program it.
The programs are in Pascal which makes using the procedures to
access the various parts of the board very easy.
Features of the Graphics Animation Board
Nas-bus compatible on an 8″x12″ double-sided board. The board
is not through-hale plated and approx. 325 track-pins need to
be put in before construction can start. Hard work but it has
kept the cost of the board down.
Fully buffered data and address bus.
ALL functions are decoded as I/O by the provided PROM
including the Nascom I/O ports therefore the board does not
take up any address space.
The heart of the video section is the TMS9929
processor together with 16k of dynamic RAM.
The processor can produce a resolution of 256 by 192 with 16
colours with the output from the board being in the form of
R-Y, B-Y and Y buffered to 75ohms. This means that the output
from the chip must be processed further to provide a signal
capable of driving a TV or colour monitor. The luminence
signal (Y) can be directly connected to the input of a black
& white monitor to give a shades of grey picture but this is
a waste when the chip is producing 16 beautiful colours.
The processor also produces 32 sprite planes containing
thirty-two 8x8, 16x16 or 32x32 pixel sprites.
The position of each sprite on the screen is given by
specifying its XY co-ordinate.
If two sprites collide ie. one sprite is moved so some of its
8x8, 16x16 or 32x32 pixels overlap another sprite, a sprite
collision flag is set allowing immediate collision sensing
without ‘peeking” the screen RAM. This makes the programming
aspect of moving graphics very easy.
Magnification and size factors for each sprite are loaded in
the sprite attribute table enabling a change from 8x8 to