A toroid tale

I'm a software developer, mainly in firmware for many years and still today I really love working on small board in C or assembly. I consider that a "real" programmer job.
Going down on the memory lane (pun intended :) ) it can explains maybe why.
On my career I used almost everything, scripting languages, assembly (from 6502 to Z80 to MPC860 to 68000, passing via PIC, AVR, MSP430, ST6 and others microcontroller), C, C++, C#, java, Pascal, Python, Fortran, Cobol and who is remembering what else, I worked from small boards with microcontrollers to mainframes and multi servers applications.
But still today is only when I'm using C on an embedded platform that I feel good and most importantly, feeling to do something real, kind of real work.
I often though about "why" I ended up loving so much to develop firmware and maybe there is an anecdote that can explain that.

I was in high school (ITIS Cobianchi), computer science, 1980, Italy.
We were learning how to develop software in assembly for an HP 2000A and it was my first program.

I don't remember the details, the program was just an exercise, writing something in a memory location and then retrieving it.
Really something trivial, by the book but .. it didn't work and I was extremely frustrated.
All the classmates had their job working perfectly, mine was not working.
It was not even starting !
So in the end I had to involve the professor that of course explored all the possible causes assuming I did something really stupid in order to mess up a so simple code.
Just for context, the program was really short and it was stored in a small bunch of punched cards. Yeah, punched cards, you did read correctly.
An assembly program on punched cards.
It make me feel quite old now ... anyway, after a while the professor looked at me and told me that the code was correct and it was supposed to work but .. it didn't.
So I started with the professor my first real debug session, involving everything, not just the code but the entire system.
We set up and run tests, changing parameters and settings, studying the HP system documentation and after hours we figured out the problem.
My program was set to start at the location 2000B (HP notation, I don't remember the actual memory address) and in that specific location one bit of the memory was "broken".
Broken ??
Yep, the HP 2000A had the RAM built with the toroid technology, also called "Magnetic-core memory"

Basically every byte of the memory was built around some toroids.

A toroid in electronic, is a ferromagnetic cylinder, used a lot in transformers and filters and at that time, computer memories.

Each toroid was crossed by 3 wires and it could store the bit as magnetic state.
The location 2000B had one broken toroid thus one broken bit !
My program never had any chance to start !
I did debug my first program going deep in the hardware and the problem was hardware, not software.

I was fascinated by the discovery.
I started to see the computer in a way different than many other people at the time.
Commonly it was assumed the computer as a "an almighty big black box", always working, always correct and if something was not working it was because the software had an error.
In my case the problem was the hardware not the software and I saw the amount of knowledge required to pinpoint the problem, a knowledge about the entire system, not only the one needed to just write some code.
I wanted to learn to do that, to be able to design systems, to identify hardware errors, not only writing code.
That day I was born as The Firmware Guy, somebody who write software never assuming the hardware will comply with your expectations or, even better, designing the hardware that will run the software you design.
Somebody who has to know not just how to code but know also the hardware where the code is running, the operating system, the peripherals, everything.
Since that day I loved to deal with "hardware/software systems".
Still I love to design hardware and not only software and always I love to write software knowing in details the hardware where the software has to run and if something is not working as expected, never assume the problem is the code alone. It could be the hardware, it could be the compiler or the operating system or a bug in a peripheral.
The essence of firmware development.