Apollo 12 Source Code: Looking at the original flown code printout, and the 1202 error fix
Vložit
- čas přidán 19. 06. 2024
- Mike Stewart recently acquired an original source code listing of Apollo 12, that he had been working on for years. In this longish video, he gives us a glimpse of what's inside, including the software fix for the infamous 1202 errors that had plagued the Apollo 11 landing.
0:00 How we got the Apollo listings
2:45 How to read the assembly listings
16:50 Landing on the Moon with the P66 program
18:15 1202 error fix code added after Apollo 11
24:27 Version control in the 1960's
The scan of the listing has been made available to all right here, thanks to Mike's dedication and the Internet Archive:
archive.org/details/luminary1...
The clean, hand-recovered, checked and known-to-recompile code derived from this listing is available here, also the master work of Mike Stewart:
www.ibiblio.org/apollo/listin...
Here is a link to the installation instructions of the unmodified Orbiter/NASSP software, which flies with the original code:
www.orbiter-forum.com/showthr...
Our sponsor for PCBs: www.pcbway.com
Support the team on Patreon: / curiousmarc
Buy shirts on Teespring: teespring.com/stores/curiousm...
Learn more on the companion site: www.curiousmarc.com
Contact info: czcams.com/users/curiousmarca... - Věda a technologie
Interested to know who 'Hugh B-S' was! Great content again... even *I* could program assembly with such a good environment! Today's MAP files leave a lot to be desired.
Hugh Blair-Smith. One of the pioneer programmers of the AGC who laid a foundation for the code, I believe the real-time executive and it's crash-resistant prioritized tasks which saved the mission (Mike did I get this right?). We met him at MIT, you can seem him briefly in this video: czcams.com/video/9iavKBdPo4U/video.html.
@@CuriousMarc Nope, you're thinking of Hal Laning. :) Hugh wrote the YUL assembler, and also played a large part in the design of the AGC's microcode and instruction set.
@@mikestewart8928 Oh, oops, monumental fail. Glad you are here Mike.
@@CuriousMarc 1q
@@CuriousMarc ahhh well it happens.....now crank that silly thing around !!!
My dad worked on the Apollo Guidance Computer design and software for Snoopy et al. He graduated from MIT with a degree in "automatic systems" and worked for Grumman on the LEM and the AGC and guidance system. He also was well versed in inertial navigation systems, radar, radio, computer design and programming and celestial navigation etc. Anyway, he had piles of those program folders that he would sit on his bed and pour over line by line, debugging errors one line at a time. Back then, to debug a program or analyze its performance they would run the program till they got an error, mark the line and then study that line of code to see what was causing the error. Since this was the 60's no one had a computer at home, so you had to debug line by line. And there were so many lines of code that one person couldn't debug the whole thing. So they printed up many copies and gave them to everyone to take home to debug a portion of the program. I know he had at least a half ton of those printouts stacked up floor to ceiling in his bedroom so they must have printed out hundreds of copies. And if they revised the program in anyway then all the previous versions became useless scrap paper. Of course, nowadays they are valuable historical artifacts that show the evolution of the whole programming part of Apollo. But in my day, they were just something that as a teenager I couldn't understand and something my mom complained about having to trip over in her bedroom. And yes I seem to recall there being a lot of strange comments in those printouts. Nasa even had small pins made that showed Snoopy in a space suit and helmet that they gave out to everyone working on the project.
Brasil - sério? Bacana
Did your dad wrote some lines? Do you know if Margaret Hamilton wrote all the code by herself? Because she is the one that appears in the photo with the pile of books and took al the credit alone.
@@JuliusWise I can't say for sure but I imagine that most of the comments were written by the original programmer. Usually programmers add those comments so that anyone who works on the program afterwards will understand the thinking of the original programmer. I believe what my dad was doing was debugging the original code. As I recall they would run the program on a simulator and if there was a glitch they would mark the line that caused the problem and then guys like my dad would try to figure out what was wrong with those particular lines of code. I do remember seeing the actual printouts and I believe my dad remarked about some of the amusing comments that were written by the original code writer. I do know that my dad worked on the actual design of the Apollo guidance computer hardware but I don't know for certain how involved he was in writing the actual code. I do know that he was involved in designing the overall flow
Before any code was written the hardware designers had to have a good idea of what they needed the computer to do and what systems or peripherals if you will needed to be controlled. Engineers like my dad were working on the hardware first and then trying to get a computer to control all that Hardware.
@@squidkid2 brother, am Brasil, e fico feliz em conseguir lhe entender
I am an Apollo Engineer who was the Emergency Control Rate Gyro Guy.
Mostly flight hardware .
A little programming. Linking other programs . I got to send Gyro signals to the Capsule at T minus 2 min30 sec. The highest excitement of my life!!
You obviously did a great job! What was that signal? Was that for the laser beam aligned booster IMU, or for the IMU in the G&N of the spacecraft itself?
Marc,
I was part of the IBM Guidance Navigation & Control group
.Instrument Unit. The 9 Gyros, Pitch (3); Yaw (3) and Roll (3) were no output. Until T zero. Angular Rate ( Rotation) was phi .
At Liftoff The engines were pointed to vertical Clear the Tower. The IMU and Guidance did that
My group was called Flight Control Analog. We fed the DC current to the ( 4 ) engines hydraulics. Can you believe Milliamps.
Summary: the Gyros only measured Rotation
I must close Marc.
Too lengthy
@@keithtyler9372 Ah, booster guidance then. For the IBM LVDC computer. Thanks for the details!
Hey Marc, my EDS CRG inputs were to the guys in the Capsule. So the lights and indicators read correctly. No room for errors.
Excessive Rate meant. We are turning in the right direction but we want to ABORT. The rocket can break apart. Your decision.
It's downright criminal that this doesn't have millions of views and likes. Such an important part of computing history is being preserved and studied, here! I truly shudder to think what's going on in my modern laptop as I type this, and if its various codes and chip layouts were to be printed on paper if there is even a warehouse big enough to contain it all. YOU CAN PICK UP AND HOLD the apollo software. That is so amazing.
One of the unsung heroes of the apollo program, in my opinion, was the ranging system they used, with the Unified S-band pseudo-random codes and the FANTASTIC precision they achieved in the 60s. If you ever discover information about that system's development, it would definitely be worth pursuing!
Absolutely - so much information and history in that one printout.
For a video that has been uploaded today, it's not surprising it doesn't have "millions of views and likes" (yet). It might never get those, but that doesn't mean that there aren't lots of people that love this kind of content.
I'm doing my part!
Yeah... good luck printing out the complete CAD drawings for any modern Inte/AMD cpu... 13-something BILION transistors...
Very true. After all, real men wire wrap and real women weave!
Fascinating. I wrote a lot of assembler in 67-76. Talk about cards. We had multiple pallets of cards delivered every other week or so. And green bar paper. I just can't believe that someone held on to this printout (safely no less) for all these years. Good stuff. That young man is on his game.
My first programming experience was RATFOR, then FORTRAN using and IBM at WVU to solve aerospace engineering design, structures and fluids problems in 1968/69. So I recognize the cards, etc. in 1969 I was on my first job and moved from cards to paper tape to analyze flight test data and calibration data using FORTRAN on a HP mini computer. A year later, I designed and coded assembly language programs to simulate surface to air, air to air missiles, and radar/IR hardware and man in the loop testing in real time! This taught me so much that about architecture and computer cpu/gpu operations and algorithm development. I still have boxes of cards, program listings etc to remind me how far we have come in just 50 years.
How they achieved this in the 60s is incomprehensible. It's not like they could just write an EEPROM with their code and test it with a simulation. How they got it this bug free is insane. We talk about cutting edge now, this I feel was pushing it even further. A computer to some people in the 60s would have just sounded like a foreign language. This is such a great channel!
They ran it on simulation on much larger mainframe computers, and ran it on the real hardware thing using core rope emulators that were loaded from regular core memory. See our restoration of the core rope emulator.
@@CuriousMarc Of course, I forgot about the emulators you spent ages repairing!. I need to watch the restoration once again. Silly me.
Now we can't update an app without breaking the UI 💀
Not to mention they did it all in assembly too!
Absolutely mind-boggling
As a former IBM Series/1 assembler programmer from the 1980's, this video brought back many fond memories (no pun intended) of reading through big, fan-fold greenbar printer listings. You guys are awesome software archeologists in posession of some of the most significant computer code ever written. This is historic code that directly enabled human footfalls on another world.
I (and several others) were assigned to "translate" the code in that listing, generate flow diagrams that could be understood by real human beings and teach classes down at the Manned Space Craft Center in Houston. It was a BIG job because the MIT programmers did not always give written comments, to the side of the instruction flow, to help people understand what they were trying to do. Often times they would do a "weird" shifting of "words" in order to interrogate a particular bit (for instance a bit that meant a specific switch was on or off). We had to figure it out, ourselves. It took MONTHS of laboring over those Apollo listings to come up with those flow diagrams.
It is modern archeology. Tracing back an acient language. Very well done.
Is your work publicly available?
That is shocking, in the extreme, that the programmers did not recognise that lack of documentation on something as important as this is a very serious no-no, unless of course, a decision had been taken that you were not meant to receive full documentation. If the functionality of those bit switches, for example, were not provided to then no one reading the code would be able to decode their meaning beyond bit x of byte/word y gets checked/set/cleared here. I wonder if the CPU had basic AND/OR opcodes or they had to suitably bit rotate to capture a suitable status flag e.g. carry?
@@ChrisM541I don't think you can even call the microchip that runs this a cpu, the generally considered "first cpu" the Intel 4004 was only released in 1971
I build Industrial control systems and I've lost count of the number of times I've written software fixes for bad hardware. Rarely are they as elegant and simple as that fix.
I guess that is also why Linux often has worse power usage compared to Windows on the same computer, as the OEM drivers in Windows have all kinds of hacks in place to work around faulty sleep modes etc.
digi owl partly. Also I suspect that the manufacturers simply put more effort/money into Windows support. I wonder if the same bares out in the server market, where Linux is far more dominant.
Yeah the ancient joke how many hw engineers it takes to change a light bulb (none, it'll be fixed in software) ain't so funny anymore.
In all reality, software by it's nature can be iterated rapidly. Hardware not so. Now think of the number of bugs in software and compare that to hardware and you will see that hardware actually has a damn good record of getting things right at tape-out.
Sadly, computers have made elegant coding unnecessary.
The moon landing is one of the most important technological leaps in the history of mankind. Out of all the billions of humans that ever existed, 99.9999999999...% have never even been outer space, nevermind landing on the moon! This video is a part of that history and hundreds of years in the future (if we are still existing) this video will be a relic to something that was great.
Fascinating trip back in time, thank you Mike and Marc. That was a good explanation of the layout of an assembler listing too, showing the one-to-one relationship between machine instructions and assembler language statements. Around the same era I was writing air traffic control software in IBM/360 assembler code (BAL) and it all came flooding back to me. I have happy memories of six inch thick assembler listings and boxes of punch cards, just like this. Too much of this history of computing has been lost for ever, so it's wonderful that you are rescuing, restoring and archiving for future generations.
@Robert Slackware the 360/30 had no "hex pad" rather it had rotary dials that set the IPL device. The CPU woukd send a start I/o to that device to begin the IPL procedure. I wrote IPL code for punch cards, but its basically the same for tape or disk IPL
Don Eyles, a name that most people probably do not recognize, is one of the great unsung heroes of the Apollo program. May he live long and prosper.
I cut my teeth programming in hex and assembly - I was 2 years old when this was assembled! I always will be a low level guy!
This is one of the most interesting video's I've ever watched. Thank you so much for all your work and dedication to the project.
OCTAL !!!!! at leat i worked in HEX in the 80s !
@@eloyex When they said erasable was 0 thru 2000 octal, I automatically reacted with, "you mean 0 thru 1777?" :) echo 'ibase=8; 1777' |bc = 1023
@rjy8960 one misplaced apostrophe in that low level code could screw everything up...
Same here Bro'. I'm a year older than you. Still love assembler!
Assembler programmers and real time processing programmers are a very special breed. I spent my computer programming career donig that. Reading the green bar was a treat, especially when tracking down a bit problem on spacecraft. Remember this is an era when bytes and words were it. Computers might be eight or sixteen bit machines. You tended to memorize a lot and work between binary, octal, decimal and hex.
Assembly code with comments. Amazing.
It sux big time when you have to work on assembly code where there is one cryptic comment per 100 lines. Early in my career I had to take over a project written that way.
@@lineshaftrestorations7903 I know that feeling.
Fantastic! Love Mike's enthusiasm for this stuff.
Its so cool to see the exact changes the programmers made to fix 1202. Love your videos, thanks for sharing.
Absolutely fascinating yet again. So much information even in each line.
One of the things I love and appreciate so much about so many CuriousMarc videos is the level of shear information that is there. This video is no let down. I've watched it a few times and there's just so much information and enthusiasm there. This is why I get excited about new videos. Great informative work guys!
Wow what a fantastic explanation of the way that the code went together thank you.
Thank you so much for the job you do. I've spent several hours browsing the PDF you uploaded with the code/documentation. What a massive job it must have been to scan all those pages. I'm very grateful!
It’s not about how many bits you’ve got, its about how you use them ;-) Thank you for making these epic videos! Greetings from Belgium
Really enjoyed this. I did much of my undergrad Computer Science degree with this sort of technology. Brought back memories of performing dry runs to track down bug, using all the features of the listings you discussed. That listing is gold. Comments and code structure give an insight into the mind of the programmer!!
The enthusiasm you all have for this stuff is infectious. So infectious that ever since I have watched your video on SCMP and AGC, my interest in the core working of these machines has increased!! Although I know only a teeny-tiny bit of AVR assembly, these videos are real gold and should be preserved!!
At just about the same time as the MIT programmers were fixing the 1202 bug, I was learning IBM 360 BAL for fun. This video is so cool, and it seems like both just yesterday, and a long time ago.
I really have no clue how Mike is able to store so much knowledge and information in this young brain of his and have it at the ready whenever Marc is asking him any in depth question.
I mean, he is answering almost everyone of them off the top of his head. Does he suffer from photographic memory or does he have cybernetic implants already ?
It kinda makes my programming job feel like I'm building Lego sets with a 4+ rating by comparison. Unbelievable.
I also wonder how many hours and money went into all of this.
After all it's "just" a hobby, right ?
Anyway, you guys rock so hard, I can't wrap my head around it !
Thank you Marc and Mike. This is a hugely important video, and one that along with the AGC rebuild will be kept for future generations. Anyone starting in systems programming and real time control should watch this and read some of the AGC manuals. There is a lot of knowledge to learn from this.
I used to program in assembler in the late 70's and early 80's. I so wish that my assembler had been as helpful as this!
That way they wrote that code is a work of art. The way everything is organized and commented makes simple to follow. Had to make it a hell of a lot easier to troubleshoot and modify. Neat to see how the 1202 fix was done. Great work as usual Marc, Mike, and the rest of the Curious Crew.
As someone who learnt to code on 6502 back in the day. This has some beautiful features built into it and looks very familiar. Thanks for this series its fantastic.
So much fun to see your work , my grand parents just gave me original new york news prints of the first moon landing in color pictures and all, felt like the first day back then.
Thanks for deep diving all things Apollo especially the AGC. This has always fascinated me.
Thanks for the support!
A nice piece of real History. Thank you all for showing it to us.
Thanks for sharing. Can't think of a better way to honour these achievements other than by simply knowing of them. Thanks again!
No matter how sophisticated we are today, this is still legendary and cool! Thanks for the video, more deep dives like this please!
So very interesting! Thank you for spending the time to explain this!
Many thanks for the detailed video. When I see the straightforward, actually easy to read structure of the programming that was responsible for the successful missions and the rather modest success of various landing missions (moon, mars) today, it makes me think and wonder.
Thanks for making these videos. Thoroughly enjoyable. I programmed a mainframe on punch cards via a remote job entry station which consisted of card readers and printers, which were connected to an Amdahl IBM/370 clone. I was a high school student taking a programming class at my local state university, in 1982.
wow ... this is awesome and good work of the programming team. Thank's for share.
Man, i never thought i would be watching the *Apollo 12 source code* . THIS, this is really cool content. I actually dont have words to describe this, it's just amazing to see this...
I'm in awe of assembly programmers. I learned FORTRAN in the 80s working on VAX/VMS and Modula-2 on Unix mainframes. Primitive compared to today, it was still a far cry from programming in assembly language. I learned some assembly language but never had to actually try to program in it, thankfully! Fascinating video, thank you for sharing!
You guys aren't just sharing with the geeks, you're making them. Thanks for sharing!
-Jake
I have no clue how I come up here but I loved every minute of it! Very fascinating stuff even if I understood probably a 1/20th of it! ❤
Mike's depth of knowledge is amazing, same with Ken.
Wow, haven't done any assembler for about 40 years but I can pick my way through some of this. Wow, thanks for the share!
This is Great! It's great that you're studying and documenting this. It's also great that you're sharing the examination of this code. I'm an old coder. I learned BAL in college before moving on to Fortran & Cobol, but when I moved into the business world, I had to occasionally write custom routines in assembler, and read core dumps of compiled code. This all brings back a lot of memories. And the coder's comments are exactly the type of stuff we used to lay into our code. Very Cool!!!
Truly amazing stuff. Thanks for sharing !!
Thank you so much for this ; it's like studying DeVinci drawings but for passionate programmers. Really great.
At 10:59, that feature where the code listing tells you how many times before a label has been used (REF) and the page number (Card Index) of its last occurrence is a "trace" feature. Most assemblers (or post assembler analyzers) have trace features like this, but they are not used much anymore since we all have computers and monitors on our desks that have source code specific editors - like Gnu's Emacs or IDEs like NI's LabWindows/CVI or Microsoft's Visual Studio. Those editors are so comprehensive and quick to browse code, there is little need to print out source listings anymore - not to mention having trace listings in them. I can't remember the last time I printed out a code listing... I think it was the mid 80's.
Great work Marc. Thank you for sharing.
Very interesting. It's crazy to think that such relatively limited technology allowed us to go to the moon, and today we can't even have synchronized, smart traffic lights everywhere in North America.
These listings reminded me very much of my early days learning Z80 machine language on my Sinclair ZX81 back in 1982. I was 17. How time flies when you're having fun. Thanks for sharing.
BTW, Mike's vast knowledge never ceases to amaze me!
Looking closely at some of the listings, the printer had trouble printing clearly the last column which makes it sometimes difficult to distinguish a C from a 0...
A great video explaining how to read the ACG assembler code. Thank you!
Thanks! I really enjoyed this episode.
A fantastic insight into NASA documentation. Thank you for your upload.
Great to see this copy of the AGC program, thank you!
In the future, humanity leaves Earth, and the robots we left behind build a civilization of their own, worshiping this listing as a holy book.
Priest: "...and deliver us from manic RR CDUs, TCF DANZIG."
r/adeptusmechanicus
Very interesting. I'm sure glad editing code is a LOT easier than it used to be.
I remember my Microprocessor language Professor telling us (in 2001) that Computer Scientists decades ago , in order to save a few bytes of memory space had some Programs rewritten
entirely .
This was after he had written two versions of one Assembly Language Program with one version of the Program saving a few bytes of space.
Memory space was considered very precious .
Incredible video, thanks for sharing!
Ah, the good old days. Man, I miss Apollo. What a fantastic time. 50 years later we need megabyte executables to print "hello world". That's rather sad. Luckily much has improved, too.
Well, in Rust you can get quite some bit of code that fits into 150 KB. Also, because it´s WAAYYYY easier to use than C/C++/Assembly, there is a potential to bring neat small apps back :)
Major consumer operating systems are closed and bloated to maintain demand for better hardware. It's a swamp...
@@manuell3505 That's why Linux is so popular.
@@LubosMudrak An up vote for Rust!
@@LubosMudrak Compiled code can indeed still be quite compact. But more and more software these days are written in the likes of Javascript by way of Electron or similar. Overweight turtles all the way to the ALU.
The nicest thing about this code is that you only have to change one line at the beginning from "DEST := 'Moon''' to "DEST := 'Mars'" and it would land the astronauts on Mars rather than the Moon.
Version control in the late 1960s! Very cool.
Yeah that asterisk at the end is almost like a branch diff between the current and previous version. Now all they need is blame lol.
Keep on doing a great job guys!
That code deserves to be etched into concrete, not only nerdy computer history but a huge part of the history of humanity.
Even concrete (depending on the mix) weathers, so something tougher than that would be neded ...
But definitely ...
@@nigelft The Romans made concrete that is still standing today.
@@nigelft Portland cement, or hydraulic concrete.
For me, this is by far the most interesting video of the series. I'm a retired electrical engineer and spent a significant portion of my career on real-time software development (please everybody stop using the word "coding" -- it is highly insulting).
My intro to computer languages was in high school, where an IBM employed neighbor brought to me an instruction manual IBM used to teach PL/1. I was instantly hooked. But, I never advanced to the point where any of my programs could be submitted for execution.
In college, my very first semester (in 1973) included a FORTRAN course, in which we punched cards for batch submission to the Xerox Sigma-6 beast. In between the SPICE runs for circuit courses, I became especially fond of writing ASCII-art programs. Which came to an abrupt halt when the sysop eventually wrote on the top of my card deck something very close to "if you ever submit something like this again, you will be banned from ever using this facility again"
I grew up in the 80s and so I learned a bit of 6502asm for the C64 and a bit of 68K asm for the Amiga. And today I learned about how they programmed the AGC, and how the fixed that infamous 1202 Error. That was extremely interesting, thank you!
Thank you for this its so interesting keep up the good work
I love that code isn't some kind of a top secret documentation and we able to dive into and appreciate it.
Those who could understand these programs are revered till this day. I could barely understand assembly language, but I still remember carrying the hugh pile of print outs during my programming term assignment.
I really admire your work and your genius. I have used assembly language to program the 6502, the z80, the 6800 family, the 8051 family and some PICs, but that was just a couple of drops compared to the ocean of your work.
Awesome narrative; learned a lot! My grandfather programmed with these systems.
Marc, I worked on the Space Shuttle computers for 20 years at IBM and LM and would be very intereted as to whether that computer has a Serial Number on a tag on the side.
Oh awesome! It sure does. P/N 6966000-6, S/N 308.
@@mikestewart8928 can you tell me where they bought it from? I am amazed that it was out in the wild.
@@mikestewart8928 Ah, it is a pre-production unit. A lot like the actual flight computers but not quite the same.
@@paulcushing8663 Apparently it came from "The Spaceflight America Museum and Science Center in Prince Frederick, MD", on RR auction. Do you know how it differs from the flight computers? We haven't found too much documentation for it yet.
@@mikestewart8928 Mike, From what I can see on the photos (the product test lab didn't work on the pre-prod units), the Pre-prod unit mainly differed physically with the black and yellow wiring harness replaced with tape-cable pages, the structure would become a welded construction instead of bolted and the electronic components, while based on Texas Instruments 74 and/or 54 series parts in the pre-prod, got new IBM-supplied partnumbers due to the radiation hardening requirement for all flight hardware.
Also, i would be very surprised if you could find ANY documentation for it in the public domain. It was an IBM design, based on the B1 computer (we were told) with modifications to connect-to and operate-with the existing (from the 1st generation AP101B system) IO Processor box. They two boxes were interconnected with three shielded cables. The forth connecter on the computer is an AGE (for ground equipment) and capped when installed in the shuttle. The IO Processor box was the only interface to the shuttle systems via 24 serial channels plus approx 40 discrete in and out lines. When first powered-on, the computer was "stupid" as there was random data in the solid state memory and it had to be IPLed from a Mass Memory Unit. This was a big change from the 1st generation computers which had core memory in them.
f more comes to mind I will post it. T'was a very long time ago!
Some years ago, my rodeo group got a guy to program an online contestant registration system in PHP. I designed the interface screens and wrote the requirements for each function. I also specified that all parts of the code was to have function comments embedded within the script. A few years later, the PHP engine on the server was updated and the entire registration system crashed. When I looked at the code, I found there were absolutely no comment markups anywhere in the script. He had not followed PHP standards and just wrote the script so it would work on the PHP version he was writing for, including a bunch of poorly implemented subroutines. Not being able to understand what each section did, required an almost entire recreation of the entire system. I really could have used your friend for that one.
Badly written software running on super fast hardware is the pervasive bane of our modern existence! See, it can even ruin a cowboy’s day!
A piece of history saved, well done all at CuriousMarc
Awesome! Nice piece of history.
Loved this, thank you.
Absolutely incredible how these systems were made.
Todays stuff is just neat.
Worked on some mini computers in the 70's and 80's. Looking at that assembly on 'greenbar' paper takes me back. Wasn't the same assembler of course, but yeah, reading those columns with the instruction, reference addresses, comments, and all the rest was an everyday thing back then. And the assembler programs themselves, that kept track of all the 'labels' and references to print out the table at the end was something. We would spend hours flipping between the tables at the end and the listings. And to think, they were doing this decades before the TRS-80 or IBM PC.
So cool! 😍
Thanks guys.
I love the cross-referencing info in the listing. I wish I had known about this when I worked on an assembler and a compiler in the 1970's. They had comprehensive cross-reference listings, but now I wish I could go back and make them even better. And I wish modern compilers told you all of the things they know about your code that you don't.
Mike is the today,s Don.
No kidding, he sure is. I am so glad the listing went to him. He is probably the only one that understands it fully. The Apollo 11 one got very expensive and got away sadly, but fortunately Mike had scanned it beforehand.
What an incredible, beautiful, irreplaceable artifact.
Quite amazing so much of it survived and, likely, still is out there. Never stops to amaze me in what ways those artifacts emerge and how diverse they are. I definitely don't know the computer side of things as much, but appreciate it when they show it and introduce it. But I also consider my Tek 2467B scope to be a beautiful artifact of testgear so lol. To each their own and to new stuff we encounter.
I would love to have Mike as a friend. I bet he is fascinating to talk to. I thought I was the only person that was this fascinated by software lol.
"FIX IT IN sOFTWARE!". and still happens even now for us bare metal guys! Love this listing!!
It used to be in all the compilers and assemblers I knew about, when you were merging input from tape and punch cards with patches (usually known as patch cards) the asterisk next to the sequence number indicated that this was a patch card. Non-marked input was coming from the master tape. There were other possible flags, like a # sign if you were generating a new merged output tape and also resequencing a range of the input lines. Of course this assembler may have worked differently.
Ah, interesting! A lot of the same terminology exists with YUL/GAP. Revision assemblies are handled with "merge control cards" -- things like DELETE 0024 THROUGH 0100. Actual code cards were called "detail cards" rather than patch cards. The only other marking like * that I can think of is that YUL (the Honeywell 1800 and earlier version of this assembler) would print an @ on any line that had been matched by an acceptor card. Acceptor cards were how they dealt with the punch card sequence number resetting to zero with each log section. In such a case, the sequence number "0123" is ambiguous, if there are multiple such cards in the program. The acceptor card let you specify the contents of a specific card (usually, the card defining the start of a log section), and it would halt the merging process until it encountered a card whose contents matched what you punched on the acceptor.
CuriousMarc, you Rock! I love your videos!!
They always go deep and you explain things so well!
Viendolo.... Simplemente Es Espectacular..... muchas gracias....❤
Incredible!
I used to read core dumps on IBM mainframes for COBOL programmers as I was one of the only assembler programmers there. I used to diagnose 3,000 page CICS dumps. Then the operations manager decides "it was a waste of paper to print dumps" so instead if paper I would get microfiche on my desk, and I didnt have a microfiche reader!!!
I taught at a large college in NY, mainframes and assembly language too. I still prefer assembly language to any other
You guys rock! Thanks
Amazing stuff!☻
Octal I wrote assembler back in 1985. wow brings back memories. I worked on the pre-internet. And Fortran.
The x86 instruction set makes more sense in octal, but is documented and used in hex.
This is amazing!
A fabulous artifact! I wish I could smell it. I can't help but be reminded of the famous picture of Margaret Hamilton standing next to a stack of these printouts as tall as she is.
That picture is heartbreaking, haha. If only that stack of listings still existed...
7:28 In 1973 I dropped two boxes of punch cards and they spread all over the floor. Luckily they were numbered from column 73 onward and there were many larger groups of cards that did not separate. It still took me all day to put the decks back together and my boss was NOT impressed. Unfortunately the company I worked for did not have a Hollerith card sorter which would have made my job so much easier.
Ken is the funniest, his quips make my day
This is real programming.
Different than importing a 100MB library to make a LED blink.
this is just every reddit and stack exchange user gatekeeping programming as their own, "reinvent the wheel" definition
At least these guys have the know how to restart the software and enable us to re-land on the Moon again!
Long time no see!!!
I love the engineers that came up with the 1202 hack. They essentially strangled the CDU with an always-0 command to shut it up.
That’s exactly what they did. Mind you, it was not that easy to shut down the runaway CDU, as even turning off the rendez-vous radar (as they did as an emergency measure for the Moon lift-off) would not do the trick, and the fault is so convoluted that it would have been a major redesign to fix the hardware. Fortunately there was that little reset line connected to the AGC. That’s how the rest of the missions flew.