Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.space.policy > #56960 > unrolled thread

Apollo 11 source code released

Back to article view | Back to sci.space.policy

Contents

  Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-10 12:43 -0400
    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 20:33 +0300
      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-10 18:28 -0400
        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-10 21:27 -0400
        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-11 00:36 -0700
          Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 06:44 -0400
            Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-11 16:20 +0300
              Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 20:53 -0400
                Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-12 14:36 -0400
                  Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 18:11 -0700
                Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 23:37 +0300
                  Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 18:14 -0700
                    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:01 +0300
                      Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-13 20:06 -0700
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-14 06:44 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 23:54 +0300
                            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 11:49 -0400
                              Re: Apollo 11 source code released William Mook <mokmedical@gmail.com> - 2016-07-17 18:41 -0700
                              Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-18 09:20 +0300
                        Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:38 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-16 00:10 +0300
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 22:26 +0300
                          Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-20 10:49 -0700
                Re: Apollo 11 source code released Snidely <snidely.too@gmail.com> - 2016-07-14 09:12 -0700
            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-11 11:51 -0400
              Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 02:19 +0300
                Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 20:58 -0400
                  Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 09:24 +0300
                    Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 10:10 -0700
                      Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:07 +0300
                        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-13 20:08 -0700
                      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:25 -0400
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 22:39 +0300
                        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-20 10:40 -0700
                  Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-12 14:41 -0400
                    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 23:26 +0300
                    Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-12 21:41 -0400
                      Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 08:54 +0300
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-13 06:43 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:08 +0300
                      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:34 -0400
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 23:06 +0300
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-15 19:48 -0400
                          Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-15 19:59 -0400
                            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 12:00 -0400
                              Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-17 12:14 -0400
                                Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 12:56 -0400
                Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 10:04 -0700
              Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 09:43 -0700
            Re: Apollo 11 source code released Alain Fournier <alain245@videotron.ca> - 2016-07-11 19:43 -0400
    Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-10 11:39 -0700
    Re: Apollo 11 source code released William Mook <mokmedical@gmail.com> - 2016-07-11 18:28 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#57026

On 2016-07-12 21:41, Jeff Findley wrote:

> Actually, I see this all the time in C++ when you define a pure virtual 
> interface function in a base class (A) and then have the same 
> implementation for two derived classes (B and C).  For the names given 
> in parenthesis, when debugging, the debugger will only show the 
> implementation of that function for B even when called on an object of 
> type C.  Dead giveaway that the linker has discarded the duplicate 
> implementation. 


Such obtimizatiosn are done by the compiler, not the linker. And in a
object oriented language, the compiler does all the stuff to convert the
"object" stuff into procedural code, ( which subroutine to call when you
invoke a method etc).  And when the compiler realises that subroutine X
is never called, it doesn't include it in the obvect module because it
is optimized away.

If you compile with a switch to "do not optimize" you will see your code
much more clearly.

In this context, assembly language is not optimized (generally). There
may be macros that are expanded into multiple assembly instructions, but
that is the extent of changes done by the assembler.

There is an exception: the VAX "MACRO" assembly language was implemented
as a compiled language on Alpha and Itanium (and soon x86). As such, the
 VAX instructions are sent through optimization during compilation (the
GEM phase of compilation). This is especially true of the Itanium thing
since the chip was very inefficient and required compilers to re-arange
stuff.

Of course, back in the 60s, this didn't happen much. And in the specific
case of th Apollo software, I reckon they did not want any such
optimizations. When they ran the assembler, it wasn't to produce a
binary object file, it was to produce a opcode"/operand listing that the
people doing the hard wiring could use to know how to wire the "rope"
memory.

[toc] | [prev] | [next] | [standalone]

#57032

On 16-07-14 18:34 , JF Mezei wrote:

> And in the specific
> case of the Apollo software, I reckon they did not want any such
> optimizations. When they ran the assembler, it wasn't to produce a
> binary object file,

I am pretty sure that the AGC SW developers tested their SW on AGC 
simulators before the SW was committed to rope memory. Those SW 
simulators would naturally read a binary object file produced by the 
assembler.

> it was to produce a opcode"/operand listing that the
> people doing the hard wiring could use to know how to wire the "rope"
> memory.

The film "Computer for Apollo" linked from the Wikipedia AGC entry at 
https://www.youtube.com/watch?v=YIBhPsyYCiM, shows (at around 22:15 into 
the film) that the rope wiring was semi-automatic: a machine read a 
paper tape and then moved an aperture (a small metal ring) to the place 
on the core-rope board where the wire should enter a core. The person 
working the machine passed the wire through the aperture, the paper tape 
advanced, and the aperture moved to the next wire-entry point. The 
wiring pattern determined the 0's and 1's of the stored program, and the 
paper tape determined the wiring pattern, so the paper tape was IMO 
equivalent to a binary object file, although differently encoded.

(The engineers in the film refer to the wiring staff -- adult women -- 
as "girls". "The girl will then pass the wire..." Weird to hear, today.)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#57035

In article <5787b105$0$34695$c3e8da3$dbd57e7@news.astraweb.com>, 
jfmezei.spamnot@vaxination.ca says...
> 
> On 2016-07-12 21:41, Jeff Findley wrote:
> 
> > Actually, I see this all the time in C++ when you define a pure virtual 
> > interface function in a base class (A) and then have the same 
> > implementation for two derived classes (B and C).  For the names given 
> > in parenthesis, when debugging, the debugger will only show the 
> > implementation of that function for B even when called on an object of 
> > type C.  Dead giveaway that the linker has discarded the duplicate 
> > implementation. 
> 
> 
> Such obtimizatiosn are done by the compiler, not the linker. And in a
> object oriented language, the compiler does all the stuff to convert the
> "object" stuff into procedural code, ( which subroutine to call when you
> invoke a method etc).  And when the compiler realises that subroutine X
> is never called, it doesn't include it in the obvect module because it
> is optimized away.

How could this possibly be done in the compiler when the code I'm 
talking about is written such that each class has its own .cxx file 
which is compiled *separately* into individual object files?

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#57036

In article <MPG.31f340409b99778c9897a1@news.eternal-september.org>, 
jfindley@cinci.nospam.rr.com says...
> 
> In article <5787b105$0$34695$c3e8da3$dbd57e7@news.astraweb.com>, 
> jfmezei.spamnot@vaxination.ca says...
> > 
> > On 2016-07-12 21:41, Jeff Findley wrote:
> > 
> > > Actually, I see this all the time in C++ when you define a pure virtual 
> > > interface function in a base class (A) and then have the same 
> > > implementation for two derived classes (B and C).  For the names given 
> > > in parenthesis, when debugging, the debugger will only show the 
> > > implementation of that function for B even when called on an object of 
> > > type C.  Dead giveaway that the linker has discarded the duplicate 
> > > implementation. 
> > 
> > 
> > Such obtimizatiosn are done by the compiler, not the linker. And in a
> > object oriented language, the compiler does all the stuff to convert the
> > "object" stuff into procedural code, ( which subroutine to call when you
> > invoke a method etc).  And when the compiler realises that subroutine X
> > is never called, it doesn't include it in the obvect module because it
> > is optimized away.
> 
> How could this possibly be done in the compiler when the code I'm 
> talking about is written such that each class has its own .cxx file 
> which is compiled *separately* into individual object files?

Microsoft explains exactly what I'm talking about.  The linker 
(necessarily) does this optimization.  

Why does the debugger show me the wrong function?
https://blogs.msdn.microsoft.com/oldnewthing/20050322-00/?p=36113

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#57039

On 2016-07-15 19:59, Jeff Findley wrote:

>> How could this possibly be done in the compiler when the code I'm 
>> talking about is written such that each class has its own .cxx file 
>> which is compiled *separately* into individual object files?
> 
> Microsoft explains exactly what I'm talking about.  The linker 
> (necessarily) does this optimization. 


As objects are hiearchical and inherit capabilities from their parent,
it is quite possible to have a chair call a method "paint chair" and a
table call "paint table". But as those inherit that capability from
their parent "furniture".  The compiler would ask the linker to resolve
"paint furniture"  for each of those 2 calls to different routine names
in the source code.

C++ and other object oriented stuff is many many layers above assembly
language where memory allocation and branchig and returning to
subroutines is very explicit.

[toc] | [prev] | [next] | [standalone]

#57040

In article <578bab93$0$51821$c3e8da3$f6268168@news.astraweb.com>, 
jfmezei.spamnot@vaxination.ca says...
> 
> On 2016-07-15 19:59, Jeff Findley wrote:
> 
> >> How could this possibly be done in the compiler when the code I'm 
> >> talking about is written such that each class has its own .cxx file 
> >> which is compiled *separately* into individual object files?
> > 
> > Microsoft explains exactly what I'm talking about.  The linker 
> > (necessarily) does this optimization. 
> 
> 
> As objects are hiearchical and inherit capabilities from their parent,
> it is quite possible to have a chair call a method "paint chair" and a
> table call "paint table". But as those inherit that capability from
> their parent "furniture".  The compiler would ask the linker to resolve
> "paint furniture"  for each of those 2 calls to different routine names
> in the source code.
> 
> C++ and other object oriented stuff is many many layers above assembly
> language where memory allocation and branchig and returning to
> subroutines is very explicit.

I've been working with C++ for the last 20 years and hold a job title 
commensurate with my 26 years of experience as a software developer.  I 
don't need to be told how C++ works as I use it every single day as part 
of my job.

You, however, ignored my original example completely, have snipped the 
link to Microsoft's explanation that I provided, and substituted an 
example that is not at all like the one I first gave.  

There is no further purpose to engaging you in this thread as you are 
being evasive, obtuse, or perhaps both.  

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#57041

On 2016-07-17 12:14, Jeff Findley wrote:

> You, however, ignored my original example completely, have snipped the 
> link to Microsoft's explanation that I provided, and substituted an 
> example that is not at all like the one I first gave.  

No. I dodn't ignored. The way I interpreted it was that the linker was
given task to resolve 2 routines which end up pointing to the same routine.

Also remember that the question on MS's web page was about the debugger.
 If, at run-time,  the debugger displays code for "routine2" when you
step into routine1 means that the COMPILER inserted debugging
instructions in the object module for the debugger run time to display
the roioginal source code associated with the next instruction. So it is
the compiler that would have realised that routine1 and routine2 would
have been identical and the compiler would have opptimized one of the 2
away.

I don't trust Microsoft to ever use the proper terminology and
standards. And in an integrated developper suite, the the line between
compiler, linker and run time debugger are muddled whereas prior to
Microsoft, there were very clear roles for each.

Note that optimizations of code is now done by the compiler, followed by
opti9mizations for platform done by GEM. (compilers now generate pseudo
code and the GEM back end generates platform specific object code with
architecture specific optimizations (pipelining, out of order execution
etc).

This is why normally, when you compile with the /debug option, you also
want /nooptimize in order to have the execution reflect what you wrote.

[toc] | [prev] | [next] | [standalone]

#56996

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

>On 16-07-11 18:51 , JF Mezei wrote:
>> On 2016-07-11 06:44, Jeff Findley wrote:
>>> much on a C-64 using a "higher level language" due to the overhead of
>>> incurred.  Even in the 1980's, compilers, optimizers, and linkers
>>> delivered code which was very "bloated".  The 1960's would have been
>>> far, far, worse.
>
>How might a 1980's or 1960's linker deliver "bloated code"? In those 
>days, linkers merely arranged given modules of code in memory and 
>corrected accordingly the cross-references from one module to another; 
>linkers did not generate or modify code in other ways.
>

Think RTOS and RTL inclusion in the link...

-- 
"The reasonable man adapts himself to the world; the unreasonable 
 man persists in trying to adapt the world to himself. Therefore, 
 all progress depends on the unreasonable man."
                                      --George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#56993

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

>On 2016-07-11 06:44, Jeff Findley wrote:
>> much on a C-64 using a "higher level language" due to the overhead of 
>> incurred.  Even in the 1980's, compilers, optimizers, and linkers 
>> delivered code which was very "bloated".  The 1960's would have been 
>> far, far, worse.
>>
>
>Not quite. older languages such as COBOL and Fortran provided reasonably
>efficient assembly.
>

For some definition of "reasonably efficient" that equates to 'bloated
when compared to pure assembly'.

<snip irrelevancies>

>
>Note: today, things are different because compilers are smart enough to
>organise code to make use of various capabilities for the architecture
>(pipelining, out of order execution, multiple execution units,
>pre-fetching, branch prediction etc).
>

Some are, some aren't.  You realize there are still people who write
assembly for good reason, right?

>
>(However, stuff like object oriented langiuages have so many layers of
>bloat that optimization at the machine dode level still leaves it bloated).
>

So in your view compilers are very clever, but not very clever?

>
>If I read correctly, the read-only "rope" memory that contained the
>programs had to manually be connected to represent the right bits. This
>makes it much easier to work with assembly language since the "compiled"
>code with the opcodes/operands in bits can more easily be matched to the
>original source code.
>

What?


-- 
"Ordinarily he is insane. But he has lucid moments when he is
 only stupid."
                            -- Heinrich Heine 

[toc] | [prev] | [next] | [standalone]

#56986

Le Jul/11/2016 à 6:44 AM, Jeff Findley a écrit :
> In article <p2j6obt05vvmbg0i08afngatpmurap66e6@4ax.com>,
> fjmccall@gmail.com says...
>>
>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>
>>> On 2016-07-10 13:33, Niklas Holsti wrote:
>>>
>>>> A custom-made computer:
>>>>
>>>> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
>>>
>>>
>>> Very interesting read. Thanks.  It mentions it was the first computer
>>> made of integrated circuits. Looks like it was all fixed decimal
>>> notation as opposed to floating point. That would have a big impact on
>>> the heavy math done for guidance and navigation (lots of angles/trig etc).
>>>
>>> Was all the code written in assembler or were portions done in higher
>>> level languages ?
>>>
>>
>> No HOL.  Have you looked at the specifications for these things?
>
> The Wikipedia entry clearly says this, "AGC software was written in AGC
> assembly language and stored on rope memory."
>
> By modern standards, we really don't have much to compare with.  Going
> back to the 1980's, the AGC was about twice the speed of my old C-64 but
> with only a tiny fraction of the RAM and a lot more more ROM (since
> there was no other place for program storage like tape or disk).
>
> Putting it in that perspective, the C-64 programs written commercially
> rarely used languages above assembly language.  You just could not do
> much on a C-64 using a "higher level language" due to the overhead of
> incurred.

No, that would be under using the C-64. The 64 in C-64 standed for 64 
kilobytes. But that was a little bit of a misnomer. You had 80 kilobytes 
of memory. The 64 kb of RAM but also 16 kb of ROM. You had to switch the 
16 kb of ROM/RAM to access one or the other. You could save some 
precious RAM by using the basic interpreter in the 16 kb of ROM. If I 
recall correctly it was a bit on byte number 1 that would be used as a 
switch to access the ROM or the underlying RAM. I wrote a program that 
could not have fit in 64 kb of RAM, but could be squeezed into the C-64 
by switching between the two memory modes. Even then, I had a hard time 
making it fit into the memory space. I had to cleverly chose where some 
parts of the program were placed in order to have an assembler jump 
instruction (a goto if you prefer) at the end of a section of code have 
just the right jump address so the next section of code could start with 
the last byte of the jump address.
So that was three bytes for the jump instruction, the jump instruction 
was one byte and the address where to jump two bytes, therefore it was
jumpto byte1byte2. But the next section of code started with an 
instruction, I think it was load into registry, but the important point 
is that this instruction's binary code was equal to the byte2 of the 
jump instruction, so byte2 was used both as an address where to jump and 
as an instruction. It took me a month to figure out how to do it but 
that single saved byte allowed me to fit my program in the 80 kb of the 
C-64.
Now that I use a computer with 24 Tera-bytes of RAM, I no longer work as 
hard to save a single byte.


Alain Fournier

[toc] | [prev] | [next] | [standalone]

#56966

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

>
>The source code for many Apollo 11 computers has been released n digital
>form on GitHub. (scanned from printed listings at MIT).
>
>https://github.com/chrislgarry/Apollo-11
>
>
>Question: what computer architecture/instruction set was used for the on
>board computers ?
>

Custom.


-- 
"The reasonable man adapts himself to the world; the unreasonable 
 man persists in trying to adapt the world to himself. Therefore, 
 all progress depends on the unreasonable man."
                                      --George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#56989

On Monday, July 11, 2016 at 4:43:37 AM UTC+12, JF Mezei wrote:
> The source code for many Apollo 11 computers has been released n digital
> form on GitHub. (scanned from printed listings at MIT).
> 
> https://github.com/chrislgarry/Apollo-11
> 
> 
> Question: what computer architecture/instruction set was used for the on
> board computers ?

https://www.youtube.com/watch?v=YIBhPsyYCiM
https://www.youtube.com/watch?v=xQ1O0XR_cA0

Vibrating structure gyros are cheaper and better than Apollo had

http://www.siliconsensing.com/technology/mems-gyroscopes/

So are the computers

https://www.youtube.com/watch?v=gu0Y4vliJcQ

So, its no surprise you could build an AGC for $3,000 in your basement these days

http://gizmodo.com/5319472/how-to-build-the-1mhz-apollo-guidance-computer-for-just-3000

http://www.galaxiki.org/web/main/_blog/all/build-your-own-nasa-apollo-landing-computer-no-kidding.shtml

You can even run an AGC simulator;

http://svtsim.com/moonjs/agc.html

Now, all you need are the checklists - and current ephemeris of the moon, and your precise launch coordinates - and you could launch a Saturn V to the moon and land!  

Now, if you take the checklists, and automate them, and then use KEYWORDS to access them in some logical way, you could use a Siri style app that talks to you, and navigates like a mobile map app;

http://www.wired.com/2014/04/out-in-the-open-jasper/

and goes where you want...generating the code to enter for the checklist.  

All using GPS and current time, along with the moon position, available via the internet, you could launch a Saturn V from anywhere on Earth to the Moon!  

lol.

http://www.mooncalc.org/#/49.495,11.073,5/2016.07.12/12:41/1

Of course, very good simulators exist - that are very instructive as well;

https://www.youtube.com/watch?v=fF4zTkLqHfc

http://www.apolloarchive.com/lander.html

http://eaglelander3d.com

Compare to the NASA simulators;

http://history.nasa.gov/computers/Ch9-2.html

Now, there is a homebuilt 737 that's awesome;

https://www.youtube.com/watch?v=cSiZ3_jy-1w&list=PLE28AAB2EC4DA45EE

I can imagine someone doing a full scale replica of the flight decks of both the Apollo Command module and the Lunar Excursion Module to the same fidelity.

Here's Michael Collins in a simulator

http://inapcache.boston.com/universal/site_graphics/blogs/bigpicture/apollo_07_15/a06_S6938317.jpg

Here's the CM and LEM simulators

https://upload.wikimedia.org/wikipedia/commons/a/a4/Apollo-lunar-simulator.jpg

So, you get in the CM and go through the launch sequence - and the CM and LEM are each on their own six-axis robot arms - like a Fanuc M-2000

http://www.fanuc.eu/bg/en/robots/robot-filter-page/m-2000-series

inside a digital planetarium similar to this Digitalis system

http://www.digitaliseducation.com

The Digitarium is $46,000 - the Fanuc M-2000 is $121,000.    The cost of the LEM and CM interiors, faithfully reproduced, and operating seamlessly with the other equipment, about $300,000 each - 

http://www.finesportscars.com/finesportscars_i2/cus_car.jpg

So, for about $890,000 - one could build a live action Apollo simulator in about a year.


The way it would work in Earth's one gee field, is you would enter the CM and lie on your back through the launch.  The robot arm would shake and toss you to simulate staging as it tilted you to a heads up position moving the CM to the center of the dome.  The digital representation outside the window would paint a scene of the SIVB and LEM as the LEM Adapter appeared to float away.  As the CM was moved by the robot arm toward the digital image, another robot arm would move a LEM into docking position beneath the full scale projection.  

As these building videos show, if you know the properties of the surface you're projecting on, you can compensate and produce amazing effects.   

https://www.youtube.com/watch?v=YADbPYJNGOg

So, it would be child's play to project an image of the LEM onto a LEM cabin simulator, so that as you docked with it, the cabin would connect with the CM.

Crew members would then be able to crawl through the tunnel, and into the LEM - on their backs in the LEM as shown in the simulator photo.  

The LEM cabin would then be rotated to a stand up position as the CM floated beyond the dome to its tart position.  In the end the LEM cabin would be placed atop a fixed descent module simulation sitting in a simulated lunar surface beneath the digitarium dome.  

The robot arms simulate vibration in synchrony with the sound tracks and digital projections during firing of the descent engine - to give a sense of the flight.  Participants climb out of the lander on to the lunar surface. 

The process is reversed to return to Earth with the CM being lowered into a pool of water beneath a dome with the ocean and sky projected on to it.  

Discounted at 8.5% per annum, over a ten year period, $890,000 costs $15.74 per hour.  For two people, that's $8.00 per person per hour.  A 42 minute ride - assuming the vehicle is open 24/7.  If open only 42 hours per week, the CAPEX is $32.00 per person - assuming a crew of two.  Another $8 per hour - or $4 per person - or $16.00 per person - for OPEX.  So, say a 42 minute ride - is $50.00 - and for another $25.00 you can have a video made - and for another $25.00 you can enjoy astronaut food.  There's also a video arcade and a restaurant and gift shop - built around the moon museum.  

  

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | sci.space.policy

csiph-web