\documentclass[a4paper,12pt]{article}
\begin{document}

\begin{center}
{\Large \bf Some say `A TRAM for me'}
\end{center}

When people get to know me, they are often suprised to learn that I am 
not a computer scientist, and I am not an electrical engineer. In fact I 
am a particle physicist. And the reaction is normally something like 
`Particle Physics -- you mean quarks and gluons and leptons and QCD and 
so on'. And the reply is `No, Particle Physics -- CCDs, Avalanche 
Photodiodes, fast analogue electronics, microcode, and transputers'.

\noindent
{\bf Put up OHP : Overview}

In this talk I am going to start by defining just what a transputer is, 
and then show how the hardware is related to the Occam programming 
language. Then I'll say a little about the somewhat unconventional CPU 
architecture and instruction set.

At that point, we'll all have a fairly clear idea as to what a transputer 
is, so I will explain how to use them, starting with the simplest 
possible transputer system, and going on to show how to link up external 
memory and I/O

I'll finish with some examples of how to link conventional I/O and 
real-time devices to a transputer system, and show a few commercial and 
less-than-commercial systems.

\noindent
{\bf What is a Transputer?}

The name `Transputer' is derrived from the words `Transistor' and 
`Computer'. It doesn't mean a computer made of transistors, it means a 
computer that you use like a transistor. Just as you link transistors 
together to make ever more complex electronic circuits, so you link 
transputers together to make ever more complex computer systems.

I am sure many of you are familiar with the conventional 
microcontrollers, like the Microchip PIC or the Intel 8048 and 8051 
families. These are single chips containing a processor, memory (both ROM 
to hold the (fixed) program and RAM for variables) and some input/output 
resources. 

\noindent
{\bf Put up OHP : T425 block diagram (p262 in databook)}

A transputer is a little like that, hence the title of the talk. A
transputer is a single monolithic chip containing a CPU, a small bootstrap
ROM, some RAM, and 4 high-speed (for the time -- 10 or 20 Mbps, 100Mbps on
the T9000 series that I am going to say nothing more about as I've never
used them!) serial links. The other blocks shown on the diagram are
concerned with interrupt handling and connecting up external memory and
I/O devices. Although the CPU architecture is not set by that definition,
all the original transputer families had essentially the same CPU
architecture. 

The important thing to realise at this point is that you can connect 
transputers by connecting up these serial links. Several transputers can 
run in parallel, communicating via the links, so you have the basis for a 
parallel computer system.

Actually, it's a little more complicated than that. Each transputer has,
at the microcode level (and thus `built into the processor') a simple task
scheduler. Thus several processes can be timesliced on the same
transputer. So a transputer program, consisting of several processes that 
are to run in parallel can be run on an array of transputers with one 
transputer per process, or on a single transputer with all the processes 
timesliced, or on something between the 2 extremes. 

\noindent
{\bf Occam}

ALthough it is possible to program a transputer in assembly language or
machine code, and a book explaining the best way to do this was available
(although it is somewhat rare) {\bf wave it about if I can find it}, the
instruction set is such that it's best to let a compiler do the code
generation. And a special programming language called OCCAM was written
which is, in a sense, designed round the transputer architecture.

The fundamental part of an OCCAM program is the {\em process}. An occam 
program consists of a number of communicating sequatial processes. They 
communcate via channels, which are implemented either as transputer links 
(between processes running on different transputers) or simulated links in 
memory between processes on the same transputer. The transputer link is 
{\em exactly} the hardware implementation of the Occam channel.

\noindent
{\bf Put up OHP : simple OCCAM process}

Here is a trivial Occam process. The first instrucion reads in a number 
over a channel -- c is declared as CHAN OF INT, for example. The next 
line, fairly obviously, squares it. And the final line outputs the 
squared number to the same channel. You could trivially make a whole 
series of similar processes that perform operations on numbers, and then 
link them together, in much the same way that you can make electronic 
circuits to square a number and do other operations like that and then 
wire them together to make signal processing systems.

Note that the only way for processes to communicate is via channels. This 
is obvious if the processes are running on different transputers, since 
the only communication between the 2 transputers is the transputer link. 
But even when the 2 processes run on the same transputer, the Occam 
compiler enforces the rule that there can be no shared variables between 
them. Actually, it is possible to cheat, and I'll show you one way to do 
that (called 'violating the occam model') later on.

As an aside at this point, perhaps I should mention one feature of the 
Occam language that really drove me mad when I was writing it. Note that 
there's no END or END PROC or similar line in the example I've given. 
That's because there is no such statement in Occam. Processes (and other 
blocks for that matter) are ended by reducing the indentation by 2 
spaces. Indentation is thus critical, which I think is a rather Bad Thing.


\noindent
{\bf CPU architecture and instruction set}

To end the first part of the talk, namely an overview of the transputer, 
I will say a little about the CPU architecture.

There are 3 series of transputers, the T2, the T4 and the T8. I have 
examples of all of them with me. The basic differences are that the T4 
and T8 are both 32 bit processors, while the T2 is only 16 bit. The T8 
has an internal floating point coprocessor which the T4 doesn't have, but 
apart from that the 2 families are almost identical, to the extent that 
you can pull a T4 out of a circuit board, plug a T8 in place of it and 
expect the machine to work when powered up. 

\noindent
{\bf Put up OHP : Registers (page 32 of databook)}

The 3 familes of transputer have essentially the same CPU architecture. 
The CPU has only 6 registers : A, B, C form a stack used for arithmetic; 
the workspace register points to local variables in the processor's 
memory; the next inst register is what you'd think of as a program 
counter and points to the next instruction to be executed; finally the 
Operand register is used to build up operands, and indeed instructions, 
and I'll explain how that's used in a moment.

The small number of registers is not the performance disaster that you'd 
expect. Remember there is RAM on the transputer chip -- RAM that can be 
accessed in one machine cycle. So you typically regard part of that RAM 
as local variable storage and use it as aditional registers.


First let me explain the use of the stack. It's basically what you'd 
expect if you've ever used a stack based programming language, or a real 
(HP) calculator. You push numbers onto the top of the stack (A end) and 
arithmetic operations, like add, take numbers off the stack, perform the 
operation, and push the result back onto the stack. 

Now for the instruction set. When you first see it, you wonder quite what 
the designer was on. But when you think about it a bit, you realise that 
it is, in fact, a very simple and powerful instruction set.

\noindent
{\bf Put up OHP : Instruction Format (page 33 of the databook)}

The instruction set is based around a byte code. A basic instrction is 1 
bytes long, and the 2 nybbles in the byte specify the operation (high 
nybble) and operand (low nybble). Of course with only 4 bits specifying 
the instruction there can only be 16 instructions, right?

Wrong!. There are a lot more than that, and I'd better explain how they 
are produced. 

Of the 16 possible operations, 13 of them are the 13 most common 
operations in a machine code program. There are operations to load a 
constant onto the stack, to load a value from memory location, either 
relative to the workspace register or the top of stack, similar store 
instructions, jump, call, add constant and so on. 

It is therefore possible to load a 4 bit number onto the stack in one 
instruction. Or to access one of the first 16 local variables. But how to 
we load larger numbers or access other memory locations?

The answer lies that that operand register that I've not explained yet. 
Two more of the 16 basic instrctions peform the following operations. 
Eitherstick the operand of the current instruction in the low 4 bits of
the operand register and shift it left 4 bits, or negate the operand
register,insert and shift. Other instructions, like load constant,
actually put their operand into the low 4 bits of the operand register, 
and then use the contents of the entire register as their operand. And 
then clear the operand register to 0s.

What this means is that you can build up an operand of more than 4 bits 
in the operand register and then, say, use is as a constant for the load 
constant instruction, or an offset for a load or store, and so on. This 
may sound inefficient, but actually, it makes the instruction decoding 
process in the CPU much simpler (and thus faster) and anyway, small 
numbers are a lot more common than large ones -- think of the number of 
times you want to increment a variable by 1, for example.

Well, that's solved the problem of only having 4 bit operands, now for 
the problem of not enough instructions. The answer, again, lies in the 
operand register. The last of the 16 possibilities for the operation is 
called `operate'. It takes the contents of the operand register (after 
loading the operand part of its own byte, of course) and treats them as 
an instruction to execute. Fairly obviously, these instructions can't 
have explicit operands (the operand register being already in use), so 
they all operate on values in the arithmetic stack.

Again, the instruction set has been designed logically. The 16 
instructions you can get by using the `operate' operation with the 16 
possible operands are the most common program operations, arithmetic, 
logical, and conditional tests. Less frequently used operations, like 
multiply and divide, need one of the 2 possible prefix instructions to 
set the higher bits of the operand register. That gives 512 possible 
instructions (4 bits from the operate instruction, 4 from the prefix 
instruction, and there are 2 possible prefix instructions), which turns 
out to be enough for the entire instruction set. So no instruction is 
more than 16 bits long.

\noindent
{\bf Using transputers}

Now that we all know a little about what's inside a transputer, I want to 
talk about how to use them. Let's start with transputer links.

\noindent
{\bf Transputer links}

A transputer link, as I've said before, is a bidirectional serial link 
running (normally) at 10 or 20 Mbps. It consists of 2 TTL level signals, 
one output and one input on each transputer, and a common ground. To 
connect a transputer link, you simply connect the output of one 
transputer to the input of the other and vice versa. Being a simple 
point-to-point link means there is no arbitration necessary, and no 
possibility of contention on the link.

For short distances, say between transputers in the same machine, you 
just link the signals up with wires or PCB tracks. For longer distances 
you can convert the signals to RS422 levels (or some other differential 
standard) to improve noise immunity.

Each transputer normally has 4 links. This means you can make up a square 
lattice, or a cube (with one spare link at each corner), or all sorts of 
other more complex structures.

Of course if you want to make a transputer system where you can rearrange 
the links 'on the fly', you can use conventional logic circuits to switch 
the signals about. They are just plain TTL level logic signals.

\noindent
{\bf Simplest Transputer System}

So, what do you actually need to use a transputer? 

\noindent
{\bf put up OHPs of transputer circuit from thesis as appropriate}

Well, obviously you need a transputer. And a 5MHz clock, and a circuit to 
generate a reset signal. And nothing more.

Don't worry, by the way, about the mention of the 5MHz clock. This 
processor has an internal phase lock loop circuit that generates a 20MHz 
or 30MHz internal clock from the 5MHz external clock. It was designed 
this way because it's a lot easier to route a 5MHz clock around the 
system than a 20MHz one.

There is a little ROM in the transputer that contains a program allowing 
the transputer to be booted via one of the links. You can send commands 
over the link to read/write any byte of the transputer's memory, or to 
download a program into the transputer and run it.

\noindent
{\bf Put up OHP : C012 pinout (page 549 in databook)}

This is all very well, but what do you connect that transputer link to? 
Another transputer is no help, because you'd have to boot that one. 
Fortunately, there were a pair of devices called link adapters (the C011 and 
C012). They are best described as UARTs for the transputer link. They 
interface between a normal processor's 8 bit bus and a transputer link. 

How many of you know what a PDP11 is? How many of you own a PDP11? And
have programmed it in machine code? About the first I/O device you learn
about on the PDP11 is the DL11, a simple dumb-UART based serial interface.
Amazingly, the C012 is very similar to the DL11 in many ways -- it has 4
registers, for example : receive data, transmit data, receiver status,
transmitter state. Just like the DL11. 

\noindent
{\bf External RAM}

That's all very well, but 4K of RAM (the typical internal RAM of a 
transputer) is not very much. Can you add external RAM? 

\noindent
{\bf Put up OHP : T425 pinout (page 328 in databook)}

Of course you can. On the 32 bit transputers, the T4 and T8, there is a
multiplexed address and data bus (32 bits data, 30 bits longword address).
And write signals for the 4 bytes of RAM. And 5 timing signals here for
things like Address Strobe. 

And that brings me to one of the nicest features of the transputer. The 
timing of those strobes is configurable. You link the MemConfig line to 
one of the data lines, and just after reset, the transputer pulses each 
data line in turn looking for the one conencted ot the MemConfig input. 
One connection gives optimum timing for static RAM. Another gives timing 
for conventional Dynamic RAM. If you've ever tried to design a DRAM 
controller from scratch you know what a pain it can be. You have to split 
the address into 2 halves and multiplex them in turn to the RAM address 
pins. And provide carefully timed Row Address Strobe and Column Address 
Strobe signals. And, of course, provide a refresh address. 

The transputer makes this easy. 3 of the timing strobes are exactly the 
RAS, CAS and address multiplexer control signals. And the transputer 
generates its own refresh address. All you need to provide externally is 
an address latch and the address multiplexers. The nasty stuff -- the 
timing -- is handled inside the transputer.

Other connections to MemConfig provide other useful bus timings. And if 
that is not enough for you, you can even link MemConfig to a 1 bit wide 
PROM connected to the transputer bus and program your own timings. 

Yes, it's easy to add external RAM to these devices. 

\noindent
{\bf put up OHP : T222 pinout (page 450 of the databook)}

The 16 bit T2 transputer is a lot simpler. It's got a conventional, 
separate 16 bit data bus and 16 bit address bus. And fairly conventional 
bus timing signals. Alas there's no internal DRAM controller.

This reminds me of a somewhat worrying story. There was a large data 
aquisition system. It consisted of a number of cardcages. Each cardcage 
contained 17 boards. 16 of the boards were identical and contained 16 
channels of fast ADC and related electronics. The last card contained a 
transputer based computer which read the data from the ADCs. The racks 
communicated via (buffered) transputer links.

Alas it was designed by more than 1 person -- a sure way of ending up 
with a mess. The original specification was designed for a T2 transputer 
and the backplane bus between the transputer and the ADCs was essentially 
the T2 bus.

Too late they realised that the T2 wasn't powerful enough, and they 
changed to a T4 or T8. Now, there would have been enough pins on the 
backplane connector to route the (multiplexed) T4 bus between the cards. 
But no, the backplane bus ahd been defined and was the T2 bus.

So what did they do? They demultiplexed the T4 bus to sepearate address
and data (not a bad idea) and then remultiplexed the data to 16 bits (a
very bad idea).  Every transputer memory cycle became 2 backplane cycles,
with no obvious way to distinguish between them. The result, of course, 
was the mess it appears.

Anyway, unless you do silly things like that, it's easy to add external 
RAM to a transputer.

You can add (EP)ROM and I/O devices too in the conventional way. In fact
the earliest transputer boards were made before the link adapters were
available. I have one here, an Inmos B001 {\bf wave it about}. It has a
transputer, RAM, EPROM and a couple of RS232 ports on it. The transputer
is set (by the state of one of the pins) not to boot from the link, but to
run the program in the EPROM. This program allows the transputer to
download a program over the RS232 interface and run it, so you can boot
this board from any host computer with an RS232 interface. Of course the
transputer does have the 4 links, which you can use to link to other 
transputers, like the B003 {\bf and wave that about} which contains 4 
transputers, each with local memory.

A more typical Transputer board is this ISA card for PCs {\bf wave about 
a Microway Monoputer or similar}. It contains a single transputer, RAM, 
and a link adapter that appears as an I/O device to the PC. Fairly 
obviously, you can boot the transputer via that link adapter. And connect 
the transputer's other links to other transputers via the connectors on 
the back.

\noindent
{\bf TRAMs}

Although, as I said earlier, the simplest transputer system is little 
more than the transputer itself, the memory is too limited for most uses, 
and the I/O consists solely of transputer links. A number of standard 
modules were therefore developed, each containing a transputer and other 
circuity. These modules are called TRAMs, often incorrectly said to stand 
for Transputer + RAM. In fact it's nothing more that TRAnsputer Module.

These TRAMs in general appear externally to be electrically similar to 
bare transputer chips. They communicate via the standard transputer 
links, and each module requires a 5MHz clock, and the reset signal. The 
simplest TRAMs are a transputer + external RAM, and are commonly known as 
'compute TRAMs' {\bf wave some about, pointing out the different 
transputers}. 

\noindent
{\bf Put up OHP : B420 block diagram (IQ book page 255)}

I believe that in a couple of weeks you're having a talk on a vector 
computer. This board here is called a VecTRAM {\bf hold one up} and 
contains a transputer linked to a vector processor chip. It is thus a 
complete (albeit small) vector processor that you can hold in one hand. 
And of course, like all TRAMs you can connect several of them together 
(if you are lucky enough to find them!).

\noindent
{\bf Put up OHP : B008 block diagram (IQ book page 309)}

The TRAMs have standard dimensions and pinouts, and plug into a number of 
standard motherboards that provide the power, clock, and reset signals, 
and which interconnect the links. A typical example is this ISA 
motherboard {\bf wave a B008 about}. It holds up to 10 of the smallest 
TRAMs or an equivalent area of larger ones.

\noindent
{\bf Put up OHP : C004 block diagram (page 480 of databook)}

Some of the transputer links of the TRAMs on this motherboard are linked 
from one TRAM to the next to form a sort of pipeline structure. Other 
links are connected to this chip {\bf point to C004}, a C004 link switch. 
This is best described as a sort of telephone exchange for transputer 
links -- it can be connected to up to 32 transputer links and it allows 
any link to be connected to any other link. The connections are loaded 
over (you guessed it) yet another transputer link!

\noindent
{\bf Input/Output}

In the title of this talk, I described the transputer as a 
microcontroller. Already we have seen that it is similar to most 
microcontrollers in that it is a single chip containing a processor, 
memory, and I/O. In the last part of the talk I want to mention how to 
link other forms of I/O -- other, that is, than transputer links -- to 
the transputer.

There are basically 2 ways to do it. The first is to use one of the link 
adapters I mentioned much earlier and a conventional microcontroller. The 
link adapter is connected to the microcontroller's bus and the 
microcontroller can transfer data to or from the transputer. 

\noindent
{\bf Put up OHP : I/O port page from thesis}

The other way is to memory map a conventional I/O device, like a serial 
port, or a parallel interface in the transputer's address space -- to 
connect such an I/O device to the transputer's bus. Of course the 
transputer doesn't have to be the one you're doing all the computations 
on -- you can link up a separate transputer for I/O.

There is no equivalent to PEEK and POKE, or pointer indirection in Occam. 
What you can do, though is PLACE a variable AT a given address. So that 
you can, for example, PLACE an 8 word array at the address of your 
8-register I/O chip, and by referencing items in that array you are 
actually reading and writing the registers in the I/O device.

I probably shouldn't mention the next trick, but you'd probably discover 
it for yourself anyway. Earlier in the talk I mentioned that the only way 
for processes to communnicate, even when running on the same transputer, 
was via channels. There were no shared variables, and the Occam compiler 
strictly enforces the rule that only one (parallel) process can access a 
given variable.

What the compiler {\em doesn't} prevent is PLACEing 2 variables at the 
same address and then accessing them from different processes. The 
compiler doesn't seem to recognise that they are, in fact, the same 
variable. Doing this is one way of `violating the Occam model', and it 
has to be done with great care or the results can be unpredictable. But 
it has been known to be useful...

\noindent
{\bf put up OHP : SCSI TRAM block diagram (IQ book page 283)}

There have been a few standard I/O TRAMs made. I have 3 examples here 
{\bf wave them about as ever} to link to ethernet, GPIB, and SCSI-1.

\noindent
{\bf put up OHP : M212 block diagram (page 464 of databook)}

There is one other way of doing I/O that I hesitate to mention because 
it's so specialised and because I don't have an actual example of the 
chip. The device is the M212 disk control transputer. It's basically a T2 
transputer core with only 2 links, but with the electonics to connect to 
floppy disk drives and the (current at the time) ST506 type of hard disk. 
This, of course, was developed as a way to add mass storage to a 
transputer system.

At the very start of this talk, I mentioned I was a particle physicist. 
Perhaps I should end by saying how that is associated with transputers. 
The answer is this PCB here {\bf wave about one of my Transputer boards} 
This is a transputer based computer, with external RAM, and with buffers 
to connect it to a particle detector readout system, which I have not 
brought along. The complete system consisted of 2 of these cards, one to 
load a program into a rather complex hardware timing pulse generator to 
control a CCD type detector, and the other to read the aquired data out 
of a framestore circuit. Once the timing generator had been loaded, the 
first transputer could be used to process some of the incoming data. And 
of course the entire system communicated (and was booted) over a 
transputer link.

\end{document}
