Community Project: NASA source code

fixed: High Level/Abstracted Source code inherently has nothing to do with hardware.

This is more accurate, and the difference could be important here due to the low level nature (from first glance) of the material.  Also, it matters on the design mentality used.  If they built it specifically for the hardware they are making, rather than properly restraining hardware specific code to a modular sort of design the hardware itself could make a huge difference.  Especially if they have custom designed parts for specific functionality to replace common programming.  Due to the design of the memory alone (again from first glance) I think we can agree this is very likely.  Sure, hardware doesn't matter *as much * in usual programming except where one accounts for it, but when its a highly specific and engineered mechanical computer designed from the ground up for a set of tasks and touched by countless folks over several years, administrations, and general design philosophies, I imagine the specifics of the hardware are extremely important and will throw us all sorts of loops.  From past history their code and mechanical design will favour clever hacks and brut coding that at times will drive us / me insane.  If you've seen the way some mathematicians or engineers that aren't programmers by training code like I have (especially in legacy code) it could be a bit like a complicated, sometimes annoying, but often rewarding puzzle game.

Of course, whether you are an expert and can read machine language or not is irrelevant; reading the machine language of a complicated program is a task beyond a reasonable timeframe and is a bit of a silly notion, even with a group of educated individuals.    Its a bit naive and uninformed to think we will be able to read the machine language itself like a book however this package is set up.  We'll likely have to come up with a few clever bruts of our own.

In fact, whatever your skillset it is irrelevant.  If you want to learn how to do this while we work on it, I'll be happy to provide training as needed and allowed by my schedule.

I'll be looking over it all later on tonight and will get back on  ideas for reasonable plan of action for any of those interested.  Just be wary, they didn't lose so many astronauts because they always followed good practice I'm sure. 

Well yes, there's going to be low level hardware interaction here, but I think the statement "source code inherently..." holds true. The famous quote about computer science and telescopes comes to mind. I guess what I want to say is: All code is tested in a simulated environment (it's not as if they launched an actual rocket for each debug run), so the distinction between simulator code and "real" code is meaningless (and it's probably mostly the exact same code). The question is, is the code correct? Could it work if applied to real hardware?

Quote from: trig on April 25, 2012, 04:02:21 PM

But unless it is accompanied by literally thousands of pages of I/O interface descriptions and thousands of diagrams, I would not even care to give my opinion on whether the code is what they say it is.

The site seems to have a pretty good documentation page:
http://www.ibiblio.org/apollo/assembly_language_manual.html

The assembly language is the least of the worries of whoever tries to make a simulator. The description of the equipment that is directly controlled by this computer and the description of the Input/Output interfaces to it are the real mind benders.

This machine or assembly language is quite specialized, having not-quite floating point operations as single instructions and highly specialized registers for the main positional parameters of the spaceship. With the explanation given the simulator of the CPU seems a very manageable project. The writing of the interpreted part of the yaYUL is more involved and time consuming.

But still the documentation of the equipment attached to this computer is something nobody in this forum has even said they might understand, much less simulate.

I don't believe in a conspiracy.  And I certainly did not invite the comment.

Oh, but you do believe in a conspiracy. Just by saying that the Moon is nothing even close to what real Science tells us you are leaving for yourself only one alternative: that NASA is lying when they say that they followed the well-known model of the Solar System and used it to put a man on the Moon.

Every engineer, physician, mechanic or specialist who heard how the spoken answers of the astronauts came about two or three seconds after the the end of the question, just to mention one specific detail, was either lied to or lied when talking about that. Every single live filming of the astronauts in different moments of the journey, where the time between the sent messages and the answers corresponded to the supposed distance of the ship from Earth was either staged or real. If it was real, the ship was hundreds of times further away than every FE model predicts. If it was staged, there was a conspiracy.

From the men who calculated the fuel, to the men who calculated the food, oxygen and water, to the men who designed the zero-gravity toilet facilities, not to mention those who calculated the expected orbits, temperatures and other critical mission parameters, every one of them is either a total liar, the victim of a conspiracy or a scientist who helped in a real mission from the real, round Earth to a real, round Moon.

You cannot just say "I do not believe in a Conspiracy, go harass  others about the Conspiracy". If you want to claim that the Earth is flat, you also have to explain what other FE'ers attribute to the Conspiracy.

Calm down, Trig.  This thread isn't so much about debating the conspiracy as it is about peer reviewing some of the technology allegedly used by the conspiracy.

...Oh, but you do believe in a conspiracy. Just by saying that the Moon is nothing even close to what real Science tells us you are leaving for yourself only one alternative...

There are more things in heaven and earth, Trig, than are dreamt of in your philosophy.   You make a string of wild assumptions and false dilemas without evidence or reason and use them as some sort of warrant for your thinly veiled and impotent attacks.  Don't tell me what I believe.  You have neither the right nor the sense to make such calls.   All this and, as markjo points out, this is neither the time nor place for this childish behavior.

Well yes, there's going to be low level hardware interaction here, but I think the statement "source code inherently..." holds true. The famous quote about computer science and telescopes comes to mind. I guess what I want to say is: All code is tested in a simulated environment (it's not as if they launched an actual rocket for each debug run), so the distinction between simulator code and "real" code is meaningless (and it's probably mostly the exact same code). The question is, is the code correct? Could it work if applied to real hardware?

Good point and I totally missed it.  Thanks.   

However, I imagine the technical information concerning the mechanics are important.  In reality though, if the assembly language was properly documented and described, then I don't see the issue.  I am doubtful it is completely documented however.

Instead of making a Virtual CPU simulate all the code, it could be easy to make an actual CPU, with all I/O and we would not have to simulate nothing: just ctrl+c, ctrl+v, and some translating work. And we could use the data gathered by NASA to directly run the machine