I don't know why, but stuff like this (e.g. the Apollo moon lander assembly code) is really interesting to me. I think it's because I wish I had this kind of knowledge and skill. It seems daunting to wrap my head around it and become proficient.
It really isn't that hard once you have to do it, as long as you have the time to get a test / feedback loop with the client going. They probably had a dozen test versions of the Furbies for whoever was doing QA to play around with.
With the moon lander code, they surely had a very good specification of what it was supposed to do.
I worked with the second case once, some IoT-ish sensors that would be buried in the ground in greenhouses, to monitor soil data. The business logic was 90% specified, and of course, the remaining 10% took 50% of the time. Before you ask why we didn't do it in C at the very least, we had a very solid codebase from the previous products. Sure, we had to port things from a Toshiba microcontroller to an STM8, different architectures, but since we were working with 8 or 16 bits inputs it was kinda trivial to test every single possible input to make sure things matched.
My only previous experience with assembly at a Computer History college course where we coded for the PDP-11, the 6502 and a stack machine. So yeah, not a lot. Winging it while admitting you don't know what you're doing can get you decently far in some circumstances.
Don't overrate the skill of writing assembly, sure. But don't underestimate the software craftsmanship. Looking at the code, it's obviously expertly written. I'm not sure if I've ever had the pleasure of working with such a well thought out and documented code base.
And don't underestimate the skill of putting together the entire product: being able to create behavior that is relatably live-like for millions of people on such a limited Plattform may not be Apollo-Level genius but is exceptional nontheless.
