Path: utzoo!news-server.csri.toronto.edu!rutgers!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!eecs.nwu.edu!phil From: phil@eecs.nwu.edu (William LeFebvre) Newsgroups: sci.space.shuttle Subject: Re: New Shuttle Computers Message-ID: <1991Mar11.195018.6479@casbah.acns.nwu.edu> Date: 11 Mar 91 19:50:18 GMT References: <2352@ksr.com> <1991Mar4.202334.22118@casbah.acns.nwu.edu> <1991Mar5.013344.7971@umiami.ir.miami.edu> <1991Mar06.063034.12021@nowhere.uucp> Sender: news@casbah.acns.nwu.edu (Mr. News) Reply-To: phil@eecs.nwu.edu (William LeFebvre) Organization: Northwestern University Lines: 24 Nntp-Posting-Host: pex.eecs.nwu.edu In article <1991Mar06.063034.12021@nowhere.uucp>, sking@nowhere.uucp (Steven King) writes: |> While its encouraging that NASA is finally moving beyond core memory |> for the shuttle ( welcome to the 90's ), why use writeable memory for |> program storage? As their code is extremely stable, it shouldnt be any |> problem to put everything they use into masked roms without any great |> penalty in weight or size ( mask roms have much better density than |> static rams ) with it all non volatile, non writeable. They load different parts of the software for different phases of flight. The 101-B (and 101-S) computer are not capable of addressing much more than 125K words, so they are constrained in that regard. The software is just too large to have all of it loaded in at the same time. And since it isn't all needed at the same time...... At the very least there are separate programs for ascent, orbit, and reentry. I am fairly confident that there are several parts of the ascent software that get loaded in at various phases of ascent. I'll check with my wife later today if I think of it. She would know, or at least would be able to look it up. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University