[TUHS] porting to different systems, Bootstrapping UNIX - how was it done

Aron Insinga via TUHS tuhs at tuhs.org
Wed Mar 25 06:01:59 AEST 2026


p.s.

The first reference to check for DEC computer history questions (up 
through when the book was published) is _Computer Engineering_ by Bell 
et al.  (Your favorite search engine is also your friend, when it isn't 
being evil. :-) )

https://gordonbell.azurewebsites.net/Computer_Engineering/00000539.htm

    We should ask: "Could a PDP-6 level processor be built in/1975/to
    sell for $10K?"

    Clearly it could, and such a system has been built as an advanced
    development project. This small 10 has a unified bus structure like
    the PDP-11 with a connection to use the Unibus family*I/O*devices. A
    system with 512 Kwords and the performance of greater than that of a
    KA10 occupies a cabinet somewhat smaller than a PDP-11/70 minicomputer.*

    ----
    *The computer called the 2020 was introduced in May 1978.

The internal bus of the DECSYSTEM-2020 was somewhat similar to the SBI 
(Synchronous Backplane Interconnect) of the VAX-11/780.

I had heard that the name change from PDP-10 to DECsystem-10 happened 
when DEC started selling PDP-10s for data processing applications, and 
started using them for that itself at the Information Processing Center 
(IPC) in PK (Parker St., Maynard), while the later capitalization change 
to DECSYSTEM-20 was due to some trademark issue.  But many people still 
called them PDP-10s or by the CPU model name (KA, KI, KL, KS).

There is a very nice table here:
http://pdp10.nocrew.org/cpu/processors.html
Although I believe the Tiny machine was to be KT20 instead of KT10 
because some old PDP-10 option was called a KT10.

For the way-too-curious :-) the MSDPM Test sources are here:
https://pdp-10.trailing-edge.com/klad_sources/01/klad.sources/msdpmt.b36.html
I can't speak for others on the team, but I'm sure that I should have 
typed more comments, sorry.
If my BLISS-36 coding style is a bit a-typical, perhaps it is because I 
liked that it was (at the time) an expression language. 
https://archive.org/details/full-bliss-history
More related files are in https://pdp-10.trailing-edge.com/klad_sources/
Naming convention: m = MainDEC (diagnostic); s = KS10; DPM, DPE, etc. 
are the boards to be tested.

(And if you get into that directory, I have to add that I think 
DAKA*.MAC is a really nice example of testing each instruction and using 
what you already tested in the remaining tests.  Hats off to JOHN R. 
KIRCHOFF and DICK MALISKA [RIP].  But I digress.)

- Aron


On 3/24/26 15:09, Aron Insinga via TUHS wrote:
> Your comments are interesting.  Do you have references?
>
> In particular, I do not believe the KS10 ever emulated the PDP-11 or 
> the Intel 8080, or ran RT-11.  (Unless you know someone who did that 
> as a hack?)  The microcode here shows the power-up sequence at listing 
> source lines 2148 (0:) and 7843 (PWRON:):
>
> https://archive.org/details/bitsavers_decpdp10KS_21955535/mode/1up
>
> The KS10 included a real 8080 as the front-end processor.
>
> In manufacturing, so that certain diagnostics could control the 
> machine under test, a serial line from a KL10, which ran the 
> diagnostic program, was connected to the 8080.  Through the 8080, the 
> diagnostic could (among other things) load microcode into the KS10, 
> single-step the KS10, and read the micro-PC.
>
> (There wasn't a direct 32-bit data output that could be sampled, so in 
> MSDPM (for the data paths to memory, DPM) board, a microcode snippet 
> branched to one of two locations based on 1 bit, the diagnostic read 
> the micro PC to find the location to see what the bit was, and the 
> snippet shifted the data to get the next bit.  I debugged that sitting 
> on the floor (I guess I had the DPE board on an extender) and used a 
> DVM to check the bit's value and then reached up to the LA36 console 
> to hit return and execute the next step.  (Return repeated the last 
> command.)  We should have put the KS10 protos up on concrete blocks 
> like they did in TW for the Comet protos, although I think the KS10 
> cabinets were taller to start with.
>
> The KS10 data path execution (DPE board) had 10 AM2901 bit slice 
> chips, with 2 bits extra on each end, so the left and right halfwords 
> were divided between chips and could be clocked separately.
>
> The DPM board had bunch of (IIRC Fujitsu 10ns but this was long ago) 
> SRAMs along with the 10-bit exponent arithmetic datapath logic (not 
> done with AMD chips) that wouldn't fit on the DPE board.
>
> The KS10's microsequencer was custom built and did not use the 
> AM2900-family chip.  I don't recall why.
>
> As for the KL10:
>
> The standard KL10 front-end PDP-11 operating system was RSX-20F (F for 
> front end).  However, when the machines started shipping, it wasn't 
> ready, so temporarily they used a different, small operating system, 
> KLDCP (the KL Diagnostic Control Program) written by the Large Systems 
> Diagnostics Group in MR1-2 for, well, running diagnostics programs.
>
> https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n5/mode/1up?q=kldcp 
>
> https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n154/mode/1up?q=kldcp 
>
>
> https://f6.erista.me/files/bitsavers/scandocs.trailing-edge.com/rsx20f-aa-h213a-tk.pdf 
>
>
> (I was hired by DEC for the Large Systems Diagnostics Group in MR1-2 
> to modify KLDCP for a new machine, I think it was Dolphin. When that 
> project suffered a design setback, I worked on the KS10 STIRS 
> diagnostic [MSDPM, mentioned above] and the VAX-11/750 [Comet] "CPU 
> Cluster" Exerciser [NOT related to VAXcluster] for character string 
> and interlocked queue instructions.)
>
> - Aron
>
> On 3/24/26 11:14, Clem Cole via TUHS wrote:
>> [...]
>> In the 2020 model, in addition to the core KL10 emulation, the AMD 
>> bitslice
>> microcode also emulated the PDP-11 and the Intel 8080.   This 
>> microcode was
>> the SW equivalent of the original 11/34, which used the 8080 as its 
>> front
>> console.  At boot time, the KS10 ran RT11 from either its own floppy 
>> disk
>> or from the system disk.  This version of RT11 could run diagnostics and
>> load the OS [originally TOPS-20, but eventually Version 7.01 could 
>> execute
>> on a KS10 too].  At some point after the OS was loaded, the microcode
>> switched to emulate KL10.  Unlike KL10-E's the console terminal via the
>> PDP-11 front-end, for the KS10 the console's UART was attached ti main
>> processor [what I don't know is after the microcode swap from 
>> PDP-11/8080
>> mode into PDP-10 mode, how console communicated with the OS - i.e., 
>> was it
>> just part of TOPS-20 or did the TOPS-20 use the same interface as the 
>> KL's
>> and thus the microcoded PDP-11 running RT11, would have actually push 
>> the
>> bits to the UART.
>


More information about the TUHS mailing list