README for Prisma VNC client

This is the source for a VNC client for uClinux 2.0.38 running on an
ISICAD Prisma model 700 with a 33249 or 33500 Video Buffer board.
It is based on the VNC X client version 3.3.2.

This is a snapshot release, it works but is unusably slow. The speed
problem is mainly due to the unusual interface to the Prisma's
graphics card. I am still looking for ways of speeding it up.

The Makefiles assume that the source is installed below the 'user'
directory of the uClinux/ColdFire source tree. They will need to be
modified for other platforms.


What is VNC
-----------
VNC stands for Virtual Network Computing, it is based on the concept
of a remote framebuffer and allows the VNC client to display the screen
of a system running the VNC server. Clients and servers have been written
for X/Unix, Windows 3.1/95/NT, Macintosh, Amiga and others. More details
can be found on the VNC web site:

    http://www.uk.research.att.com/vnc/


VNC on the Prisma
-----------------
The Prisma port is based on the X client. To minimise the number of 
changes in the core code (so that it will be easier to upgrade when
a new X client is released), I have used dummy structures and functions
in place of the missing X headers and libraries and a simple mouse driver
has been added to work with a standard two-button serial mouse.

Most of the effort has gone into the display interface but the
results to date are disappointing. The Prisma's video buffer is not
memory mapped, instead it is only accessible through a series of
control registers. The board does have hardware assist for line
drawing but has no block fill or move capability. Pixels can only
be written or read in vertical groups of four and the order in which
they appear varies with both the x and y coordinates!

Information on programming the video buffer is scant so most of the
details have been deduced by looking at how the monitor ROM does it.
I have spent a lot of time trying to improve the performance by
moving some of the loops into optimised assembler code but although
this has helped, the overall performace is still unusable. It may be
that there are better ways of driving the display but I haven't
found them yet :-(


George Harvey
fr30@dial.pipex.com                             10th February 2000