KV10-PRM.tex

% -*- mode: latex; fill-column: 96 -*-

\documentclass[12pt]{report}
\pagestyle{headings}

%\usepackage{fullpage}
%\usepackage{calc}
\usepackage{graphicx}
\usepackage[hidelinks=true]{hyperref}

\newcommand{\code}[1]{\textsf{#1}}

\newenvironment{register36}
  { \noindent
    \setlength{\dimen0}{0.0272\textwidth}
    \setlength{\unitlength}{\dimen0}
    \begin{picture}(36, 3)
      % make the box outline
      \put(0, 2){\line(1, 0){36}}
      \put(0, 0){\line(1, 0){36}}
      \put(0,0){\line(0,1){2}}
      \put(36,0){\line(0,1){2}}
      % put the numbers on top
      \count255 = 0
      \loop
        \put(\the\count255, 2.3){\makebox[\dimen0][c]
	  {\tiny\number\count255}}
	\ifnum\count255 < 35
	\advance\count255 by 1
	\repeat

      \newcommand{\bit}[2] {
	\put(##1,0){\line(0,1){2}}
	\put(##1,0)
	    {\parbox[b][2\dimen0][c]{\dimen0}
	      {\begin{center} \tiny ##2 \end{center}}}
	    \count255 = ##1
	    \advance\count255 by 1
	    \put(\the\count255,0){\line(0,1){2}}  
      }
      	
    \newcommand{\bits}[3] {
      \put(##1,0){\line(0,1){2}}
      \count255 = ##2
      \advance\count255 by 1
      \put(\the\count255,0){\line(0,1){2}}
      \advance\count255 by -##1 % get the width of the field
      \put(##1,0)
	  {\parbox[b][2\dimen0][c]{\the\count255\dimen0}
	    {\centering \tiny ##3 }}
    }
  }
  {\end{picture} \smallskip}
	 

\begin{document}
\title{KV10 Processor Reference Manual}
\author{David Bridgham \\ \textless dab@froghouse.org\textgreater}

\maketitle

\begin{abstract}
This document describes the KV10 processor, an implementation of the DEC PDP-10
architecture.  Much of the description is how it differs from Dave Conroy's PDP-10/X.
\end{abstract}

\tableofcontents

\chapter{Introduction}
The KV10 is an implementation of the Digital Equipment Corporation's PDP-10 architecture,
written in Verilog, and realized (thus far) on an FPGA. It mostly follows the PDP-10/X
architecture, designed by Dave Conroy and described in his \textit{PDP-10/X System
  Manual}\cite{conroykx10}, and, like Dave's design, is targeted at supporting the
Incompatible Timesharing System (ITS) from MIT.

For now, this document is woefully incomplete.  It contains a mix of things I've done,
things I plan to do, and flights of fancy about where this project could go one day.  It
is slowly growing to describe more and more of the processor and may one day even
delineate those three categories.  For now, determining what's real and what's speculative
is left as an exercise to the reader.

\begin{figure}
\begin{register36}
\bits{0}{8}{\small Opcode}
\bits{9}{12}{\small AC}
\bit{13}{\small I}
\bits{14}{17}{\small Index}
\bits{18}{35}{\small Y}
\end{register36}

\begin{register36}
\bits{0}{2}{\small 7}
\bits{3}{9}{\small Device}
\bits{10}{12}{\small Op}
\bit{13}{\small I}
\bits{14}{17}{\small Index}
\bits{18}{35}{\small Y}
\end{register36}
\caption{Normal and I/O Instruction Formats}
\end{figure}

\section{Internal Modules}

\begin{figure}
\setlength{\unitlength}{.01\textwidth}
\begin{picture}(95,28)
  \thicklines
  
  \put(0,11){\line(1,0){20}}
  \put(0,17){\line(1,0){20}}
  \put(0,11){\line(0,1){6}}
  \put(20,11){\line(0,1){6}}
  \put(7,13){\code APR}

  \put(0,22){\line(1,0){20}}
  \put(0,28){\line(1,0){20}}
  \put(0,22){\line(0,1){6}}
  \put(20,22){\line(0,1){6}}
  \put(5,24){\code Console}
  
  \put(25,11){\line(1,0){20}}
  \put(25,17){\line(1,0){20}}
  \put(25,11){\line(0,1){6}}
  \put(45,11){\line(0,1){6}}
  \put(32,13){\code PAG}
  
  \put(50,11){\line(1,0){20}}
  \put(50,17){\line(1,0){20}}
  \put(50,11){\line(0,1){6}}
  \put(70,11){\line(0,1){6}}
  \put(55,13){\code CACHE}
  
  \put(75,11){\line(1,0){20}}
  \put(75,17){\line(1,0){20}}
  \put(75,11){\line(0,1){6}}
  \put(95,11){\line(0,1){6}}
  \put(82,13){\code MEM}
  
  \put(50,0){\line(1,0){20}}
  \put(50,6){\line(1,0){20}}
  \put(50,0){\line(0,1){6}}
  \put(70,0){\line(0,1){6}}
  \put(57,2){\code IOM}
  
  \put(10,17){\vector(0,1){5}}
  \put(20,14){\vector(1,0){5}}
  \put(45,14){\vector(1,0){5}}
  \put(70,14){\vector(1,0){5}}
  \put(60,11){\vector(0,-1){5}}
\end{picture}
\caption{Internal modules of the KV10}
\end{figure}

\subsubsection{Arithmetic Processor -- APR}

The APR is the core of the processor, responsible for executing the instructions
and maintaining the processor state.

\subsubsection{Pager -- PAG}

The pager is modeled after the paging box that MIT designed and built to support ITS.  It
maps the 18-bit virtual addresses generated by the APR into 22-bit physical addresses and
generates page faults on protection violations or missing memory pages.

\subsubsection{Cache}

The cache is a two-way, set associative, write-through cache.  It also handles converting
between the 36-bit words of the PDP-10 and the width of the memory which is likely not
36-bits.

Additionally, the cache is where the I/O bus is split out from the memory bus.  Since the
pager and cache have their own I/O devices, they grab their own device operations as they
go by.  Any that make it past the cache are directed to the IOM.  When, in the future, we
add DMA devices, they can communicate with the cache to either bypass it, to update it, or
to invalidate entries as appropriate.

\subsubsection{Memory Controller -- MEM}

The memory controller varies, depending on the memory technology in use such as SRAM,
SDRAM, or MRAM.  Because of variables like the memory width, mapping of that width into
the cache's linelength, and optimizations like burst-mode, the memory controller and the
cache are closely tied.

\subsubsection{I/O Multiplexer -- IOM}

The I/O Multiplexer includes connections to all the rest of the I/O devices in the system.
Simple devices may be implemented inside the IOM while more complex ones will get their
own modules.

\subsubsection{Console}

The operator's console or front-panel was a staple of computers from the 1950s and 1960s.
Using the console, an operator could control the computer, enter simple programs, or boot
the machine.  Front-panels have become pass\'{e}, with good reason, but one is available
for the KV10.\footnote{The console should be optional but I'll have to figure out how to
  boot the machine without one.}

\section{On Names}

\subsection{Processor}

This implementation of the PDP-10 architecture is called the KV10. As mentioned above, it
was designed explicitly to run the ITS operating system, namely with a KA-like interrupt
system\footnote{I'm considering adding some of the interrupt system from the KI10} and the
MIT Paging Box (also \code{CIRC} and one-proceed (yet to be implemented)). However, being
implemented in Verilog, it will be fairly straightforward to have variations such as extra
instructions, different paging hardware, and extended memory so it can run TOPS-20.

The exact combination of compile options as well as the version of the code used are 
identified by option codes following the name.

\begin{center} \large KV10A-FDICp-10-1.3 \end{center}

\begin{description}
  \item[model] \hfill
    \begin{description}
      \item[A] The base model.  Essentially this implements the KA10 instruction set and
        interrupt architecture, a single set of accumulators, and so on.  Really it's
        taken more from the PDP-10/X.
      \item[L] The extended instructions of the KL10 processor, its interrupt
        architecture, and multiple accumulator sets.  There are probably other differences
        but I haven't studied the KL10 very much.  Anyway, if someone puts the work in to
        let the KV10 run TOPS-20, it will get a model designation.
    \end{description}
  \item[options] Options are listed in this order.
    \begin{description}
      \item[F] Implemented on an FPGA.
      \item[V] Implemented on an ASIC.
      \item[P] Implemented as a printed IC.
      \item[D] SDRAM controller.
      \item[1] DDR SDRAM controller.
      \item[2] DDR2 SDRAM controller.
      \item[3] DDR3 SDRAM controller.
      \item[4] DDR4 SDRAM controller.
      \item[I] The ITS pager as described for the PDP-10/X.
      \item[C] Implements the \code{CIRC} instruction.
      \item[p] Implements One-Proceed.
      \item[U] Unassigned Codes indirect through 60/61 instead of 40/41.
      \item[X] Implements extended addressing.
    \end{description}
  \item[cache] \hfill \\ The size of the cache is indicated by $log_2$ of the number of
    words in the cache.  For instance, 10 indicates a 1,024 word cache.  0 indicates no
    cache rather than one word.
  \item[version] \hfill \\
    The version number of the code as major.minor.
\end{description}

\subsection{I/O Devices}

I/O devices get their own names separately from the processor [to be described later].
Since many of the I/O devices are actually implemented along with the processor, it might
make sense to have a list like the option list along with the processor name.  I haven't
decided yet.

\subsection{Computer}

Computers include a realization of the processor, some memory, plus a set of supported
I/O devices and are named separately from all of those.  The initial realization, only run
a few times, was on a Terasic DE2-115 FPGA board and called Trilobyte.  The current
intention is to design and build a daughter card to go with the ZTEX 2.13 FPGA module
providing a useful set of I/O ports.  This will be called Ammonite.


\chapter{APR}

\section{Instructions}

\subsubsection{JRST}

The \code{JRST} instruction works like on the KA10, with the four bits of the AC field enabling
special functions.  However, the microcode dispatches to 16 locations allowing for more
variations.  In particular, I'm considering adding a \code{JRST} that halts but leaves
interrupts enabled like Wait for Interrupt from the PDP-11.

\subsubsection{CIRC - Circulate}

\begin{register36}
  \bits{0}{8}{\small 247}
  \bits{9}{12}{\small A}
  \bit{13}{\small I}
  \bits{14}{17}{\small X}
  \bits{18}{35}{\small Y}
\end{register36}

\code{CIRC} was added to the MIT KA10s in place of what was usually an unassigned code.
This instruction rotates the two accumulators \code{A} and \code{A+1} the number of
positions specified by \code{E}\marginpar{\raggedright \tiny The DEC documentation
  specifies that E is taken modulo 256; it never has a magnitude greater than 255. The
  diagnostics make it clear that -256 is expected to move 256 positions.} very much like
\code{ROTC} except it rotates \code{A+1} in the opposite direction. If \code{E} is
positive, bit 0 of \code{A} is rotated into bit 0 of \code{A+1} and bit 35 of \code{A+1}
is rotated into bit 35 of \code{A}.  If \code{E} is negative, bit 35 of \code{A} is
rotated into bit 35 of \code{A+1} and bit 0 of \code{A+1} is rotated into bit 0 of
\code{A}.\marginpar{\raggedright \tiny \code{CIRC A,36} will swap \code{A} and \code{A+1}
  while reversing their bit order.}

\setlength{\unitlength}{.01\textwidth}
\begin{picture}(95,15)
  \thicklines
  \put(10,0){\line(1,0){30}}
  \put(10,6){\line(1,0){30}}
  \put(10,0){\line(0,1){6}}
  \put(40,0){\line(0,1){6}}
  \put(24,2){\code{A}} \put(11,7){\tiny 0} \put(38,7){\tiny 35}

  \put(58,0){\line(1,0){30}}
  \put(58,6){\line(1,0){30}}
  \put(58,0){\line(0,1){6}}
  \put(88,0){\line(0,1){6}}
  \put(70,2){\code{A+1}} \put(59,7){\tiny 0} \put(86,7){\tiny 35}
	
  \put(10,3){\line(-1,0){6}}
  \put(4,3){\line(0,1){8}}
  \put(4,11){\line(1,0){40}}
  \put(44,11){\line(1,-1){8}}
  \put(52,3){\vector(1,0){6}}
	
  \put(88,3){\line(1,0){6}}
  \put(94,3){\line(0,1){8}}
  \put(94,11){\line(-1,0){40}}
  \put(54,11){\line(-1,-1){8}}
  \put(46,3){\vector(-1,0){6}}
\end{picture}

\smallskip
Inclusion of the \code{CIRC} instruction is controlled by the \texttt{CIRC} option in the
\texttt{constants.vh}.

\section{Interrupts and UUOs}

\subsection{Interrupt Instructions}

On the KV10, any instruction may be used as an interrupt instruction though that doesn't mean
any instruction makes sense there and most haven't been tested.  There are three broad
classes of instruction that have different effects when used as an interrupt instruction.

\begin{description}
  \item[JSR, JSP, PUSHJ, JSA, or JRST] These instructions will clear the CM flag (put the
    processor in exec mode) and jump to the destination address as per the instruction.
    \code{JSR} is the typical example of this and the most commonly used interrupt
    instruction.  The interrupt service routine is expected to clear the condition causing
    the interrupt (if needed) and dismiss the interrupt with \code{JEN}.\footnote{The KI10
      allows MUUO instructions as interrupt instructions.  This might work but has not
      been tested.}

  \item[AOSx, SKIPx, SOSx, CONSx, or BLKx] If the skip condition is satisfied, then the
    APR dismisses the interrupt and returns to the interrupted program.  If the skip
    condition is not satisfied, the instruction in the second interrupt location for the
    channel is executed as an interrupt instruction.

  \item[everything else] All other instructions take their action then dismiss the interrupt and
    return to the interrupted program.  This differs from the KA10 but is like the KI10 and
    later models.  Differing from the KI10, jump and skip instructions (other than those listed
    above) do not jump or skip but simply return to the interrupted instruction.
\end{description}

\subsection{Unassigned Codes}

\marginpar{\raggedright \tiny The unassigned codes are 100-107, 114-117, 123, 247 (if
  \code{CIRC} is not included), and 257.}The KA10 handles unassigned codes much like MUUOs
except they go through locations 60 and 61 rather than 40 and 41.  The KX10 sends both
MUUOs and unassigned codes through locations 40 and 41.  The KV10 may do it either way and
is controlled through the \texttt{UAC} option in \texttt{constants.vh}.  Defining
\texttt{UAC} causes the KV10 to use locations 60 and 61 for unassigned code processing.
\footnote{At some point I expect I will settle on one or the other and remove this compile
  option.}

\chapter{Input / Output}

\section{BLKI}

On some I/O devices, \code{BLKI} works a little differently than on most PDP-10s.  Normally
\code{BLKI} skips only if the count in the left half of location \code{E} is not zero so
not-skipping indicates the read buffer is full and reading is finished.  However, in some
cases the I/O device may know better than the software when the end is reached.  These
devices may notify the APR they've reached the end and this will cause \code{BLKI} to not
skip even though the count has not yet reached 0.

An example of this might be an Ethernet device.  It can start delivering data to the
processor before it knows the length of the packet so a device driver that wanted to use
\code{BLKI} as the interrupt instruction would not know how many words to set up in its
block.  With this modification, when either the end of the packet or the end of the buffer
is reached, \code{BLKI} doesn't skip.  The code outside of the \code{BLKI} loop then needs
to check why it was reached, if it was end of packet or buffer overflow.

\section{I/O Devices}

Some I/O devices go with the processor itself (APR, PI, and PAG) while others are specific
to the particular realization of the computer.  It may be eventually that this distinction
will be important and the implementation specific devices will be separated out into
separate manuals.  That's awfully forward looking; my optimism knows no bounds.

The operations of \code{CONSZ}, \code{CONSO}, \code{BLKO}, and \code{BLKI} are not
described in here as they're just operations on top of the base of \code{CONI},
\code{DATAO}, and \code{DATAI}.  Any exceptions will be noted -- so far, there are none.


\subsection{APR -- Device 000}

\subsubsection{CONI APR, E}

\begin{register36}
  \bit{0}{E\\H\\E}
  \bit{1}{E\\S\\E}
  \bit{2}{E\\E\\2}
  \bit{3}{E\\E\\1}
  \bit{4}{E\\U\\2}
  \bit{5}{E\\U\\1}
  \bits{6}{8}{E\\I\\A}
  \bit{9}{T\\H\\E}
  \bit{10}{T\\S\\E}
  \bit{11}{T\\E\\2}
  \bit{12}{T\\E\\1}
  \bit{13}{T\\U\\2}
  \bit{14}{T\\U\\1}
  \bits{15}{17}{T\\I\\A}
  \bit{25}{F\\H\\E}
  \bit{26}{F\\S\\E}
  \bit{27}{F\\E\\2}
  \bit{28}{F\\E\\1}
  \bit{29}{F\\U\\2}
  \bit{30}{F\\U\\1}
  \bit{31}{E\\I\\R}
  \bit{32}{T\\I\\R}
\end{register36}

See PDP-10/X documentation.

\subsubsection{CONO APR, E}

\begin{register36}
  \bit{18}{S\\S\\E}
  \bit{19}{R\\I\\O}
  \bit{20}{C\\S\\F}
  \bit{21}{S\\F}
  \bit{22}{C\\F}
  \bit{23}{L\\E}
  \bit{24}{L\\T}
  \bit{25}{M\\H\\E}
  \bit{26}{M\\S\\E}
  \bit{27}{M\\E\\2}
  \bit{28}{M\\E\\1}
  \bit{29}{M\\U\\2}
  \bit{30}{M\\U\\1}
  \bits{33}{35}{I\\A}
\end{register36} 

See PDP-10/X documentation.

\subsubsection{DATAI APR, E}
\subsubsection{DATAO APR, E}

\begin{register36}
  \bits{0}{35}{\small Switch Register}
\end{register36}

Since the switches in the BL10 console are capacitive touch switches whose current state
is held by internal flip-flops, like the KI10 their values can be written as well as read.
Unlike the KI10, writing is done to the APR device rather than paper-tape reader (PTR).
This switch register is reflected in and controlled by the \textsc{data switches} on the
console.

If the console is not included, the switch register is still there and can be read and
written under software control.  It's just that it can't be observed by looking at the
front of the computer and it can't be changed manually.

\subsection{PI -- Device 004}


\subsubsection{CONI PI, E}

\begin{register36}
  \bit{11}{S\\R\\1}
  \bit{12}{S\\R\\2}
  \bit{13}{S\\R\\3}
  \bit{14}{S\\R\\4}
  \bit{15}{S\\R\\5}
  \bit{16}{S\\R\\6}
  \bit{17}{S\\R\\7}
  \bit{21}{I\\P\\1}
  \bit{22}{I\\P\\2}
  \bit{23}{I\\P\\3}
  \bit{24}{I\\P\\4}
  \bit{25}{I\\P\\5}
  \bit{26}{I\\P\\6}
  \bit{27}{I\\P\\7}
  \bit{28}{G\\E}
  \bit{29}{L\\E\\1}
  \bit{30}{L\\E\\2}
  \bit{31}{L\\E\\3}
  \bit{32}{L\\E\\4}
  \bit{33}{L\\E\\5}
  \bit{34}{L\\E\\6}
  \bit{35}{L\\E\\7}
\end{register36}

See PDP-10/X documentation.

\subsubsection{CONO PI, E}

\begin{register36}
  \bit{22}{C\\S\\R}
  \bit{23}{R\\P\\I}
  \bit{24}{S\\S\\R}
  \bit{25}{S\\L\\E}
  \bit{26}{C\\L\\E}
  \bit{27}{C\\G\\E}
  \bit{28}{S\\G\\E}
  \bit{29}{L\\1}
  \bit{30}{L\\2}
  \bit{31}{L\\3}
  \bit{32}{L\\4}
  \bit{33}{L\\5}
  \bit{34}{L\\6}
  \bit{35}{L\\7}
\end{register36}

See PDP-10/X documentation.

\subsubsection{DATAO PI, E}

\begin{register36}
  \bits{0}{35}{\small Memory Indicator}
\end{register36}

Display the contents of location \code{E} on the console \textsc{memory/program data} and
light the \textsc{mem} light.

\subsubsection{DATAI PI, E}

This one is up for grabs.  I could just read back in the value written out to the Memory
Indicator but since those can't be changed manually, it seems rather pointless.  I could
read in the address switches but I'd be disappointed not to have a way to set them too.  I
could make use of \code{DATAO PTR} like the KI did for writing the address switches.  I
could read the \textsc{read in device} switches on the console.  This has the potential
use of letting boot code know where it booted from and those switches could pick up the
functionality of the \textsc{sense} switches that the BL10 console doesn't have.

\chapter{Console}

\section{Hardware}

The BL10 console device is an array of lights and capacitive touch switches designed to
display some of the internal state of a PDP-10 processor and let an operator control the
computer.  It communicates with the processor over an I2C bus so it doesn't come close to
keeping up at full speed.  Humans can't see lights blink that rapidly anyway.

It has an alternative communications port of a logic-level async serial interface with a
connector that matches with the FTDI serial to USB cables that are readily available.
This is to enable someone to implement console functions on a simulated processor such as
the KLH10 or SIMH.

\begin{figure}
\includegraphics[angle=0,keepaspectratio=true,width=\textwidth]{../front-panel/overlay.pdf}
\caption{BL10 Operator's Console}
\end{figure}

\section{Operation}

The console gives an operator direct, low-level control over the KV10.  It can be used to
poke around with the base machine, enter simple programs, or boot the computer.

Starting in the top, right: green lights indicate power is applied and the processor is
running.  Three red lights indicate the processor is stopped and the reason for stopping,
whether manual (from the console), the program (it executed a \code{HALT} instruction,
aka \code{JRST 4}), or the processor encountered a double hard error.

The PAG lights show if the pager is enabled and when it signals page fault and the
Processor Flags show those architectural flags that the programmer might use.

To the right of those are a block of lights showing the status of the PI system: whether
the system as a whole is enabled, which levels are enabled, which are in-progress, and
whether there are PI requests either from hardware devices or internally from the APR.

Moving down we have the Program Counter and below that the instruction that's executing.
To the right of the Program Counter are lights indicating if that instruction is being
executed in exec or user mode.

The Memory/Program Data lights serve a dual purpose.  When the APR is running, a
\code{DATAO PI} will write to these lights and be indicated by lighting the PROG light.
When the APR is halted, these lights will show the results of reading memory from the
console and this state will be indicated by the MEM light.

The Address Switches set the address to be read or written from the console.  Clear sets
the Address Switches to all 0 while Load sets them to the corresponding bits shown in the
Memory Data indicators.

To the left of the Address Switches are the Paging controls.  Reading and writing to
memory can be done to physical memory or to virtual memory of either the executive or
user memory spaces, as defined by the pager.  If virtual memory, only the right 18-bits of
the Address Switches are used.  The current pager only defined 22-bits of physical address
but there is potential room in the page-table entries for up to three more bits so I've
left room for that.

The Data Switches are used for writing data to memory locations.  The clear and load
switches to the right work like they work for the Address Switches.

The bottom row of switches are what initiate the various operations of the console.  [need
  to write a lot more here, once I know what operations I'm going to have.]

The Read In Device is for booting the computer.  Enter the device to boot from, then push
Read In to load the boot code from that device and run it.  Read In resets the device and
then reads, using repeated DATAI operations, a .SAV file from the device until it reaches
the end where it finds a \code{JRST} instruction and it starts the processor at the
location indicated.  The KV10 actually does execute this final instruction of the .SAV
file (in the sense of the \code{XCT} instruction) so if you arrange to put some other
instruction at the end of your .SAV file, you may get unexpected results.  Or perhaps
that's what you wanted to happen.


\chapter{Internals}

The KV10 is a horizontal micro-code machine with a 64 bit micro-word.\footnote{Currently not all
  bits are used and this is subject to change as more is implemented.}  The data-paths are shown
in Figure \ref{datapaths}.


\begin{figure}
  \includegraphics[width=\textwidth]{data-paths/dp.pdf}
  \caption{KV10 Data Paths}
  \label{datapaths}
  \end{figure}

A key aspect to the micro-engine is the conditional branches that are available to the
micro-code.  These branches are OR'd into the next micro-address, therefore requiring that
branch destinations be suitably aligned.

\begin{description}
\item[brJUMP]
  The default is just to transfer to the next micro-instruction as specified by the next
  instruction field of the micro-instruction.
\item[brREAD]
  A two-way branch that allows waiting for the read ack to appear when reading memory.  The read
  data will be read one clock cycle after the ack.  The address does not have to be held on
  mem\_addr after mem\_read is asserted.
\item[brWRITE]
  A two-way branch that allows waiting for the write ack to appear when writing to memory.  The
  address and data to be written do not have to be held after mem\_write is asserted.
\item[brIX] A three-way branch on the Index and Indirect fields of an instruction to allow for
  effective address calculation.  This is currently taken from \code{write\_data} rather than
  \code{inst} because we want to do the branch one cycle early.  Indexing takes priority since
  we want to do that calculation first.
  \begin{description}
  \item[0] Index is non-zero
  \item[1] Indirect
  \item[2] Otherwise
  \end{description}
\item[brI] If we process a Index during the Effective Address calculation, then we need to come
  back and check for Indirect.  This check is for that and operates off the \code{inst} register
  since the instruction will have been written by now.
\item[brDISPATCH] This is a complicated branch that handles a variety of different tasks, all
  put into a single branch to save cycles.  It is primarily driven from the instruction decode
  ROM.  The default is that the branch dispatch is the opcode of the instruction.

  Instructions that read the contents of the memory at the effective address branch to $740_8$
  to execute that read.  An internal flag is set so when the instruction is dispatched again, it
  doesn't just read the contents at E again.

  Some instructions get special dispatching, namely \code{JRST} and the I/O
  instructions.\footnote{Eventually I wish to attempt merging more of the effective address
    calculations into brDISPATCH to save a clock cycle on any instructions that don't use
    Indexing or Indirection.}
\item[brCOMP]
  Branch if the comparison (as specified from the instruction decode) matches.
\item[brCOMP0]
  Branch if the comparison with 0 (as specified from the instruction decode) matches.
\item[brSELF]
  For instructions that write to self, check if AC is not equal to 0.
\item[brTEST]
  Branch if the bitwise AND of the A and M inputs to the ALU is not 0.  This is used for the
  \code{TEST} instructions.
\item[brJFCL]
  For the \code{JFCL} instruction, branch if and of the processor flags are about to be cleared.
\item[brMUL]
  An 8-way branch for the different \code{MUL} and \code{DIV} instructions.
  \begin{description}
  \item[0] \code{IMUL}/\code{IDIV}
  \item[1] \code{IMULI}/\code{IDIVI}
  \item[2] \code{IMULM}/\code{IDIVM}
  \item[3] \code{IMULB}/\code{IDIVB}
  \item[4] \code{MUL}/\code{DIV}
  \item[5] \code{MULI}/\code{DIVI}
  \item[6] \code{MULM}/\code{DIVM}
  \item[7] \code{MULB}/\code{DIVB}
  \end{description}
\item[brOVR]
  Branch if the ALU is indicating overflow.
\item[brBPDISP]
  A 4-way branch for the different Byte instructions.
  \begin{description}
  \item[0] \code{ILDB}
  \item[1] \code{LDB}
  \item[2] \code{LDPB}
  \item[3] \code{DPB}
  \end{description}
\item[brFPD]
  Branch if the First Part Done flag is set.
\item[brBLTDONE]
  Branch if RIGHT(AC) equals E -- used for terminating \code{BLT}.
\item[brIOREAD]
  Branch when we receive the ack for an I/O read.
\item[brIOWRITE]
  Branch when we receive the ack for an I/O write.
\end{description}

During a memory read we may receive an interrupt.  In this case the micro-engine immediately
jumps to location $777_8$ to begin the interrupt processing.

During a memory read or write we may receive a page fault.  In this case the micro-engine
immediately jumps to location $775_8$ which simply aborts the current instruction execution and
begins again.  If interrupts are set up correctly, the attempt to fetch the instruction will be
blocked and the interrupt will be taken.  If not, this is a double-error.\footnote{Need to
  implement double errors.}

\begin{thebibliography}{9}

\bibitem{conroykx10}
  Dave Conroy,
  \emph{PDP-10/X System Manual}.
  \url{http://fpgaretrocomputing.org/pdp10x/}

\bibitem{PRM1970}
  Digital Equipment Corporation,
  \emph{PDP-10 System Reference Manual}.
  \url{http://bitsavers.com},
  1970.

\bibitem{PRM1971}
  Digital Equipment Corporation,
  \emph{DECsystem-10 System Reference Manual}.
  DEC-10-HGAD-D,
  1971.

\bibitem{PRM1982}
  Digital Equipment Corporation,
  \emph{DECsystem-10/DECSYSTEM-20 Processor Reference Manual}.
  AH-H391A-T1,
  June 1982.

\end{thebibliography}

\end{document}