Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore!uunet!world!ksr!jfw
From: jfw@ksr.com (John F. Woods)
Newsgroups: sci.space.shuttle
Subject: Re: New Shuttle computers
Message-ID: <2601@ksr.com>
Date: 11 Mar 91 22:31:51 GMT
References: <9103111905.AA09702@cmr.ncsl.nist.gov>
Sender: news@ksr.com
Lines: 55

roberts@CMR.NCSL.NIST.GOV (John Roberts) writes:
>"Went out" of what? Went out of *fashion*??? You feel the Shuttle computers
>must have the newest technology, the shiniest chrome, the biggest tailfins,
>just to *impress* people?

Oh, come on now.  I think the Shuttle would look GREAT with tailfins!  :-)
[Although it might not look like it, I'm actually agreeing with John Roberts
here, just looking at the questions from a slightly different viewpoint]

>>I would expect radiation hardened processors, of an industry sstandard
>>type (80x86, or 680x0 series) 
>Why - so high school students can write the Shuttle flight programs?
>This is a very highly specialized software package, with all sorts of
>constraints that do not apply to most other software. It makes sense to build
>a computer to run the particular intended application, and making special-
>purpose computers out of standard bit-slice components is a long-established
>industry standard.

Well, as I understand it, the AP-101 architecture is pretty much a small
IBM 360, which was pretty "standard" when it was designed.  NASA now has
a huge stack of assembly-language (or near-assembly-language) software
which is extremely thoroughly debugged -- not "well, gee, it ran ok twice
in a row" but debugged as in hundreds of suspicious software engineers can't
find any more problems.  That is NOT the kind of investment you throw away
just so that Flight Simulator will run on the flight system...  :-)

>>As has been suggested by someone else already, EAROMS or just
>>straight ROMS can be used for holding much of the non changing code in memory
>>during a flight.
>They tend to be slower than RAM, and ... EAROMs [have] fewer write cycles.

ROMs aren't all that slow (they're faster than the cores that got replaced).
However, battery-backed-up SRAM (as is indeed found in the AP-101S) is faster,
and certainly more flexible -- you can recover the address space used by the
launch program!  (:-)  An EPROM-based semiconductor-"disk" might make sense,
but as you point out, tape drives now have capacities far in excess of a
reasonable semiconductor disk system.

>>as for RAM needs, if in 1991, the leading manufacturers of semiconductors can
>>put upwards of 10^6 transistors on a chip, but can't make radiation resistant
>>store, then ...
>Remember that "radiation resistant" does not mean the same thing as "radiation
>proof". I'm sure radiation resistant DRAM exists, even though static RAM is
>likely to be more resistant. (Static RAM also tends to be faster.) But I think
>you're missing the point of the choice of static RAM: it's much simpler to 
>use in a real-time system.

DRAM refresh isn't really all that tough a problem, and can be made as
deterministic as you like if the DRAMS are fast enough.  I think it is more
likely that the key is the battery backup -- DRAM refresh consumes power at
the same rate as normal use, whereas SRAMs frequently have power-down modes
consuming fractional microwatts (this, though, depends on whether the memory
"scrubbing" is performed when the system is powered down; if it is, then the
SRAMs probably aren't being put into low-power mode...); and, of course,
SRAMs are generally more radiation resistant as you mention.