While I couldn't locate the specific thread, I recall that one of the Hoax Proponents' claims is that the computer on the LM was insufficiently powerful enough to perform its function.

As a datapoint, consider that the flight control software for the F/A-18 is only about 160KB of compiled code and runs on a Motorola 68040 computer.

My source for this information is the September 2004 issue of IEEE Spectrum Magazine (ISSN 0018-9235).

__________________
"That's Not Blight. It's New Jersey" - The Wall Street Journal

Todays computer kids are used to compile "Hello, world!" programs that use up several megabytes as a file and uses plenty of CPU power to get the pixels of the writing through all abstraction layers.
When I started computing, I could do it with some 20 or 30 bytes, copying the ASCII values of the text into the text-mode video RAM.

Harald

__________________
"Flying in space is risky business, but just staying on this planet is risky business too." - John Young, astronaut

Thanks. Harald, it's good, sometimes, to remember the constraints we worked with (and through) back a few years.

__________________
Some try to tell me, thoughts they cannot defend,... - Moody Blues.

Embedded systems are a completely different programming regime compared to what many people today consider programming.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

I can't find a copy of the specific Dilbert cartoon on the web, but....

__________________
"I'd take the awe of understanding over the awe of ignorance any day." - Douglas Adams

And we felt lucky to have it. Ya know, it was tiring walking uphill, both ways, in a blizzard, to get to the dumb terminal. :wink:

__________________
Some try to tell me, thoughts they cannot defend,... - Moody Blues.

I'm reminded of "Every OS Sucks" by Three Dead Trolls in a Baggie.
(Note: a number of their other tracks contain some off-color language, but this one is clean)

__________________
"Earth diameter is 7,900 miles, and Moon diameter is 2,160 miles. It takes on average 90 minutes to complete one Earth orbit, so one Moon orbit should take roughly 25 minutes." - Sam "NasaScam" Colby

Bearer of the highly coveted "I found Venus in nine Apollo photos" sweatsocks.

DataCable^2008 A+

Even having an OS might be considered wasteful in a real-time situation. You may get by using a few routines to handle context switching and resource management.

__________________
"We do not require reality to conform to the expectations of the ignorant"

Back in the early 80's, my spacecraft simulation group wrote our own operating systems to do the very basic stuff that we needed them to do. Anything else would have been too much overhead.

__________________
Everything I need to know I learned through Googling.

Operating systems for embedded applications can be minimal. But you typically do want the ability to have multiple tasks or threads, and it's better organized if those execution units conform to some external standard of synchronization and control. But what am I saying? We're living in a day and age when we have Java on cell phones.

The AGC designers realized early on that some form of operating system would be necessary. And they designed a good one. They correctly partitioned tasks into real-time and less-than-real-time operations. They provided for priority execution. They provided common library routines. Very well done.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

You got to use a terminal!?!

Yes, as has been pointed out, you don't need an operating system - I've written spacecraft software without it, using something under 128 kB for everything (code and data) - and that was mostly in C, with a little hand optimizing for speed and almost none for space.

For the guys who wrote the custom AGC OS and application code, I have much admiration. And I certainly will take Jay's evaluation of it over the likes of BS.

All this reminds me of this: User Friendly.

__________________
Jeff Schwarz
__________________________________________________
Argh!! They booby-trapped their sun!!****--Invader ZIM

You'd think that HBers would give up on the computer issue, given that people have written emulators for the onboard computer. If you don't believe it worked, you can now try it for yourself.

It is interesting that NASA has gone to a fairly standard realtime OS (VXWorks) for its modern missions; CPU power on spacecraft has finally caught up with general purpose programming requirements. In general this should lead to fewer bugs and cheaper software development, but the complexity has gone up a lot; the embarrassing Flash driver reboot bug on the Mars rovers is a classic example.

As a side note, my father won a special award from NASA back in high school for his science fair project (he was looking at temperature effects on timing in transistor flip-flop circuits). The prize was cool—large full color prints of Saturn (not sure which model off hand) rockets and Apollo hardware. I found them in a closet a few months back, to my delight. They are now decorating my pool table room.

__________________
Do try not to take me too seriously.

I understand that when I press the "a" key on an OS like Windows or Unix, there is no guarantee when the letter a is going to show up on the screen. (And I have learned through experience that encouraging the system with a motivational, "Come on, already! How hard can it be to display that keystroke?" doesn't really help.) I also understand that in some scenarios, say when a Mars lander had to fire its rockets moments before landing, that even a short delay between the radar reporting the altitude and the time the rockets fire can be the difference between a successful landing and a new Martian crater. I understand the need for real-time systems. But how is it that a real-time OS is able to guarantee applications will get the necessary work done on time? Are the applications written differently?

Often the applications are written differently. Other times it's a different scheduling policy.

The AGC had a real-time job class. The jobs had to be written so as to execute in less than a certain time -- 4 milliseconds or something like that. So you alot a certain amount of time in each scheduling cycle for real-time tasks, implying that a certain number of real-time jobs could be simultaneously active in addition to the regular job load.

In some real-time OSes you can have a priority designation that guarantees reselection during a scheduling pass. So even after being interrupted after a time-slice, it's all but guaranteed to get the CPU back. That's attractive because it doesn't mean restructuring the algorithm. You just set up the priorities.

In other cases you use cooperative multitasking. Once a job gets the CPU, it holds onto it until it yields. There's no interruptive scheduling. When the job yields the CPU, the scheduler runs and possibly selects a new job. This allows jobs to be structured into critical and non-critical sections.

If the entire system is well structured you can just preassign the tasks and priorities. If the problem is less structured you have to adopt a more adaptive strategy. Real-time doesn't mean always running. It just has to keep up with the input and output demands.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

Yes. A true real-time operating system allows the programmer to set priorities for different tasks and should permit pre-emption, i.e., if a high-priority task needs to run, it will interrupt a lower priority task even if the latter isn't done yet. The programmer then needs to analyze very carefully what his system needs to do and assign priorities accordingly. When I do this, I ideally like to have every task at a separate priority so that I know in any situation just which task will be executing.

In your example, the radar reporting task would be a high priority while the rocket firing task would be (I would think) even higher, while, say, the task sending telemetry back to Earth would be at a comparatively low priority. So if the CPU runs out of time, the lander will still land okay, though Earth might not hear about it as promptly. But that's not a critical issue.

(By contrast, a non-realtime OS may just execute tasks in round-robin fashion, giving each a slice of time no matter what their priority. So potentially the lander might be sending telemetry while it should be firing its rockets, with unfortunate results. But of course no such OS would be used on a NASA mission.)

As a real-time programmer, a significant part of my effort is to identify and prioritize tasks, and to slice them up in a way that makes sense. For example, perhaps the radar task receives the radar data, processes it, and sends it both to the task controlling the rocket firings and to the telemetry task as well as storing it in memory. It may make sense to pull out the telemetry and storage parts of that task and create a separate, low-priority task that handles those functions. Else the system may be executing less urgent activities at an excessively high priority.

And we haven't even gotten to writing interrupt routines and device drivers yet. I may be biased, but I think real-time programming is the most challenging type of programming there is.

__________________
Everything I need to know I learned through Googling.

Real-time embedded systems of any appreciable complexity are indeed the most challenging types of programs to write. It requires not only intimate knowledge of algorithms and low-level functions, but also more theoretical, high-level concepts like serializability and fair-share. These concepts are generally not taught to the Java prodigies being churned out by the truckload in technical schools these days, and they are utterly alien to the end user.

Computer programming was very different in the 1960s and 1970s than it is today. It required considerably more skill and commensurately demanded considerably more time. The digital autopilot, for example, took more than a year to write even though it comprises comparatively few instructions in the final software image. The manual deconfliction of resources you speak of in your work is perfectly consistent with the type of programming done on the AGC.

The evident result of this was the 120x alarms that occurred during the Apollo 11 landing. They were, respectively, a statement that a position in the job queue could not be allocated for a certain job, and a statement that a bank of erasable memory could not be allocated. These arose not from a programming error, but a change in the operational procedure of the LM which violated the assumptions on which the software had been written. The LM designers used the LGC right up to the limits of its capacity, such that any request for additional work met with resistance.

__________________
"Facts are stubborn things." --John Adams
Clavius Moon Base

Thanks for those explanations, guys. It sounds like real-time responsiveness to inputs and outputs comes not just from a real-time OS, but from that and from the application developers carefully controlling the processes or threads that may be active or marked with a high priority at any given time. I thought that perhaps a real-time OS had a capability to impose real-time responsiveness on any old set of programs.

The talk of slicing up a program reminds me of a program I wrote when I was dinking around learning 8086 assembler in the days of DOS. DOS was not really a multitasking OS, but it occurred to me I could write a program that lived on the timer interrupts, which fired 18 times a second. The first thing I learned was how screwy the system can get when your interrupt routine uses up all the CPU cycles between timer interrupts. I had to restructure the program not by function as I was used to, but by time. I broke it up into tiny pieces timewise and wrapped it all in a state machine that advanced with each interrupt. I found that somewhat tedious and an unusual way to think about a program.

No, a real-time OS just provides the programmer with the resources to do real-time programming, such as priority levels, tasking schemes, and timers. You have to make appropriate use of the resources to get a system that responds the way you want it to.

__________________
Everything I need to know I learned through Googling.