Moon Hoax. what do you think?

[InquisitiveMind]

Hold on. Are you saying that only conspiracy theorists think for themselves, or that those who think for themselves are always labeled conspiracy theorists?

 

So - all scientists, writers, intellectuals etc are conspiracy theorists?

 

 

 

So - Hitler was a conspiracy theorist?

 

Does that mean you support Hitler, or only his ideas? Or just his methods? Or what? :phones:

 

Are you still working the Apollo angle, or are we moving into conspiracies in general now?

 

 

Well some scientists are actually considered conspiracy theorists sometimes.

Galileo was considered a conspiracist; he was conspiring against the truth of the bible.

Some scientists who are now known as great scientists who made science progress were not immediately accepted.

For instance, Pasteur was not accepted at the start, his theories were contested, he had to make his way, to show he was right.

Freud had to make his way too, at the start his theories were despised.

Many scientists were rejected, despised, sometimes persecuted before they finally were accepted as great men who made science and humanity progress.

Yes, they often started as "conspiracists".

 

 

I didn't say that Hitler was a conspiracy theorist in my comment, I said that there was a time that people who were saying that Hitler was a dangerous man, bad for Germany were despised by other people who were considering them as conspiring against Germany.

 

But now, I say that Hitler was indeed a conspiracy theorist, for he believed in the conspiracy of the protocol of zion which is something which has been forged.

[Buffy]

I have made a complete web page explaining what's weird with the operating system, and why the program can't work.

Here are some tips: Why restrict the addressing to 12 bits, and make memory bank switching, when memory addressing could perfectly have been made on 16 bits, without the need of using memory bank switching which is extremely penalyzing and doesn't simplify hardware, far from it.

B)

 

Ya mean like a PDP-8? Do you even know what a PDP-8 is?

 

Do you how the memory was constructed?

 

Know anything about power consumption? Limitations imposed by size-weight requirements?

There are some weird instructions, almost impossible to use, whereas some basic instructions are missing.

For example to make a conditional jump, there is one instruction testing the accumulator, which only does a jum if accululator is zero; this is totally unsifficent, all other processors have a complete set of conditional jump instruction; there is another instruction, CCS, which can test the sign of a data memory, but this instruction destroy the contents of the accumulator by computing siomething weird in it which can hardly have a practical use.

Never a normal conceptor of CPU would have made it this way, it makes no sense at all.

Do you realize what the CPU consisted of? Do you realize the nature of the complexity of increasing its ability to have all those "obvious" instructions? The AGC used an architecture whereby the program used one word for each instruction, using 3 bits for the op code and 12-bits for the address (with one bit left over for error detection): this was incredibly efficient given that the "CPU" was really just a huge mass of raw NOR gates.

 

Concerning the program, it's full of errors, for instance invalid and duplicate labels, incorrectly specified addresses, redundant instructions, undocumented instructions,

There are no problems with any of these issues: do you understand that the system was written with a custom compiler that was modified on the fly to make the machine work? Or that this was a very common practice--especially for embedded systems--well into the 1980s?

but what I like most is when a subroutine calls another one with instruction "TC": this is totally impossible since the return address is saved into an unique register, which prevents a subroutine from calling another one.

Why bother? They had no stack anyway, because in systems this slow with this little memory, a subroutine call is an expensive operation. What you clearly don't understand is that TC was NOT a subroutine call as we know it today, it's just a plain old *jump* with a return address, and old time programmers knew that they had to write their own code if they wanted a stack. With only 2k of random access memory, you're not going to do much of this and the notion that computer "doesn't work" because you can't write elaborate recursive algorithms is stunning. Why is any of this a problem?

 

Just because you couldn't write a coherent program without a modern CPU doesn't mean that the folks at MIT in 1965 couldn't.

Yes, the operaint system is aberrant, et the program can't work.

Well something around here is "aberrant", but it isn't the "operating system": you apparently don't understand the difference between the CPU and the OS either. The OS was a simple job scheduler that didn't do much but juggle no more than 8 processes with a very simple interrupt mechanism. That's not aberrant, that's exactly what the initial kernel of the Unix operating system looked like. Not much to it to even find fault with, but on the other hand, it was in fact far more capable than MS-DOS or CP/M....

 

Seems to me you're haughtily sitting here in 2010, looking back and saying "they were morons if they could not see that they should have used an Intel i7!"

 

Your answers unfortunately make it obvious that you haven't the slightest idea of what you're talking about.

 

We don't have any obligation to convince you, you need to convince us. Or better yet, don't waste our time....

 

Computers in the future may only have 1,000 vacuum tubes and perhaps weigh only 1.5 tons, :phones:

Buffy

[InquisitiveMind]

Do you how the memory was constructed?

 

 

Yes, I know how the memort was constructed, but it's no excuse.

 

 

Know anything about power consumption? Limitations imposed by size-weight requirements?

 

The problem of power consumption and limitations inposed by size-weigh requirements cannot be an excuse for the problems I talked of.

 

 

Do you realize what the CPU consisted of? Do you realize the nature of the complexity of increasing its ability to have all those "obvious" instructions? The AGC used an architecture whereby the program used one word for each instruction, using 3 bits for the op code and 12-bits for the address (with one bit left over for error detection): this was incredibly efficient given that the "CPU" was really just a huge mass of raw NOR gates.

 

The CPU could perfectly have had other basic instructions; if it could have a BZF and a CCS instructions, it could have had other basic instructions which would have made it easier to use; so this is not an excuse.

There have been other CPU before the Apollo computer which had the same restrictions and didn't work this way.

No, it wasn't efficient at all, it could have been much more efficient differently.

"The CPU was a huge mass of NOR gates": That's a nice tale!

 

 

"There are no problems with any of these issues: do you understand that the system was written with a custom compiler that was modified on the fly to make the machine work? Or that this was a very common practice--especially for embedded systems--well into the 1980s?"

 

But where did you take all that from?

This is completely weird.

How do you want to modify a program on the fly?

Why not write it correctly from the start?

 

 

 

"Why bother? They had no stack anyway, because in systems this slow with this little memory, a subroutine call is an expensive operation."

 

 

Why bother?

They had no stack indeed, but that's precisely the point: in the program a subroutine calls another one, and it's forbidden, it can't work, it creates a deadlock situation.

 

The problem is that you are ready to excuse everything with the weirdest excuses, and it's me you are calling insane.

[InquisitiveMind]

the system was written with a custom compiler that was modified on the fly to make the machine work

 

And Buffy, about this assertion in particular, I dare you to give me a serious (other than Apollo) source which supports this assertion.

And if ever you find a source that you think it supports it, I bet it will mean something different from what you imagined.

[Buffy]

Yes, I know how the memort was constructed, but it's no excuse.

Well then you obviously don't understand the implications: the physical limitations of the manufacture of core memory at the time made it very difficult to have a large number of words for a single memory module, and they were stacked and bank switching was not only practical but it was more efficient.

 

Apparently you are unaware of this.

The problem of power consumption and limitations inposed by size-weigh requirements cannot be an excuse for the problems I talked of.

Would you like to explain why not?

 

I get the impression you have not taken the time to consider what the processor itself consisted of, or the implications thereof:

The CPU could perfectly have had other basic instructions; if it could have a BZF and a CCS instructions, it could have had other basic instructions which would have made it easier to use; so this is not an excuse...."The CPU was a huge mass of NOR gates": That's a nice tale!

Uh, yah, it did: it required over 5000 individual chips to be soldered together by hand to construct a CPU that was even capable of the limited instruction set that you so summarily dismiss.

 

Do you realize that they didn't have an i7 to work with?

 

Have you ever designed a CPU from TTL chips? I have. It's fun. It's instructional, and it can be done. And while by the time I got around to doing it they let us use NANDs, XORs, straight NOTs and other by then easily obtainable gates, if you've had any computer architecture, you'd know that NOR's are all you need.

 

Are you really telling us that you believe it's impossible to build a computer of the complexity of the AGC with nothing more than NOR gates?

There have been other CPU before the Apollo computer which had the same restrictions and didn't work this way.

Yes, which DID NOT HAVE THE SIZE AND POWER CONSUMPTION CONSTRAINTS REQUIRED by Apollo.

No, it wasn't efficient at all, it could have been much more efficient differently.

And even if I were to grant you that they didn't have the size/power-consumption requirements--which I won't because that is the true "absurdity" of your argument--so what if it "could" have been more efficient? Does that make it "impossible?" How on earth does that represent a logical argument?

the system was written with a custom compiler that was modified on the fly to make the machine work

And Buffy, about this assertion in particular, I dare you to give me a serious (other than Apollo) source which supports this assertion.

And if ever you find a source that you think it supports it, I bet it will mean something different from what you imagined.

A friend of mine was one of the founders of Wind River Systems. Look it up.

 

Until standard embeddable operating systems came along, every black box system was custom. People reused whatever code was lying around from the last project and modified it to provide the "operating system" and since the hardware was all hand built, the "complier" was too, and you did successive refinement to get it right.

 

I understand. You have no idea what I'm talking about, and the concepts I'm trying to relate here are unfamiliar to you:

This is completely weird. How do you want to modify a program on the fly? Why not write it correctly from the start?

Have you ever heard of Lisp? Are you not aware that in the days when Assembler ruled that virtually every program had self-modifying code *precisely* because of memory limits? Do you even realize that what I said was in reference to the *compiler* and not to the program itself? Have you ever written a compiler? Have you ever embedded one in an application? Have you always written them perfectly and without error so that you never had to tweak them during development and in the process left around moribund syntax in it's input code because you didn't need to?

 

I didn't think so.

They had no stack indeed, but that's precisely the point: in the program a subroutine calls another one, and it's forbidden, it can't work, it creates a deadlock situation.

...and you program around it. Do you know how many of these systems had instruction manuals with pages that ended with "...and if that happens, hit the reset button?"

The problem is that you are ready to excuse everything with the weirdest excuses, and it's me you are calling insane.

Wanna know why? It's because real engineers have to deal with this thing called "the real world." All of your objections are pulled out of the theory of a perfect world in which there are no limitations or practical constraints.

 

If you find this stuff weird, then I'd like to introduce you to reality. C'mon in! It's fun!

 

But seriously dude, you've done nothing here but convince us that you really have no idea what you're talking about, let alone find any reason to believe you're some sort of Real Computer Scientist.

 

You should probably stop while you're behind, but go ahead, this is entertaining! :cheer:

 

But Grace, then anyone will be able to write programs! :hyper:

Buffy

[lemit]

Here is my own evidence, and it's very rich:

http://www.angelfire.com/moon2/xpascal/MoonHoax/MainPage.HTM

 

I just looked at the introduction to your rich evidence and found inconsistencies in the placement of rocks on the lunar surface. You claim these are identical photos in which the only difference is the one you intend to show.

 

In other words, your photographic evidence is fake. Next time try photoshopping.

 

Any other "proofs?"

 

--lemit

[modest]

I just looked at the introduction to your rich evidence and found inconsistencies in the placement of rocks on the lunar surface. You claim these are identical photos in which the only difference is the one you intend to show.

 

In other words, your photographic evidence is fake. Next time try photoshopping.

 

Any other "proofs?"

 

--lemit

 

Indeed :hyper:

 

The images,

 

 

11057 and 11082 from Apollo 15 show the same background because they are both pointed at the same background. The foreground is different because the images were taken more than a kilometer apart. If you look at the mission journal the first image is taken just north of the LEM and the second is at station 9 about a kilometer to the west.

 

-source

-a second map showing the same

 

It is not a surprise then that the LEM is not in the second photo (and, of course, not evidence of a conspiracy). The LEM is more than a kilometer to the left. It's likewise not a surprise that the 20 meter crater from the center of which the second photo is taken (making up the dark rocks at the bottom of the image) are not in the first. They are more than a kilometer to the right.

 

It's really fascinating to follow their journey. The journal page I linked has audio, images, and video. Fascinating and inspiring.

 

~modest

[REASON]

Indeed :hyper:

 

The images,

 

 

11057 and 11082 from Apollo 15 show the same background because they are both pointed at the same background. The foreground is different because the images were taken more than a kilometer apart. If you look at the mission journal the first image is taken just north of the LEM and the second is at station 9 about a kilometer to the east.

 

What you are referring to, modest, is known as parallax, which is the apparent displacement of an observed object due to a change in the position of the observer.

 

This is rudimentary debunking.

[Eclogite]

I just wanted to thank Buffy for taking me back to the days when I worked with an HP 2100 that was almost a decade after the Apollo computer in sophisitication. Inquisitive Mind, that little baby took up the space of three modern towers, weighed five times as much and had a 4k core memory and sixteen bit words. Yet with it we monitored twenty or so variables on a drilling rig, calculated a hundred more, and output them to primitve printers, dodgy tape recorders and displays loaded with LEDs, J-K flip flops and the like. You clearly have no idea.

[InquisitiveMind]

What you are referring to, modest, is known as parallax, which is the apparent displacement of an observed object due to a change in the position of the observer.

 

This is rudimentary debunking.

 

Conecerning these two photos (11057 and 11082), I agree there is a problem of parallax, and that's why I have not included these photos in my evidence.

But I have other pieces of evidence on which I can make a rigorous demonstration.

[InquisitiveMind]

Until standard embeddable operating systems came along, every black box system was custom. People reused whatever code was lying around from the last project and modified it to provide the "operating system" and since the hardware was all hand built, the "complier" was too, and you did successive refinement to get it right.

 

Of course you do refinement until you get it right, but the code which is provided in the project is supposed to be working, and it isn't.

 

Have you ever heard of Lisp? Are you not aware that in the days when Assembler ruled that virtually every program had self-modifying code *precisely* because of memory limits?

 

Yes I have heard of Lisp, but that doesn't excuse the errors I have seen; it's not minor errors, it's not code which is to be completed, it's very important errors, even with deadlock situations.

 

..and you program around it. Do you know how many of these systems had instruction manuals with pages that ended with "...and if that happens, hit the reset button?"

 

Oh come one, you hit the reset button, and the program locks again because it enters the same deadlock situation; if you keep resetting the computer, I doubt it will be any use.

 

Wanna know why? It's because real engineers have to deal with this thing called "the real world."

 

I know what dealing with the real world means, that's what I'm doing all day long in my job.

I have even worked on an embarked missile guiding program in the seventies, and on helipcoter stabilization, so I know what dealing with the real world means, but that's not what I see in the AGC.

 

I can give you some further tips about the weirdness of the operating system of the AGC:

 

- When an interrupt service routine is triggered, not only the program counter is saved, which is a normal operation, but furthermore the instruction which was about to be executed is also saved into a special register "BRUPT", and this is not normal at all!

Why? Because this instruction will anyway be executed upon return of the interrupt routine, so why save it? It's useless and takes CPU cycles for nothing; it doesn't make any sense.

 

- The "DV" instruction divides the pair of CPU registers A and L by a data of which the memory address is given on 12 bits.

The problem with this instruction is that it works according two different modes (divide the pair A&L by a single precision value or by a "double length 1s complement integer" pointed to by the memory location), but absolutely nothing tells the CPU what mode to use, since there is just the instruction and the memory location and no additional information.

The CPU must be extralucid to determine what mode to use!

 

- the "RAND" instruction is said to logically bitwise ANDs the contents of an I/O channel into the accumulator.

Other CPUs only read or write I/O channels, even the most modern ones; the Apollo CPU is the only one in the world since the processor has existed which can modify an I/O channel in the same instruction that reads it!

Not bad for a CPU which is said to be limited in possibilities.

 

- The "DTCB" instruction is said to perform a jump and switch both fixed and erasable banks.

This is perfectly ridculous, this instruction has a so limited use that it is practically impossible to use; they rather should have implemented a more practical instruction instead, and many are missing!

 

- The "TS" instruction transfers the accumulator to a data memory; if we say just that, this instruction is normal; but it can also destroy the contents the accumulator in some conditions.

That restricts considerably the use of this instruction, and many instructions of the AGC are in this case.

 

- There also are instructions which are quoted in the documentation, but without specifying what they do (such as STCALL); it's the first time I see this in a CPU documentation.

 

- the instruction "STORE" probably stores something into the specified address; I say "probably" because what it does is not explicitly specified.

They say that 'X' is either an unswitched erasable address or in the current erasable bank.

if it is in the unswitched erasable bank, it is provided as such in the instruction word.

If it is in the current erasable bank, it is computed as: 0400 * Erasable BankNumber + (X-1400)

This is where it becomes comical: Why provide the number of the erasable bank in the formula, since it can only be the one of the current erasable bank and no other one?

And what happens if in the formula another number of erasable bank is used instead (which is normally forbidden)? How will the instruction behave?

This is totally illogical!

 

 

Just some examples, it is not exhaustive!

 

And you want me to believe that this operating system is normal?

No way!

[InquisitiveMind]

This is an animation made with the photos AS17-134-20381 and AS17-134-20382:

 

 

Between the two photos, the photographer has moved on the right; this is visible because the jeep and the Lem have moved on the right relatively to the flag which is closer to the photographer.

Normally, the flag should show an anti-clockwise rotation around the vertical axis on the second photo...bit it doesn't.

 

Normally, this is what we should see (or something like this):

 

 

And there are plenty of other problems of rotation in the Apollo photos (and many examples of foreground and background rotating contradictorily).

[InquisitiveMind]

If I have doubts about Apollo, it's not because I have a deranged mind which sees conspiracies everywhere, but because I have noticed many abnormal things which have no logical explanation and of which the sum contributes to generate a reasonable doubt in my mind.

[lemit]

This is an animation made with the photos AS17-134-20381 and AS17-134-20382:

 

 

Between the two photos, the photographer has moved on the right; this is visible because the jeep and the Lem have moved on the right relatively to the flag which is closer to the photographer.

Normally, the flag should show an anti-clockwise rotation around the vertical axis on the second photo...bit it doesn't.

 

Normally, this is what we should see (or something like this):

 

 

And there are plenty of other problems of rotation in the Apollo photos (and many examples of foreground and background rotating contradictorily).

 

Sorry. I see a lot of consistency in the animation that's supposed to be inconsistent and inconsistency in the animation that's supposed to be consistent. Of course, I only looked at the flag and the astronaut. Was I supposed to look at something else? I'm not very good at following misdirection.

 

--lemit

 

p.s. I think looking at that animation has worsened my heart condition.

[InquisitiveMind]

Sorry. I see a lot of consistency in the animation that's supposed to be inconsistent and inconsistency in the animation that's supposed to be consistent. Of course, I only looked at the flag and the astronaut. Was I supposed to look at something else? I'm not very good at following misdirection.

 

--lemit

 

p.s. I think looking at that animation has worsened my heart condition.

 

 

The problem with the Apollo believers is that they have lost contact with reality.

Walk along a house, and you will see it turn before your eyes like you were standing still and it was the house which was turning instead.

There are other examples of such problems, like in Apollo 15 where the photographer is waling along the lem and the lem shows no optical rotation in reaction to the photographer's move.

 

 

I take a photo of my bike placed before cars; then I move on the right, and take again a photo of the bike, and, because of my move on the right, the bike shows an optical anti-clokwise rotation.

It is not difficult to understand, and it's real life, not fantasy.

[InquisitiveMind]

Anyway, I don't expect to convince you.

I never could convince an apollo believer about anything, even when I gave him a very clear proof he was wrong.

As long as he thinks he has a counter-argument, even wrong, he gives it.

And when my proof is so clear that he can't counter-argument it any more, he doesn't speak about it any more, and makes like this evidence was not existing.

Never an Apllo believer has said to me:"OK, you are right on this point".

But when an Apollo believer has made a pojnt, that I have realized I had made a misinterpretation, and it has occasionally happened (though not very often), I have accepted it and said "Ok, I give you the point".

The day that an Apollo believer will say to me:"Ok, you are right on this", I will be extremely surprised, but I know it will never happen, because Apollo believers are as stubborn as creationists.

 

Another very clear incoherence in Apollo 15 (AS15-82-11146):

 

 

The way the visor of the astronaut is oriented relatively to the photographer, the tibias of the photographer we see in the visor are incorrectly oriented; they should be oriented the other way.

 

 

In Apollo 11, between these two photos (AS11-40-5862 and AS11-40-5863) the photographer backs up and moves on the right; could you explain me why the US plate on the extreme left doesn't move on the right on the second photo like it logically should?

 

 

In Apollo 12, on this photo (AS12-46-6716), could you explain me why we see the lunat ground in the reflection of the astronaut's visor whereas he is turning his back to it?

 

 

In Apollo 16, could you explain me why there are perfectly repetitive mud spots on some thirty successive photos (which prove they are on the lens); this animation shows three photos, but if the animation could be made with thirty photos, and the mud spots would still appear identical.

 

 

In Apollo 16, on photos AS16-107-17441 and AS16-107-17442, we see a fork near the lem's foot.

On the first photo, we can see that the fork's teeth are out of the ground, which means that the fork can't stand up if it isn't sustained.

On the second photo, we see that there is a triangle to sustain the fork, but the string of the triangle is not tight, which means that it doesn't sustain the fork.

We also see a bent nail which gets out of the fork: Very dangerous for the gloves of the astronauts!

 

 

I love this one: In Apollo 15, on photo AS15-88-12004 we cann see on the glass the reflection of a hand of an astronaut who takes photos of the moon.

One finger of this hand wears a ring which appears in the reflection; the only astronaut of the mission who was wearing a ring was the commander Scott, but his ring had a blue dark saphir, while the ring of the reflection appears to be brilliant!

 

And these are only just some of the many incoherences I have found.

I have many more of them, and in particular many geometrical demonstrations.

After having seen all these incoherences, it's difficult for me to have no doubt.

I kind of envy you for having no doubt at all.

[modest]

Normally, the flag should show an anti-clockwise rotation around the vertical axis on the second photo...bit it doesn't.

 

You are mistaken. Here is the video shot from the rover while the images were taken:

 

http://history.nasa.gov/alsj/a17/a17v.1182451.rm

 

The first image is taken at 0:35 and the second at 0:41. The astronaut moves roughly 1 meter parallel with the flag between shots. Assuming as a point of reference that the camera is 3 meters from the left side of the flag in the first photo then 3 meters from the right side of the flag in the second photo and the motion is parallel then one can prove via trig that the angular size of the flag will not change between shots.

 

EDIT-->

 

Let me rephrase that. Assuming that a line from the camera to the left edge of the flag to the right side makes a right angel in the first shot and a line from the camera to the right edge to the left makes a right angle for the second... trig will show no dθ...

 

<--EDIT

 

What will happen is that the left side of the flag will be proportionally larger in the first shot and the right side will be larger in the second while the overall width stays the same. I'll test this hypothesis now...

 

Yep, as expected,

 

 

The left side of the flag gets a tad bit further from the camera and the right side gets a tad bit closer to the camera between shots. The flag behaves exactly as it should.

 

Also, this is very wrong:

 

Normally, this is what we should see (or something like this):

 

 

The astronaut being photographed does not move between shots, so if the flag shrank like that while the distance between the astronaut and flagpole did not shrink in a similar fashion it would mean the flag had been rotated relative to the ground between shots.

 

This is the second claim of yours that I've checked and in both cases it was your mistaken interpretation of what you were seeing that was at fault. If you make any further allegations of inconsistencies please include a proper scientific proof so as to remove your subjective errors in interpretation. You could, for example, do a perspective projection for images that you claim don't rotate right or don't look right. Saying that something doesn't look right is not evidence and I, for one, am not interested in hand waving.

 

~modest