Talk:Scientific Data Systems

Early comments

Greg

I would love to know who your father is. I worked on the entire Sigma family while employed as a field engineer, diagnostician and product engineer at Xerox from 1969 until 1978. During that time, I was fortunate to have mastered their design, became a specialist in their CPU, Memory and I/O components, and worked many challenging assignments, especially with the Sigma 9, which was my favorite. I even hold the distinction of having actually manufactured two of them. Long story, more on this below.

The Sigma family included ths Sigma 2 and Sigma 3 (16bit) and the Sigma 5,6,7,8 and 9 (32bit). Before Xerox left the main frame computer market, they also introduced a follow on family to Sigma, the 530 (16-bit) and 550/560/570 (32-bit) systems. Sigma systems were first introduced in the 1960's and were extremely advanced at the time. Designed specifically for real-time computing tasks, their execution was faster and more efficient than any competitors systems. Using multiple banks of registers and real-time interrupt levels, context switching for priority task execution could be performed with nanosecond precision. The Sigma 2/3 systems were typically applied to dedicated real-time tasks such as control and data acquisition. The Sigma 5 and 7 systems were general purpose 32Bit computing systems capable of simultaneous real-time control. Sigma 6 was a specialized version of the Sigma 7 for data processing. The grand systems of all were the Sigma 8 and Sigma 9, which supported parallel instruction pipelines with look-ahead analysis and pre-fetch, expanded system memory architecture, and exceptional maintainability. These were exceptional machines and were applied to high volume real-time data acquisition and control as well as multi-user time-sharing applications. The Sigma 8/9 ran the CP-V operating system, the only general purpose system executive ever written that fully supported high speed general computing and I/O tasks simultaneously with precision real-time computing.

Sigma systems were widely used in research and development, education, process control and government applications, and I was exposed to a good many of them as a Technical Support engineer for the Western Region, based at the home plant in El Segundo California. Because of our direct association with the factory and design engineering staff, our office was often called to help resolve difficult system anomolies all over the world.

I was fortunate to be exposed to some of the most challenging applications of the Sigma 9 series, and became known as somewhat of a specialist on them. As a result, I was assigned to support one of the most unique applications of this series at Nellis Air Force Base in 1975-1977. Sigma 9 systems were used to provide data acquisition and correlation for real-time air space management of the Nellis range complex. In addition, two specialized systems, each consisting of 3 Sigma 9 CPU's tightly coupled as a single system, were applied in the monitoring and control of multiple aircraft engaged in air combat tactics test and evaluation. Commonly known as the Air Combat and Maneuvering Instrumentation (ACMI) system, these systems were capable of tracking and displaying 3-dimension views of up to 16 aircraft within a large block of air space in real-time, and also provided simulation of weapons systems to provide a true realistic combat environment. A unique design of the system was dedication of one of the CPU's to filter the real-time data and generate filtered projection of future events based on current and historical data for each aircraft. This allowed the system to provide accurate prediction of saftey issues, as well as seamless display even when data from one or more aircraft was disrupted due to dynamic maneuvering. If you have seen the movie "Top Gun", there are scenes that show real-time air combat graphic displays produced by a similar system employed at Miramar Naval Air Station. That system, and several others like it deployed world wide, used 3 Sigma 5 CPU's.

After Xerox left the main frame computing business, support for all Sigma systems transitioned to Honeywell, where I continued to work as a systems engineer until 1978, when I joined Comshare Corporation, the largest single user of Sigma 9 computers. A combination of continued business growth, and the unavailability of more Sigma 9's in the near term threatened Comshare's growth, so while negotiating a contract with Honeywell to build more new Sigma 9's, we initiated an effort to do the same using available spares and scrap obtained from Xerox. Based in a rent-a-garage facility in Phoenix, I led a team that hand built from scratch two Sigma 9's, integrated them with a custom I/O processor that allowed use of IBM compatible Tape and Disk peripherals, as well as 3rd party Memory provided by Ampex. The result was two fully functional systems delivered to Comshare in 1979 and 1980. Since we could not legally name these two system "Sigma 9", they were delivered with the monikers "Kermit" and "Miss Piggy". They served Comshare customers for many years afterward.

Suffice to say, I had fun, and even though it was a long time ago, I can still tell what pins to hang scope probes on to get a synchronized view of an I/O transaction.

Today, I have a system in a small box next to my desk that is capable of processing instructions faster than a Sigma 9, and has a whole lot more memory and disk, but it will never have the class.

Regards Dave Phillips

Dlphillips1 (talk) 06:54, 14 April 2008 (UTC)

Dave, that's really amazing. I worked with Sigma in the early 1980's as a summer student at NASA Goddard. I learned a lot from that machine, it was magical in so many ways. I have had contact with other Sigma experts over the years. I even have a complete Sigma 9 processor control panel in my basement. Some years ago, I started work on a Sigma emulator written in Java. It worked fairly well, ran most of the smaller tests successfully, but I never got far enough to boot CP-V. I'd like to learn more about Sigma and CP-V. Please email me here: madhu at madhu dot com. Madhu (talk) 00:03, 12 August 2008 (UTC)

Bold textMy father was a field engineer and eventually field service manager for Scientific Data Systems (SDS) and the later Xerox company and then Honeywell. I believe this article to be fairly accurate.

Greg

I was involved with the second startup in 1979 and have added to some of the history on that company.

William L. Scheding, wls@wls.org

There was a Sigma series computer at Pacific Missile Test Center, Point Mugu, California. It was in the integration lab of the F-14 Tomcat fighter, I believe to control the simulation environment. This would have been from around 1969 to whenever the last software changes were made. —Preceding unsigned comment added by 205.175.225.22 (talk) 21:01, 5 October 2007 (UTC)

I worked with the 32-bit Sigma machines between 1972 and 1985 in the UK and Sweden. They were almost exclusively used for real-time processing, although a timesharing service bureau (Atkins) also used them. Their software was very advanced for the time. Chrisj1948 18:08, 26 October 2007 (UTC)

Excuse me butting into the flow, but I, too, worked as a programmer on Sigma 7 and Sigma 9 systems, first with Cybernetics Research Consultants (CRC) from 1974 based at their offices in Clerkenwell Road in London with the hardware in a warehouse in Slough, then from 1976 to 1980 at the offices of Atkins Computer Services in Epsom. CRC bought the machines purely for a time-sharing service. WS Atkins originally bought the Sigma 9s for finite-element analysis in the design of early North Sea oil platforms and only later formed ACS to exploit the excess of resources through a time-sharing service. Wonderful machines! I managed to invent a report-writing language for business users that included a compiler written in COBOL (really). But they were large (hundreds of square feet), hot and loud: I recall accidentally shutting down the entire Atkins computer room while rerunning a payroll overnight after struggling to dismount a tape reel and backing into the emergency power cut-off - the deathly silence brought the other operators running. Hey, ho, those were the days! P.r.newman (talk) 13:15, 4 January 2012 (UTC)

On the subject of known users; there are indications that a certain UK government establishment used a Sigma in the 1970's although, because of the nature of their work, this was never openly declared :-) Chrisj1948 (talk) 10:20, 30 November 2007 (UTC)

Possible related trivia: The predecessor to the Sigma-7 was the SDS 940. After Xerox sold the business to Honeywell, Honeywell reportedly got a request for spare parts or other assistance from a site in the U.S.S.R. concerning an SDS 940. I have been told (but my source cannot verify, for reasons similar to what Chrisj1948 cites above) that Honeywell had records indicating where all but one of the SDS 940 systems were. None had been shipped to the U.S.S.R. The unaccounted-for system had been on the U.S.S. Pueblo. Ksbooth (talk) 08:15, 23 March 2009 (UTC)

First transistors?

The article lead claims SDS was the first to use silicon transistors. I don't believe this is even remotely true. For one thing, the CDC 1604 was introduced in 1960 and was already in use by the time SDS formed. Maury Markowitz (talk) 12:50, 23 January 2009 (UTC)

I haven't been able to find an attribution from SDS directly, but the claim seems to have originated as a Marketing one and is specific to being the first to use ONLY Silicon Transistors (implying not geranium ) in its design. Instantsquirrel (talk) 19:23, 5 October 2009 (UTC)

BRL report from 1964 put up on web site of Ed Thelen - http://ed-thelen.org/comp-hist/BRL64-s.html References the SDS 910 and 920 " System uses silicon solid-state components to widen operating temperature range and thereby increase reliability by an order of magnitude." Instantsquirrel (talk) 19:45, 5 October 2009 (UTC)

" These are arguably the first commercial systems based on silicon, which offered much better performance for no real additional cost." - this sentence needs to say what it's comparing to, maybe germanium is it. Peter Flass (talk) 16:56, 15 February 2020 (UTC)

I do remember working on an SDS-930 around 1989 and it had documentation claiming it was the first transistorised computer (even though its memory was magnetic core, complete with a temperature gauge which normally hovered at around 55oC) Robin48gx (talk) 12:11, 21 April 2023 (UTC)

Humorous Asides

I started a long IT career working for SDS in El Segundo as a lowly mail clerk around the time the Sigma 7 was coming out, pushing a cardboard box with mail around on a hand truck. (That is, I was pushing the hand truck, not the Sigma 7). Remember the oil leaks on the original hydraulic CDC disk drives, causing the large stress-test units to wander across the floor at night?

My real reason for breaking in on this conversation was to relate a jape that went around the traps about the time Xerox was selling off the field engineering business. The idea was that Fairchild Camera and Instrument and Honeywell Information Systems (two suitors for the business) would form a consortium, called "Farewell Honeychild". 203.45.22.246 (talk) —Preceding undated comment added 04:32, 19 November 2010 (UTC).

Lack of carry foward from the SDS 940 experience

The Sigma-7 had a number of really neat features, but a few just short of what they needed to be. For example, the mapping registers (256 one-byte registers that mapped the high eight-bits of a virtual address to the high eight-bits of the physical address) could be written but not read. When a page fault took place, there was no indication in the hardware of the cause of the page fault, other than that some address involved in the instruction being executed was not accessible. This required a software work-around to decode first the address of the instruction (to see if the page fault had occurred fetching the instruction) and then (if that was not the cause of the fault) decode the instruction to determine what location(s) in memory the instruction would have tried to access. The program status doubleword (PSD) that was saved when a page fault trap occurred made it easy to determine the virtual address of the instruction being fetched. The inability to read back the mapping registers or the access control (permission) registers meant that copies of both sets of registers had to be maintained in software.

If the instruction fetch was not the problem, the eight-bit op-code had to be fetched from physical memory by simulating the hardware mapping, the determining how many operands the instruction had and the determine whether those operands were the cause of the page fault. Byte string instructions had two addresses (source and destination) and a variable number of byte. The load/store multiple and push/pop multiple instructions could access up to 16 words. In either case these operands might cross page boundaries during execution, so the page fault might occur after partial completion of the instruction. All of this lead to quite a long sequence of instructions that had to be executed to determine the cause of a page fault.

The team that had worked on the SDS 940 at U.C. Berkeley had suggested to SDS the principle that every register that could be written should be readable, which would have sped up the process. Better would have been a register that provided the virtual address causing a page fault (which later computers had).

Because the Sigma-7 allowed an unlimited number of indirections before computing the effective address of some operands, it was possible to have a page fault caused (for example) by a byte string instruction over-write itself with an instruction that used indirect addressing that could cycle through all of memory, making it problematic to process a page fault without running the risk of locking out interrupts for a very long time.

Apparently, the first version of the Motorola 68000 memory mapping scheme could have a similar problem if a page fault occurred during an instruction that was modifying multiple words in memory.

IBM had avoided this problem in their virtual memory for the IBM 360 by aborting character string instructions when a page fault occurred, forcing a re-execution of the entire instruction. The Sigma-7 had the nice feature that these instruction were interruptible, but this interacted poorly with the paging hardware in the special case where the instruction wrote over itself just before causing a page fault (as described above). Ksbooth (talk) 08:15, 23 March 2009 (UTC)

"I" is inappropriate

Several places "I" is used. It isn't even clear who "I" is. —Preceding unsigned comment added by DHR (talk • contribs) 01:50, 27 March 2010 (UTC)

Some Factual Errors

I've made a couple of corrections to this page, and thus would like to explain where I got the information from in more detail.

One can look at the referenced manuals for the 9300 versus the 910/920/930/940 from bitsavers, and the opcodes for the 9300 are different. Also, the 9300 did not have Programmed Operators (POPs) like the others did; presumably, with hardware floating-point, it wasn't felt to need them (and the bit was used to address more memory).

Also, it was stated that the Sigma went to 8 bits because of ASCII. But the Sigma used EBCDIC!

Looking at the manual for a 32-bit Sigma computer, it's obvious how the computer was positioned. It had multiple registers, like a 360; the floating-point format was almost identical (negative numbers were complemented, though, unlike in the 360); it had character and packed decimal instructions. But its instructions were all 32 bits long, not variable length.

It was basically a simpler design, similar to older computers in which every instruction was a 36-bit word (like the IBM 7090) or a 24-bit word (like the SDS 9300) that was intended to be "just as good", or at least have similar specs, to a 360. Compare the RCA Spectra 70, in which the ordinary instructions were the same as a 360, but the I/O and other privileged instructions were different, the early Interdata machines, or the Univac 9500 which implemented only a compatible subset of the 360 instruction set, as other approaches to competing with the 360 on a continuum of increasing compatibility. — Preceding unsigned comment added by Quadibloc (talk • contribs) 18:21, 20 April 2011 (UTC)

Lists of users

Most of these seem to be Sigma users, shouldn't they be in SDS Sigma series rather than here? By the way, probably more names could be extracted from the EXCHANGE documents.Peter Flass (talk) 20:16, 31 August 2013 (UTC)

Swiss air had a DC9 flight simulator running on an SDS-930. This was bought by Eastern Airlines (Miami Int) Sometime around 1988 and upgraded by putting the flight model on an ENCORE 32/67 but transferring data on a custom parallel link to the SDS to keep its I/O connectivity. i.e. the I/O data was transferred to the ENCORE running a FORTRAN flight model and the output data from the flight model was transferred back within a 50mS time frame. Robin48gx (talk) 12:05, 21 April 2023 (UTC)

More photos would be nice!

My first paying programming job was to assist the retirement of an old SDS, by porting the software that ran on it. As I recall, it had 4 tape drives, 16K core (reportedly heated to 400-odd degrees, close to the Curie temp for faster switching; this in an air-conditioned raised-floor computer room), an IBM Selectric as the system console, and a control panel, maybe 2 feet wide, 3 feet tall, bolted to a Formica desk. It was black (not white as in another photo) and had a row of 25-odd red/brown throw switches along the bottom for IPL. You'd have to manually enter about 4-6 words with the throw switches, then hit the start/run button, and that was enough to breath life into the IBM Selectric and it was off to the races from there. Be nice to have a photo and say "ah, that's the one!" Fond memories.

FWIW, the devel process was to mount the source code tape on the first tape drive, the compiler/assembler tape on the second tape drive, and a blank tape for the object code on the third. Then you'd move the object tape (for gods sake, why???), mount the linker tape, and a blank tape for the executable. Once you had the executable, you could then mount the data input tape and start doing your actual data processing. FWIW, this was for the particle telescope on Pioneer 10/11, it counted energies and charges of protons, helium, nitrogen, oxygen nuclei in the solar wind. 1977-1980. University of Chicago, Lab for Astrophysics and Space Research (LASR) headed up by J. A. Simpson. Data tapes were delivered by JPL; they got the radio signal and split out the science data for each individual experiment (there were 7 or 8 onboard) and sent them out to the principle investigators. 67.198.37.16 (talk) 06:45, 17 November 2024 (UTC)

All that tape movement is something that should have been fixed by a competent systems programmer. Obviously the default input for both the assembler and the linker was “MTA0” (or whatever). If there wasn’t a standard way to change that the program should have been patched. Likewise the compiler and linker should have been stacked on one tape, if possible. Peter Flass (talk) 18:01, 17 November 2024 (UTC)

Heh. Thanks. As I said, they were in the process of decommissioning, so perhaps it was a bit neglected. This article contains a "list of customers". LASR isn't included, but maybe it's counted as being counted as a part of NASA. My memories are anecdotal; beyond attesting here, I can't provide a reliable source. 67.198.37.16 (talk) 06:17, 19 November 2024 (UTC)