On 9 Nov 2010 at 9:15, Roger Holmes wrote: Here's where we run smack-dab into Alice and Humpty-Dumpty again. Companies had their own vocabulary and words meant what they meant within the company and often, within a given division. In the CDC world, PPU (or PP) had a very specific meaning. Not SPOOL or ASP as in the IBM world, but a processor that was an inseparable part of a system. One of the projects I worked on used 1700 minicomputers as communications processors and had several 16-bit minicomputers identified as "controllers" to handle disk and tape drive interfacing. None of these was called a PPU. No, on 6000/Cyber 70/170 systems, a PPU was a 12-bit processor that had unrestricted access to CPU memory and had the only connections to the world outside of the CPU. The cycle time of the CPU was 100 nsec.; that of the 10 PPUs was 1 usec. Essentially, the set of PPUs was nothing more than 10 sets of registers and 4K of 12 bit words multiplexed 10 ways with a processor core with a 100 nsec cycle time. ("Hyperthreading" anyone?) In addition to being able to read and write the memory of the CPU, any PPU could "exchange jump" the CPU; that is, force a swap of the entire CPU register set with an area in memory. We'd call that an "interrupt" today, I guess. In the traditional scheme of things, only two PPUs had dedicated functions; PP0 served as the timekeeper and observed the state of the CPU (PPUs could also read the CPU P-counter) and was delegated the function of interrupting the CPU. PP1 (this could vary a bit) served to provide operator console display--the original display was an unbuffered vector-mode display and so needed to be continuously refreshed. The remainder of the PPs were consigned to be "pool" PPs and assigned to specific operating system tasks as needed. One PP could transfer data to another PP or to an external device via a "channel". Humpty strikes again--in CDC parlance, a channel was nothing more than a bidirectional latch with flags for empty or full and connected or disconnected. Unlike the IBM interpretation, a CDC channel has no intelligence at all--it's just a conduit. Up until about 1975 or so, almost no part of the operating system resided in the CPU. OS activity was the province of the PPs--and users did not have the ability to write their own PP programs. One interesting aspect of this arrangement is that a program could initiate I/O activity on a device using a circular-buffer interface with a PPU and, as long as data could be accepted or supplied, continue on that same device chasing pointers with the PP without any other intervening OS interruptions, save for the scheduler intervening at the end of a time slice. When the 7600 came along, the PPs were removed from the time- multiplexed arrangement and made to run asynchronously, but they were also barred from freely accessing CPU memory or even reading the CPU P-counter. Instead, each was hardware-assigned a pair of buffers (one input, the other output) in memory and the CPU given an instruction to set an I/O request flag. The OS thus had to be moved into the CPU and the PPs relegated to I/O exclusively. --Chuck

On 9 Nov 2010 at 11:18, Richard wrote: Wow, you've got your work cut out for you, starting with the 3-phase 400Hz power feed. Did you manage to get the controller for the display also? My own experience mostly was with the older two-tube display: http://bit.ly/aRrdrc I seem to recall that the CRTs for the things were very expensive and imported from Germany. The 7600 used a single-tube display and was driven by the MCU. I think the single-tube displays on other equipment came in on the Cyber 170 series. Earlier models were the two-tube variety--no difference in programming. The usual order of things was to have the system dayfile on the "A" display and the running job display (control point) on the "B" side. The console driver used auto-completion for commands, so typing "7RO" would cause autocompletion to "7,ROLLOUT". There were probably around 20 different displays that could be brought up, each assigned a letter. Lots of room to spread out listings, spill coffee, etc... --Chuck

From: Chuck Guzis Sent: Tuesday, November 09, 2010 8:39 AM This does not accord with my recollection of the 6600 at all. I started college at the University of Texas in September, 1969, and was immediately exposed to the CDC 6600: Since I had learned FORTRAN IV the preceding spring, the work-study folks sent me over to the Comp Center to interview for a job. I'm afraid my IBM bigotry kept me from getting the position. However, I met CS grad students through my job at the CAI Lab (IBM 1800 and 360 based) who were working on the 6600. One of them was a whiz at writing PPU code. I signed up for a COMPASS class in the fall of 1970; besides learning about the CPU, there were sections of the syllabus on PPU programming. Since this was an undergraduate intro-level class, I can't imagine that they were teaching anything privileged and/or dangerous. But it's 40 years ago, so I may very well have killed off those neura. Rich Alderson Vintage Computing Sr. Server Engineer Vulcan, Inc. 505 5th Avenue S, Suite 900 Seattle, WA 98104 mailto:RichA at vulcan.com mailto:RichA at LivingComputerMuseum.org http://www.PDPplanet.org/ http://www.LivingComputerMuseum.org/

IIRC the 2 processors in an HP9845 (which I consider to be a micro) are the PPU (Peripheral Processor Unit) and LPU (Language Processor Unit). -tony

A helluva lot of beginning computer courses now, and back to mid 1960s introduced the term CPU, and sometimes ALU, but don't/didn't mention PPUs. I did some FORTRAN on a 7094 at GSFC (SSDC Bldg 26) 40 years ago. They were using a 360/30 to do I/O for the 7094! Would that make that 360 a PPU :-? -- Grumpy Ol' Fred cisin at xenosoft.com

In article <4CD92AF4.3381.E8EA28 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: I just have the console desk as pictured in those photos (not of my hardware, but mine looks comparable). For dealing with the exotic power requirements, I was hoping that simply replacing the power supply with a more modern supply would be sufficient. However, I haven't investigated what the CC545 requires for internal voltage and current. My only experience with CDC machines was through a PLATO terminal. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On 9 Nov 2010 at 14:30, William Donzelli wrote: Not according to the CC545 hardware manual (62952600) that Richard pointed to: "This manual documents the CONTROL DATA CYBER 170 Display Station, equipments CC545-C/D and the U.L.-listed equipments CC545E/F. The display station contains a 21-inch crt to display information received from a computer via a CYBER 170 Display Controller..." Nothng I see in the schematics for the thing shows anything about a display controller, just the basic display box. The display controller interprets the 12-bit data sequences and outputs either character or graphics (depending on the content), automatically keeping track of the drawing position. So the display controller is apparently separate from this thing, just as it is with the DD60. Where it's located, I don't know--the CYBER 170 was after I moved on within CDC. Looking at the schematics, the power supply takes both 60 Hz single- phase and 3-phase 208V 400Hz. The 60 Hz looks to be mostly for fan power. The 400Hz is a regular delta-wye transformer feed with several secondaries. --Chuck

On Nov 9, 2010, at 5:15 PM, Fred Cisin <cisin at xenosoft.com> wrote: Hey, I used to live down the street from there, right off of Greenbelt Road. -Dave -- Dave McGuire Port Charlotte, FL

I did a lot of FORTRAN on a 7094 at UTIAS (University of Toronto Institute of Aerospace Studies) about 45 years ago. While I can't be positive, I believe that all of the input and output was via tape. IIRC, a 1401 was used to read the standard IBM cards and copy the input to a tape drive on the 1401. The 7094 would then read the tape after it was transferred to a drive on the 7094 with output being to a second tape on the 7094. I think there were probably a number of additional tape drives on the 7094 along with a disk drive (washing machine size and probably only megabytes in size). Finally, the output tape was transferred back to a drive on the 1401 and the actual output became printed pages and punched cards. In my case, the punched cards were the executable program about 300 to 400 cards which was a substantial reduction since all cards could be read at the same speed. If my memory of the system is correct, the Toronto installation had only tape drives and a small disk drive as units which allowed input and output. Does anyone else remember how the 7094 handled input and output? I would guess that if the 360 could handle the user interface, then the 360 might be a bit slow at computation. About 42 years ago, I worked for NORTEL on the CDC 3300. That system allowed many users to edit their input files (probably 10 to 20 users on terminals) and submit the files to the system to run their programs as batch jobs. IIRC, the batch queue was one user at a time since that was probably faster considering the limited capability of a system in 1968. For the users, all of their files could be held on the computer hard drives and no cards were required. Output was printed hard copy. Jerome Fine

In article <4CD9BE41.20182.412F8 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: What you're calling the display controller I was lumping into the PPU. The project ends up being the same scope -- you need to drive the display and there's not much in the display itself. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

In article <4CDA6CBF.13205.9B6937 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: This seems similar to the 12-bit word commands described in the docs for the CC545. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On 11 Nov 2010 at 11:43, Rich Alderson wrote: Having written my share of CCW chains in the past, I'd say "analogous" but not "equivalent"--unless you've seen a command-line parser or COBOL compiler written in CCWs... (Yes, a PPU COBOL compiler actually existed--done as a "project" by a couple of COBOL freaks.) --Chuck