I think the term disappeared with the microcomputer age. Intelligent peripherals like, say, the Commodore 1541 were always considered to have CPUs, not PPUs (especially since the CPU in that particular disk drive was almost exactly the same as the one in the host). To NES programmers, PPU means something else entirely ( http://en.wikipedia.org/wiki/Picture_Processing_Unit ). -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- My opinions may have changed, but not the fact that I'm still right. -------

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