Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Space Technology

Apollo On Board Computer Emulator 166

frankk74 writes "For those of you interested in Historical Computing and the Apollo manned spaceflights Ron Burkey has created a open source emulation of the Apollo Guidance Computer called vAGC. I use it as my desktop clock of choice. Note it only keeps mission time so after 24 hours you have reset the time :-). P.S. Another cool Apollo toy free and payware can be found here."
This discussion has been archived. No new comments can be posted.

Apollo On Board Computer Emulator

Comments Filter:
  • Slashdotted (Score:5, Funny)

    by dreamer8815 ( 757752 ) on Saturday August 28, 2004 @05:07AM (#10095132) Homepage Journal
    In three two one... Huston, we have a problem.
  • by incog8723 ( 579923 ) on Saturday August 28, 2004 @05:11AM (#10095139)
    Forget Linux. Forget overclocking/unconventional CPU cooling. This is cool shit.
  • Warning (Score:4, Interesting)

    by poofyhairguy82 ( 635386 ) on Saturday August 28, 2004 @05:24AM (#10095160) Journal
    From site: For Win32 users, it's much more work to get your computer set up to build Virtual AGC than it is in Linux, and the steps needed will be less familiar.

    That made me feel good seeing as how this is the first week I've tried linux.

  • by ndevice ( 304743 ) on Saturday August 28, 2004 @05:30AM (#10095175)
    Took a quick scan at the architecture of the machine, and I'm suprised that it's so simple.

    People say over and over again that simple handheld calculators are more powerful than that thing, and it seems that the oft-parroted line is more accurate than they realize.

    Add to that: RTL (before TTL) and magnetic core memory bring up the nostalgic value.
    • by thhamm ( 764787 ) on Saturday August 28, 2004 @05:51AM (#10095213)
      some of the "moon hoaxers" think thats why they could never get to the moon at all.
      "though much faster, my pentium can barely run [insert 3d shooter here] at good FPS. how could it fly to the moon? so they never did."

      logic?
      clavius explanations [clavius.org].
      • by TheHawke ( 237817 ) <rchapin@nOSpam.stx.rr.com> on Saturday August 28, 2004 @09:10AM (#10095601)
        Eh, Brute force. They needed the AGC to be as simple, yet programmable with all the steps necessary to get the boys on the moon and back.
        So they took the PDP8 and squeezed it down into the size of a early 80's era Kaypro portable (now that's saying something about my age) and managed to get it to draw as much power as your coffeemaker.
        THEORETICALLY, they could have done it with a sextant and a good clock, BUT! Their navigation skills had to be dead-bang on every time to the fraction of a minute.
        So it was easier to shoehorn this colossus into the spacecraft and let it do the driving.
      • by Speare ( 84249 ) on Saturday August 28, 2004 @10:10AM (#10095808) Homepage Journal
        But somehow a few rafts colonized the polynesian islands. Somehow a compass, a sextant and a bunch of canvas guided boats across the Atlantic for centuries.
        • Look at just about any operation your computer performs. Not only is it all math, it's generally fairly simple math. You could do it all with a pencil and paper -- but you can't do it as fast. It's speed that's the issue. On a ship, you have time to correct your errors. When landing on the Moon ... you don't.
          • It's speed that's the issue. On a ship, you have time to correct your errors. When landing on the Moon ... you don't.

            Wasn't the actual landing manual ?

            • During the final few seconds, yes it was manual. But with Apollo 11 they had about 5 seconds of reserve fuel left when they actually set down. That was not 5 seconds to abort and go back up, but simply 5 seconds before they ran out of fuel.

              While indeed there was actual piloting and people were clearly in the loop to run the spacecraft (and needed!), some of the critical timing issues for orbit insertion and lanuch windows simply have to be run with computers. There is no other way to ensure that you can
              • IIRC correctly during the Apollo 11 landing they actually passed the "no-abort" point at about 60 seconds of fuel, when they were simply too low for a successful ascent stage abort.

                OI isn't really that critical timewise unless you have to hit *precisely* the orbit you want; a few seconds either way (and there often was during the lunar missions even with the computer running things) meant merely that your orbit would have a few miles or tens of miles discrepancy in perigee/apogee, correctable with a sho
      • by Archibald Buttle ( 536586 ) <`steve_sims7' `at' `yahoo.co.uk'> on Saturday August 28, 2004 @10:37AM (#10095910)
        The hoaxers are dicks.

        It is of course completely irrelevant that their pentium is a heap of crap, as you imply. These are the kind of idiots that don't believe that you could have a 3d game on a 20 year old 8bit micro - showing them Elite blows their minds.

        They think that because a computer is slow it's worthless. Well, that's what Microsoft and Intel keep telling us so it must be true. Also their 3d shooter is damn slow. That's gotta be proof.

        Conversely those of us with brains, real software development knowledge, and an appreciation of physics realise that you hardly need any computing power at all for an Apollo space craft. Indeed it's arguable that the computer they did have was overkill - a computer-less solution could have been engineered.
        • Actually, with the FDIV bug, I wouldn't trust an old pentium to fly my to the moon. It proboably wouldn't make a diffrerence, but still.

          Who am I kidding, if I had a chance to go to the moon, I'd go almost no matter what...
    • by RedWizzard ( 192002 ) on Saturday August 28, 2004 @06:13AM (#10095251)
      People say over and over again that simple handheld calculators are more powerful than that thing, and it seems that the oft-parroted line is more accurate than they realize.
      Or perhaps they repeat it because it's accurate and they know it?
    • by Edward Teach ( 11577 ) on Saturday August 28, 2004 @06:37AM (#10095292)
      In the Apollo 11 descent to the moon, you hear someone say "twelve oh one alarm." This was the alarm that told the LM crew that the computer reset because it ran our of memory.
      • by Anonymous Coward
        No, it didn't 'run out' of memory, there was no OS capable of making that determination. There were simply too many real-time interrupts coming in. The time-slice approach of the Apollo system simply couldn't handle all those requests.
        • by Erbo ( 384 )
          Right...1201 was "Executive overflow - no vacant areas." The computer was simply unable to complete all its jobs in the course of a major cycle.

          Gene Kranz's book Failure Is Not An Option talks about simulating the moon landing, and seeing 1201 alarms coming up and the controllers unable to deal with them. Kranz ordered an abort after a 1201 alarm...but it turned out that was the wrong thing to do. Dick Koos, the simulation supervisor, told him, "This was not an abort. You should have continued the landi

      • Also, I beleive that they left the rendevous docking radar switch in the on position during decent (a no no) also contributed to the 1201's. Even though it was listed in the Flight manual as being in the on postion. A mistake i believe that wasnt tested in the simulators but was found by 2 engineers during a passing conversation in a hall.
      • by oogoliegoogolie ( 635356 ) on Saturday August 28, 2004 @10:05AM (#10095787)
        ...the computer reset because it ran our of memory.

        That's because when the LM was being designed some engineer decided "640 Bytes should be enough for anyone."
      • Wow. The last thing you want on the descent to the moon is a BSOD...
  • by Anonymous Bullard ( 62082 ) on Saturday August 28, 2004 @05:46AM (#10095205) Homepage
    Now the Chinese Communist Party can finally be confident that their Soviet-era space capsule can be launched at the moon, with one or two "People's Liberation" Army's faithful inside.

    Like Deng Xiao Ping's 50-year plan towards (real) World Domination by using the capitalists' greed against their own long-term interests, this space-conquering plan began over 50 years ago when the "People's Liberation" Army invaded their peaceful neighbour Tibet, to be used as a back-up landing area. Well, Tibet can also be looted for their natural resources (oil, gas, uranium) and subjugation the hapless Tibetan people has been used as a great propaganda victory for Party jingoism, but clearly one of the main reasons to invade was to use the Tibetan territory as a back-up landing site.

    Apollo On Board Emulator, running on Red Flag Linux and locally-built Dragon CPU... even Evil Invading Dictatorships can be pretty geeky when it suits their World Domination Plans... ;-)

  • by Anne Thwacks ( 531696 ) on Saturday August 28, 2004 @05:51AM (#10095212)
    A quick inspection of the instruction set reveals why they only made 157 of these and made 6 million PDP8s.
    • by Rosco P. Coltrane ( 209368 ) on Saturday August 28, 2004 @06:01AM (#10095228)
      A quick inspection also shows that a PDP8 weighs as much as the Saturn V rocket, and weight is the last thing they needed to haul stuff on the moon...
      • by hughk ( 248126 ) on Saturday August 28, 2004 @06:36AM (#10095290) Journal
        Not really, and it had an excellent reputation for real-time work. The thing is when NASA were shopping for processors a long time before the landing, the PDP-8 didn't exist in the compact form. By the time of the first landing it certainly did, but it was already too late. The PDP-8 and later the PDP-11 then just swept through the world of real-time computing.
        • Also, it takes a long time to get electronic components approved for use in space, which is why the stuff in satellites is usually way behind what sits on your average desk. The university I attended designed and launched a series of very cheap satellites, which, apparently, ran some of the most advanced computing equipment in orbit, simply because it didn't matter too much if it blew up after 3 days.
          • I think you'll find that if it did blow up after 3 days someone would have cared.
            • Well, yes, but, by memory, it was a $500,000 project (tucked in the space between a few commercial payloads). If it went down after 3 days, I'm sure there would have been a few drunk electronic engineers in the student union, and maybe there might have been questions about funding the next shoebox-satellite, but it wasn't going to leave half a continent without telephones or punch a hole in the CIA's spy network, let alone kill any astronauts (which is where we came in).

              I remember seeing a documentary abou
    • by kfg ( 145172 ) on Saturday August 28, 2004 @06:06AM (#10095237)
      A quick inspection of an Apollo capsule reveals why they didn't just use a PDP8.

      Think of three fat guys trying to move one of those things in a Mini Cooper.

      KFG
      • by AndroidCat ( 229562 ) on Saturday August 28, 2004 @08:30AM (#10095482) Homepage
        And they made Buzz Aldrin sit in the back. No wonder he gets cranky [csicop.org] if someone says that he didn't go to the Moon!
      • The PDP-8s were rack mounted. If you didn't have extra memory, the tape units or the high-speed paper tape reader, then the whole thing was about 4U high.
  • by Anonymous Coward on Saturday August 28, 2004 @06:00AM (#10095223)
    What I would like to see is a complete Apollo computing system simulator, consisting of the hardware simulator, where you could realistically simulate the effects of increased core voltage, heat, power surges, fluctuations, etc. coupled with the hardware emulator capable of running native Apollo code, just like vAGC.

    Do they have this at NASA? For them it must be easier and more reliable to just use an identical environment for testing purposes, but some Apollo enthusiasts would enjoy tinkering with such a combined simulation-emulation environment (SEE).
  • by Purifier ( 782794 ) on Saturday August 28, 2004 @06:11AM (#10095247) Homepage
    ...without having a "Start" button? ;)
  • Slingshot (Score:5, Funny)

    by Hypharse ( 633766 ) on Saturday August 28, 2004 @06:19AM (#10095260)
    I tried to use this to run games. It didn't work at first, there just wasn't enough power. Then I used the gravitational pull of my neighbor's house as a slingshot and was running Doom 3 in no time.
  • ......how long it will take someone to try and load it up with pr0n. "Huston, we have a REALLY BIG problem......"
  • by NewtonsLaw ( 409638 ) on Saturday August 28, 2004 @06:22AM (#10095269)
    Does someone have a copy of that old favourite: "Lunar Lander" which runs on this emulator? :-)

    Hell, even my Texas Instruments card-programmable calculator played that game!
  • I feel sorry for the guys who have been spending a lot of time on tis yaAGC.. cool but is there a good reason for a light green on light grey simulated lcd display? I can barely make out what the figures are supposed to me and it would seem to cause fatigue. On the heels of the Siemens story.
  • by Veteran ( 203989 ) on Saturday August 28, 2004 @07:59AM (#10095421)
    An engineer I work with at JSC has an actual - legally obtained Space Shuttle flight computer. The government declared it surplus, and he bought it from the surplus section, so he has the paperwork documenting that he is the legal owner. His box is an actual flight unit, which was in space, not a ground test unit or engineering sample. He has the paperwork documenting its complete history.

    Every once in a while you can find some incredible things in government surplus.
  • Linux (Score:2, Funny)

    by schweini ( 607711 )
    Darn. another platform to port linux to! Just when we thought we had most architectures covered :-)

    But seriously: would it, theoretically (!), be possible to write a x86 emulator on something like that?
    • Re:Linux (Score:3, Funny)

      by AndroidCat ( 229562 )
      If you can write a Turing Machine on it, you're there. Just give it a long enough R/W tape, and let'er rip! (I will warn you that your FPS frame rate will suck.)
  • by panurge ( 573432 ) on Saturday August 28, 2004 @08:15AM (#10095452)
    This machine is optimised for the acquisition of fairly real-time data; read the architectural description. Multiple channel counters are implemented in hardware, partly because in the days of discrete logic this was relatively easy to do (and, of course, the tube calculators with which people had gained experience used lots of counters, because it is relatively easy to make a counter tube, while binary tube logic is very hardware inefficient.)

    Calculators have absolutely minimal I/O and need hardly any interrupt handling capability, and general purpose CPUs like the PDP-8 require a great deal of external hardware to give efficient programmed I/O. It was only really with integrated electronics that general purpose CPUs became appropriate for real time instrumentation and control.
    It's also important that in a space environment, every added gate is a hazard because it can get flipped by radiation. The ideal is to have the minimum gate count, minimum memory cell count, and the shortest possible path between phyical I/O and computing. The computers used in the Apollo meet this requirement.

    Sorry to restate what may be obvious to some people, but a lot of people here will never have had to implement a rad-hard design, and will not understand why simplicity and directness are such virtues in design for space use.

  • How long before somebody cobbles together a "system" this will run on - a re-creation of the hardware using today's components, or at least a neat-looking case for this emulator?

    I'm sure somebody out there with more time than I have is working on it ... :)

  • by Veteran ( 203989 ) on Saturday August 28, 2004 @08:39AM (#10095508)
    I had occasion to look at the plans for the oxygen tank that blew up on Apollo 13. There is no great mystery why it blew up, the mystery is why they didn't all blow up.

    Trying to figure out how much is left in a liquid oxygen tank in outer space is not an easy task. If you wanted to know that answer here on earth you would weigh the tank - which obviously won't work in free fall.

    The idea they came up with was to have a sensor in the tank that could measure the level by resistive means. In order to have a 'level' to measure they had to create an artificial gravity inside the tank by swirling the contents with an internal electric motor and a blade. In the movie "Apollo 13" one of the astronauts talks about "stirring the O2 tank", that is what he is talking about.

    Consider what this all means: you have a tank full of liquid Oxygen, you have several pounds of highly combustible aluminum and graphite parts which are soaked in liquid Oxygen, and you have a DC motor with brushes sparking up a storm inside the tank. Another name for such a combination is a "bomb".

    NASA's - management driven - engineering has long been full of "Whir click, whir click - OK, Russian Roulette is flight certified as safe" thinking. Nobody does a "how could this all go wrong" analysis.
    • Not posting this as troll, flamebait, or anything other than a matter of engineering: could you do better?
    • Just thinking about this...could we not tell the mass of the liquid in a tank by shaking it slightly? The time/energy it takes to get the tank moving, combined with the momentum after turning off the shaker could probably determine how much stuff is in there.

      Or another alternative...sonar...sound reflected off the contents of the tank.

      wbs.
      • Good idea, the problem you need to solve with it is potential for leakage from the fittings.

        I think I would use a small Gamma emitter with a radiation sensor to measure absorbtion instead of sonar, since bubbles could affect the sonar.
    • by WolfWithoutAClause ( 162946 ) on Saturday August 28, 2004 @10:42AM (#10095935) Homepage
      In order to have a 'level' to measure they had to create an artificial gravity inside the tank by swirling the contents with an internal electric motor and a blade.

      They didn't use artificial gravity to seperate the LOX; quite the opposite.

      In fact, in zero gravity LOX tends to divide up into regions of gas and liquid. If the gas happens to float past the sensor, then they get an incorrect reading of the density, and hence they don't know how much is in there. This was a big problem on previous flights. Stirring the tank mixes it all up and makes it the same density; allowing a reliable reading to be taken.

      you have several pounds of highly combustible aluminum and graphite parts

      Aluminum, particularly bulk aluminum is *not* combustible in LOX. It's used on the Space Shuttle main tank fer heavens sake!

      Graphite can't really burn either; for it to burn it needs to reach ~3000K, and the LOX is pretty keen on it not reaching that temperature.

      LOX only really explodes in contact with greases- it's soluble in them, and they form a contact explosive.

      and you have a DC motor with brushes sparking up a storm

      Provided the brushes are carefully chosen, this need not be a problem.

      That's not actually what caused the explosion anyway.

      During testing a relay welded itself shut due to incorrect voltages. In flight, the wiring overheated- and the insulation burnt in the LOX. That caused the LOX tank to overpressure, and it blew away half the side of the vehicle.

      • by Beryllium Sphere(tm) ( 193358 ) on Saturday August 28, 2004 @10:50AM (#10095966) Journal
        In addition, the incorrect voltages during testing were the result of failed communication between the contractor and NASA, a spectacular example of why the paperwork is important.
      • by Veteran ( 203989 ) on Saturday August 28, 2004 @11:26AM (#10096168)
        They didn't use artificial gravity to seperate the LOX; quite the opposite.

        In fact, in zero gravity LOX tends to divide up into regions of gas and liquid. If the gas happens to float past the sensor, then they get an incorrect reading of the density, and hence they don't know how much is in there. This was a big problem on previous flights. Stirring the tank mixes it all up and makes it the same density; allowing a reliable reading to be taken.


        Yes and no. In zero g the bubbles and liquid have no reason to separate. In a gravity field the bubbles float just like the do in water - so you get a liquid without voids in it - which you can measure.

        Aluminum, particularly bulk aluminum is *not* combustible in LOX. It's used on the Space Shuttle main tank fer heavens sake!

        Aluminum will burn in air if there is enough energy to break through the surface layer of aluminum oxide which builds up on the surface. In fact aluminum is so reactive with oxygen that this layer forms instantly when the metal is exposed to oxygen. Anything which will burn in air will really burn in LOX.

        Graphite can't really burn either; for it to burn it needs to reach ~3000K, and the LOX is pretty keen on it not reaching that temperature.

        There was an experiment where a scientist used LOX and charcoal to see how fast it would burn - it esentially flashed in less than a second. DO NOT ATTEMPT THIS. IT IS RIDICULOUSLY DANGEROUS. Your statement is like saying Nitro Glycerin is safe to have in your house. NOTE FOR THE YOUNG AND INEXPERIENCED: DO NOT STORE NITRO GLYCERIN IN YOUR HOUSE. IT WILL BLOW UP AND KILL YOU!!!

        Provided the brushes are carefully chosen, this need not be a problem.

        This is exactly the sort of thinking which resulted in the original disaster. Brushes are mechanical devices - there is inductance in a motor - when the brush connection is broken the inductance of the motor will cause a spark. We have studied the ignition properties of such sparks in LOX in my group. There is a statistical probability of a given spark igniting the brush material.

        That's not actually what caused the explosion anyway.

        During testing a relay welded itself shut due to incorrect voltages. In flight, the wiring overheated- and the insulation burnt in the LOX. That caused the LOX tank to overpressure, and it blew away half the side of the vehicle


        That is the official theory which was reached by people who knew nothing about the spark ignition problem. The voltage in the GFE power supply used in the test was not enough to weld contacts - the LOX would have cooled the wires so that they wouldn't have reached ignition temperature. The explosion didn't happen until the tank was stirred. The thinking behind reaching that official theory was "Well none of the other tanks blew up so the design was OK so it must have been someing which was done to that particular tank that caused the problem."

        Thanks for demonstrating the "Whirr click, whirr click " mind set to everyone.

        • In flight, the wiring overheated

          No, the wiring overheated on the ground, as the test conductors ran the internal tank heater for hours to boil off the LOX inside. The tank contents did not empty as quickly as usual because the tank fill pipe had been dislodged when the tank was dropped two inches during installation some months before. Because the tank heater was built for 28V and the older ground test equipment delivered 65V, the heater thermostat failed, and the tank heater stayed on 100% of the time
          • Thanks for the additional data. I had read this a year and a half ago and had forgotten it.

            In LOX the wires themselves in the precense of a spark can ignite. This is dependant upon the size of the spark and the size of the wires; does the wire lose heat to the LOX bath faster than the combustion can provide it? If so there is no ignition of the wire - if not then the wire can ignite.

            Breaking a wire which is carrying a current is one of the best ways we have found of causing a fire.

            Regardless, the design
            • The tank design itself was safe. The problem was voltages and the thermal limit switches.
              Where the LOX tank was fabricated they used 24 volt power to test the tanks. At the Cape, they used 48 or 72 volts DC at the pad. When they did the forced LOX purge, the limit switches fused shut the instant they were subjected to the higher voltages, hence the temperature inside the tank rose to a nice 400 degrees F. The interior temperature gauges were not calibrated to detect the oven-like heat that occurred. The tef
        • There was an experiment where a scientist used LOX and charcoal to see how fast it would burn - it esentially flashed in less than a second.

          Experiment? More like "let's see how fast we can light a barbecue grill [llnl.gov]!" ;)

          p
      • Aluminum, particularly bulk aluminum is *not* combustible in LOX.

        The british navy used to think this as well, so they built some ships from aluminum, and sent them down to the Falkland Islands to stem off an invasion. They discovered the hard way, if you heat a piece of aluminum to the correct temperature (achieved thru the ignition of an exocet missle) then the aluminum superstructure indeed will burn, and continue to burn, in a gas mix that's only 16% oxygen, with the rest relatively inert gasses (ai

        • Yes, but the Falkland island thing isn't quite the same- the aluminum structure was uncooled. What happens is that the aluminum gets hot and melts, and then droplets of it disconnect from the body- they can then easily burn and set off a self-sustaining reaction.

          In a LOX tank or pipe, the LOX continuously cools the aluminum, and *cooled* aluminum is incredibly hard to melt, let alone ignite.

    • Just think in your car there is a 12 volt DC motor submerged in gasoline with air and fuel vapor filling the void space in the tannk.

      This is an even nastier mix than LOX in an AL tank
      and we all drive around with it every day.

      At least on apollo only the oxidizer was in the tank...
  • by stinky wizzleteats ( 552063 ) on Saturday August 28, 2004 @08:39AM (#10095512) Homepage Journal
    When you fly [orbitersim.com] it?

    The most recent version of the apollo spacecraft add-on (NASSP 5) has a partial working AGC built into the navigation system.
  • Car-PC (Score:2, Funny)

    by LakeSolon ( 699033 )
    Does anyone else have a sudden urge to run this on the touch-screen of their car-pc? I can't wait...

    ~Lake
  • by today ( 27810 ) on Saturday August 28, 2004 @09:42AM (#10095693) Homepage
    Humorous snippet from the landing module code...

    P63SPOT3 CA BIT6 # IS THE LR ANTENNA IN POSITION 1 YET
    EXTEND
    RAND CHAN33
    EXTEND
    BZF P63SPOT4 # BRANCH IF ANTENNA ALREADY IN POSITION 1

    CAF CODE500 # ASTRONAUT: PLEASE CRANK THE
    TC BANKCALL # SILLY THING AROUND
    CADR GOPERF1
    TCF GOTOP00H # TERMINATE
    TCF P63SPOT3 # PROCEED SEE IF HE'S LYING

    P63SPOT4 TC BANKCALL # ENTER INITIALIZE LANDING RADAR
    CADR SETPOS1

    TC POSTJUMP # OFF TO SEE THE WIZARD ...
    CADR BURNBABY
  • by Chemisor ( 97276 ) on Saturday August 28, 2004 @10:12AM (#10095814)
    > Note it only keeps mission time so after 24 hours you have reset the time

    Yeah. 24 hours ought to be enough for everybody.
    • It doesn't have a 24 hour limit, you have to reset the time at 24 hours if you want to use it as a clock, because it doesn't wrap to 0:00, it keeps counting up... i.e. 23:59...24:00, and later, 24:59...25:00.

      It will do this to ~31 days, at which point the timers overflow.

  • Does anyone have the specs on the mainframes NASA used for orbit calculations, mission planning and so on? I was wondering when personal computers reached the equivalent power level, and whether my Prius has more computing power on board.
    • NASA was using IBM360s in those days. They really had little processing power in real terms (although they were quite good on I/O).

      I have no idea what the Prius has as a processor, but a modern laptop would substantially exceed the processing power of the ground installation. Perhaps only if programmed in FORTRAN though (the NASA language of choice at the time).

  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Saturday August 28, 2004 @11:07AM (#10096064) Homepage
    If we have a Beowulf cluster of these, do we have a space invasion on our hands ?

    If so: who is invading who ?
  • by dswartz ( 749795 ) on Saturday August 28, 2004 @11:22AM (#10096141)
    I would just like to point out that Draper Labs in Cambridge, MA (the company I work for) built the AGC. An exact replica of the real AGC sits in our Simulation Lab.
  • Intuitive (Score:3, Funny)

    by suwain_2 ( 260792 ) on Saturday August 28, 2004 @12:03PM (#10096358) Journal
    Some people complain that the Linux CLI is too user-unfriendly. Have they tried using this thing?

    Setting the time:
    Press Verb 2 5 Noun 3 6 Entr. Then enter a + to indicate you're entering the time in decimal, not octal. Be sure to enter all 5 digits of the hour. Then press Entr, and enter minutes, and then repeat for seconds. And make sure you remember that the seconds are in 100ths.

    V25N36E+00012E+00002E+04400E

    Totally intuitive.
  • Notes on compiling (Score:5, Informative)

    by crucini ( 98210 ) on Saturday August 28, 2004 @02:27PM (#10097363)
    I didn't immediately succeed with the author's instructions. Here's what worked for me:

    cd yaAGC
    ./configure
    make
    sudo make install
    cd yaDSKY
    ./configure
    make
    sudo make install
    yaAGC --core=Validation.bin --debug
    In another window, still in the yaDSKY directory: yadsky --cfg=src/LM.ini
    (Note lowercase yadsky)
    Congratulations, Ronald. Pretty cool. Does the contrast on the LED display have to be so low? The background is very light.

    Am I the only one here who actually tried the program?
    • Probably... or else everyone else is still struggling with it. :)

      Thanks, your instructions worked here while the original ones didn't. Lots of warning during compilation, but I have some weird lib versions on the box I compiled it on, gotta take it down for a few days to update libs (Gentoo is nice but time consuming :) and I run some software that requires custom beta libs, so that might have something to do with...

      and now that I've blown the better part of two hours playing with this, it'll probabl
      • I'm running Red Hat Linux release 9 (Shrike) - actually Pink Tie, a CheapBytes copy. And fluxbox 0.1.14 - love it.

        Agreed about Gentoo. I run it at work, with much help from a nearby Gentoo expert, and frequently have to put too much time into fixing it. The benefit is that I can run recent Mozilla, etc.

        I added apt-get to Red Hat and it gives me some of the functionality, but most applications I want aren't available. It is much faster than emerge, of course.

        I don't know Orbiter - I'll take a look.
  • This is just too weird a coincidence.

    I just bought The Sky Moves Sideways [cduniverse.com], and I was listening to it while reading Slashdot.

    By the time I had read through the articles on the home page, most of the album had played out. Then I read the AGC article and downloaded the code.

    The weird part is that when I started reading the Luminary source code, the track playing was, "Moonloop", and hit the part at 13:18 where an excerpt of the Apollo landing broadcast is mixed it.

    I am totally freaked out right now.

If you think the system is working, ask someone who's waiting for a prompt.

Working...