Hacker News Reader

Comment by Arnavion | Hacker News Reader

>with no hope of doing an update

To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-...

In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upg...

Edit: I'm not saying this was possible in 1969. I posted this because I was genuinely curious if it was ever done.

View on HN

> space probes occasionally do get software updates

Sure. In 2014. Not in 1969.

I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft. It used an 1802 processor with 2k bytes of memory and was programmed in Forth. The development system ran on an Apple II. The instrument developed a bad byte of RAM and so a patch had to be developed, but the Apple II that ran the Forth compiler had long since been decommissioned. (It was nine years between when the spacecraft was completed and when it arrived at Jupiter, three of which were a delay caused by the Challenger explosion.)

I ended up writing a complete 1802 emulator and new Forth development environment that was able to compile the original source code and reproduce what was then running on the instrument. That code ran in Common Lisp on a Macintosh II. Using that new development system, I produced a patch, which was only about a dozen bytes long. It was quite an inexpensive project by NASA standards (took about three months from start to finish with just me working on it) but the cost per byte of output code was pretty staggering :-)

> I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft.

Sigh. Reading this at the start of my workday is not doing wonders to my morale.

Only tangentially related to the article, but since you are commenting here, I'd like to thank you for the "Lisping at JPL". I've read it several times, which caused me to start collecting all the info I could get on the Remote Agent. I couldn't find that much though. Surely such a project should have generated way more research papers than it did? Since it doesn't seem to be used anymore, where's the source code? It feels like it was killed with fire.

I wonder if current generation spacecraft now have something even half as powerful as the DS1 REPL...

> Reading this at the start of my workday is not doing wonders to my morale

I'm very sorry to hear that. Would it help if I told you how my life sucks now? ;-)

> Surely such a project should have generated way more research papers than it did? Since it doesn't seem to be used anymore, where's the source code?

I have no idea. I strongly suspect that the RAX code was not preserved, though I could be wrong. You might want to contact the JPL public-relations office and ask them.

It is hard to appreciate just how chaotic the entire DS1 project was. The mission was trying to do things that had never been done before on a budget and schedule that was a tiny fraction of anything that had come before. And then RAX was a little cauldron of chaos within the larger chaos. We were a team forced to work together by largely political rather than technological considerations. We were using CVS for version control (this was the mid-90's remember). It was all we could do to come up with something that worked at all. It was very stressful, and when it was over, everyone just wanted to distance themselves from it as fast as possible. There was no money for anyone to properly catalog and archive the code (AFAIK).

> I'm very sorry to hear that. Would it help if I told you how my life sucks now? ;-)

Not at all. It would only increase the (perceived!) overall suckyness of the universe :)

> I have no idea. I strongly suspect that the RAX code was not preserved, though I could be wrong. You might want to contact the JPL public-relations office and ask them.

I didn't know that such an attempt could have a greater than zero chance of success. Let's see how that goes.

> And then RAX was a little cauldron of chaos within the larger chaos.

And yet, it flew!

> It was very stressful, and when it was over, everyone just wanted to distance themselves from it as fast as possible.

Uh oh. That's far worse than having no budget for archival.

> And yet, it flew!

Yes, it did. And it even mostly worked. And even when it didn't work it let us demonstrate in-situ debugging and repair, which had also never been done before (and AFAIK has not been done since).

> That's far worse than having no budget for archival.

Indeed. :-(

> I'm very sorry to hear that. Would it help if I told you how my life sucks now? ;-)

I'm sure it does ;)

However: back in those days, computing skills were in mad demand (much more so than today, impressions to the contrary notwithstanding) and almost everything that you could do with a computer turned out to be something interesting and new.

With all the 'base' problems solved and the enormous resources available today the creativity and joy have definitely dropped a level or two. That doesn't mean that it isn't possible to derive some satisfaction of the creation of something but it is definitely harder to come by than it was in the days past.

Creativity explodes when there are more constraints, we are now for all practical purposes almost unconstrained.

> Sure. In 2014. Not in 1969.

The LM computer on Apollo 14 had to be updated in flight in order to bypass a faulty abort switch.[1] The patch was applied by radioing the instructions to the crew and having them enter it manually.

[1] https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html

Note that this was not a code patch: This was a sequence of changes to the program state that tricked it into ignoring the abort switch. The code itself was stored in read only core rope memory, so it was physically impossible to change it (the memory was written by appropriately winding wires around ferrite cores).

EDIT: More details (in the form of a puzzle): http://www.ibiblio.org/apollo/#Final_exam_for_the_advanced_s...

> I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft.

One of the many reasons why I love reading the comments on this site.

I guess that makes you R.G.?

Yes. (Note the "about" link on https://news.ycombinator.com/user?id=lisper)

Sometimes I like to see what I can figure out in 5 minutes without help or using easy search terms. Keep my Google Fu sharp. Clicking on your name would've been way too easy. Although, I probably should've looked just in case before I asked haha.

Anyway, nice to run into you. I remember your writings were some inspiration in my work on an embedded, efficient 4GL. I no longer had the tool or even remember what I read but your writings factored into it a bit I know. So, thanks for that I guess is all I can say there. :)

Btw, I recently discovered the 1802 in my high assurance and anti-subversion research in hardware. That foray was interested in chips that demonstrated extreme reliability and longevity. I looked into spaceflight given overlap in requirements. Discovered it. The Intersil datasheet had amazing amount of info compared to most chips with some impressive claims about what it could handle.

Since you had to study it, do you think it's worth using on an older process node for high-reliability today? Anything good about it you remember that's worth copying today? Or one of the bigger headaches of your career? I'm just curious as verifiable designs will likely require inspectable fabs... which require tiny CPU's. Means I can't overlook any old wisdom from a time with similar constraints.

I liked the 1802 a lot. Nice orthogonal architecture, lots of registers, made writing the emulator a snap. The only problem with it was that it was dog-slow even in its day: 8 clock cycles per machine instruction. I think you could do better today with a modern FPGA.

I'm doing some work on secure hardware (and software) myself. Would love to compare notes. I sent you an email.

Dug this out of the datasheet:

" Equals 2 machine cycles - one Fetch and one Execute operation for all instructions except Long Branch and Long Skip, which require 3 machine cycles - one Fetch and two Execute operations."

Max clock is 3.6MHz. So, better than 8 clock cycles but still dog slow compared to most. 3.6MHz is still very usable in lost of control applications, some logging, and possibly trusted coprocessor if simple function. Speed improvement is a must, though, for the 1802/2.

I remember the 8080 used 3 clock-cycles for a T-cycles, and 2 or three T-cycles for an instruction. It really took years to get one-instruction-per-clock-cycle. Pretty much all modern processors can do that now (or even three or four per)

Thanks as I couldnt recall how average CPU was then. I was writing it off as possibly the safety/reliability sacking the performance a bit. Still wondering about the "noise immunity" feature. Thought all digital gates had that property.

Ha! I found the old GLL mag code. Here's the actual patch as delivered to the magnetometer team:

  ;;;  Engineering offset patch:
  
  (compile-patch ": FIL! 1234 SWAP FILTF ;")
  
  44C8         00 CA 00 1F 12 34
  44D0   01 71 44 A2 00 D5
  
  
  ;;; Optimal averager sampling period patch.  (Uses 2 bytes at 46FE)
  
  (compile-patch
   ": SDSPIN DUP 15 = IF 1ST-DSPVECTOR TS! THEN DUP 28 = IF
     ADDR-BUFFER DUP @ 20 + DUP 4CF8 > IF DROP 4800 THEN
     DUP ROT 2+ 20 MOVE ADDR-BUFFER ! THEN
     1 46FE +! 46FE @ 0= IF OPTST -7 46FE ! THEN
     DUP 0= IF MAT-LOAD 4FF0 C@ 20 - 2/ CMDPTR +! THEN ;")
  
  42B8               00 CA 01 60
  42C0   00 2A 15 02 43 00 76 05
  42C8   04 3B 41 63 01 60 00 2A
  42D0   28 02 43 00 76 2C 40 50
  42D8   01 60 01 95 00 2A 20 00
  42E0   E9 01 60 00 1F 4C F8 02
  42E8   37 00 76 07 01 6C 00 1F
  42F0   48 00 01 60 02 B0 02 5D
  42F8   00 2A 20 01 03 40 50 01
  4300   A3 02 3F 00 1F 46 FE 01
  4308   AF 00 1F 46 FE 01 95 01
  4310   C0 00 76 0D 41 B8 00 1F
  4318   FF F9 00 1F 46 FE 01 A3
  4320   01 60 01 C0 00 76 14 42
  4328   54 00 1F 4F F0 00 8A 00
  4330   2A 20 00 F6 0E 3A 04 71
  4338   01 AF 00 D5

A little longer than I remembered it, so maybe NASA got its money's worth after all!

I have the complete source code for this project. If anyone is interested let me know and I'll post it somewhere.

It would be beautiful if you could post this on github. Such a piece of history deserves to remain available for posterity.

Yeah, I know the modern era machines have in-the-field updates, but I assume that wasn't a feature on the Lunar Module. You need a device capable of self-programming and with the state and cost of memory at the time I would think that an impossibility at the time.

We'll just include a little robot that can rethread the core rope memory!

Reply on news.ycombinator.com