% -*- Mode:Text  -*- 

\chapter{Box controller circuitry}\label{box-circuit}


A \cam\ box contains some circuitry that belongs to the box as a whole
rather than to the individual modules.  For this purpose, the present
implementation uses a passive motherboard and an additional board,
called the {\em box controller}, that plugs into the motherboard.


\section{\bus\ interface}

The box controller provides interfacing between the {\sym \bus\ root}
connector and the \bus\ portion of the local bus. On the backplane,
the sixteen data lines are bussed across the eight modules. Outbound
data are received by all the modules; inbound data are put on this
data bus by at most one of the eight modules, while the others remain
in the high-Z state \memo{Any pull-ups?}. On the box controller, the
bussed data lines are driven/sensed by a bidirectional bus buffer, whose
enable and data-direction lines are controlled by buffered versions of
{\sym Inner Data Enable} ({\sym IDE*}) and {\sym Inner Data
Direction} ({\sy IDD}), generated by multipurpose pins of module 0 (see \fig{}).

The outbound control signals, {\sym Reset*}, {\sym Sync}, {\sym
Frame*}, and {\sym Outbound Handshake}, coming from the {\sym \bus\
root} connector, are buffered by the box controller and put on
backplane bus rails; each module will buffer them again and distribute
them to the sixteen chips of the module. Logically reprocessed copies
of {\sym Sync}, {\sym Frame*}, and {\sym Outbound Handshake} are then
put on the {\sym \bus\ branch} connectors by the modules. The {\sym
Reset*} signal, on the other hand, is put on these connectors directly
by the box controller, using separate buffers.

The inbound control signal {\sym Inbound Handshake} and {\sym Status}
generated by multipurpose pins on each of the modules (see \fig{}),
are separately brought to the box controller (i.e., they are not
bussed on the backplane). There, the eight {\sym Status}
signals are {\sc or}ed, yielding the {\sym Status} signal for the {\sym
\bus\ root} connector; similar considerations apply to {\sym Inbound Handshake}.



\section{Video interface}

The video interface turns raw video data (the sixteen {\sym Raw Video}
data signals, bussed across the eight modules on the backplane so that
any one module can put its data on them) into multilevel Red, Green,
and Blue, as well as horizontal and vertical sync and related framing
signals. The raw video data are buffered by the box controller and
then sent to a writeable video palette (consisting of a 64Kx8x3 \sram\
block) which produces an eight-bit output for each of the three
colors. A triple digital-to-analog converter (video {\sc dac})
produces 256 intensity levels for each color.

The {\sym Display Valid*} signal is fed to the video {\sc dac}'s
blanking input, thus producing a ``blacker-than-black'' video output
level when no valid video data are available.

For prototyping convenience, the video palette can be bypassed, and
the 16 buffered raw video signals routed directly to a subset of the
24 {\sc dac} inputs.

\subsection{Video sync}

The \bus\ {\sym Sync} line carries, encoded as 4-bit bursts on
background of zeros, messages used for achieving synchronization
between sweeps and scans of the \cam\ machine (\sect{}) and,
respectively, horizontal and vertical scans of a \crt\ monitor (or
similar external equipment).
 \figonegiven{sync-messages}{
	\begin{tabular}{|c|l|l}\hline
 	code & \multicolumn{1}{c|}{message}\\\hline\hline
 	1001 & \sym HMON & {\sc crt} monitor\\
 	1010 & \sym VMON & {\sc crt} monitor\\\hline
	1100 & \sym HCAM & \cam\ machine\\
 	1111 & \sym VCAM & \cam\ machine\\\hline \end{tabular}
 }{The above codes, transmitted on a background of all zeroes, signal
the appropriate times for a \crt\ monitor to start horizontal and
vertical scans, and for the \cam\ machine to start sweeps and scans.}

On the \cam\ controller



The {\sym HMON} and {\sym VMON} messages specify the start of,
respectively, the {\sym HSync*} and {\sym VSync*} pulses that will
drive a \crt\ monitor. They are produced at the desired rates by
programmable countdown timers on the \cam\ controller.

The {\sym HCAM} message echoes {\sym HMON} with a programmable delay,
and similarly {\sym VCAM} echoes {\sym VMON} with a programmable
delay, so as to give the monitor sufficient retrace and trace-lead
time before the \cam\ machine starts putting on the video lines
data to be displayed on the monitor.  The {\sym Scan Sync Mode}
(\sect{RMR}) determines to what extent a \chip\ should take into account
these timing signals.

\medskip

On the box controller, the {\sym HMON} message triggers a one-shot,
producing an {\sym HSync*} pulse of appropriate width (a few
microseconds). Similarly, the {\sym VMON} message starts a countdown
timer, producing a {\sym VSync*} of appropriate width (a few {\sym
HMON} cycles). For convenience, the box controller may also
provide a composite {\sym HVSync*} signal, as well as a separate
{\sym Blank*} signal (which will be a buffered version of
\bus\ {\sym Display Valid}. 



\subsection{Video palette}

Normally, the 16 raw video lines drive the palette's address lines,
while the palette's data lines, configured as outputs, drive the video
{\sc dac} with. Rudimentary downloading facilities are provided as
follows.

In {\em download} mode, the palette's data lines are turned into
inputs and are fed by the raw video lines with the data to be
downloaded; control of the palette's address lines is switched to an
autoincrementing counter. Sequential clocking of 16-bit data words
into the palette, starting from location 0, is driven by the system
clock, using the local bus {\sym Display Data Valid*} as a
clock-enable signal.

Since the palette has a word width of 24 (=3\by8) bits, two 16-bit
raw-video words are used for each palette address: each even word will
provide 8 bits of Red and 8 bits of Green, while the odd word which
follows will provide 8 bits of Blue (the remaining 8 bits are not
used).

Normally, {\sym Display Valid*} echoes {\sym Site Valid*} with a delay
which may vary from one to $\ell_{\rm max}$ clock cycles; the value of
$\ell_{\rm max}$ is determined by a \chip\ flag; \cf{HER} \memo{LPL or FPL?}).
For palette downloading, the {\sym Site Valid*} line is forced to the
unasserted state. Thus, every clock cycle in which an asserted {\sym
Display Valid} is not preceded, within $\ell_{\rm max}$ cycles,
by an asserted {\sym Site Valid*} is interpreted as a
palette-download clock cycle. The first of an unbroken series of
downloading clock cycles,\footnote
	{I.e., when the previous occurrence of {\sym
Display Valid*} {\em was} preceded by {\sym Site Valid*} within 
$\ell_{\rm max}$ cycles.}
	is interpreted as the beginning of a new palette-downloading
sequence, and resets the downloading counter to zero.
 

 
