My EuroBSDCon talk on the fist 10 years of Unix is up. EuroBSDCon Unix at 50, V7 at 40 I hope you enjoy.
20191027
20191010
Video Footage of the first PDP-7 to run Unix
Hunting down Ken's PDP-7: video footage found
In my prior blog post, I traced Ken's scrounged PDP-7 to SN 34. In this post I'll show that we have actual video footage of that PDP-7 due to an old film from Bell Labs. this gives us almost a minute of footage of the PDP-7 Ken later used to create Unix.
The Incredible Machine
The Incredible Machine is a Bell Labs film released in 1968 and available on youtube here: https://www.youtube.com/watch?v=iwVu2BWLZqA It outlines a number of innovative computer things that Bell Labs was doing around audio and visual things with different PDP machines from DEC. Pretty cool, right? Especially because this film features the song "Daisy" sung by a computer, a plot point that would feature heavily in Stanley Kubrick's 2001: A Space Odyssey. (although that plot point was set in 1962, and was based on work done by IBM with the first song sung by a computer).
I'll concentrate on footage from 9:19 to 10:31 in the film. This footage talks about making computer made music. If you listen to the audio, it sounds quite quaint, although when it was made it was cutting edge.
Making the case that it's a PDP-7
Here's a screen shot from 9:43 in The Incredible Machine. From it we can make the case that we're looking at a PDP-7, hereafter called TIM PDP-7.
The screen shot looks a little boring until we compare it against two photos of PDP-7s from the archives. The first one is photo from a DEC PDP-7 sales catalog that's available online at https://www.soemtron.org/pdp7.html. The second photo is from SN115 from a machine in Oslo from the Institute of Physics that's been semi-restored (picture also from Soemtron).
I've superimposed the three photos together and highlighted 4 areas of convergence with numbers:
- The register panel that reports the status of an expansion cabinet. This is clearly visible in both photos in similar places.
- The control panel. It's clearly the same between these two photos. The control panel is used to examine and modify memory contents of the system as well as displaying internal registers of the PDP-7.
- The paper tape reader (option 444B). This reader is also visible from 9:19 to 9:30 in The Incredible Machine reading in a new program.
- Is the PDP-7 name badge. Although it's quite obscure in these photos, its clearly the same.
So, I think it is safe to conclude that the computer in this footage is a PDP-7. We have two different pictures of actual PDP-7s that the computer in The Incredible Machine clearly corresponds to. I'll leave it as an exercise for the reader to exclude all the other machines from that era, though my experience suggests that the register and control panels should be enough.
Hunting the Serial Number for this PDP-7
So we have found footage of a PDP-7 from Bell Labs. That's cool, can we push the envelope further and track down which serial number TIM PDP-7 might be? Let's look at the key features of the machine in the picture above and the video footage.
- Option 444B, paper tape reader (Also seen in 9:19-9:30 in The Incredible Machine)
- Option 340 Display (seen 10:06-10:14 and 10:22-10:25)
- Option 370 High Speed Light Pen (seen 10:06-10:25 as well)
So, if we look at the PDP-7 field service list available at https://www.soemtron.org/downloads/decinfo/18bitservicelist1972.pdf (itself a excerpt of a more complete one at bitsavers), we find there's two machines with the display and light pen: SN 34 and SN149.
Ken's machine (SN34) has all these options:
The other candidate machine (SN149) in the list has them as well:
So how can we decide which is which?
If we look at dates, we see that the SN34 machine was in place early enough to be in a 1968 film with an installation date of 1965. SN149 appears to be too late with a 1969 date. However, that's not conclusive. The other fields are blank and SN148 and SN150 both have 1967 dates. It's weakly suggestive, so we need more. We can't eliminate it based on dates, as pleasing as it would be to do so.
We may be able to eliminate the TIM PDP-7 as SN149 because TIM PDP-7 clearly had the Option 444B paper tape reader, and SN149 doesn't list that in the field service log. Based on this we can exclude SN149, but only weakly because the paper tape readers were common.
Can we make the case stronger? The service logs show that SN149 has a Option 550/TU55 which is a DECtape and controller, while the SN34 does not. Ken Thompson has confirmed there was no DECtape, just paper tape on the machine he used. If we could confirm this machine didn't have a DECtape, our case would be strong for it being SN34.
Looking at the footage is hard because it is so dark. Even so, we can see a blank panel over the Option 444B paper tape reader shown starting at 9:19, though it's hard to be sure. If we look at the 9:43 frame above, we can't tell. When the color balance is adjusted we see the following:
we can clearly see here the card reader from the initial footage and what appears to be a blank panel above. There's no tell-tale circles that would indicate an installed DECtape there. Single stepping the video with this enhancement shows no other targets. There is something weird just over the younger gentleman's head, but it's not a DECtape.
Looking at the field log, the DECtape components were serviced in 1969, after this film was made. It's not clear if this was when the parts were added, or if they were merely repaired or replaced. After studying the field service log for a while, I thing we'd bias our data towards replacement rather than installation. Especially since there's no other bulk input media, like a paper-tape, listed.
Pulling it all together: we have clearly found a PDP-7. There were only 4 PDP-7s shipped to AT&T. Only two had the 340 display option clearly seen in the film. Of those two, one had DECtape, the other had a paper-tape reader. We know from Ken that his had a paper-tape reader. There's no DECtape evident in this film, but clear evidence of the paper-tape reader. It's not known where either SN34 or SN149 lived inside Bell Labs, but we know that Ken used a machine that had been cast off from the Visual and Acoustics Department. While the film doesn't list the internal departments that contributed to it, the computer generated music strongly suggests it could have been the Visual and Acoustics Department. Taken together, we can say that three lines of evidence support that the PDP-7 in The Incredible Machine from 9:19 to 10:30 would later be used by Ken to create Unix.
Labels:
historic unix,
ken thompson,
pdp7,
unix,
unix50,
video
20190709
The PDP-7 Where Unix Began
Serial Number of First Unix System
In preparation for a talk on Seventh Edition Unix this fall, I stumbled upon a service list from DEC for all known PDP-7 machines. From that list, and other sources, I believe that PDP-7 serial number 34 was the original Unix machine.PDP-7 System from DEC sales literature |
Building The Case
We know from simh sources, the restored PDP-7 Unix version 0 sources, and recollections from the time that the original machine used by Ken Thompson and Dennis Ritchie had, or likely had, the following hardware:- 8k word of memory (option 149B)
- A tape reader (option 444B)
- A tape punch (option 75D)
- A 1MB disk drive (RB09 same as an RD10)
- A tty controller for a teletype (option 649)
- A standard video display (option 340)
- A custom video display (Unknown option number)
- A keyboard for input (also option 340)
We know from the service list that Bell Labs had three PDP-7s and one PDP-7A. Several of these machines had the standard options (the tape reader and teletype) and extra memory. Only one system, serial number 34, also had a disk drive, a custom unknown board that could be a Bell Custom display, and the standard display. In addition, that system shipped to Bell Labs in 1965 and appears to have been refurbished in 1969. This timeline matches the oral histories describing a discarded PDP-7 used to bring up the system in late 1969.
Here's the full table of all the systems shipped to Bell Labs with each system's options, taken from the 18 bit service list provided by Bob Supnik. You can check the list for other contenders.
Serial Number | Option # | Option Name | Ship Date |
PDP-7 #3 | 1100? | ||
7 | PDP7 CPU unit? | ||
75D | Perforated paper tape punch and control | ||
173 | Data interrupt multiplexer | 07-68 | |
177B | Extended arithmetic element | 1128? | |
444B | Perforated tape reader and control | ||
550A | DECtape dual magnetic tape control | 12-67 | |
649 | Teleprinter and control | ||
CR01B | 100Cpm card reader and control | ||
TU55 | Single DECtape transport | 12-67 | |
TU55 | Single DECtape transport | 12-67 | |
TU55 | Single DECtape transport | 03-69 | |
PDP-7 #34 | 01-69 | ||
75D | Perforated paper tape punch and control | 07-65 | |
149B | Core memory module 8K, extends in 8K blocks | 07-65 | |
177 | Extended arithmetic element | 07-65 | |
340 | Precision incremental CRT display | 07-65 | |
342 | Symbol generator for 340 display, first 64 characters | 07-65 | |
370 | High speed light pen | 07-65 | |
444B | Perforated tape reader and control | 07-65 | |
649 | Teleprinter and control | 07-65 | |
CR01B | 100Cpm card reader and control | 12-66 | |
PDP7 | CPU unit | 07-65 | |
RC09 | RB09 disk? | 01-69 | |
76 05477 | Custom Bell Labs Display? | 01-69 | |
PDP-7 #44 | 11-65 | ||
75D | Perforated paper tape punch and control | ||
149B | Core memory module 8K, extends in 8K blocks | 11-65 | |
177 | Extended arithmetic element | ||
444B | Perforated tape reader and control | ||
649 | Teleprinter and control | ||
PDP7 | CPU Unit | 11-65 | |
PDP-7A #149 | 03-69 | ||
149 | Core memory module 4K, extends subsequent 4K blocks | ||
175 | Information collector expansion | ||
175 | Information collector expansion | 03-69 | |
177B | Extended arithmetic element | ||
340 | Precision incremental CRT display | ||
347C | CPU CRT subroutine interface | ||
370 | High speed light pen | ||
550 | DECtape dual magnetic tape control | 03-69 | |
637 | Bit synchronous data communication system | ||
CR01B | 100Cpm card reader and control | ||
KA71A | I/O device package | ||
KA77A | Processor unit (PDP-7/A) | ||
KB03 | Device selector expansion | 03-69 | |
TU55 | Single DECtape transport | 03-69 |
Another surprise
V0 Unix could run on only one of the PDP-7s. Of the 99 PDP-7s produced, only two had disks. Serial number 14 had an RA01 listed, presumably a disk, though of a different type. In addition to the PDP-7 being obsolete in 1970, no other PDP-7 could run Unix, limiting its appeal outside of Bell Labs. By porting Unix to the PDP-11 in 1970, the group ensured Unix would live on into the future. The PDP-9 and PDP-15 were both upgrades of the PDP-7, so to be fair, PDP-7 Unix did have a natural upgrade path (the PDP-11 out sold the 18 bit systems though ~600,000 to ~1000). Ken Thompson reports in a private email that there were 2 PDP-9s and 1 PDP-15 at Bell Labs that could run a version of the PDP-7 Unix, though those machines were viewed as born obsolete.Please see this followup post where I make the case that footage of the PDP-7 Ken would later use has been found on youtube....
Labels:
historic unix,
ken thompson,
pdp7,
unix,
unix50
20190211
Strange Code
Now That's Weird
I was trying to compile some ancient code I pulled off the net. It is related to the Venix stuff I've been doing on and off of late.
This code originally ran on BSD 4.1. The only system that version of Unix ran on was a VAX (later versions were more widely ported, but 4.1 was more of a limited distribution version). OK, looking up the movc3 instruction on vax references online, we see it is the "Move Character" instruction. r8 is the length. srcaddr is (r11) and dstaddr is (r7). So in effect, someone has done an inline of bcopy() here. Now, that's half of the problem. The other half is puzzling out what is in r7, r8 and r11 at the time of this call. In a perfect world, I'd just crank up the compiler to tell me. We live in an imperfect world where spinning up a 4.1 BSD system takes a substantial amount of time.
Fortunately, we can guess. cnt -= put gives us our first clue. We're decrementing by how much we copied, it seems. So r8 (the length) is put. OK. Now, we have this nice variable named 'to' that was most likely in the dstaddr (so r7), and we update it after (to appears only to be here for the side effect, so that's nice). But what's the from? The only thing it could logically be is 'p' since we += it by put as well.
So my best guess is that can be replaced by memcpy(to, p, put); and life will be good. My spidy sense also tells me that we don't need memmove here because they aren't overlapping ranges.
So that's weird, right. What the heck is that movc3 doing in the middle of that code.put = bp->b_nleft;if (put > cnt)put = cnt;bp->b_nleft -= put;to = bp->b_ptr;asm("movc3 r8,(r11),(r7)");bp->b_ptr += put;p += put;cnt -= put;goto top;
This code originally ran on BSD 4.1. The only system that version of Unix ran on was a VAX (later versions were more widely ported, but 4.1 was more of a limited distribution version). OK, looking up the movc3 instruction on vax references online, we see it is the "Move Character" instruction. r8 is the length. srcaddr is (r11) and dstaddr is (r7). So in effect, someone has done an inline of bcopy() here. Now, that's half of the problem. The other half is puzzling out what is in r7, r8 and r11 at the time of this call. In a perfect world, I'd just crank up the compiler to tell me. We live in an imperfect world where spinning up a 4.1 BSD system takes a substantial amount of time.
Fortunately, we can guess. cnt -= put gives us our first clue. We're decrementing by how much we copied, it seems. So r8 (the length) is put. OK. Now, we have this nice variable named 'to' that was most likely in the dstaddr (so r7), and we update it after (to appears only to be here for the side effect, so that's nice). But what's the from? The only thing it could logically be is 'p' since we += it by put as well.
So my best guess is that can be replaced by memcpy(to, p, put); and life will be good. My spidy sense also tells me that we don't need memmove here because they aren't overlapping ranges.
Subscribe to:
Posts (Atom)