Merge changes with upstream VirtualAGC about apollo-11 HOT 24 OPEN

Thanks. If you know what is missing, mind submitting a PR?

from apollo-11.

@ohommes @corvuscrypto first, thanks for sharing your thoughts and the effort you guys put. Very much appreciated. I created this repo two years ago when I saw the original Apollo 11 source online bundled with Virtual AGC. I wanted the original Apollo 11 source just for viewing, so I extracted it and uploaded it to a repo for myself. Recently, somebody found my repo and shared it online, and here we are. Although Virtual AGC is awesome, I never was and am still not interested in Virtual AGC here in this repo. I am interested in the original Apollo 11 source only. I didn't know about the Virtual AGC repo until the other day when Ron shared the link with me and candidly stated "It probably would have helped if I had actually included this information on my website rather than keeping it to myself. :-)." This repo was meant to be for my own interest, but here we are, and now I am doing my best to maintain it as a repo for simply viewing the code. The community has already cleaned up a bunch of typos from digitization, and I suspect a lot more work in that area. We may get it to the point where it is truly reflective of the hard copies, which is my goal. The rekindled interest is tremendous, and I want to keep that going. Such a historical artifact as this deserves it's own repo without all the extras to build it in a VM, and I'm very appreciative of all the hard work that went into digitization, and is still going into it right now.

from apollo-11.

It is crucial to split out the code for the Command Module and the Lunar Module. I have worked closely with Ron Burkey and many others in the world to transcribe the source code for the 40th anniversary of the lunar landing for Apollo 11 over a period of many weeks. Without thinking to much about the source code build names; for the Command Module (CM) the names are starting with a "C" (e.g. Colossus238 and Comanche055 ) and the Lunar Module (LM) started with "L" (e.g. Luminary). There are however many exceptions to this Like Artemis and Sundance, Sundial and Sunburst but having the code split is a must. There are MANY difference crucial for the landing versus the orbit only and reentry for the CM. The original source listings that we made available on sourcecode.google.com and at biblio had these significant distinctions. Combining them in one location does not even make them compile anymore with yaYUL from Ron Burkey. Hope to see this fixed soon.

from apollo-11.

I don't know how you want to organize things, but separating the code for Comanche055 and Luminary099 would be a good start. I very much doubt that any of the identically named files of the two AGC versions are completely identical, so I guess you'll want to go through all the files that you didn't copy to this repository because they were already there (from the other AGC version).

from apollo-11.

Given that we haven't really edited any of this AGC source in a long
time, I'd venture to say that if you continue to make headway on this,
then it will simply be easier for me to replace the files in my source
tree with yours, or otherwise merge them in ... eventually. In other
words, I think any effort to set me individual up-to-the-minute changes
in the interim is probably wasted.

Fortunately, we have the touchstone of always being able to assemble the
source code and verify that the binary is 100% correct (or at least
identical), so merging should be a relatively safe operation.

-- Ron Burkey

On 07/11/2016 02:13 PM, oznogon wrote:

@chrislgarry https://github.com/chrislgarry @ohommes
https://github.com/ohommes It would still be nice to find a way for
the corrections against this repo to make their way "upstream" to
rburkey2005/virtualagc, or to @rburkey2005
https://github.com/rburkey2005 directly per the transcription
project's comment proofing instructions
http://www.ibiblio.org/apollo/volunteer.html#Proofing_of_comments_in_source-code.

1.

    You don't need any special assignment from me. I have no
    better idea as to where there may be bugs in program comments
    than you; they could be anywhere, in any source file; nor is
    there any team working on this problem in a fashion that needs
    coordination. However, the more times that a source file has
    been proofed, the less likely that you'll find errors in it.
    So simply choose an AGC source file whose modification history
    (in the header of the file) doesn't indicate that it has
    already had its comments proofed, or has been proofed less
    than other source files.

2.

    Download or examine online the assembly listing for the same
    AGC spacecraft/mission/version. (I'd recommend looking at it
    online, but you're free to do it however you like.)

3.

    Edit the file header "mod history" to show that you are
    comment-proofing the file. (See the pictures in the
    code-conversion section above.) Note: Source code is 7-bit
    ASCII only! If you use a Unicode-enabled editor, you will
    produce something that looks fine, but which will be a big
    mess for me to use, since I will have to seek out and destroy
    all of the Unicode characters you have inadvertantly added.
    This has proven to be a particular problem when people use
    Macs. If you are using a Mac and you are not certain that you
    can completely disable Unicode editing, it is perhaps best if
    you don't participate in this particular activity.

4.

    Compare the source file line-by-line against the scanned file,
    making changes where necessary. Step 6 in the
    "code-conversion" section above gives a lot of hints as to how
    to do this effectively.

5.

    *Important note:* If you find a comments which needs to be
    corrected, it is very likely that the same mistake exists in
    source-code files for other spacecraft or other missions. For
    example, suppose you are working on proofing INTERPRETER.s for
    Luminary131. There is also an INTERPRETER.s for Luminary099,
    Colossus249, Comanche055, etc. So if you correct all of these
    files, then you are multiplying the effectiveness of the
    proofing you are doing. But remember that the comments may
    actually have changed in the page images, so you can't blindly
    assume that a fix is necessarily applicable to a different AGC
    version unless you examine the page images for that AGC
    version as well.

6.

    Email the new source files you've created directly to me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#38 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ALSveMqykwZ4JAJJpy8ppRV9RVt9QGIMks5qUpXpgaJpZM4JIsP_.

from apollo-11.

Had the same idea as @indy91. submitted a PR with folder organization as per the original source listings. PR: #73

from apollo-11.

For sure I support that setup by original build-name. I worked on the transcription painstakingly with many others to support the 40th anniversary of the Moon Landings.

In 2009, the year of the 40th anniversary of Apollo 11, a size-able group of Apollo enthusiast from all across the world transcribed both Comanche055 and Luminary099 from pictures taken of each page.

This process started by Ron Burkey, who travelled to make photographs of each page of the code on site since we could not take the actual hardcopy. Then a process started where each individual of this project checked out a block of pages and transcribed the assemble code with comments. The images contained both the binary code and the assembly mnemonics with comments.

Once transcribed the process of verification started:

• The first pass was to compile the code with yaYUL from Ron Burkey. The binary code was then verified agains the binary code on the printout.
• The second stage was visual re-inspection for the comments.
• The third stage was the verification of the memory bank which was done by running the actual code in yaAGC and by running the original Checksum verification program with Verb 91 (V91E) the checksum (including the so called bugger word) if correct is the same value as the bank number. I think it would be interesting for people to know these verification steps and how this process took many weeks with the deadline of the 40th anniversay of Apollo 11.

from apollo-11.

@rburkey2005 sounds good to me. I have a ton of fixes to go through so I can let you know when this reaches a steady state.

from apollo-11.

Btw why is this re-uploaded on github. It has been placed here by Ron Burkey ever since Google Code went bye bye: https://github.com/rburkey2005/virtualagc

from apollo-11.

It would be really cool for all of us that know nothing of this style of programming, if there was a basic README or Wiki instructions on how to compile and run and what tools to do so.

Thanks for all the effort! Very interesting! 👍 🚀

from apollo-11.

@chrislgarry @rburkey2005 Well, the fact that the source's license is "public domain" somewhat complicates things. As you know, the phrase "public domain" is legally tricky as some countries do not even recognize that it means "no copyright at all." As we have not taken any CLA from contributors, it is difficult to determine whether or not the contributors wished to ultimately be attributed for their works beyond the Git history, as the entirety of the source is in the public domain. The only copyright that could be claimed is "sweat of the brow" - i.e. credit contributors by their transcription efforts, not by the text itself.

However, as the original source code is in the public domain and there are way too many contributors in this transcription effort (past, present, and future), crediting "the efforts made by the contributors of https://github.com/chrislgarry/Apollo-11" would be very nice, but legally speaking not necessary, since the phrase "public domain" means in this case that no one is entitled to receive credit for this work.

I believe it's safe to merge, but you should expect another merge every 6 months or so, as we're only done with 27% of Comanche055 (per milestone). (I was wondering how much code Comanche and Luminary shared in common, which would deduplicate the typo fixing efforts, but I haven't come to a conclusive answer yet.)

from apollo-11.

Updated title as original title has long since been addressed (giving the impression we are still lacking Apollo 11 code) and the actual discussion was unrelated and the reason why the issue is open.

from apollo-11.

Updated title as original title has long since been addressed (giving the impression we are still lacking Apollo 11 code) and the actual discussion was unrelated and the reason why the issue is open.

This really has just become a meta issue. Let me know what you think.

from apollo-11.

For context:

• ibiblio organizes the HTML transcriptions and page scans into directories by project/build (apollo/listings/Luminary099).
• rburkey2005/virtualagc organizes them into directories by project/build (Luminary099)

from apollo-11.

Well like I said I have a pr open for exactly this using the described format that's been mentioned several times so everything should be cherry then :). Also the main program loop will still compile you just need to change the file endings in the include list to .s. it will just be boring since all it will do is wait for jobs :P

from apollo-11.

Huh. I knew of the work but never knew that all the source was available already on GH. This is a good point. Though perhaps the owner wants this to be more of a playground? Either way after seeing that I agree that a fork from Ron would be more appropriate regardless

from apollo-11.

@corvuscrypto thanks a lot!

from apollo-11.

@chrislgarry @ohommes It would still be nice to find a way for the corrections against this repo to make their way "upstream" to rburkey2005/virtualagc, or to @rburkey2005 directly per the transcription project's comment proofing instructions.

1. You don't need any special assignment from me. I have no better idea as to where there may be bugs in program comments than you; they could be anywhere, in any source file; nor is there any team working on this problem in a fashion that needs coordination. However, the more times that a source file has been proofed, the less likely that you'll find errors in it. So simply choose an AGC source file whose modification history (in the header of the file) doesn't indicate that it has already had its comments proofed, or has been proofed less than other source files.
2. Download or examine online the assembly listing for the same AGC spacecraft/mission/version. (I'd recommend looking at it online, but you're free to do it however you like.)
3. Edit the file header "mod history" to show that you are comment-proofing the file. (See the pictures in the code-conversion section above.) Note: Source code is 7-bit ASCII only! If you use a Unicode-enabled editor, you will produce something that looks fine, but which will be a big mess for me to use, since I will have to seek out and destroy all of the Unicode characters you have inadvertantly added. This has proven to be a particular problem when people use Macs. If you are using a Mac and you are not certain that you can completely disable Unicode editing, it is perhaps best if you don't participate in this particular activity.
4. Compare the source file line-by-line against the scanned file, making changes where necessary. Step 6 in the "code-conversion" section above gives a lot of hints as to how to do this effectively.
5. Important note: If you find a comments which needs to be corrected, it is very likely that the same mistake exists in source-code files for other spacecraft or other missions. For example, suppose you are working on proofing INTERPRETER.s for Luminary131. There is also an INTERPRETER.s for Luminary099, Colossus249, Comanche055, etc. So if you correct all of these files, then you are multiplying the effectiveness of the proofing you are doing. But remember that the comments may actually have changed in the page images, so you can't blindly assume that a fix is necessarily applicable to a different AGC version unless you examine the page images for that AGC version as well.
6. Email the new source files you've created directly to me.

from apollo-11.

To compile the original code, use the yaYUL compiler see http://www.ibiblio.org/apollo/yaYUL.html
The original compiler was called YUL it was named for it being ready for xmas: Yuletide. Nice xmas gift.

If you want a good programmers reference manual then use the book below. It is well written and teaches you the AGC assembler. But for all the detailed stuff, checklists and operations there is really nothing better than what Ron has collected over the years. His continued effort has create the single source for all that is AGC and more.

https://www.amazon.com/Apollo-Guidance-Computer-Architecture-Operation/dp/1441908765?ie=UTF8&ref_=cm_cr_arp_d_product_top

from apollo-11.

@bluengreen if you'd like to compile, I recommend checking out virtual agc. I will add a link to the README so anyone interested in something beyond viewing will know where to look. Thanks.

from apollo-11.

Regarding my earlier comment that eventually we'd like to merge the corrections you guys have come up with back into Virtual AGC ... I don't really know what the difficulty level of doing that is, or what the mechanics of it are, but I've glanced over some of your files and no obvious problem with merging it jumped out. I was wondering what your thoughts on the subject were: Is it getting close to being a propitious time, or would it be wiser to give it X amount of extra time (where X is some value TBD)?

Not that we'd necessarily merge it right this instant anyway, since I have to consult with my guys about how to go about it, we have to verify that it still assembles properly, and so on, but I'm just trying to get some idea of where we're at with it.

I'm also a little concerned with how to credit the folks to have done the work, since the only way to deduce that seems to be from the commit-logs (and not from comments embedded in the code as we have done), and I'm not sure how many of those commit-message can survive the merge process. Of course, not everyone is as fanatical about being credited as I am with crediting people, so perhaps that's not an issue.

Thoughts?

from apollo-11.

@rburkey2005 This is essentially an open source project now, and therefore accreditation is implicit in their activity in this repo as with most OSS. Perhaps you can simply make a note/link that you have integrated work from this repository. @wopian @oldmud0 thoughts? So far we have closed 41 issues related to enhancements/corrections.

from apollo-11.

If the git trees are merged, all the contributions from either side would remain.

from apollo-11.

@wopian are you referring to --allow-unrelated-histories flag? Would that interleave our two histories? If it doesnt interfere with them reviewing their own history and tracking down changes internally within the VirtualAGC project, this is a good idea. Otherwise, it could add noise to their project with little benefit.

from apollo-11.