Bob Lidral wrote: > I worked on a 1700 (used as an interface, sort of, to a 777 graphics > processor) and studied the 18-series "architecture" and its "Pascal" > compiler. The 1700 was a different design from the PP design.
It was probably a "Digigraphic" controller.
If you have *any* 1700 (or Cyber-18) system software in any medium, even hardcopy, I could really use a copy of it for a 1700 emulation I have been developing.
> I worked for CDC from 1978 - 1985 and had worked with CDC machines > before that since 1973. I had heard of the STAR-100 and subsequent > 200-series machines but never worked on a project that used (or needed) > that architecture.
Someone in 1978 told me that the STAR-100 has decimal floating point. I believed that for a long time, until I was told by a more reliable source that it didn't.
I believe, though, that it does have a square root instruction, which was pretty rare at the time.
>>I worked on a 1700 (used as an interface, sort of, to a 777 graphics >>processor) and studied the 18-series "architecture" and its "Pascal" >>compiler. The 1700 was a different design from the PP design.
> It was probably a "Digigraphic" controller.
> If you have *any* 1700 (or Cyber-18) system software in any medium, > even hardcopy, I could really use a copy of it for a 1700 emulation > I have been developing.
All of the code on which I worked was under contract to the Air Force for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA JUDY). Theoretically, it might be available somewhere, but not from me.
CDC owned the original source code. You may be able to find some from one of its successors or assigns (used to be Syntegra and now BT Global Services, apparently). You might also try the Air Force. Anything they own that's not classified might be available to citizens for the asking, but I wouldn't know how to go about getting it.
>> I worked for CDC from 1978 - 1985 and had worked with CDC machines >> before that since 1973. I had heard of the STAR-100 and subsequent >> 200-series machines but never worked on a project that used (or needed) >> that architecture.
>Someone in 1978 told me that the STAR-100 has decimal floating point. >I believed that for a long time, until I was told by a more reliable >source that it didn't.
I can't find an op code for anything like that - but it did have decimal add, subtract, multiply and divide.
>I believe, though, that it does have a square root instruction, >which was pretty rare at the time.
I just checked my copy of the "programmer's instant" for the STAR 100 and I see there were in fact 3 different op codes for square root operations:
Op codes 53 and 73 are both defined as: " Significant Square Root of (R) to (T) " and categorised as being instruction type "register" - I'm not sure what difference (if any) there was between these two.
Op code 93 is defined as: " Significant Square Root of A -> C " and categorised as being instruction type "vector"
> > I worked for CDC from 1978 - 1985 and had worked with CDC machines > > before that since 1973. I had heard of the STAR-100 and subsequent > > 200-series machines but never worked on a project that used (or needed) > > that architecture.
> Someone in 1978 told me that the STAR-100 has decimal floating point. > I believe, though, that it does have a square root instruction, > which was pretty rare at the time.
One of the Elliott machines had square root hardware instruction c. 1956 at the WRE.
Bob Lidral wrote: > Douglas A. Gwyn wrote: > > If you have *any* 1700 (or Cyber-18) system software in any medium, > > even hardcopy, I could really use a copy of it for a 1700 emulation > > I have been developing. > All of the code on which I worked was under contract to the Air Force > for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA > JUDY). Theoretically, it might be available somewhere, but not from me.
Yes, last time I searched the net for it, apart from entries in resumes, the Babbage Institute holdings, and my own mention in newsgroups the only link to 1700 software I found was some document at Hanscom AFB.
> CDC owned the original source code. You may be able to find some from > one of its successors or assigns (used to be Syntegra and now BT Global > Services, apparently). You might also try the Air Force. Anything they > own that's not classified might be available to citizens for the asking, > but I wouldn't know how to go about getting it.
I've tried, but so far haven't been able to get in touch with anybody who has a good idea about how to get hold of whatever sources might exist "somewhere". There should be at least a fiche listing somewhere. (I have one for SMM17, a diagnostic monitor, but not for any "user" oriented system software.)
I have constructed my own object-code-compatible cross-linker in C and was partway through creating a cross-assembler when I shelved the project. It could be dusted off and reactivated if I got hold of actual system software to act as an incentive.
>Bob Lidral wrote: >> Douglas A. Gwyn wrote: >> > If you have *any* 1700 (or Cyber-18) system software in any medium, >> > even hardcopy, I could really use a copy of it for a 1700 emulation >> > I have been developing. >> All of the code on which I worked was under contract to the Air Force >> for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA >> JUDY). Theoretically, it might be available somewhere, but not from me.
>Yes, last time I searched the net for it, apart from entries in >resumes, the Babbage Institute holdings, and my own mention in newsgroups >the only link to 1700 software I found was some document at Hanscom AFB.
Send a FOIA request to Hanscom and see what happens. The chances that anybody will have anything lying around still (and that it is not classified) is slim, but you never know, and it doesn't take a lot of effort to make the request. --scott
-- "C'est un Nagra. C'est suisse, et tres, tres precis."
"robin" <robi...@bigpond.com> writes: > "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote > > Bob Lidral wrote:
> > (snip)
> > > I worked for CDC from 1978 - 1985 and had worked with CDC machines > > > before that since 1973. I had heard of the STAR-100 and subsequent > > > 200-series machines but never worked on a project that used (or needed) > > > that architecture.
> > Someone in 1978 told me that the STAR-100 has decimal floating point.
> > I believe, though, that it does have a square root instruction, > > which was pretty rare at the time.
> One of the Elliott machines had square root hardware > instruction c. 1956 at the WRE.
It's trivial to add square root to division operations. The Univac 490 series machines for which I taught hardware maintenace had exactly one extra logic gate for square root.
-Fred Bradford... I worked at CDC from 1968-1979.. My comments interspersed below....
On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral
<l1dralspamb...@comcast.net> wrote: >This is sort of OT for this group, so I've changed the subject and >cross-posted to comp.sys.cdc (whose members may be more familiar with >the subject).
>Shmuel (Seymour J.) Metz wrote:
>> In <477DE53B.5000...@comcast.net>, on 01/03/2008 >> at 11:50 PM, Bob Lidral <l1dralspamb...@comcast.net> said:
>>>I worked with CDC machines until 1985. They were just coming out with >>>the 180-series to supersede the 170-series (descended from the 6600). I >>>don't remember a 160-series.
FB: the 160 and 160A were standalone computers. Later integrated into the 6600 series as "PPU's"
> > > > I thought the progression went: 6600 >>>series, 70 series, 170 series (with the 176 being based on the 7600 >>>rather than the 6600 architecture as were the lower-numbered models in >>>the series), and the 180 series -- all based on the 6600 design.
FB: the above is correct. The Cyber-70 was the 6000 series with "new skins" and two totally worthless "character type" instructions that were never implimented. Primarily, it was a "marketing" machine.
The first of the 6000 series was the 6600. It put CDC on the map.
Later, the 6400, simply the 6600 with no vector instruction stack. considered a "starter machine" to reduce the cost of the basic seriies.
The most cost effective machine was the 6500, a machine with two 6400 scalar CPU's.
Soon after with more compressed circuitry, a 6700 was tried, a 6500 but with a 6600cpu with a 6400cpu.
Then another machine, the 6200 came along. A slowed down 6400. (Simply the clock slowed down, nothing else. Cost the same to build but sold at more narrow profit margin. Not successfull.)
An internal joke was that it was "field upgradable to a 6400" for just a few thousand dollars. The upgrade was a toggle switch hidden inside to increase the clock speed to that of the 6400!!!
>> There were also Cyber 203 and Cyber 205, based on the STAR-100.
FB: The Star (later "STAR-100") came before the globalized "Cyber" name change. thus STAR->STAR-100->Cyber-203->Cyber-205-->ETA-xxx
> > You may >> have come on board after those were spun off to ETA.
>I worked for CDC from 1978 - 1985 and had worked with CDC machines >before that since 1973. I had heard of the STAR-100 and subsequent >200-series machines but never worked on a project that used (or needed) >that architecture.
FB: The internal conflicts between Seymour Cray (and his failed 8600) and the military's enforced hardward designes used in the STAR series brought about the mess discribed below.
Also forgotten in all the histories I've seen are the dirivatives of the STAR hardware that were, I believe, called the STAR-50 and lower numbers. These used some of the STAR logic but only in non-vector mode. Prototypes were built and running in Toronto (suburb) in 1971+/-
There was also a CDC-3700 prototype that I did timings on. It was a logicallly similar machine to the 3300 and 3500 machines, but with circiutry looking like the 6600 pancake boards. While faster than the 3700, not fast enought to be put into production.
>ETA was one of CDC's stupidest mistakes. One of the stupider things >they did was the way they announced the spinoff in the company >newsletter. Basically, it said the supercomputer group was at the >cutting edge of technology and needed the best and brightest of the >company (thereby categorizing those of us not being spunoff in some >other group). It also said CDC had too much bureaucracy and wasteful >internal procedures for anyone to make any significant contributions >toward progress so it was necessary to spin off the supercomputer group >into a new company not saddled with all that overhead (implying that >there was no hope for anyone not spun off to do anything useful or >significant and that the company had no plan or even intention to >improve internal procedures). As you might imagine, this was a major >morale-booster for the rest of us. I read a summary somewhere of CDC's >subsequent gross mismanagement of ETA (which they apparently never >really did spin off) but have no first-hand knowledge and, anyway, >that's a long story for another time and another newsgroup.
>>>There were also the 1700 series and the 18 "series".
>> Could the 18 series have been a new version of the 160, 160A or 160G?
FB: no.... The 1700 was a ripoff attempt to copy the IBM1600. It used 8-bytes and 6600 style pancake ciruits. The "18" was similar but used integrated cirucuits. Neither related to the 160 computer seriies.
The
>> 160 was very similar to the PP on a 6600.
FB: The 160 -> 160A were computers built into desks. Later redesigned into virticle rack type computer called the 8090. It had 6-bit characters.
A really messy dirivative of the 8090 was the 8092 that had 4-bit characters, but two together created an early 8-byte capability. I never saw one in operation.
>That depends on how much Seymour Cray was involved with all of those >designs. My understanding was that Cray had designed the 1700 series >and that the 18 series was based on that design. See, for example, >http://en.wikipedia.org/wiki/CDC_Cyber#Cyber-18 .
>I believe the 160 series was a straight 12-bit design. The PP was a >12-bit design but with an 18-bit accumulator (weird, but useful in the >self-modifying one-pass divide-by-5 algorithm).
>I worked on a 1700 (used as an interface, sort of, to a 777 graphics >processor) and studied the 18-series "architecture" and its "Pascal" >compiler. The 1700 was a different design from the PP design.
>> Note: I didn't mention, e.g., the 924, 1604, 3600 or 3800 because those >> were never marketed under the Cyber label.
>I seem to remember the 1604, 3600, 3800, and 3300(?) were pretty much on >their way out by the time I joined the company. I saw a few of them at >various customer installations, but never worked with them. I believe >the 6600-series and subsequent related architectures still used unit >record equipment originally designed for some of those earlier models, >though.
FB: the 1604/3600/3800 were basically similar... 48??-bit words of 6-bir characters. the 3300/3500/[3700] and cheapo machines 3200 and later the 3150 used 24bit words of 6 bits.
Peripheral equipment for ALL CDC machines with 6-bit characters, but of the so called BCD mode rather than the 6600 "Display Mode" and 60-bit words. This required massive translation boxes for each device attached to the 6000 machines that had to be included free in the cost of the system. Totally a third of the computer room was will with these "dumb" machines.
Fred Bradford wrote: > -Fred Bradford... I worked at CDC from 1968-1979.. My comments > interspersed below....
> On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral > <l1dralspamb...@comcast.net> wrote:
> ...
>>Shmuel (Seymour J.) Metz wrote:
>>>In <477DE53B.5000...@comcast.net>, on 01/03/2008 >>> at 11:50 PM, Bob Lidral <l1dralspamb...@comcast.net> said:
> ... >>>>> I thought the progression went: 6600
>>>>series, 70 series, 170 series (with the 176 being based on the 7600 >>>>rather than the 6600 architecture as were the lower-numbered models in >>>>the series), and the 180 series -- all based on the 6600 design.
> FB: the above is correct. The Cyber-70 was the 6000 series with "new > skins" and two totally worthless "character type" instructions that > were never implimented. Primarily, it was a "marketing" machine.
> The first of the 6000 series was the 6600. It put CDC on the map.
> Later, the 6400, simply the 6600 with no vector instruction stack. > considered a "starter machine" to reduce the cost of the basic > seriies.
I once worked with on projects with both 174s and 175s. The 175 was basically the 6600 architecture, while the 171, 172, 173, and 174 were based on the 6400 architecture. We had a program that ran fine on a 174 but kept getting an address exception on a 175.
It took awhile to figure out. It turns out the 175 had the aforementioned instruction stack and used to pre-fetch two memory words beyond the instruction stack; the other models didn't. The executable exactly filled the available memory for the process and failed on the 175 because at least one of the words it tried to pre-fetch was beyond the end of the available memory.
> The most cost effective machine was the 6500, a machine with two 6400 > scalar CPU's.
> Soon after with more compressed circuitry, a 6700 was tried, a 6500 > but with a 6600cpu with a 6400cpu.
I actually worked on a 6700 using remote access to a machine located in some Naval laboratory somewhere (NSRDC maybe?). I heard there were only a handful of them. Given that we were limited to remote batch or telephone modem access, I never observed a speed difference among the 6400, 6600, and 6700 available to us.
Unfortunately, for us, the NOS "interactive" interface was full-duplex without type-ahead (one of their less inspired design decisions). That meant it ignored any character typed until it had echoed the previous character. I can remember dozing off between keypresses while waiting for the previous character to be echoed. Sigh.
> Then another machine, the 6200 came along. A slowed down 6400. (Simply > the clock slowed down, nothing else. Cost the same to build but sold > at more narrow profit margin. Not successfull.)
> An internal joke was that it was "field upgradable to a 6400" for just > a few thousand dollars. The upgrade was a toggle switch hidden > inside to increase the clock speed to that of the 6400!!!
I heard there was a similar relation between the 173 and 174. The "upgrade" from a 173 to a 174 was rumored to consist of removing one jumper -- but at least it cost a lot. :-)
In <vfndo35ub9a8bajgiadjiq6cd91rd3n...@4ax.com>, on 01/10/2008 at 07:50 PM, Fred Bradford <avpo...@earthlink.net> said:
>FB: the 160 and 160A were standalone computers. Later integrated into >the 6600 series as "PPU's"
While the PP architecture certainly derived from the 160, the implimentation was quite different;; there was one real CPU running at 10 MHz in order to look like 10 virtual CPU's at 1 MHz each.
>Later, the 6400, simply the 6600 with no vector instruction stack.
?
The 6600 was a scalar machine. It did, however, have an instruction pipeline.
There were a couple of specialized machines consisting of a ring of PP's with no CP; I don't know how well they did.
>FB: the 1604/3600/3800 were basically similar... 48??-bit words of 6-bir >characters.
Yes; the 924 was 24 bit. The 3600 and 3800 had much larger instruction sets and an improved architecture.
> the 3300/3500/[3700] and cheapo machines 3200 and later the 3150 used >24bit words of 6 bits.
Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamt...@library.lspace.org
<l1dralspamb...@comcast.net> wrote: >I removed the comp.lang.pl1 newsgroup.
>Fred Bradford wrote: >> -Fred Bradford... I worked at CDC from 1968-1979.. My comments >> interspersed below....
>> On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral >> <l1dralspamb...@comcast.net> wrote:
>> ...
>>>Shmuel (Seymour J.) Metz wrote:
>>>>In <477DE53B.5000...@comcast.net>, on 01/03/2008 >>>> at 11:50 PM, Bob Lidral <l1dralspamb...@comcast.net> said:
>> ... >>>>>> I thought the progression went: 6600
>>>>>series, 70 series, 170 series (with the 176 being based on the 7600 >>>>>rather than the 6600 architecture as were the lower-numbered models in >>>>>the series), and the 180 series -- all based on the 6600 design.
>> FB: the above is correct. The Cyber-70 was the 6000 series with "new >> skins" and two totally worthless "character type" instructions that >> were never implimented. Primarily, it was a "marketing" machine.
>> The first of the 6000 series was the 6600. It put CDC on the map.
>> Later, the 6400, simply the 6600 with no vector instruction stack. >> considered a "starter machine" to reduce the cost of the basic >> seriies.
>I once worked with on projects with both 174s and 175s. The 175 was >basically the 6600 architecture, while the 171, 172, 173, and 174 were >based on the 6400 architecture. We had a program that ran fine on a 174 >but kept getting an address exception on a 175.
>It took awhile to figure out. It turns out the 175 had the >aforementioned instruction stack and used to pre-fetch two memory words >beyond the instruction stack; the other models didn't. The executable >exactly filled the available memory for the process and failed on the >175 because at least one of the words it tried to pre-fetch was beyond >the end of the available memory.
FB: sounds like a problem I noticed (I think in the CDC-8600 preliminary manual, or at least a similar CDC or Cray machine with a stack.) The resolution was to pad the loop with no-ops either to keep the code entirely in the stack or to prevent timeconsuming search outside the loop.)
>> The most cost effective machine was the 6500, a machine with two 6400 >> scalar CPU's.
>> Soon after with more compressed circuitry, a 6700 was tried, a 6500 >> but with a 6600cpu with a 6400cpu.
>I actually worked on a 6700 using remote access to a machine located in >some Naval laboratory somewhere (NSRDC maybe?). I heard there were only >a handful of them. Given that we were limited to remote batch or >telephone modem access, I never observed a speed difference among the >6400, 6600, and 6700 available to us.
>Unfortunately, for us, the NOS "interactive" interface was full-duplex >without type-ahead (one of their less inspired design decisions). That >meant it ignored any character typed until it had echoed the previous >character. I can remember dozing off between keypresses while waiting >for the previous character to be echoed. Sigh.
>> Then another machine, the 6200 came along. A slowed down 6400. (Simply >> the clock slowed down, nothing else. Cost the same to build but sold >> at more narrow profit margin. Not successfull.)
>> An internal joke was that it was "field upgradable to a 6400" for just >> a few thousand dollars. The upgrade was a toggle switch hidden >> inside to increase the clock speed to that of the 6400!!!
>I heard there was a similar relation between the 173 and 174. The >"upgrade" from a 173 to a 174 was rumored to consist of removing one >jumper -- but at least it cost a lot. :-)
On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote: >In <vfndo35ub9a8bajgiadjiq6cd91rd3n...@4ax.com>, on 01/10/2008 > at 07:50 PM, Fred Bradford <avpo...@earthlink.net> said:
>>FB: the 160 and 160A were standalone computers. Later integrated into >>the 6600 series as "PPU's"
>While the PP architecture certainly derived from the 160, the >implimentation was quite different;; there was one real CPU running at 10 >MHz in order to look like 10 virtual CPU's at 1 MHz each.
>>Later, the 6400, simply the 6600 with no vector instruction stack.
FB: ... I should not have used the word "vector" above. -f
>The 6600 was a scalar machine. It did, however, have an instruction >pipeline.
>There were a couple of specialized machines consisting of a ring of PP's >with no CP; I don't know how well they did.
FB: I believe it also had full central memory. It's purpose was to be a sort of "server" on a network. I don't think it ever was put into production.
>>FB: the 1604/3600/3800 were basically similar... 48??-bit words of 6-bir >>characters.
>Yes; the 924 was 24 bit. The 3600 and 3800 had much larger instruction >sets and an improved architecture.
FB: I never know where the "924" fit in or what it was used for.
CDC made some really terrible remote terminial/cardreader/printer devices. One called the "200 User Terminal" a.k.a. "200 Loser Terminal!
A 934 terminial somewhat better.
But the beast of all beasts was a printer with alternate character drums missing. The entire "shuttle" would bump back and forth to print odd then even columns. Know as the "shuttle printer." I only saw one. Made an awful noise.
Silver Bells wrote: > On Thu, 10 Jan 2008 21:21:17 -0800, Bob Lidral > <l1dralspamb...@comcast.net> wrote:
> ... >>I once worked with on projects with both 174s and 175s. The 175 was >>basically the 6600 architecture, while the 171, 172, 173, and 174 were >>based on the 6400 architecture. We had a program that ran fine on a 174 >>but kept getting an address exception on a 175.
>>It took awhile to figure out. It turns out the 175 had the >>aforementioned instruction stack and used to pre-fetch two memory words >>beyond the instruction stack; the other models didn't. The executable >>exactly filled the available memory for the process and failed on the >>175 because at least one of the words it tried to pre-fetch was beyond >>the end of the available memory.
> FB: sounds like a problem I noticed (I think in the CDC-8600 > preliminary manual, or at least a similar CDC or Cray machine with a > stack.) The resolution was to pad the loop with no-ops either to keep > the code entirely in the stack or to prevent timeconsuming search > outside the loop.)
We didn't have the option of padding the loop -- directly, at least. I don't remember how we resolved it. Except that, clearly, the last (highest-address) instruction had to have been a backward branch. In assembly language we could just have added a couple of no-ops to the source. In a high-level language we'd have had to be careful that any dummy code we added wouldn't have been optimized away.
As I remember, the way the 6600 architecture worked was that it only kept the most recently-executed 7 contiguous words plus the next two (pre-fetch). Since the words were 60 bits and instructions were 15, 30, or 60 bits, the stack could potentially hold up to 28 15-bit instructions. In practice it was usually a few fewer than that, but the FTN optimizer was good at getting close to that for inner loops.
Backward branches to addresses still in the instruction stack executed from the stack so loops entirely contained in the stack were very fast. ...
Silver Bells wrote: > On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz > <spamt...@library.lspace.org.invalid> wrote:
>>In <vfndo35ub9a8bajgiadjiq6cd91rd3n...@4ax.com>, on 01/10/2008 >> at 07:50 PM, Fred Bradford <avpo...@earthlink.net> said:
>>>FB: the 160 and 160A were standalone computers. Later integrated into >>>the 6600 series as "PPU's"
>>While the PP architecture certainly derived from the 160, the >>implimentation was quite different;; there was one real CPU running at 10 >>MHz in order to look like 10 virtual CPU's at 1 MHz each.
>>>Later, the 6400, simply the 6600 with no vector instruction stack.
> FB: ... I should not have used the word "vector" above. -f
Well, there was some concurrency in the 6600 architecture. The 6600 CPU had several instruction units that could operate simultaneously; the 6400 architecture did not.
Some arithmetic and logical operations could be performed by different instruction units. As I recall, it had a floating-point unit, an integer unit, a logical unit, and, I believe, some others. For example, arithmetic negation could be accomplished by the integer arithmetic unit or by bitwise logical complement by the logical unit since it was a 1s complement machine. For these types of operations, a smart optimizer (and CDC's FTN optimizer was pretty good) could use whichever instruction unit was not being used for something else at the time. In an ideal situation, all instruction units could operate simultaneously on different instructions.
The FTN optimizer used to build a dependency graph of operations and operands and then generated instructions that could be executed simultaneously. Since each operation could take different lengths of time, it was necessary to make sure no operation was started until its operands were available -- that is, that any instructions used to compute the input operands of an instruction had finished before starting the instruction.
I believe the FTN optimizer first located a critical path through the intermediate language, assigned operations on that path to the fastest-possible CPU unit, and then assigned any operations not on the critical path to other available CPU units, if possible. It made an impressive improvement in the speed of carefully-written FORTRAN programs.
Not really a vector architecture, but it did provide some localized concurrency.
> ... > FB: I never know where the "924" fit in or what it was used for.
> CDC made some really terrible remote terminial/cardreader/printer > devices. One called the "200 User Terminal" a.k.a. "200 Loser > Terminal!
> A 934 terminial somewhat better.
> But the beast of all beasts was a printer with alternate character > drums missing. The entire "shuttle" would bump back and forth to print > odd then even columns. Know as the "shuttle printer." I only saw one. > Made an awful noise.
My favorite futile CDC product was called, I think, the Mass Storage System (MSS). Whatever it was called, it was a huge magnetic tape jukebox -- sort of. The following description is based on a nearly 30-year old memory of only a couple of minutes observation, so it may be more than a little off.
It was huge -- probably about 8 or 10 feet tall by 8 feet or more wide. It was implemented as a large honeycomb (well, rows and columns rather than a hexagonal matrix) of wide tape reels that were roughly the same size and shape as wax cylinders (another state-of-the-art medium :-)).
These tape reels were kept in what was probably a hermetically-sealed cabinet with a glass front so you could watch it work (the best part :-)). It had a picker of some sort. I seem to remember horizontal and vertical rods that moved back-and-forth and up-and-down to position the picker at one of the cylinders (though my memory is a little vague). It would then extract tapes from the frame and move them to the read/write unit or remove them from the read/write unit and return them to the frame. I think it even had a queue of pre-fetched tapes that it would fill while the read/write unit was busy with another tape.
It was huge, sucked a lot of power, and was extremely expensive. It could be used to store a huge amount of data for its time. But it wasn't worth it if you had significantly lower data storage requirements and, although reputedly much faster than the 7- and 9-track tapes CDC was fond of using, it was still limited in speed compared to disks.
It was extremely impressive to watch, if you had an application that needed to read or write data on several different tape reels so the picker arm would have to pull and replace tapes from the frame a lot. But I don't know whether CDC ever sold any; the one I saw was a demo prototype -- at Arden Hills, I believe.
>> On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz >> <spamt...@library.lspace.org.invalid> wrote:
>>>In <vfndo35ub9a8bajgiadjiq6cd91rd3n...@4ax.com>, on 01/10/2008 >>> at 07:50 PM, Fred Bradford <avpo...@earthlink.net> said:
>>>>FB: the 160 and 160A were standalone computers. Later integrated into >>>>the 6600 series as "PPU's"
>>>While the PP architecture certainly derived from the 160, the >>>implimentation was quite different;; there was one real CPU running at 10 >>>MHz in order to look like 10 virtual CPU's at 1 MHz each.
>>>>Later, the 6400, simply the 6600 with no vector instruction stack.
>> FB: ... I should not have used the word "vector" above. -f
>Well, there was some concurrency in the 6600 architecture. The 6600 CPU >had several instruction units that could operate simultaneously; the >6400 architecture did not.
>Some arithmetic and logical operations could be performed by different >instruction units. As I recall, it had a floating-point unit, an >integer unit, a logical unit, and, I believe, some others. For example, >arithmetic negation could be accomplished by the integer arithmetic unit >or by bitwise logical complement by the logical unit since it was a 1s >complement machine. For these types of operations, a smart optimizer >(and CDC's FTN optimizer was pretty good) could use whichever >instruction unit was not being used for something else at the time. In >an ideal situation, all instruction units could operate simultaneously >on different instructions.
>The FTN optimizer used to build a dependency graph of operations and >operands and then generated instructions that could be executed >simultaneously. Since each operation could take different lengths of >time, it was necessary to make sure no operation was started until its >operands were available -- that is, that any instructions used to >compute the input operands of an instruction had finished before >starting the instruction.
>I believe the FTN optimizer first located a critical path through the >intermediate language, assigned operations on that path to the >fastest-possible CPU unit, and then assigned any operations not on the >critical path to other available CPU units, if possible. It made an >impressive improvement in the speed of carefully-written FORTRAN programs.
>Not really a vector architecture, but it did provide some localized >concurrency.
>> ... >> FB: I never know where the "924" fit in or what it was used for.
>> CDC made some really terrible remote terminial/cardreader/printer >> devices. One called the "200 User Terminal" a.k.a. "200 Loser >> Terminal!
>> A 934 terminial somewhat better.
>> But the beast of all beasts was a printer with alternate character >> drums missing. The entire "shuttle" would bump back and forth to print >> odd then even columns. Know as the "shuttle printer." I only saw one. >> Made an awful noise.
>My favorite futile CDC product was called, I think, the Mass Storage >System (MSS). Whatever it was called, it was a huge magnetic tape >jukebox -- sort of. The following description is based on a nearly >30-year old memory of only a couple of minutes observation, so it may be >more than a little off.
>It was huge -- probably about 8 or 10 feet tall by 8 feet or more wide. > It was implemented as a large honeycomb (well, rows and columns rather >than a hexagonal matrix) of wide tape reels that were roughly the same >size and shape as wax cylinders (another state-of-the-art medium :-)).
>These tape reels were kept in what was probably a hermetically-sealed >cabinet with a glass front so you could watch it work (the best part >:-)). It had a picker of some sort. I seem to remember horizontal and >vertical rods that moved back-and-forth and up-and-down to position the >picker at one of the cylinders (though my memory is a little vague). It >would then extract tapes from the frame and move them to the read/write >unit or remove them from the read/write unit and return them to the >frame. I think it even had a queue of pre-fetched tapes that it would >fill while the read/write unit was busy with another tape.
>It was huge, sucked a lot of power, and was extremely expensive. It >could be used to store a huge amount of data for its time. But it >wasn't worth it if you had significantly lower data storage requirements >and, although reputedly much faster than the 7- and 9-track tapes CDC >was fond of using, it was still limited in speed compared to disks.
>It was extremely impressive to watch, if you had an application that >needed to read or write data on several different tape reels so the >picker arm would have to pull and replace tapes from the frame a lot. >But I don't know whether CDC ever sold any; the one I saw was a demo >prototype -- at Arden Hills, I believe.
FB: I too worked at Arden Hills from mid 1968 thru 1971 in the "6000 Demonstration Lab"
The CDC MSS was a ripoff of a simliar product by IBM. IBM made reliable tape devices, All CDC's sucked.
Computer rooms by their nature are supposed to be spot less.
But...
I complained once that the janitors used those 30inch cicurlar buffers with steel-wool pads to buff down the floors. I remembers bits of broken steel wool flowing around the room where ever we walked.
Management was totally blind to this stupidity until I told them. Then it stopped immediately.
I also remember the use of cirgarette ash (dabbed from ashtrays brought into the computer lab, to polish the tape heads. No commercially made product would remove the corrosion from the tape heads.
Take some cloth, add some liguid "freon", dab some ashes, and scrub as hard as possible to remove the deposits.
Silver Bells wrote: > ... > FB: I too worked at Arden Hills from mid 1968 thru 1971 in the "6000 > Demonstration Lab"
I never actually worked there. I took a tour as part of my New Hire class, I took a few classes up there, and I tried to run a benchmark there once. It was a holiday weekend I think (July 4th, maybe) and the regular Benchmark Lab had shut down or maybe the Benchmark Lab was already booked 24/7. So, at somebody's suggestion, I wandered up to Arden Hills and wandered the halls until I found a machine room. The only machine that looked plausible had the rear panels open and a bunch of spaghetti hanging out the back. So I found another machine and couldn't figure out how to start it. I found someone else wandering the halls (it was probably about 11 PM) and he explained to me the second machine was a 176 so it wouldn't have been useful anyway (I was still new and not familiar with the physical appearance of the product line and, of course, it didn't have a model number on it). We finally got the first machine deadstarted and I was able to do some benchmarking, but it was a surreal experience.
> The CDC MSS was a ripoff of a simliar product by IBM. IBM made > reliable tape devices, All CDC's sucked.
CDC seemed to be able to sell 9-track tape drives, though. My big problem with CDC's tape drives was the software. The software for them really sucked. When I escaped from grad school (uh, that should read, "left to enter the workforce") in 1978, I copied all of my projects (completed, half-finished, and barely-begun) to 800 BPI 9-track tapes. It seemed the most portable format at the time. For the IBM files, it was simple: ANSI-standard multi-file labeled tapes in EBCDIC encoding (they were, after all, intended to be used on an IBM architecture and CDC's FORM claimed to be able to read all sorts of IBM tape formats -- and did a fair job). For the CDC machine, I tried to write ANSI-standard multi-file labeled tapes using ASCII encoding.
The CDC tapes were a nightmare. I would try to write something like 17 files and then try to verify the tape. The verification step would only show something like 12 files the first time and then maybe only 8 the second time I tried it. I tried to write the tapes several times and finally gave up on the verification, deciding to hope fervently that the tapes had the intended data on them and that I would be able to read them somehow at some future time.
By the time I finally could afford enough personally owned or rented disk space, I had trouble finding a tape drive that could handle 800 BPI tapes (should have used 1600 BPI -- sigh). When I finally did get them converted to CD years later by a commercial data recovery establishment, I learned that the CDC machine had correctly labeled the files on the tape but, despite my explicit specifications (at least according to the documentation), they had been written in CDC display code which wasn't readable by the people who did the copy to CD. So I finally had them copy the raw bits to CD and I had to write a conversion program to read 3 8-bit bytes at a time, assemble them into a 24-bit chunk, break it up into 4 6-bit fields, and then convert those into 4 8-bit ASCII characters (this last was the easy part). An amusing exercise, I suppose (well, to me -- I suspect I've bored everyone else in this group -- sorry 'bout that).
> Computer rooms by their nature are supposed to be spot less.
> But...
> I complained once that the janitors used those 30inch cicurlar buffers > with steel-wool pads to buff down the floors. I remembers bits of > broken steel wool flowing around the room where ever we walked.
> Management was totally blind to this stupidity until I told them. Then > it stopped immediately.
> I also remember the use of cirgarette ash (dabbed from ashtrays > brought into the computer lab, to polish the tape heads. No > commercially made product would remove the corrosion from the tape > heads.
> Take some cloth, add some liguid "freon", dab some ashes, and scrub as > hard as possible to remove the deposits.
> Nothing else worked.
My favorite janitor story has to do with a Tandem machine. One of my employers supplied software to a medical testing company that required 24/7 reliability -- hence their decision to use Tandem fault-tolerant platforms (MIPS architecture running NonStop-UX). We were involved in a joint venture with another software firm for this customer. Naturally, whenever something went wrong we and the other joint-venture firm would point fingers at each other (they were usually at fault, but we usually had to prove it to them -- another long story and really OT).
Anyhow, the customer complained that the software stopped and restarted (losing data and context) every night. Neither we nor our joint venture partner could figure out the cause and the customer could never provide any useful information because it always happened late at night when nobody was there. Finally one night, one of the customer's programmers was pulling an all-nighter in the machine room and discovered the cause.
Very late at night, he heard a vacuum cleaner in the hallway; it ran for awhile and then stopped. Shortly thereafter, the door to the machine room cracked open; a hand reached in and unplugged the Tandem in order to plug in another cord. The vacuum cleaner started up again for a few minutes and then shut off. The door to the machine room cracked open again and a hand reached in to unplug the vacuum cleaner and plug the Tandem back in. Then the Tandem started up (it was configured to reboot after a power outage) again.
Fred Bradford wrote: > Then another machine, the 6200 came along. A slowed down 6400. (Simply > the clock slowed down, nothing else. Cost the same to build but sold > at more narrow profit margin. Not successfull.)
> An internal joke was that it was "field upgradable to a 6400" for just > a few thousand dollars. The upgrade was a toggle switch hidden > inside to increase the clock speed to that of the 6400!!!
My recollection is that for these kinds of machines, particularly for machines like the 6600, slowing down the clock might result in much cheaper maintenance.
I think that one of the 170 series machines had a similar clock speed and upgrade path.
LR wrote: > Fred Bradford wrote: ... > My recollection is that for these kinds of machines, particularly for > machines like the 6600, slowing down the clock might result in much > cheaper maintenance.
> I think that one of the 170 series machines had a similar clock speed > and upgrade path.
> Perhaps that was part of the point for the 6200?
> LR
This is from my memory of 1982 - 1983 and at least some of it is hearsay, so it may be a little off. I believe that was the 173 -> 174 upgrade.
There was an error in the marketing literature for the 170 series that mis-stated the MIPS rate for the 173, claiming it was faster than it actually was. For some reason, it apparently never got updated. Of course salespeople and management believed the printed values and couldn't be persuaded otherwise.
I met a former CDC employee once who had been a Shark analyst. He got PO-ed at CDC because part of his reward for being a Shark was a free trip to some resort area but he had to share a double room with someone else. He felt that if he'd contributed that much to the CDC bottom line, the least they could do was give him his own room -- so he quit.
Anyhow, before he left, he had discovered the problem during a benchmark and tried to get CDC to reprint the material with the corrected 173 MIPS rate. Either they didn't do it or the salesmen and managers never saw the reprints.
One customer had ordered a pair of 173s in a competitive bid because the published MIPS rate met their requirements more cost effectively than any other company's offerings. They were shipped and installed at the customer site for an evaluation period. During the evaluation, the customer discovered that one of the 173s was fast enough for their application but the other was too slow. Unfortunately, the 174, while fast enough, was not as cost-effective as some of CDC's competitor's solutions so the customer wanted to send the "slow 173" back for replacement with a "fast 173" (which, of course, didn't exist).
The difference between the 173 and 174 was reputed to be a single jumper on the 173 to slow it down. Somebody forgot to connect that jumper on one of the machines so it was actually a 174. The salesman, known far and wide for aggressive and "creative" solutions (and a no-prisoners attitude towards co-workers) was rumored to have demanded that the CE remove the jumper from the 173 to turn it into a 174 without telling anyone. The CE refused unless his own manager would approve it; his manager required approval from above and eventually the problem made its way all the way to HQ.
I heard (I wasn't directly connected with that project) that CDC sent 3 or 4 VPs to the customer to discuss the issue. My feeling was that CDC should have admitted they sent a 174 by mistake and just offer to provide the customer with two 174s for the price of two 173s for that one site. It was then explained to me that it wasn't just the lease price on the hardware that differed. Apparently CDC charged different lease rates for software depending on the platform. Thus, for example, the same FTN compiler cost more to lease for a 174 than for a 173.
I don't know how it was resolved. I was transferred to another state before then and somehow the resolution wasn't as interesting as the problem so I never followed up.
Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamt...@library.lspace.org
|
