TVC release #2 aka "Utah Spinner"


This release most importantly adds a Z-buffered polygon scanline
routine to the TVC.  The MCU has been improved to allow unaligned
access to the framebuffer and a real scheduler has built into it to
fairly share the framebuffer between memory users and yet give the
display priority access to pixel data.  A simple C++ 3d engine
(included) drives the TVC and spins a flat shaded Utah teapot about
its y axis in one degree increments.  The driver software now only
flushes epp data registers that have changed to the TVC.  A block set
memory user has been added to speed clearing the front and z buffer.
The rp_writer memory user has been removed partly for logic space
constraints.  The development hardware is unchanged from Release #1.

The depthbuffer is signed 32 bit integer.  The framebuffer is 8bpp
with 2bits for red, 3 bits each for green and blue.  The framebuffer
depth and layout is determined by my development kit.  I am limited to
a theoretical peak memory bandwidth of 50MB/sec, and certainly no more
than 1MB/sec in command bandwidth.  The clock is 50MHz.  I am rapidly
filling the Xilinx Spartan XC2S200E FPGA, but have not yet tried to
optimize anything.

The next logical enhancements are:

Improve the hardware! Digilent has recently released several very
nice kits. In particular the S3E1600 and the FX12.  I am more
interested in the FX12 due to other embedded projects.  Can't the FX12
be programmed with the TVC, and booted with Linux and X?

TVC infrastructure:
The mcu-hl has plenty of bugs.

Implementing the poly-scanline demonstrated a weakness in the mu-buss
design, so something completely new will have to interconnect all
functional units.  This will be less traumatic than it sounds.

The pixel pusher still starts drawing the display near the bottom of
the screen.  The pixel pusher needs to be able to do display double
and quad buffering.  The pixel pusher needs a hardware cursor.

For 2d routines:
Add a solid rectangle filler.

Draw single pixel wide lines.  Add read/modify/write functionality
to the MCU to effortlessly do XOR, etc.  of lines, rectangles,
etc. (any implemented primitive).  The 2d stuff above is easy-ish. A
few weeks at the most.

Add a bit-blit.  (tough if it is a generic implementation that can
handle overlapping regions).


For 3d:
Won't someone please document how to port Mesa to new hardware!?  I
wrote engine after looking for a hour or so at Mesa.  I'd have spent
10x longer than the time writing engine in figuring out what to do
with Mesa.

Looking up texture map data quickly seems to be the hard problem of
TVC.  A simple slow nearest single point sampling will be easy to
implement (and is a logical next step), but to do bi and tri-linear
texture mapping quickly looks very hard.

Implement in hardware scanning along the edges of triangles.  This
means replicating the C++ algorithms in VHDL.  This is much less
important than texture mapping.

Other:
Create a command sequencer.  This will fetch commands previously
written into the framebuffer and drive the functional units.

I effectively have two jobs right now, so the TVC has taken a back
burner since release #1 and will continue to be low priority to me for
some time.

It would be great if someone else either ported TVC to another dev
kit, or started a parallel independent development.  I would like to
see other solutions to various design questions.

To download TVC release #2 see http://www.johnculp.net/tvc.html

-John