ApolloHoax.net
Apollo Discussions => The Reality of Apollo => Topic started by: smartcooky on December 30, 2020, 01:43:34 AM
-
For those who are familiar with Destin Sandlin's YouTube channel "Smarter Every Day", he has a second channel to which he posts longer, more in-depth and detailed videos.
In this video, Destin he teams up with Linus Sebastian from Linus Tech Tips to go to the US Space & Rocket Center in Huntsville, Alabama for a visit with Luke Talley, one of the IBM computer engineers who worked on the Saturn V.
This is a really fascinating look into the functionality and detail of the Launch Vehicle Digital Computer and other parts of the instrument ring, with a guy who knows every little detail of how it all worked. Its a 45 minute video, but if you are at all interested in the nitty-gritty of electronics, computers and spaceflight (or at least as interested as I am) you will feel at the end that it wasn't long enough... and I've just added another place to my bucket list for my US visit when the current Covid-19 crisis is over.
Enjoy...
-
Oh, yeah, I remember that video. I agree, it's great.
-
When I began my training in Avionics in 1973 (it was called Aircraft Electronics back then) it was less than six months after Apollo 17, so all that style of technology; discrete components, ULDs and monolithic RTL integrated circuits similar to those used in the Apollo Guidance Computer was all the stuff I cut my teeth on. When Luke Talley talked about two-second loops with interrupts and shorter loops running within them, I knew exactly what he was talking about. For our digital logic final exam, we were given a theoretical two/three lane "X" intersection and had to design a digital controller to operate the traffic lights, complete with pedestrian crossings and green-arrow free turns. Interrupts and loops galore, and it was a lot more difficult that you might think.
-
When I began my training in Avionics in 1973 (it was called Aircraft Electronics back then) it was less than six months after Apollo 17, so all that style of technology; discrete components, ULDs and monolithic RTL integrated circuits similar to those used in the Apollo Guidance Computer was all the stuff I cut my teeth on. When Luke Talley talked about two-second loops with interrupts and shorter loops running within them, I knew exactly what he was talking about. For our digital logic final exam, we were given a theoretical two/three lane "X" intersection and had to design a digital controller to operate the traffic lights, complete with pedestrian crossings and green-arrow free turns. Interrupts and loops galore, and it was a lot more difficult that you might think.
Of course, if it were easy anyone could do it. :)
-
That video was outstanding! Even I could grasp some of it. Everyone should have a squizz at it.
-
There's a companion video on Destin's second channel that has more material with Luke abusing Linus ("those are called wires"), and it's a blast. I had a few flashbacks when he described combing through octal dumps for a couple of weeks to troubleshoot a particular issue, only to discover that wasn't the problem after all; I've done a variation on that dance more than once.
I also like how it quietly refutes the whole "we didn't have the technology to go to the Moon in 1969" nonsense. You don't need 64-bit general-purpose CPUs and gigabytes of memory to guide a rocket or spacecraft. What we had at the time was heavy, power-hungry, and labor-intensive to build, but it was adequate for the task.
-
In a class once I guided a discussion about what it would take to have a guidance system. Or rather, the processor portion of it. It was an exercise in requirements analysis. We started off with a COTS solution, then pared it down to needing only six registers and some custom arithmetic hardware. I honestly think those guys back then had an easier time thinking outside the box because back then there wasn't as much of a box yet.
But also with the hex dumps -- I've been there too. My first computer stuff as an engineer was done on the IBM 370 mainframes. You could always tell whether your program worked by the thickness of the printout. A thin printout meant your program ran and produced results. A thick one meant it crashed and OS/MVS (or whatever it was back then) dumped all 256 kB of core as hex. The Michigan Terminal System, which ran on the same hardware, used EBCDIC 'a' (0x81) as a "core constant." Before bringing your program into memory, it filled your entire memory space with that value. And then when the inevitable dumps happened, it "cleverly" omitted those from the dump as untouched.
-
But also with the hex dumps -- I've been there too. My first computer stuff as an engineer was done on the IBM 370 mainframes. You could always tell whether your program worked by the thickness of the printout. A thin printout meant your program ran and produced results. A thick one meant it crashed and OS/MVS (or whatever it was back then) dumped all 256 kB of core as hex. The Michigan Terminal System, which ran on the same hardware, used EBCDIC 'a' (0x81) as a "core constant." Before bringing your program into memory, it filled your entire memory space with that value. And then when the inevitable dumps happened, it "cleverly" omitted those from the dump as untouched.
And I can just imagine how "helpful" that was for debugging, and the amount of cursing from that
-
But also with the hex dumps -- I've been there too. My first computer stuff as an engineer was done on the IBM 370 mainframes. You could always tell whether your program worked by the thickness of the printout. A thin printout meant your program ran and produced results. A thick one meant it crashed and OS/MVS (or whatever it was back then) dumped all 256 kB of core as hex. The Michigan Terminal System, which ran on the same hardware, used EBCDIC 'a' (0x81) as a "core constant." Before bringing your program into memory, it filled your entire memory space with that value. And then when the inevitable dumps happened, it "cleverly" omitted those from the dump as untouched.
And I can just imagine how "helpful" that was for debugging, and the amount of cursing from that
Oh, it was fun (for certain values of "fun" ;) ). Although once you'd read through a few dumps it started to become easier and faster. I could recognise most of the op-codes, and how certain sequences corresponded to sections of the program source (compilers weren't too smart in those days), whether an address was valid or not, common operand values etc. It didn't take long to find the bugs in most cases.
However, having a decent debugger and IDE is a big leap forward, and I wouldn't want to go back to digging through dumps these days (although I have on occasion had to!).
-
Speaking for myself, our programs were simpler back then too. Or at least had less code in them. And yes, you got good at knowing what parts of the source code corresponded to sections of opcodes. The MTS "core constant" was a big help, because you could more quickly home in on parts of the memory image that had been manipulated. You didn't have to worry whether you were looking at garbage left over from the last program that occupied that memory. Of course I did a lot of work in IBM 370 assembly language (because engineers want the raw speed). The assembler listing gave you the opcodes. And the crash dump printout gave you some -- but not a lot -- of the things you ask modern interactive debuggers to tell you.
And yes, I'd have to agree that IDEs and interactive debuggers are game changers. But our programs are vastly more complex these days. And the expected turnaround is much shorter. I'm not sure I could agree with the notion that it's just easier these days. The tools are better, but the problems are harder.