Difference between pages "Linux" and "KT11-B Technical Manual"

From Computer History Wiki
(Difference between pages)
Jump to: navigation, search
m (split cat)
 
m (Timing Logic: +link)
 
Line 1: Line 1:
{{Infobox OS
+
As a Special Systems Option, the [[KT11-B Paging Option|KT11-B]] does not have the usual [[DEC]] Technical Manual. This page attempts to provide at least the high-level portions of such a manual.
| image = Linux 0.11 on Qemu.jpg
 
| caption = Linux 0.11 booted on Qemu
 
| name = Linux
 
| creator = Linus Torvalds
 
| year introduced = 1991
 
| architecture = Originally [[80386]] now cross-platform.
 
| type = Time-sharing
 
| multitasking = Multitasking with paging/swap
 
}}
 
  
Linux is a computer [[operating system]] originally developed in the 1990s by a student Linus Torvalds. Today's Linux systems are split into various branches, developed over time by millions of volunteers, Debian, Ubuntu, RedHat, [[IBM]] as well as various commercial vendors.
+
'''Note:''' KT11-B operation must be thoroughly understood (either from the KT11-B page above, or the Option Description manual) before trying to read this page. In particular, KT11-B external [[register]] names must be known, as well as the function of the [[Central Processing Unit|CPU]] and [[peripheral|device]] [[UNIBUS]]es, and also high-level internal entities such as the associative memories, and the scratchpad memory.
  
Versions of relevance for hobbyists include ports to the [[Amiga]], early [[Macintosh|Macs]], a partial port to the [[VAX]] and a port to [[System/390]] as well as various [[SGI]] and [[Sun Microsystems]] workstations and servers.
+
'''''Further Note:''''' This page is under construction. It is believed to be accurate, but the writer's understanding on the KT11-B circuity is not complete, and so it may contain errors.
  
Linux gained in popularity because it was a 'fresh' implementation of [[UNIX]], not incumbered by the AT&T vs BSDI/CSRG legal wars, and was not sidelined because of it.  While the BSD world stalled during this lawsuit, Linux was able to thrive, and pick up users.
+
==High-Level Overview==
  
== Minix days ==
+
[[Image:KT11-B_DataPaths.jpeg|450px|right|Main data paths]]
  
The first public version of Linux (0.01) was originally bootstrapped from within [[Minix]].  The first versions required that you have a minix filesystem, and it booted from floppies ONLY.  The only way to determine where the root filesystem was located, was to hex edit the boot floppy.  Once Linux started to gain in popularity, it prompted one of the more famous flamewars between [[Linus Torvalds]] and [[Andy Tanenbaum]].  You can read about it [http://www.oreilly.com/catalog/opensources/book/appa.html here].
+
The heart of the KT11-B is the scratchpad memory, which is used to hold both cached [[page table]] entries, and also most of the KT11-B registers.
  
The [http://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 notes file] from back then goes into the details.
+
(Since the KT11-B does not contain any internal registers to which the CPU does not have access, the term 'register' hereinafter refers to any of the registers visible to the CPU in the KT11-B.)
  
== Early distros ==
+
The scratchpad has a built-in [[address]] multiplexor, so address lines from a variety of sources are all fed directly into it; see the "Keys and Associative Memory" section below, for details. A latching input data multiplexor is provided to select among data from a number of sources for storage in the scratchpad.
  
MCC Interim Linux, from Owen Le Blanc of the Manchester Computing Centre, was the first distro to be installable without the need of another operating system to partition, and format the hard disk.  With the ease of installing from MCC, it gave rise to more comprehensive distros, namely SLS. MCC started out with Linux 0.12.
+
One of the possible inputs to that mux is the output of the scratchpad itself: since there is no latch on the output of the scratchpad, the ability to select its output, and then latch it, is sometimes used to hold data from the scratchpad for other users. (E.g. the comparator which checks to see whether cycles are in the Simple part of the [[address space]].)
  
[[SLS]], released some time in 1992. You can find some of the old SLS installs [http://www.oldlinux.org/Linux.old/distributions/SLS/?C=S;O=A here]. [[Qemu]] is capable of running some of them, keep in mind hard disks need to be small, and of course you'll need to force an ISA bus install (-M isa).
+
A uni-directional address [[bus]] runs from the CPU's UNIBUS to the device UNIBUS; the KT11-B internals, such as the scratchpad, may also generate addresses (e.g. for loading page table entries). An address multiplexor for this bus can perform non-trivial selections (e.g. getting high address bits - i.e. physical page numbers - from scratchpad output, and low bits - i.e. addresses within a page - from the incoming address bus).
  
[[Debian]] and [[Slackware]] quickly superseded SLS, and continue to this day.
+
A bi-directional data bus connects to both UNIBUSes; the KT11-B may also source data to the CPU (e.g. when the CPU is reading KT11-B registers), or obtain data from either UNIBUS (e.g. for reading page table entries, or to intercept data the CPU is attempting to save to memory during a [[page fault]]).
  
== Early Versions ==
+
The majority of the signals that control the operation of the buses, multiplexors, etc. are generated by random [[logic]] - a group of [[gate]]s (and sometimes [[flip-flop]]s as well); it is usually necessary to inspect the actual drawings to ascertain how any major data-handling item is controlled.
*[[Linux 0.00|0.00]] The first "AAAABBBB" Kernel.
 
*[[Linux 0.01|0.01]] The initial non working public version.
 
*[[Linux 0.02|0.02]] The first 'working' public version, able to run bash & GCC.
 
*0.03 Linux apparently could build GCC under itself.
 
*0.10 Bug fixes, and greater stability.
 
*[[Linux 0.11|0.11]] The last version to be cross compiled form [[Minix]].  Also first version with a floppy disk driver.
 
*[[Linux 0.12|0.12]] Added PTY,shared libc/libm & 387 emulation support, along with paging (VM).
 
*0.95 Linux had made rapid progress at this point, and was optimistically approaching the 1.0 milestone.
 
*[[Linux 0.95a|0.95a]]
 
*0.96a Added SCSI support
 
*0.96b
 
*0.96c Introduced UNIX domain sockets (still no TCP/IP) & the ext filesystem
 
*0.97 Adds MS-DOS filesystem.
 
*0.98 Introduction of TCP/IP mainly from Ross Biro
 
*[[Linux 0.99pl9|0.99pl9]] This was the basis for the [[Amiga]] [[m68k]] port.
 
  
== Linux History ==
+
If the optional extended [[cache]] (holding an additional scatchpad memory, and an array of associative memories) is installed, it functions in much the same way as the base cache, except that since it does not hold any registers, its role is nowhere near as central as that of the main scratchpad.
  
 +
===States===
  
Linux History
+
A key part of KT11-B operation is a state composed of two parts, the 'X' or major part, and the 'Y' or minor part; the progression of this through the various states is the major control mechanism in the KT11-B.
Note: The following text was written by Linus on July 31 1992. It is a collection of various artifacts from the period in which Linux first began to take shape.  
 
  
This is just a sentimental journey into some of the first posts concerning linux, so you can happily press Control-D now if you actually thought you'd get anything technical.  
+
Note that a state is only part of what controls the operation of the KT11-B; in many states, depending on control signal(s), differing actions may be taken, before the KT11-B moves on the same next state.
  
 +
The X state counter (composed of a pair of D flops, with 4 AND gates with inverting inputs) creates individual major state outputs, signals 'XSRx' (x = 0-3).
  
<pre>
+
The Y state counter is an M826 Flip Chip; its outputs are signals 'YSRx' (x = 0, 1 ,3, 7, 15, 14, 12, 8). (The odd sequence of minor state numbers, and the fact that they are not in numerical order, ''is'' confusing, but since that's what's on the prints, that nomenclature has to be used.)
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)  
 
Newsgroups: comp.os.minix
 
Subject: Gcc-1.40 and a posix-question
 
Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
 
Date: 3 Jul 91 10:00:50 GMT
 
Hello netlanders,  
 
Due to a project I'm working on (in minix), I'm interested in the posix
 
standard definition. Could somebody please point me to a (preferably)
 
machine-readable format of the latest posix rules? Ftp-sites would be  
 
nice.  
 
</pre>
 
  
The project was obviously linux, so by July 3rd I had started to think about actual user-level things: some of the device drivers were ready, and the harddisk actually worked. Not too much else.  
+
The two groups of signals are combined into signals which indicate that the KT11-B is in that state, for each individual major/minor state, by NAND gates; inverters then provide non-inverted forms of each.
  
 +
====State Table====
  
As an aside for all using gcc on minix - [ deleted ]
+
The following table shows the state transitions:
  
Just a success-report on porting gcc-1.40 to minix using the 1.37 version made by Alan W Black & co.  
+
{| class="wikitable"
 +
! State !! Next State(s) !! Comment
 +
|-
 +
| 0.0 || 0.8, 1.0 || Idle
 +
|-
 +
| 0.8 || 0.12 || Interrupt, Trap and Start User
 +
|-
 +
| 0.12 || 0.14
 +
|-
 +
| 0.14 || 0.15
 +
|-
 +
| 0.15 || 0.7A
 +
|-
 +
| 0.7A || 0.3A
 +
|-
 +
| 0.7B || 0.3B || Although the state names are identical to the preceding ones, this is shown on the state diagram as a separate state loop
 +
|-
 +
| 0.3A || 0.1A
 +
|-
 +
| 0.3B || 0.1B || Window?
 +
|-
 +
| 0.1A || 0.0
 +
|-
 +
| 0.1B || 1.1 || Although the state name is identical to the preceding one, this is shown on the state diagram as a separate state loop
 +
|-
 +
| 1.0 || 1.1, 3.0
 +
|-
 +
| 1.1 || 1.3
 +
|-
 +
| 1.3 || 1.7, 3.3 || Exec-per-Process
 +
|-
 +
| 1.7 || 0.7B, 1.15
 +
|-
 +
| 1.15 || 1.14 || Page Violation?
 +
|-
 +
| 1.14 || 1.12
 +
|-
 +
| 1.12 || 0.12
 +
|-
 +
| 1.8 || 1.0
 +
|-
 +
| 2.0 || 0.0
 +
|-
 +
| 2.1 || 2.0, 2.3 || Shared Entry?
 +
|-
 +
| 2.3 || 2.7
 +
|-
 +
| 2.7 || 2.15
 +
|-
 +
| 2.15 || 2.14 || Page Violation?
 +
|-
 +
| 2.14 || 0.14
 +
|-
 +
| 2.12 || - || State does not exist
 +
|-
 +
| 2.8 ||  - || State does not exist
 +
|-
 +
| 3.0 || 2.0, 3.1, 3.8
 +
|-
 +
| 3.1 || 1.1, 2.1, 3.0
 +
|-
 +
| 3.3 || 3.1, 3.7A
 +
|-
 +
| 3.7A || 1.7
 +
|-
 +
| 3.7B || 3.3 || Although the state name is identical to the preceding one, this is shown on the state diagram as a separate state loop
 +
|-
 +
| 3.15 || 3.7B
 +
|-
 +
| 3.14 || 3.15
 +
|-
 +
| 3.12 || 3.14
 +
|-
 +
| 3.8 || 1.8, 3.12
 +
|}
  
<pre>
+
This table is a transcription of the single-page one in the KT11-B Option Description; that diagram contains a number of labels, but it is not completely clear which states (or transitions) the labels apply to. Over time the hope is to check this table against the multi-page table in that document, and also better described what each state means/does.
Linus Torvalds torvalds@kruuna.helsinki.fi
 
PS. Could someone please try to finger me from overseas, as I've
 
installed a "changing .plan" (made by your's truly), and I'm not certain
 
it works from outside? It should report a new .plan every time.
 
</pre>
 
  
So I was clueless - had just learned about named pipes. Sue me. This part of the post got a lot more response than the actual POSIX query, but the query did lure out arl from the woodwork, and we mailed around for a bit, resulting in the Linux subdirectory on nic.funet.fi.
+
==Drawing Conventions==
  
Then, almost two months later, I actually had something working: I made sources for version 0.01 available on nic sometimes around this time. 0.01 sources weren't actually runnable: they were just a token gesture to arl who had probably started to despair about ever getting anything. This next post must have been from just a couple of weeks before that release.  
+
The drawings are somewhat easier to understand if the conventions used in the drawings are understood. Although no document lists them, they can be ascertained by study of the drawings.
  
<pre>
+
Note that in the prints, the symbol '*' in a signal name means logical AND, and '+' means logical OR; this notation is used throughout the KT11-B prints.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
 
Newsgroups: comp.os.minix
 
Subject: What would you like to see most in minix?
 
Summary: small poll for my new operating system
 
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
 
Date: 25 Aug 91 20:57:08 GMT
 
Organization: University of Helsinki
 
  
Hello everybody out there using minix -
+
===Signal Names===
I'm doing a (free) operating system (just a hobby, won't be big and
 
professional like gnu) for 386(486) AT clones. This has been brewing
 
since april, and is starting to get ready. I'd like any feedback on
 
things people like/dislike in minix, as my OS resembles it somewhat
 
(same physical layout of the file-system (due to practical reasons)
 
among other things).
 
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
 
This implies that I'll get something practical within a few months, and
 
I'd like to know what features most people would want. Any suggestions
 
are welcome, but I won't promise I'll implement them :-)
 
Linus (torvalds@kruuna.helsinki.fi)
 
PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
 
It is NOT protable (uses 386 task switching etc), and it probably never
 
will support anything other than AT-harddisks, as that's all I have :-(.
 
</pre>
 
  
Judging from the post, 0.01 wasn't actually out yet, but it's close. I'd guess the first version went out in the middle of September -91. I got some responses to this (most by mail, which I haven't saved), and I even got a few mails asking to be beta-testers for linux. After that just a few general answers to quesions on the net:
+
Signal names as written in this drawing set usually start with 'Dxx', where 'xx' is related to the drawing number (given in the table below). (This is similar to the convention in the [[KA11 CPU]] drawings, where 'Kxx-y' means that the signal originates on page y of drawing xx.) Note that the 'Dxx' correspondence seems to sometimes be off by one; i.e. a signal tagged 'D04' can be found originating on drawing 05.
  
<pre>
+
In signal names of the form 'XXX (yy)', 'yy' is a bit number (in standard [[PDP-11]] order) in a register or bus. For signals which are provided in both asserted low and asserted high forms, one will see signal names of the form 'XXX (y)', where 'y' is 1 or 0. Note that sometimes these two notations are combined, and one can find signal names of the form 'XXX (yy) (z)'. Inverted (asserted low) signals are also sometimes shown as '-XXX'; this form is particularly common with composite signals (i.e. '-(xxx * yyy)').
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)  
 
Newsgroups: comp.os.minix
 
Subject: Re: What would you like to see most in minix?
 
Summary: yes - it's nonportable
 
Message-ID: <1991Aug26.110602.19446@klaava.Helsinki.FI>
 
Date: 26 Aug 91 11:06:02 GMT
 
Organization: University of Helsinki
 
In article <1991Aug25.234450.22562@nntp.hut.fi> jkp@cs.HUT.FI
 
(Jyrki Kuoppala) writes:
 
>> [re: my post about my new OS]  
 
>
 
>Tell us more! Does it need a MMU?
 
Yes, it needs a MMU (sorry everybody), and it specifically needs a  
 
386/486 MMU (see later).  
 
>
 
>>PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
 
>>>It is NOT protable (uses 386 task switching etc)
 
>
 
>How much of it is in C? What difficulties will there be in porting?
 
>Nobody will believe you about non-portability ;-), and I for one would
 
>like to port it to my Amiga (Mach needs a MMU and Minix is not free).
 
Simply, I'd say that porting is impossible. It's mostly in C, but most
 
people wouldn't call what I write C. It uses every conceivable feature
 
of the 386 I could find, as it was also a project to teach me about the
 
386. As already mentioned, it uses a MMU, for both paging (not to disk
 
yet) and segmentation. It's the segmentation that makes it REALLY 386
 
dependent (every task has a 64Mb segment for code & data - max 64 tasks
 
in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
 
It also uses every feature of gcc I could find, specifically the __asm__
 
directive, so that I wouldn't need so much assembly language objects.
 
Some of my "C"-files (specifically mm.c) are almost as much assembler as
 
C. It would be "interesting" even to port it to another compiler (though
 
why anybody would want to use anything other than gcc is a mystery).  
 
</pre>
 
  
Note: linux has in fact gotten more portable with newer versions: there was a lot more assembly in the early versions. It has in fact been ported to other architectures by now.
+
The following specific signal names have the meaning given:
  
<pre>
+
* Signals of the form 'x.y' are states, with 'x' being the major state, and 'y' being the minor state; the origin of all of them is on page D12.
Unlike minix, I also happen to LIKE interrupts, so interrupts are
+
* Signal names 'A (x)' are the internal address bus, and 'D (x)' are the data bus.
handled without trying to hide the reason behind them (I especially like
+
* Signal names starting with 'SP' refer to the scratchpad memory; SPIN is its input bus, and SPDA is its output bus.
my hard-disk-driver. Anybody else make interrupts drive a state-
+
* Signal names starting with 'AM' sometimes refer to the associative memory, but there are others, e.g. signals named 'ENB AMX' which control the address multiplexor.
machine?). All in all it's a porters nightmare.
+
* Signal names starting with 'DV' refer to the UNIBUS '''from''' the KT11-B to the devices and memory of the system.
>As for the features; well, pseudo ttys, BSD sockets, user-mode
+
* Signal names starting with 'CP' refer to the UNIBUS '''to''' the KT11-B from the KA11 CPU.
>filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger),
+
* Signal names starting with 'PGC' refer to the contents of the Control Status register.
>window size in the tty structure, system calls capable of supporting
+
* Signal names starting with 'PGM' refer to the contents of the Maintenance register.
>POSIX.1. Oh, and bsd-style long file names.
 
Most of these seem possible (the tty structure already has stubs for
 
window size), except maybe for the user-mode filesystems. As to POSIX,
 
I'd be delighted to have it, but posix wants money for their papers, so
 
that's not currently an option. In any case these are things that won't
 
be supported for some time yet (first I'll make it a simple minix-
 
lookalike, keyword SIMPLE).  
 
Linus (torvalds@kruuna.helsinki.fi)
 
PS. To make things really clear - yes I can run gcc on it, and bash, and
 
most of the gnu [bin/file]utilities, but it's not very debugged, and the  
 
library is really minimal. It doesn't even support floppy-disks yet. It
 
won't be ready for distribution for a couple of months. Even then it
 
probably won't be able to do much more than minix, and much less in some
 
respects. It will be free though (probably under gnu-license or similar).
 
</pre>
 
  
Well, obviously something worked on my machine: I doubt I had yet gotten gcc to compile itself under linux (or I would have been too proud of it not to mention it). Still before any release-date.
+
===Common Circuits===
  
Then, October 5th, I seem to have released 0.02. As I already mentioned, 0.01 didn't actually come with any binaries: it was just source code for people interested in what linux looked like. Note the lack of announcement for 0.01: I wasn't too proud of it, so I think I only sent a note to everybody who had shown interest.  
+
[[Image:LatchingMux.jpg|right|Latching mux]]
  
<pre>
+
This circuit (first used in the [[KA11]]) is seen in several places in the KT11-B. It is almost always seen as an array of identical circuits, since it provides a 3-input multiplexor with latching capability, and it is used on data paths (usually 16 bits wide).
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
 
Newsgroups: comp.os.minix
 
Subject: Free minix-like kernel sources for 386-AT
 
Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI>
 
Date: 5 Oct 91 05:41:06 GMT
 
Organization: University of Helsinki
 
Do you pine for the nice days of minix-1.1, when men were men and wrote
 
their own device drivers? Are you without a nice project and just dying
 
to cut your teeth on a OS you can try to modify for your needs? Are you
 
finding it frustrating when everything works on minix? No more all-
 
nighters to get a nifty program working? Then this post might be just
 
for you :-)
 
As I mentioned a month(?) ago, I'm working on a free version of a
 
minix-lookalike for AT-386 computers. It has finally reached the stage
 
where it's even usable (though may not be depending on what you want),
 
and I am willing to put out the sources for wider distribution. It is  
 
just version 0.02 (+1 (very small) patch already), but I've successfully
 
run bash/gcc/gnu-make/gnu-sed/compress etc under it.
 
Sources for this pet project of mine can be found at nic.funet.fi
 
(128.214.6.100) in the directory /pub/OS/Linux. The directory also
 
contains some README-file and a couple of binaries to work under linux
 
(bash, update and gcc, what more can you ask for :-). Full kernel
 
source is provided, as no minix code has been used. Library sources are
 
only partially free, so that cannot be distributed currently. The
 
system is able to compile "as-is" and has been known to work. Heh.
 
Sources to the binaries (bash and gcc) can be found at the same place in
 
/pub/gnu.
 
ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled
 
(and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to
 
set it up if you want to run it, so it is not yet a standalone system
 
for those of you without minix. I'm working on it. You also need to be
 
something of a hacker to set it up (?), so for those hoping for an
 
alternative to minix-386, please ignore me. It is currently meant for
 
hackers interested in operating systems and 386's with access to minix.
 
The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
 
you are still interested, please ftp the README/RELNOTES, and/or mail me
 
for additional info.
 
I can (well, almost) hear you asking yourselves "why?". Hurd will be
 
out in a year (or two, or next month, who knows), and I've already got
 
minix. This is a program for hackers by a hacker. I've enjouyed doing
 
it, and somebody might enjoy looking at it and even modifying it for
 
their own needs. It is still small enough to understand, use and
 
modify, and I'm looking forward to any comments you might have.
 
I'm also interested in hearing from anybody who has written any of the
 
utilities/library functions for minix. If your efforts are freely
 
distributable (under copyright or even public domain), I'd like to hear
 
from you, so I can add them to the system. I'm using Earl Chews estdio
 
right now (thanks for a nice and working system Earl), and similar works
 
will be very wellcome. Your (C)'s will of course be left intact. Drop me
 
a line if you are willing to let me use your code.
 
Linus
 
PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
 
"forward error - strawberry unknown domain" or something.  
 
</pre>
 
  
Well, it doesn't sound like much of a system, does it? It did work, and some people even tried it out. There were several bad bugs (and there was no floppy-driver, no VM, no nothing), and 0.02 wasn't really very useable.
+
The latch is cleared by de-asserting the 'Latch' input; data from any of the three inputs (A, B, C) may then be selected for output, and potentially storage, by asserting the matching 'Gate' input. Asserting 'Latch' while an input is selected then stores the current output of the mux.
  
0.03 got released shortly thereafter (max 2-3 weeks was the time between releases even back then), and 0.03 was pretty useable. The next version was numbered 0.10, as things actually started to work pretty well. The next post gives some idea of what had happened in two months more...  
+
(Asserting more than one input simultaneously ORs the two inputs together; this capability is used in the KA11, but probably not here.)
  
<pre>
+
[[Image:SRFlopSym.jpg|left|150px|Latching mux]]
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
 
Newsgroups: comp.os.minix
 
Subject: Re: Status of LINUX?
 
Summary: Still in beta
 
Message-ID: <1991Dec19.233545.8114@klaava.Helsinki.FI>
 
Date: 19 Dec 91 23:35:45 GMT
 
Organization: University of Helsinki
 
In article <469@htsa.htsa.aha.nl> miquels@maestro.htsa.aha.nl (Miquel van
 
Smoorenburg) writes:
 
>Hello *,
 
> I know some people are working on a FREE O/S for the 386/486,
 
>under the name Linux. I checked nic.funet.fi now and then, to see what was
 
>happening. However, for the time being I am without FTP access so I don't
 
>know what is going on at the moment. Could someone please inform me about it?
 
>It's maybe best to follow up to this article, as I think that there are
 
>a lot of potential interested people reading this group. Note, that I don't
 
>really *have* a >= 386, but I'm sure in time I will.
 
Linux is still in beta (although available for brave souls by ftp), and
 
has reached the version 0.11. It's still not as comprehensive as
 
386-minix, but better in some respects. The "Linux info-sheet" should
 
be posted here some day by the person that keeps that up to date. In
 
the meantime, I'll give some small pointers.
 
First the bad news:
 
- Still no SCSI: people are working on that, but no date yet.
 
Thus you need a AT-interface disk (I have one report that it
 
works on an EISA 486 with a SCSI disk that emulates the
 
AT-interface, but that's more of a fluke than anything else:
 
ISA+AT-disk is currently the hardware setup)
 
</pre>
 
  
As you can see, 0.11 had already a small following. It wasn't much, but it did work.  
+
The prints use an unusual symbol for an SR flop, with the Q outputs at the top (shown here).
  
 +
Some of the SR flops are variants with two 'set' inputs. Note that these are sometimes drawn with the two 'set' inputs on the left hand side, instead of the right; in this case, those inputs are being used as 'reset' inputs, and to compensate, the Q and -Q outputs are reversed; i.e. the usual Q output pin becomes the -Q output, and vice versa. (Since SR flops are symmetric with respect to the S/Q and R/-Q input/output pairs, this inversion is trivial.)
  
* still no init/login: you get into bash as root upon bootup.
+
==Signal Dictionary==
  
That was still standard in the next release.  
+
These are main control signals, their meaning, and the drawing page (below) where they are generated. Listings of the form 'aaa(x) (y-z)' indicate that 'aaa' is a group of signals generated on page y-z, and this is the xth; similarly for 'bbb(w-x) (y-z)'. (Note that occasionally the drawings use the notation 'ccc(p:q) for a control signal which acts on bits p through q, or the AND of bits p through q.)
  
 +
Note: A few of these are not actually generated as individual signals, only as composites. (E.g. "EXEC PER PROC" is only generated ANDed with "3.1". In that particular case, the drawing could have been modified to have an "EXEC PER PROC" output, but that would have been misleading, since that signal is not used elsewhere on its own.<!-- In other cases, such as "", that would not be possible.-->) Such cases are marked with a '+' on the signal name.
  
* although I have a somewhat working VM (paging to disk), it's not ready yet. Thus linux needs at least 4M to be able to run the GNU binaries (especially gcc). It boots up in 2M, but you cannot compile.
+
* A(0-17) (2-1): Internal address bus
 +
* A CLK (7-1):
 +
* AM CLK (5-2):
 +
* AMOK (6-1): Associative memory matched
 +
* AMXA(0-8) (2-2): Address mux output, high half
 +
* AMXB(0-8) (2-2): Address mux output, low half
 +
* CLC (7-1)
 +
* CLK A (13-1): Maintenance clock pulse
 +
* CLK AA (15-1):
 +
* CLR B (2-1): Clear latch of B (high) half of address mux
 +
* D(0-15) (7-2, 7-3): Internal data bus
 +
* DST (5-2):
 +
* ENB AMXA(0) (2-1): Select scratchpad output data for high address
 +
* ENB AMXA(1) (2-1): Select scratchpad input mux data for high address
 +
* ENB AMXA(2) (2-1): Select incoming address for high address
 +
* ENB AMXB(0) (2-1): Select scratchpad output data for low address
 +
* ENB AMXB(7:1) (2-1): Select scratchpad input mux data for low address
 +
* ENB AMXB(8,0) (2-1): Select special data for low and high bits of address
 +
* ENB AMXB(2) (2-1): Select incoming address for low address
 +
* ENB C (7-1): Enable C0/C1 on device UNIBUS
 +
* ENB CLK B (7-1):
 +
* ENB CLK C (7-1):
 +
* ENB CPD (7-1):
 +
* ENB D (7-1):
 +
<!-- * ENB SPMX0 (4-1): Select internal address bus for scratchpad input
 +
* ENB SPMX1 (4-1): Select internal data bus for scratchpad input
 +
* ENB SPMX2 (4-1): Select scratchpad output for scratchpad input -->
 +
* ENB SPOR(0) (6-1): Select scratchpad cache entry for read
 +
* ENB SPOR(1) (6-1): Select scratchpad cache entry for replacement
 +
* ENB SPOR(2) (6-1): Select scratchpad register for internal use
 +
* ENB SPOR(3) (6-1): Select scratchpad register for UNIBUS access
 +
* ENB XPOR(0-1, 3) (6-1): As above, but for extra scratchpad for optional cache extension
 +
* +EXEC PER PROC (3-1):
 +
* EXZE (5-1): Reference to Exec mode page 0
 +
* FORCE TIMEOUT (15-1):
 +
* INTRAP (5-1):
 +
* KEY(0) (8-1): Writeable page
 +
* KEY(1) (8-1): Public page
 +
* KEY(2) (8-1): Resident page
 +
* LONG (8-1): Address in Simple part
 +
* LONGF (10-1): PGM(12)
 +
* +LOOKUP (13-1):
 +
* NORMAL (3-1):
 +
* ODD ADD ERR (15-1):
 +
* PAGE (5-1): Cycle with paging enabled?
 +
* PAD SEL (5-1): Paging register selected?
 +
* PASS (3-1): PGM(11)
 +
* PGC(0), PGC(1) (11-1): Function (un-paged; normal; start user)
 +
* PGC(1:0) (7-1): Start user
 +
* PGC(4) (11-1): User mode
 +
* PGC(7) (11-1): Interrupted User
 +
* PGC(15:12) (11-1): Violation
 +
* PGM(0-4) (10-1): Replacement Counter
 +
* PGM(6) (10-1): Previous instruction User mode TRAP?
 +
* PGM(7) (10-1): Previous instruction fetch Private?
 +
* PGM(12) (10-1): Cycle to non-Simple part of addess space
 +
* PGM(13) (10-1): Window access (phase 1)?
 +
* PGM(14) (10-1): Window access (phase 0)?
 +
* PGM(15) (10-1): Time out
 +
* PKER (5-1): Paging error (write into a R/O page, etc)
 +
* PKIV (5-1): Instruction violation - HALT, RESET, etc in User mode
 +
* SP SEL (5-1):
 +
* SPEN (6-1): Scratchpad output enable
 +
* SPOR(2) (6-1): Register select
 +
* SRC (5-2):
 +
* uT (8-1): 
 +
* XSHL, XSHR (3-1): Controls major state transitions
 +
* YSHL, YSHR (3-1): Controls minor state transitions
 +
* WELF (10-1): PGM(13)
 +
* WIND (5-1): Reference to Window register?
 +
* WINF (10-1): PGM(14)
 +
* WREND (7-2):
 +
* WRITE (7:0) (6-1):
 +
* WRITE (15:8) (6-1):
 +
* XM CLK (5-2):
 +
* XPEN (6-1): Optional scratchpad (for cache extension) output enable
  
I actually released a 0.11+VM version just before Christmas -91: I didn't need it myself, but people were trying to compile the kernel in 2MB and failing, so I had to implement it. The 0.11+VM version was available only to a small number of people that wanted to test it out: I'm still surprised it worked as well as it did.
+
The following signals are provided by the KA11:
  
 +
* CLKT: ?
 +
* DEST: In 'Destination' major state
 +
* FETCH: In 'Fetch' major state
 +
* ISR 7: Bit 7 of the current instruction
 +
* ISR 12: Bit 7 of the current instruction
 +
* JSR: Current instruction is 'JSR'
 +
* RTI: Current instruction is 'RTI'
 +
* RTS: Current instruction is 'RTS'
 +
* SERVICE: In 'Service' major state
 +
* SOURCE: In 'Source' major state
 +
* TIME OUT:
 +
* TRAP: Current instruction is 'TRAP'?
 +
* TRAPS: ?
  
* minix still has a lot more users: better support.
+
==Prints==
* it hasn't got years of testing by thousands of people, so there are probably quite a few bugs yet.
 
  
Then for the good things..
+
The Engineering Drawings for the KT11-B (7605071) include the following logic prints:
* It's free (copyright by me, but freely distributable under a
 
very lenient copyright)  
 
  
The early copyright was in fact much more restrictive than the GNU copyleft: I didn't allow any money at all to change hands due to linux. That changed with 0.12.
+
{| class="wikitable"
 +
! Number !! Page Count !! Content
 +
|-
 +
| 2 || 2 || Address Bus and Control Logic
 +
|-
 +
| 3 || 1 || State Control Logic
 +
|-
 +
| 4 || 1 || SP Input Mux
 +
|-
 +
| 5 || 2 || Associative Memory Control
 +
|-
 +
| 6 || 1 || Scratch Pad and State Control Logic
 +
|-
 +
| 7 || 3 || Data Bus and Control Logic
 +
|-
 +
| 8 || 1 || Keys and Associative Memory
 +
|-
 +
| 9 || 1 || XP Option for KT11 Associative Memory Control
 +
|-
 +
| 10 || 1 || PGM Register
 +
|-
 +
| 11 || 1 || PGC Register
 +
|-
 +
| 12 || 1 || Timing Logic
 +
|-
 +
| 13 || 1 || Buffered Signals and Main Logic
 +
|-
 +
| 14 || 1 || Extended Associative Memory
 +
|-
 +
| 15 || 1 || KA11 to KT11 Interface
 +
|-
 +
| 17 || 1 || KT11-B Bus Connectors
 +
|}
  
 +
The KT11-B is not composed of discrete boards, but rather a large number of mostly small [[FLIP CHIP]]s, so the division into drawings, some of which are multi-sheet (as opposed to them all being single-sheet) is a bit arbitrary. It is probably intended to align the drawings with the high-level internal structure.
  
* it's fun to hack on.
+
References to drawing pages are given as 'x-y', where 'x' the drawing number, and 'y' is the individual sheet.
* /real/ multithreading filesystem.
 
* uses the 386-features. Thus locked into the 386/486 family, but
 
it makes things clearer when you don't have to cater to other
 
chips.
 
* a lot more... read my .plan.
 
'''I''' think it's better than minix, but I'm a bit prejudiced. It will never be the kind of professional OS that Hurd will be (in the next century or so :), but it's a nice learning tool (even more so than minix, IMHO), and it was/is fun working on it.  
 
  
<pre>
+
==Detailed logic description==
Linus (torvalds@kruuna.helsinki.fi)
 
---- my .plan --------------------------
 
Free UNIX for the 386 - coming 4QR 91 or 1QR 92.
 
The current version of linux is 0.11 - it has most things a unix kernel
 
needs, and will probably be released as 1.0 as soon as it gets a little
 
more testing, and we can get a init/login going. Currently you get
 
dumped into a shell as root upon bootup.
 
Linux can be gotten by anonymous ftp from 'nic.funet.fi' (128.214.6.100)
 
in the directory '/pub/OS/Linux'. The same directory also contains some
 
binary files to run under Linux. Currently gcc, bash, update, uemacs,
 
tar, make and fileutils. Several people have gotten a running system,
 
but it's still a hackers kernel.
 
Linux still requires a AT-compatible disk to be useful: people are
 
working on a SCSI-driver, but I don't know when it will be ready.
 
There are now a couple of other sites containing linux, as people have
 
had difficulties with connecting to nic. The sites are:
 
Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31):
 
directory /pub/msdos/replace
 
tsx-11.mit.edu (18.172.1.2):
 
directory /pub/linux
 
There is also a mailing list set up 'Linux-activists@niksula.hut.fi'.
 
To join, mail a request to 'Linux-activists-request@niksula.hut.fi'.
 
It's no use mailing me: I have no actual contact with the mailing-list
 
(other than being on it, naturally).
 
Mail me for more info:
 
Linus (torvalds@kruuna.Helsinki.FI)
 
0.11 has these new things:
 
- demand loading
 
- code/data sharing between unrelated processes
 
- much better floppy drivers (they actually work mostly)
 
- bug-corrections
 
- support for Hercules/MDA/CGA/EGA/VGA
 
- the console also beeps (WoW! Wonder-kernel :-)
 
- mkfs/fsck/fdisk
 
- US/German/French/Finnish keyboards
 
- settable line-speeds for com1/2
 
</pre>
 
  
As you can see: 0.11 was actually stand-alone: I wrote the first mkfs/fsck/fdisk programs for it, so that you didn't need minix any more to set it up. Also, serial lines had been hard-coded to 2400bps, as that was all I had.  
+
This section covers each drawing in more detail, explaining what functions are found in each one. The term 'logic' below means a group of gates (and sometimes flops as well), often used to produce control signals.
  
 +
'''Note''': For describing which part of a print is being discussed, the terms 'left', 'center' and 'right' refer to the side-side axis, and 'top', 'middle' and 'bottom' refer to the up-down axis. Which axes 'center' and 'middle' refer to can be remembered by the observation that 'center' is usually used in a side-side context, not an up-down one.
  
Still lacking:
+
===Address Bus and Control Logic===
* init/login
 
* rename system call
 
* named pipes
 
* symbolic links
 
  
Well, they are all there now: init/login didn't quite make it to 0.12, and rename() was implemented as a patch somewhere between 0.12 and 0.95. Symlinks were in 0.95, but named pipes didn't make it until 0.96.
+
The first sheet contains, on the left, buffering between the address lines of the CPU's UNIBUS, and the internal address bus; and in the center and right, logic which generates control signals for the address mux (on the next page).
  
Note: The version number went directly from 0.12 to 0.95, as the follow-on to 0.12 was getting feature-full enough to deserve a number in the 0.90's
+
The left of the second sheet contains an address latching mux (see [[KT11-B Technical Manual#Common Circuits|above]] for the implementation), divided into high and low 9-bit halves, which may be controlled separately (for page and byte-within-page), and which separately select between:
 +
* Scratch-pad data output (9 bits wide, repeated in the low and high halves)
 +
* Scratch-pad data input (18 bits wide, with the low and high halves swapped - although note that that data source is only 16 bits wide: so the low bit in the low half is zero - presumably because only word addresses are used; and the high bit in the low half is a synthetic signal)
 +
* The internal address bus
 +
The right half of the second sheet contains drivers for the address lines of the device UNIBUS, sourced from the above mux.
  
 +
===State Control Logic===
  
0.12 will probably be out in January (15th or so), and will have:
+
This drawing contains logic which generates two state change control signals for each of the major and minor states (XSHL, XSHR, YSHL, YSHR).
* POSIX job control (by tytso)  
 
* VM (paging to disk)
 
* Minor corrections
 
  
Actually, 0.12 was out January 5th, and contained major corrections. It was in fact a very stable kernel: it worked on a lot of new hardware, and there was no need for patches for a long time. 0.12 was also the kernel that "made it": that's when linux started to spread a lot faster. Earlier kernel releases were very much only for hackers: 0.12 actually worked quite well.
+
===Scratchpad Input Mux===
  
Note: The following document is a reply by Linus Torvalds, creator of Linux, in which he talks about his experiences in the early stages of Linux development
+
At the top, a 16-bit wide latching mux (see [[KT11-B Technical Manual#Common Circuits|above]]) which provides the input to the scratchpad memory. The three inputs are:
 +
* The internal address bus
 +
* The internal data bus
 +
* Scratchpad data output
 +
At the bottom is logic which generates the selection control signals for that mux.
  
<pre>
+
===Associative Memory Control===
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
 
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
 
Subject: Re: Writing an OS - questions !!
 
Date: 5 May 92 07:58:17 GMT
 
In article <10685@inews.intel.com> nani@td2cad.intel.com (V. Narayanan) writes:
 
  
Hi folks,
+
The first sheet contains a number of different logical units: the top left contains logic which indicates that the CPU is 'executing a TRAP instruction'?/'in a trap sequence'?; the top right contains logic to recognize references to KT11-B internal registers; and the bottom right contains logic to generate several control signals.
For quite some time this "novice" has been wondering as to how one goes about
 
the task of writing an OS from "scratch". So here are some questions, and I
 
would appreciate if you could take time to answer 'em. Well, I see someone
 
else already answered, but I thought I'd take on the linux-specific parts.
 
Just my personal experiences, and I don't know how normal those are.  
 
  
1) How would you typically debug the kernel during the development phase?
+
The bottom left contains logic to detect illegal instructions in User mode (HALT, WAIT and RESET), and non-'entry' instruction when transferring to a private page. The column of three 4-input NAND gates recognize the 'entry' instruction, HALT/WAIT, and RESET, respectively; the first is then combined wirh other signals (PGC(7)(0) is probably a type for PGM(7)(0)), before all three are ORed together, and then ANDed with signals indicating the KA11 is in (instruction) 'Fetch' major state, and the KT11-B is in 'User' mode, to generate the IV error signal.
Depends on both the machine and how far you have gotten on the kernel:
 
on more simple systems it's generally easier to set up. Here's what I had
 
to do on a 386 in protected mode. The worst part is starting off: after
 
you have even a minimal system you can use printf etc, but moving to
 
protected mode on a 386 isn't fun, especially if you at first don't know
 
the architecture very well. It's distressingly easy to reboot the system
 
at this stage: if the 386 notices something is wrong, it shuts down and
 
reboots - you don't even get a chance to see what's wrong. Printf() isn't
 
very useful - a reboot also clears the screen, and anyway, you have to
 
have access to video-mem, which might fail if your segments are incorrect
 
etc. Don't even think about debuggers: no debugger I know of can follow
 
a 386 into protected mode. A 386 emulator might do the job, or some heavy
 
hardware, but that isn't usually feasible. What I used was a simple
 
killing-loop: I put in statements like
 
  
die:  
+
The second sheet also contains a number of different logical units: the right side contains logic to load individual associative memories; the bottom left contains logic to generate the binary-coded identification of the scratchpad memory entry corresponding to a associative memory which matched (used to read that entry out of the scratchpad); the center bottom contains logic to indicate an associative memory match.
jmp die
 
  
at strategic places. If it locked up, you were ok, if it rebooted, you
+
===Scratchpad and State Control Logic===
knew at least it happened before the die-loop. Alternatively, you might
 
use the sound io ports for some sound-clues, but as I had no experience
 
with PC hardware, I didn't even use that. I'm not saying this is the
 
only way: I didn't start off to write a kernel, I just wanted to explore
 
the 386 task-switching primitives etc, and that's how I started off
 
(in about April-91). After you have a minimal system up and can use
 
the screen for output, it gets a bit easier, but that's when you have to
 
enable interrupts. Bang, instant reboot, and back to the old way. All
 
in all, it took about 2 months for me to get all the 386 things pretty
 
well sorted out so that I no longer had to count on avoiding rebooting
 
at once, and having the basic things set up (paging, timer-interrupt
 
and a simple task-switcher to test out the segments etc).
 
  
2) Can you test the kernel functionality by running it as a process on a
+
Logic which controls the scratchpad memory: the center top and entire right side contain logic which (apparently) indicates which register (stored in the scratchpad) the KT11-B itself needs access to; the center bottom contains logic which indicates which set of scratchpad address inputs (out of four, see the "Keys and Associative Memory" section) are to be used ; the left bottom performs the same function for the scratchpad in the optional extended cache.
different OS? Wouldn't the OS(the development environment) generate
 
exceptions in cases when the kernel (of the new OS) tries to modify
 
'priviledged' registers? Yes, it's generally possible for some things,
 
but eg device drivers usually have to be tested out on the bare machine.
 
I used minix to develop linux, so I had no access to IO registers,
 
interrupts etc. Under DOS it would have been possible to get access to
 
all these, but then you don't have 32-bit mode. Intel isn't that
 
great - it would probably have been much easier on a 68040 or similar.
 
So after getting a simple task-switcher (it switched between two
 
processes that printed AAAA... and BBBB... respectively by using the
 
timer-interrupt - Gods I was proud over that), I still had to
 
continue debugging basically by using printf. The first thing written
 
was the keyboard driver: that's the reason it's still written completely
 
in assembler (I didn't dare move to C yet - I was still debugging at
 
about instruction-level). After that I wrote the serial drivers, and
 
voila, I had a simple terminal program running (well, not that simple
 
actually). It was still the same two processes (AAA..), but now they
 
read and wrote to the console/serial lines instead. I had to reboot
 
to get out of it all, but it was a simple kernel. After that is was plain
 
sailing: hairy coding still, but I had some devices, and debugging was
 
easier. I started using C at this stage, and it certainly speeds up
 
developement. This is also when I start to get serious about my
 
megalomaniac ideas to make "a better minix that minix". I was hoping
 
I'd be able to recompile gcc under linux some day... The harddisk
 
driver was more of the same: this time the problems with bad documentation
 
started to crop up. The PC may be the most used architecture in the  
 
world right now, but that doesn't mean the docs are any better: in
 
fact I haven't seen /any/ book even mentioning the weird 386-387
 
coupling in an AT etc (Thanks Bruce). After that, a small
 
filesystem, and voila, you have a minimal unix. Two months for basic
 
setups, but then only slightly longer until I had a disk-driver
 
(seriously buggy, but it happened to work on my machine) and a small
 
filesystem. That was about when I made 0.01 available (late august-91?
 
Something like that): it wasn't pretty, it had no floppy driver, and
 
it couldn't do much anything. I don't think anybody ever compiled
 
that version. But by then I was hooked, and didn't want to stop
 
until I could chuck out minix. 3) Would new linkers and loaders
 
have to be written before you get a basic
 
kernel running? All versions up to about 0.11 were crosscompiled under
 
minix386 - as were the user programs. I got bash and gcc eventually
 
working under 0.02, and while a race-condition in the buffer-cache  
 
code prevented me from recompiling gcc with itself, I was able to
 
tackle smaller compiles. 0.03 (October?) was able to recompile gcc
 
under itself, and I think that's the first version that anybody
 
else actually used. Still no floppies, but most of the basic things
 
worked. Afetr 0.03 I decided that the next version was actually
 
useable (it was, kind of, but boy is X under 0.96 more impressive),
 
and I called the next version 0.10 (November?). It still had a
 
rather serious bug in the buffer-cache handling code, but after patching
 
that, it was pretty ok. 0.11 (December) had the first floppy driver,
 
and was the point where I started doing linux developement under itself.
 
Quite as well, as I trashed my minix386 partition by mistake when
 
trying to autodial /dev/hd2. By that time others were actually using
 
linux, and running out of memory. Especially sad was the fact that
 
gcc wouldn't work on a 2MB machine, and although c386 was ported, it
 
didn't do everything gcc did, and couldn't recompile the kernel. So I
 
had to implement disk-paging: 0.12 came out in January (?) and had paging
 
by me as well as job control by tytso (and other patches: pmacdona had
 
started on VC's etc). It was the first release that started to
 
have "non-essential" features, and being partly written by others.
 
It was also the first release that actually did many things better
 
than minix, and by now people started to really get interested.
 
Then it was 0.95 in March, bugfixes in April, and soon 0.96.
 
It's certainly been fun (and I trust will continue to be so) - reactions
 
have been mostly very positive, and you do learn a lot doing this type
 
of thing (on the other hand, your studies suffer in other respects :)
 
  
Linus
+
===Data Bus and Control Logic===
  
</pre>
+
The first sheet contains logic to create various control signals.
  
[[Category: UNIX Clones‎]]
+
The far left of the second sheet contains input buffers (from the CPU's UNIBUS) for various bus control signals; the center left contains the drivers for data lines of the device UNIBUS, which are fed from the (buffered) data lines of the CPU's UNIBUS; the right contains half of a multiplexor (built from NAND gates connected in a wired-OR network) which drives the data lines of the CPU's UNIBUS, for which the inputs are:
 +
* The data lines of the device UNIBUS (through a set of receivers, which also generate the internal data bus)
 +
* Scratchpad data output
 +
* The KT11-B Control and Maintenance registers
 +
 
 +
The left and center of the third sheet contains the other half of the data mux; the right shows the KW11-L Line Time Clock card.
 +
 
 +
===Keys and Associative Memory===
 +
 
 +
The left side shows the scratchpad memory; note that the register number input select lines (top group, left side of the block) select one of four sets of register number input lines (also on the left). From the top, they are:
 +
 
 +
* The binary-coded number of the associative memory that matched - note that the high bit is tied high, indicating the cache page table entries are stored in the top half of the scratchpad
 +
* Replacement counter (from the KTMR); note that the lowest value this can have is 010, so that it always addresses cache entries, which are stored in the top 010 locations
 +
* A set of signals which apparently indicate which register the KT11-B needs to be able to store - note that the high bit here is tied low, indicating they are stored in the bottom half of the scratchpad
 +
* The low bits of the internal address bus (likely for register read-out)
 +
 
 +
The top center shows the associative memories; note that the only inputs to each are the 7 high bits of the internal address bus, and the Exec/User mode bit; the associative memory must be loaded from the internal address bus early during a cycle which provokes a cache replacement.
 +
 
 +
The top right shows a comparator used for the division of the Exec and User address spaces into two kinds of pages; the bottom right is the counter?/shift register? which generates the minor state.
 +
 
 +
The bottom center is a 3-bit wide latching mux which holds protection key information for the current memory cycle. The three inputs are:
 +
* A signal indicating a reference to Exec mode page 0 (replicated to all three key bits), used to generate a synthetic 07 key for Exec page 0 (which does not have a page table entry)
 +
* 3 bits from the device UNIBUS (for page table entries loaded from memory)
 +
* 3 bits from the scratchpad (for cached page table entries)
 +
 
 +
===XP Option for KT11 Associative Memory Control===
 +
 
 +
This contains logic to control the optional cache entries: the left and center contain gates to control loading of associative memories; the right contains logic to generate the binary-coded identification of the entry in the optional scratchpad memory (used with the extended cache) corresponding to a associative memory which matched.
 +
 
 +
===PGM Register===
 +
 
 +
The KT11-B's Maintenance register: the center top is the replacement counter; the rest of the page is logic (including S/R flops) to generate the currently un-documented other bits in the Maintenance register - bits 6, 7, 11, 12, 13, 14, 15. (The Option Description indicates - Section 3.3.2.6 - that there are 5 bits, but the drawings show 7.) Note than many of these bits are actually used elsewhere in the KT11-B during normal operation, they are not purely diagnostic.
 +
 
 +
The top right is logic to record that the instruction is a TRAP in User mode; it includes a modified 'gated D latch' (with addition inputs to the SR latch which is its second stage). The middle and lower right is logic (again including a 'gated D latch') that records if a cycle is to the non-Simple part of the address space; the middle center is a delayed copy of that. The bottom center holds logic to record that the CPU reported a timeout, and logic to record a cycle to the Window register; the lower left corner contains a delayed copy of that. The middle left is logic (again including a 'gated D latch') that records if a fetch is to a Private page.
 +
 
 +
===PGC Register===
 +
 
 +
The KT11-B's Control and Status register - S/R flops to store the bits, and logic to control setting and clearing them: in the upper right, the Source and Destination bits; in the center and lower right, the five Violation bits; in the upper left and center, the two Function bits; in the left and center middle, the User and Interrupted User bits, respectively.
 +
 
 +
===Timing Logic===
 +
 
 +
{{Main article | KT11-B Major State circuitry}}
 +
 
 +
The top and lower right contain gates which combine major and minor state lines into signals for each individual state.
 +
 
 +
The lower left contains the 2-bit counter (built out of two D flops, and associated circuitry) which produces the major state; and also logic to produce major state signals. Note that the two flops (and their input circuitry) don't form a straight binary counter, but rather a [[Gray code]] counter. So, a sequence of XSHL pulses will generate the following major state sequence:
 +
 
 +
00, 10, 11, 01, 00
 +
 
 +
and XSHR will produce:
 +
 
 +
00, 01, 11, 10, 00
 +
 
 +
===Buffered Signals and Main Logic===
 +
 
 +
The left side shows the W130 Maintenance Card; the top left and center contain buffering for various internal signals; the right contains buffering for the high 9 bits (i.e. the page number) of the internal address bus.
 +
 
 +
===Extended Associative Memory===
 +
 
 +
On the left, the scratchpad memory for the optional 16-entry page table cache extension (to 24 entries total), with the possible register number inputs:
 +
* The binary-coded number of the extended associative memory that matched
 +
* Replacement counter (from the KTMR)
 +
* The low bits of the internal address bus (likely for register read-out)
 +
Note that the fourth set of address inputs to the scratchpad are unused (note the selector line for that set of inputs is tied low).
 +
 
 +
The center and right are the associative memories for the extended cache.
 +
 
 +
===KA11 to KT11 Interface===
 +
 
 +
In addition to the interface cable, this sheet also shows the synthesis of a number of signals which are passed across the interface.
 +
 
 +
Note that the gates on the left are actually physically in the KA11 (an additional M135 hex NAND card is plugged into slot B08 of the KA11's backplane).
 +
 
 +
In addition to logic in the KT11, the right side also shows buffers for signals coming from, or going to, the interface cable.
 +
 
 +
==Construction==
 +
 
 +
As mentioned, the KT11-B is constructed out of a large number of smaller FLIP CHIPs, plugged into a custom-wired [[backplane]].
 +
 
 +
===Module Counts===
 +
 
 +
The module type usage counts are:
 +
 
 +
{| class="wikitable"
 +
! Type !! Function !! Count !! Comment
 +
|-
 +
| M111 || 16 x Inverters || 10
 +
|-
 +
| M112 || 10 x 2-input NOR || 5
 +
|-
 +
| M116 || 6 x 4-input NOR || 10
 +
|-
 +
| M133 || 10 x 2-input NAND || 24
 +
|-
 +
| M135 || 8 x 3-input NAND || 6
 +
|-
 +
| M139 || 3 x 8-input NAND || 1
 +
|-
 +
| M167 || Magnitude comparator || 1
 +
|-
 +
| M203 || 8 x R/S flip flops || 1
 +
|-
 +
| M206 || 6 x D flip flops || 1
 +
|-
 +
| M207 || 6 x J/K flip flops || 1
 +
|-
 +
| M225 || Scratchpad memory || 1 || 2 for 24 cache entries
 +
|-
 +
| M240 || R/S flip flop || 1
 +
|-
 +
| M244 || 6 x quad-2-input-AND/OR gates || 6 || Used as latched multiplexors (see above)
 +
|-
 +
| M259 || Associative memory || 4 || 12 for 24 cache entries
 +
|-
 +
| M602 || 2 x Pulse amplifier || 1
 +
|-
 +
| M611 || 14 x Power inverter || 3
 +
|-
 +
| M627 || 6 x NAND amplifier || 7
 +
|-
 +
| M721 || UNIBUS transceiver || 4
 +
|-
 +
| M783 || 12 x UNIBUS NAND transmitters || 6
 +
|-
 +
| M784 || 16 x UNIBUS inverter receivers || 2
 +
|-
 +
| M826 || Clock/shift register || 1
 +
|}
 +
 
 +
The counts are from the list in the "KT11-B Option Description" document; they have been cross-checked against the 'Module Utilization' sheet from the KT11-B Engineering Drawings, and also the module location chart (below) and all known variances have been sorted out.
 +
 
 +
===Module Locations===
 +
 
 +
The following table, drawn from the 'Module Utilization' sheet from the KT11-B Engineering Drawings, gives the location of the various modules in the backplane:
 +
 
 +
{| class="wikitable"
 +
! Slot !! A || B || C || D
 +
|-
 +
| 01 || colspan="2" style="text-align:center;" | UNIBUS In || M259 || M133
 +
|-
 +
| 02 || colspan="2" style="text-align:center;" | M930 || M259 || M133
 +
|-
 +
| 03 || colspan="2" style="text-align:center;" | UNIBUS Out || M259 || M133
 +
|-
 +
| 04 || colspan="2" style="text-align:center;" | M930 || M259
 +
|-
 +
| 05 || M721 || M721 || M259%
 +
|-
 +
| 06 || M721 || M721 || M259%
 +
|-
 +
| 07 || M783 || M784 || M259%
 +
|-
 +
| 08 || M783 || M784 || M259% || M133
 +
|-
 +
| 09 || M783 || M787 $ || M259% || M133
 +
|-
 +
| 10 || M783 || M244 || M259% || M133
 +
|-
 +
| 11 || M783 || M244 || M259% || M133
 +
|-
 +
| 12 || M783 || M244 || M259% || M903 @
 +
|-
 +
| 13 || M826 || M244 || M627 || M111
 +
|-
 +
| 14 || W130 $ || M244 || M627 || M133
 +
|-
 +
| 15 || M116 || M244 || M627 || M133
 +
|-
 +
| 16 || colspan="2" style="text-align:center;" | M225 || M627 || M133
 +
|-
 +
| 17 || colspan="2" style="text-align:center;" | M225% || M111 || M133
 +
|-
 +
| 18 || M116 || M112 || M627 || M133
 +
|-
 +
| 19 || M116 || M112 || M627 || M133
 +
|-
 +
| 20 || M116 || M112 || M627 || M133
 +
|-
 +
| 21 || M116 || M112 ||  || M133
 +
|-
 +
| 22 || M116 || M112 ||  || M133
 +
|-
 +
| 23 || M116 || M602 ||  || M133
 +
|-
 +
| 24 || M116 || M135 ||  || M133
 +
|-
 +
| 25 || M116 || M135 || M611 || M133
 +
|-
 +
| 26 || M116 || M135 || M611 || M133
 +
|-
 +
| 27 || M203 || M135 || M111 || M133
 +
|-
 +
| 28 || M206 || M135 || M111 || M133
 +
|-
 +
| 29 || M207 || M135 || M611 || M133
 +
|-
 +
| 30 || M240 || M133 || M111 || M111
 +
|-
 +
| 31 || M139 ||  || M111 || M111
 +
|-
 +
| 32 || M167 || M111 ||  || M111
 +
|}
 +
 
 +
* % = Optional
 +
* $ = Not part of KT11-D
 +
* @ = Cable
 +
 
 +
Questionable entries (since the table is hand-written, and hard to read in places because of poor-quality duplication from the originals) have been cross-checked against the prints, and all known uncertainties have been cleared up.
 +
 
 +
==Card Information==
 +
 
 +
The drawings contain a number of different FLIP CHIPs as blocks, without showing individual details; information about them is given here.
 +
 
 +
===M167=== <!-- RS64-MM -->
 +
 
 +
Shown on page 8-1, this is a 8-bit comparator; see [[FLIP CHIP details#M167|here]] for details.
 +
 
 +
===M203=== <!-- '68-'77 -->
 +
 
 +
Shown on pages 7-1, 10-1 and 11-1, although not as as a single block, but rather individual units, this contains eight R/S flip flops; see [[FLIP CHIP details#M203|here]] for details.
 +
 
 +
===M225=== <!-- KA11 -->
 +
 
 +
Shown on pages 8-1 and 14-1, this is a 16x16-bit scratchpad memory; see [[FLIP CHIP details#M225|here]] for details.
 +
 
 +
Pin AN1 is a control input of some sort, but it is not yet clear what it does. It is possible that it is some sort of 'output enable', for use in cases where the optional second scratchpad memory is installed, since the two feed the same output bus.
 +
 
 +
===M240=== <!-- -->
 +
 
 +
Shown on pages 10-1 and 11-1, although not as as a single block, but rather individual units, this contains six R/S flip flops; see [[FLIP CHIP details#M240|here]] for details.
 +
 
 +
===M259=== <!-- -->
 +
 
 +
Shown on pages 8-1 and 14-1, this is a dual 8-bit associative memory.
 +
 
 +
===M602=== <!-- '68-'77 -->
 +
 
 +
Shown on pages 6-1 and 13-1, although not as as a single block, but rather individual units, this is a dual pulse amplifier; see [[FLIP CHIP details#M602|here]] for details.
 +
 
 +
===M787===
 +
 
 +
Shown on page 7-3, this is actually not a part of the KT11-B; rather, it is the [[KW11-L Line Time Clock]], which must reside in the KT11-B's backplane.
 +
 
 +
===M826=== <!-- -->
 +
 
 +
Shown on page 8-1, this is a clock with counter?/shift-register?
 +
 
 +
===W180===
 +
 
 +
Shown on page 13-1, this is actually not a part of the KT11-B; rather, it is the Maintenance Card, which must plug into the KT11-B's backplane.
 +
 
 +
{{PDP-11}}
 +
 
 +
[[Category: PDP-11 Processors]]

Revision as of 19:30, 22 June 2019

As a Special Systems Option, the KT11-B does not have the usual DEC Technical Manual. This page attempts to provide at least the high-level portions of such a manual.

Note: KT11-B operation must be thoroughly understood (either from the KT11-B page above, or the Option Description manual) before trying to read this page. In particular, KT11-B external register names must be known, as well as the function of the CPU and device UNIBUSes, and also high-level internal entities such as the associative memories, and the scratchpad memory.

Further Note: This page is under construction. It is believed to be accurate, but the writer's understanding on the KT11-B circuity is not complete, and so it may contain errors.

High-Level Overview

Main data paths

The heart of the KT11-B is the scratchpad memory, which is used to hold both cached page table entries, and also most of the KT11-B registers.

(Since the KT11-B does not contain any internal registers to which the CPU does not have access, the term 'register' hereinafter refers to any of the registers visible to the CPU in the KT11-B.)

The scratchpad has a built-in address multiplexor, so address lines from a variety of sources are all fed directly into it; see the "Keys and Associative Memory" section below, for details. A latching input data multiplexor is provided to select among data from a number of sources for storage in the scratchpad.

One of the possible inputs to that mux is the output of the scratchpad itself: since there is no latch on the output of the scratchpad, the ability to select its output, and then latch it, is sometimes used to hold data from the scratchpad for other users. (E.g. the comparator which checks to see whether cycles are in the Simple part of the address space.)

A uni-directional address bus runs from the CPU's UNIBUS to the device UNIBUS; the KT11-B internals, such as the scratchpad, may also generate addresses (e.g. for loading page table entries). An address multiplexor for this bus can perform non-trivial selections (e.g. getting high address bits - i.e. physical page numbers - from scratchpad output, and low bits - i.e. addresses within a page - from the incoming address bus).

A bi-directional data bus connects to both UNIBUSes; the KT11-B may also source data to the CPU (e.g. when the CPU is reading KT11-B registers), or obtain data from either UNIBUS (e.g. for reading page table entries, or to intercept data the CPU is attempting to save to memory during a page fault).

The majority of the signals that control the operation of the buses, multiplexors, etc. are generated by random logic - a group of gates (and sometimes flip-flops as well); it is usually necessary to inspect the actual drawings to ascertain how any major data-handling item is controlled.

If the optional extended cache (holding an additional scatchpad memory, and an array of associative memories) is installed, it functions in much the same way as the base cache, except that since it does not hold any registers, its role is nowhere near as central as that of the main scratchpad.

States

A key part of KT11-B operation is a state composed of two parts, the 'X' or major part, and the 'Y' or minor part; the progression of this through the various states is the major control mechanism in the KT11-B.

Note that a state is only part of what controls the operation of the KT11-B; in many states, depending on control signal(s), differing actions may be taken, before the KT11-B moves on the same next state.

The X state counter (composed of a pair of D flops, with 4 AND gates with inverting inputs) creates individual major state outputs, signals 'XSRx' (x = 0-3).

The Y state counter is an M826 Flip Chip; its outputs are signals 'YSRx' (x = 0, 1 ,3, 7, 15, 14, 12, 8). (The odd sequence of minor state numbers, and the fact that they are not in numerical order, is confusing, but since that's what's on the prints, that nomenclature has to be used.)

The two groups of signals are combined into signals which indicate that the KT11-B is in that state, for each individual major/minor state, by NAND gates; inverters then provide non-inverted forms of each.

State Table

The following table shows the state transitions:

State Next State(s) Comment
0.0 0.8, 1.0 Idle
0.8 0.12 Interrupt, Trap and Start User
0.12 0.14
0.14 0.15
0.15 0.7A
0.7A 0.3A
0.7B 0.3B Although the state names are identical to the preceding ones, this is shown on the state diagram as a separate state loop
0.3A 0.1A
0.3B 0.1B Window?
0.1A 0.0
0.1B 1.1 Although the state name is identical to the preceding one, this is shown on the state diagram as a separate state loop
1.0 1.1, 3.0
1.1 1.3
1.3 1.7, 3.3 Exec-per-Process
1.7 0.7B, 1.15
1.15 1.14 Page Violation?
1.14 1.12
1.12 0.12
1.8 1.0
2.0 0.0
2.1 2.0, 2.3 Shared Entry?
2.3 2.7
2.7 2.15
2.15 2.14 Page Violation?
2.14 0.14
2.12 - State does not exist
2.8 - State does not exist
3.0 2.0, 3.1, 3.8
3.1 1.1, 2.1, 3.0
3.3 3.1, 3.7A
3.7A 1.7
3.7B 3.3 Although the state name is identical to the preceding one, this is shown on the state diagram as a separate state loop
3.15 3.7B
3.14 3.15
3.12 3.14
3.8 1.8, 3.12

This table is a transcription of the single-page one in the KT11-B Option Description; that diagram contains a number of labels, but it is not completely clear which states (or transitions) the labels apply to. Over time the hope is to check this table against the multi-page table in that document, and also better described what each state means/does.

Drawing Conventions

The drawings are somewhat easier to understand if the conventions used in the drawings are understood. Although no document lists them, they can be ascertained by study of the drawings.

Note that in the prints, the symbol '*' in a signal name means logical AND, and '+' means logical OR; this notation is used throughout the KT11-B prints.

Signal Names

Signal names as written in this drawing set usually start with 'Dxx', where 'xx' is related to the drawing number (given in the table below). (This is similar to the convention in the KA11 CPU drawings, where 'Kxx-y' means that the signal originates on page y of drawing xx.) Note that the 'Dxx' correspondence seems to sometimes be off by one; i.e. a signal tagged 'D04' can be found originating on drawing 05.

In signal names of the form 'XXX (yy)', 'yy' is a bit number (in standard PDP-11 order) in a register or bus. For signals which are provided in both asserted low and asserted high forms, one will see signal names of the form 'XXX (y)', where 'y' is 1 or 0. Note that sometimes these two notations are combined, and one can find signal names of the form 'XXX (yy) (z)'. Inverted (asserted low) signals are also sometimes shown as '-XXX'; this form is particularly common with composite signals (i.e. '-(xxx * yyy)').

The following specific signal names have the meaning given:

  • Signals of the form 'x.y' are states, with 'x' being the major state, and 'y' being the minor state; the origin of all of them is on page D12.
  • Signal names 'A (x)' are the internal address bus, and 'D (x)' are the data bus.
  • Signal names starting with 'SP' refer to the scratchpad memory; SPIN is its input bus, and SPDA is its output bus.
  • Signal names starting with 'AM' sometimes refer to the associative memory, but there are others, e.g. signals named 'ENB AMX' which control the address multiplexor.
  • Signal names starting with 'DV' refer to the UNIBUS from the KT11-B to the devices and memory of the system.
  • Signal names starting with 'CP' refer to the UNIBUS to the KT11-B from the KA11 CPU.
  • Signal names starting with 'PGC' refer to the contents of the Control Status register.
  • Signal names starting with 'PGM' refer to the contents of the Maintenance register.

Common Circuits

Error creating thumbnail: Unable to save thumbnail to destination

This circuit (first used in the KA11) is seen in several places in the KT11-B. It is almost always seen as an array of identical circuits, since it provides a 3-input multiplexor with latching capability, and it is used on data paths (usually 16 bits wide).

The latch is cleared by de-asserting the 'Latch' input; data from any of the three inputs (A, B, C) may then be selected for output, and potentially storage, by asserting the matching 'Gate' input. Asserting 'Latch' while an input is selected then stores the current output of the mux.

(Asserting more than one input simultaneously ORs the two inputs together; this capability is used in the KA11, but probably not here.)

Latching mux

The prints use an unusual symbol for an SR flop, with the Q outputs at the top (shown here).

Some of the SR flops are variants with two 'set' inputs. Note that these are sometimes drawn with the two 'set' inputs on the left hand side, instead of the right; in this case, those inputs are being used as 'reset' inputs, and to compensate, the Q and -Q outputs are reversed; i.e. the usual Q output pin becomes the -Q output, and vice versa. (Since SR flops are symmetric with respect to the S/Q and R/-Q input/output pairs, this inversion is trivial.)

Signal Dictionary

These are main control signals, their meaning, and the drawing page (below) where they are generated. Listings of the form 'aaa(x) (y-z)' indicate that 'aaa' is a group of signals generated on page y-z, and this is the xth; similarly for 'bbb(w-x) (y-z)'. (Note that occasionally the drawings use the notation 'ccc(p:q) for a control signal which acts on bits p through q, or the AND of bits p through q.)

Note: A few of these are not actually generated as individual signals, only as composites. (E.g. "EXEC PER PROC" is only generated ANDed with "3.1". In that particular case, the drawing could have been modified to have an "EXEC PER PROC" output, but that would have been misleading, since that signal is not used elsewhere on its own.) Such cases are marked with a '+' on the signal name.

  • A(0-17) (2-1): Internal address bus
  • A CLK (7-1):
  • AM CLK (5-2):
  • AMOK (6-1): Associative memory matched
  • AMXA(0-8) (2-2): Address mux output, high half
  • AMXB(0-8) (2-2): Address mux output, low half
  • CLC (7-1)
  • CLK A (13-1): Maintenance clock pulse
  • CLK AA (15-1):
  • CLR B (2-1): Clear latch of B (high) half of address mux
  • D(0-15) (7-2, 7-3): Internal data bus
  • DST (5-2):
  • ENB AMXA(0) (2-1): Select scratchpad output data for high address
  • ENB AMXA(1) (2-1): Select scratchpad input mux data for high address
  • ENB AMXA(2) (2-1): Select incoming address for high address
  • ENB AMXB(0) (2-1): Select scratchpad output data for low address
  • ENB AMXB(7:1) (2-1): Select scratchpad input mux data for low address
  • ENB AMXB(8,0) (2-1): Select special data for low and high bits of address
  • ENB AMXB(2) (2-1): Select incoming address for low address
  • ENB C (7-1): Enable C0/C1 on device UNIBUS
  • ENB CLK B (7-1):
  • ENB CLK C (7-1):
  • ENB CPD (7-1):
  • ENB D (7-1):
  • ENB SPOR(0) (6-1): Select scratchpad cache entry for read
  • ENB SPOR(1) (6-1): Select scratchpad cache entry for replacement
  • ENB SPOR(2) (6-1): Select scratchpad register for internal use
  • ENB SPOR(3) (6-1): Select scratchpad register for UNIBUS access
  • ENB XPOR(0-1, 3) (6-1): As above, but for extra scratchpad for optional cache extension
  • +EXEC PER PROC (3-1):
  • EXZE (5-1): Reference to Exec mode page 0
  • FORCE TIMEOUT (15-1):
  • INTRAP (5-1):
  • KEY(0) (8-1): Writeable page
  • KEY(1) (8-1): Public page
  • KEY(2) (8-1): Resident page
  • LONG (8-1): Address in Simple part
  • LONGF (10-1): PGM(12)
  • +LOOKUP (13-1):
  • NORMAL (3-1):
  • ODD ADD ERR (15-1):
  • PAGE (5-1): Cycle with paging enabled?
  • PAD SEL (5-1): Paging register selected?
  • PASS (3-1): PGM(11)
  • PGC(0), PGC(1) (11-1): Function (un-paged; normal; start user)
  • PGC(1:0) (7-1): Start user
  • PGC(4) (11-1): User mode
  • PGC(7) (11-1): Interrupted User
  • PGC(15:12) (11-1): Violation
  • PGM(0-4) (10-1): Replacement Counter
  • PGM(6) (10-1): Previous instruction User mode TRAP?
  • PGM(7) (10-1): Previous instruction fetch Private?
  • PGM(12) (10-1): Cycle to non-Simple part of addess space
  • PGM(13) (10-1): Window access (phase 1)?
  • PGM(14) (10-1): Window access (phase 0)?
  • PGM(15) (10-1): Time out
  • PKER (5-1): Paging error (write into a R/O page, etc)
  • PKIV (5-1): Instruction violation - HALT, RESET, etc in User mode
  • SP SEL (5-1):
  • SPEN (6-1): Scratchpad output enable
  • SPOR(2) (6-1): Register select
  • SRC (5-2):
  • uT (8-1):
  • XSHL, XSHR (3-1): Controls major state transitions
  • YSHL, YSHR (3-1): Controls minor state transitions
  • WELF (10-1): PGM(13)
  • WIND (5-1): Reference to Window register?
  • WINF (10-1): PGM(14)
  • WREND (7-2):
  • WRITE (7:0) (6-1):
  • WRITE (15:8) (6-1):
  • XM CLK (5-2):
  • XPEN (6-1): Optional scratchpad (for cache extension) output enable

The following signals are provided by the KA11:

  • CLKT: ?
  • DEST: In 'Destination' major state
  • FETCH: In 'Fetch' major state
  • ISR 7: Bit 7 of the current instruction
  • ISR 12: Bit 7 of the current instruction
  • JSR: Current instruction is 'JSR'
  • RTI: Current instruction is 'RTI'
  • RTS: Current instruction is 'RTS'
  • SERVICE: In 'Service' major state
  • SOURCE: In 'Source' major state
  • TIME OUT:
  • TRAP: Current instruction is 'TRAP'?
  • TRAPS: ?

Prints

The Engineering Drawings for the KT11-B (7605071) include the following logic prints:

Number Page Count Content
2 2 Address Bus and Control Logic
3 1 State Control Logic
4 1 SP Input Mux
5 2 Associative Memory Control
6 1 Scratch Pad and State Control Logic
7 3 Data Bus and Control Logic
8 1 Keys and Associative Memory
9 1 XP Option for KT11 Associative Memory Control
10 1 PGM Register
11 1 PGC Register
12 1 Timing Logic
13 1 Buffered Signals and Main Logic
14 1 Extended Associative Memory
15 1 KA11 to KT11 Interface
17 1 KT11-B Bus Connectors

The KT11-B is not composed of discrete boards, but rather a large number of mostly small FLIP CHIPs, so the division into drawings, some of which are multi-sheet (as opposed to them all being single-sheet) is a bit arbitrary. It is probably intended to align the drawings with the high-level internal structure.

References to drawing pages are given as 'x-y', where 'x' the drawing number, and 'y' is the individual sheet.

Detailed logic description

This section covers each drawing in more detail, explaining what functions are found in each one. The term 'logic' below means a group of gates (and sometimes flops as well), often used to produce control signals.

Note: For describing which part of a print is being discussed, the terms 'left', 'center' and 'right' refer to the side-side axis, and 'top', 'middle' and 'bottom' refer to the up-down axis. Which axes 'center' and 'middle' refer to can be remembered by the observation that 'center' is usually used in a side-side context, not an up-down one.

Address Bus and Control Logic

The first sheet contains, on the left, buffering between the address lines of the CPU's UNIBUS, and the internal address bus; and in the center and right, logic which generates control signals for the address mux (on the next page).

The left of the second sheet contains an address latching mux (see above for the implementation), divided into high and low 9-bit halves, which may be controlled separately (for page and byte-within-page), and which separately select between:

  • Scratch-pad data output (9 bits wide, repeated in the low and high halves)
  • Scratch-pad data input (18 bits wide, with the low and high halves swapped - although note that that data source is only 16 bits wide: so the low bit in the low half is zero - presumably because only word addresses are used; and the high bit in the low half is a synthetic signal)
  • The internal address bus

The right half of the second sheet contains drivers for the address lines of the device UNIBUS, sourced from the above mux.

State Control Logic

This drawing contains logic which generates two state change control signals for each of the major and minor states (XSHL, XSHR, YSHL, YSHR).

Scratchpad Input Mux

At the top, a 16-bit wide latching mux (see above) which provides the input to the scratchpad memory. The three inputs are:

  • The internal address bus
  • The internal data bus
  • Scratchpad data output

At the bottom is logic which generates the selection control signals for that mux.

Associative Memory Control

The first sheet contains a number of different logical units: the top left contains logic which indicates that the CPU is 'executing a TRAP instruction'?/'in a trap sequence'?; the top right contains logic to recognize references to KT11-B internal registers; and the bottom right contains logic to generate several control signals.

The bottom left contains logic to detect illegal instructions in User mode (HALT, WAIT and RESET), and non-'entry' instruction when transferring to a private page. The column of three 4-input NAND gates recognize the 'entry' instruction, HALT/WAIT, and RESET, respectively; the first is then combined wirh other signals (PGC(7)(0) is probably a type for PGM(7)(0)), before all three are ORed together, and then ANDed with signals indicating the KA11 is in (instruction) 'Fetch' major state, and the KT11-B is in 'User' mode, to generate the IV error signal.

The second sheet also contains a number of different logical units: the right side contains logic to load individual associative memories; the bottom left contains logic to generate the binary-coded identification of the scratchpad memory entry corresponding to a associative memory which matched (used to read that entry out of the scratchpad); the center bottom contains logic to indicate an associative memory match.

Scratchpad and State Control Logic

Logic which controls the scratchpad memory: the center top and entire right side contain logic which (apparently) indicates which register (stored in the scratchpad) the KT11-B itself needs access to; the center bottom contains logic which indicates which set of scratchpad address inputs (out of four, see the "Keys and Associative Memory" section) are to be used ; the left bottom performs the same function for the scratchpad in the optional extended cache.

Data Bus and Control Logic

The first sheet contains logic to create various control signals.

The far left of the second sheet contains input buffers (from the CPU's UNIBUS) for various bus control signals; the center left contains the drivers for data lines of the device UNIBUS, which are fed from the (buffered) data lines of the CPU's UNIBUS; the right contains half of a multiplexor (built from NAND gates connected in a wired-OR network) which drives the data lines of the CPU's UNIBUS, for which the inputs are:

  • The data lines of the device UNIBUS (through a set of receivers, which also generate the internal data bus)
  • Scratchpad data output
  • The KT11-B Control and Maintenance registers

The left and center of the third sheet contains the other half of the data mux; the right shows the KW11-L Line Time Clock card.

Keys and Associative Memory

The left side shows the scratchpad memory; note that the register number input select lines (top group, left side of the block) select one of four sets of register number input lines (also on the left). From the top, they are:

  • The binary-coded number of the associative memory that matched - note that the high bit is tied high, indicating the cache page table entries are stored in the top half of the scratchpad
  • Replacement counter (from the KTMR); note that the lowest value this can have is 010, so that it always addresses cache entries, which are stored in the top 010 locations
  • A set of signals which apparently indicate which register the KT11-B needs to be able to store - note that the high bit here is tied low, indicating they are stored in the bottom half of the scratchpad
  • The low bits of the internal address bus (likely for register read-out)

The top center shows the associative memories; note that the only inputs to each are the 7 high bits of the internal address bus, and the Exec/User mode bit; the associative memory must be loaded from the internal address bus early during a cycle which provokes a cache replacement.

The top right shows a comparator used for the division of the Exec and User address spaces into two kinds of pages; the bottom right is the counter?/shift register? which generates the minor state.

The bottom center is a 3-bit wide latching mux which holds protection key information for the current memory cycle. The three inputs are:

  • A signal indicating a reference to Exec mode page 0 (replicated to all three key bits), used to generate a synthetic 07 key for Exec page 0 (which does not have a page table entry)
  • 3 bits from the device UNIBUS (for page table entries loaded from memory)
  • 3 bits from the scratchpad (for cached page table entries)

XP Option for KT11 Associative Memory Control

This contains logic to control the optional cache entries: the left and center contain gates to control loading of associative memories; the right contains logic to generate the binary-coded identification of the entry in the optional scratchpad memory (used with the extended cache) corresponding to a associative memory which matched.

PGM Register

The KT11-B's Maintenance register: the center top is the replacement counter; the rest of the page is logic (including S/R flops) to generate the currently un-documented other bits in the Maintenance register - bits 6, 7, 11, 12, 13, 14, 15. (The Option Description indicates - Section 3.3.2.6 - that there are 5 bits, but the drawings show 7.) Note than many of these bits are actually used elsewhere in the KT11-B during normal operation, they are not purely diagnostic.

The top right is logic to record that the instruction is a TRAP in User mode; it includes a modified 'gated D latch' (with addition inputs to the SR latch which is its second stage). The middle and lower right is logic (again including a 'gated D latch') that records if a cycle is to the non-Simple part of the address space; the middle center is a delayed copy of that. The bottom center holds logic to record that the CPU reported a timeout, and logic to record a cycle to the Window register; the lower left corner contains a delayed copy of that. The middle left is logic (again including a 'gated D latch') that records if a fetch is to a Private page.

PGC Register

The KT11-B's Control and Status register - S/R flops to store the bits, and logic to control setting and clearing them: in the upper right, the Source and Destination bits; in the center and lower right, the five Violation bits; in the upper left and center, the two Function bits; in the left and center middle, the User and Interrupted User bits, respectively.

Timing Logic

Main article: KT11-B Major State circuitry

The top and lower right contain gates which combine major and minor state lines into signals for each individual state.

The lower left contains the 2-bit counter (built out of two D flops, and associated circuitry) which produces the major state; and also logic to produce major state signals. Note that the two flops (and their input circuitry) don't form a straight binary counter, but rather a Gray code counter. So, a sequence of XSHL pulses will generate the following major state sequence:

00, 10, 11, 01, 00

and XSHR will produce:

00, 01, 11, 10, 00

Buffered Signals and Main Logic

The left side shows the W130 Maintenance Card; the top left and center contain buffering for various internal signals; the right contains buffering for the high 9 bits (i.e. the page number) of the internal address bus.

Extended Associative Memory

On the left, the scratchpad memory for the optional 16-entry page table cache extension (to 24 entries total), with the possible register number inputs:

  • The binary-coded number of the extended associative memory that matched
  • Replacement counter (from the KTMR)
  • The low bits of the internal address bus (likely for register read-out)

Note that the fourth set of address inputs to the scratchpad are unused (note the selector line for that set of inputs is tied low).

The center and right are the associative memories for the extended cache.

KA11 to KT11 Interface

In addition to the interface cable, this sheet also shows the synthesis of a number of signals which are passed across the interface.

Note that the gates on the left are actually physically in the KA11 (an additional M135 hex NAND card is plugged into slot B08 of the KA11's backplane).

In addition to logic in the KT11, the right side also shows buffers for signals coming from, or going to, the interface cable.

Construction

As mentioned, the KT11-B is constructed out of a large number of smaller FLIP CHIPs, plugged into a custom-wired backplane.

Module Counts

The module type usage counts are:

Type Function Count Comment
M111 16 x Inverters 10
M112 10 x 2-input NOR 5
M116 6 x 4-input NOR 10
M133 10 x 2-input NAND 24
M135 8 x 3-input NAND 6
M139 3 x 8-input NAND 1
M167 Magnitude comparator 1
M203 8 x R/S flip flops 1
M206 6 x D flip flops 1
M207 6 x J/K flip flops 1
M225 Scratchpad memory 1 2 for 24 cache entries
M240 R/S flip flop 1
M244 6 x quad-2-input-AND/OR gates 6 Used as latched multiplexors (see above)
M259 Associative memory 4 12 for 24 cache entries
M602 2 x Pulse amplifier 1
M611 14 x Power inverter 3
M627 6 x NAND amplifier 7
M721 UNIBUS transceiver 4
M783 12 x UNIBUS NAND transmitters 6
M784 16 x UNIBUS inverter receivers 2
M826 Clock/shift register 1

The counts are from the list in the "KT11-B Option Description" document; they have been cross-checked against the 'Module Utilization' sheet from the KT11-B Engineering Drawings, and also the module location chart (below) and all known variances have been sorted out.

Module Locations

The following table, drawn from the 'Module Utilization' sheet from the KT11-B Engineering Drawings, gives the location of the various modules in the backplane:

Slot A B C D
01 UNIBUS In M259 M133
02 M930 M259 M133
03 UNIBUS Out M259 M133
04 M930 M259
05 M721 M721 M259%
06 M721 M721 M259%
07 M783 M784 M259%
08 M783 M784 M259% M133
09 M783 M787 $ M259% M133
10 M783 M244 M259% M133
11 M783 M244 M259% M133
12 M783 M244 M259% M903 @
13 M826 M244 M627 M111
14 W130 $ M244 M627 M133
15 M116 M244 M627 M133
16 M225 M627 M133
17 M225% M111 M133
18 M116 M112 M627 M133
19 M116 M112 M627 M133
20 M116 M112 M627 M133
21 M116 M112 M133
22 M116 M112 M133
23 M116 M602 M133
24 M116 M135 M133
25 M116 M135 M611 M133
26 M116 M135 M611 M133
27 M203 M135 M111 M133
28 M206 M135 M111 M133
29 M207 M135 M611 M133
30 M240 M133 M111 M111
31 M139 M111 M111
32 M167 M111 M111
  •  % = Optional
  • $ = Not part of KT11-D
  • @ = Cable

Questionable entries (since the table is hand-written, and hard to read in places because of poor-quality duplication from the originals) have been cross-checked against the prints, and all known uncertainties have been cleared up.

Card Information

The drawings contain a number of different FLIP CHIPs as blocks, without showing individual details; information about them is given here.

M167

Shown on page 8-1, this is a 8-bit comparator; see here for details.

M203

Shown on pages 7-1, 10-1 and 11-1, although not as as a single block, but rather individual units, this contains eight R/S flip flops; see here for details.

M225

Shown on pages 8-1 and 14-1, this is a 16x16-bit scratchpad memory; see here for details.

Pin AN1 is a control input of some sort, but it is not yet clear what it does. It is possible that it is some sort of 'output enable', for use in cases where the optional second scratchpad memory is installed, since the two feed the same output bus.

M240

Shown on pages 10-1 and 11-1, although not as as a single block, but rather individual units, this contains six R/S flip flops; see here for details.

M259

Shown on pages 8-1 and 14-1, this is a dual 8-bit associative memory.

M602

Shown on pages 6-1 and 13-1, although not as as a single block, but rather individual units, this is a dual pulse amplifier; see here for details.

M787

Shown on page 7-3, this is actually not a part of the KT11-B; rather, it is the KW11-L Line Time Clock, which must reside in the KT11-B's backplane.

M826

Shown on page 8-1, this is a clock with counter?/shift-register?

W180

Shown on page 13-1, this is actually not a part of the KT11-B; rather, it is the Maintenance Card, which must plug into the KT11-B's backplane.