I also have a CS degree and felt the same black magic during my studies, but then I took some microcontroller classes, and they were eye-opening. In the sense that all of the CS operating system stuff suddenly made so much more sense.
For example, take something like (1) the simplest AVR microcontroller (the type used in Arduinos, hence there is a ton of third-party documentation and code floating around) and (2) your typical Hitachi HD44780 LED display.
To control the display, one needs to pull certain pins high and low, for specific intervals -- this is all in the HD44780's data sheet. Of course, you don't do this every time you send a character; you abstract this away into functions setchar(x, y, c), clearDisplay(), and so on.
Presto, your first driver!
Then you might think: let's print stuff that we receive via a serial connection. So how do you react to that data? Then you learn about interrupts and interrupt handling.
Then you might think: I could be doing stuff while I wait for I/O. Actually, I'd like to do a lot of stuff, in parallel, but the AVRs are single-core (so to speak). So you do what you've heard other OSes do: take available compute time, divide it into slices, and distribute slices to processes. And thus, you have learned about multi-tasking.
This was relatively simple to do on AVRs, and great fun.
Yeah, people don't realize that the operating systems we have today arise from devices about as powerful as some of these microcomputers. Removing the complexities that have been added to the x86 platform itself and being able to see "oh when this pin goes high cause I pressed that momentary button the CPU runs the code at this memory address" things can really start clicking. A great youtube creator I recommend for those types of explanations (he's making his own CPU out of base components) is Ben Eater and specifically his 6502 series, but the series on how USB keyboards work is also quite instructive for people looking at the hardware at that level of detail.
+1 to Ben Eater. His breadboard computer series, when I first watch it a few years ago, is when computers as a whole finally started to click for me, and not just the high-level programming languages.
For example, take something like (1) the simplest AVR microcontroller (the type used in Arduinos, hence there is a ton of third-party documentation and code floating around) and (2) your typical Hitachi HD44780 LED display.
To control the display, one needs to pull certain pins high and low, for specific intervals -- this is all in the HD44780's data sheet. Of course, you don't do this every time you send a character; you abstract this away into functions setchar(x, y, c), clearDisplay(), and so on.
Presto, your first driver!
Then you might think: let's print stuff that we receive via a serial connection. So how do you react to that data? Then you learn about interrupts and interrupt handling.
Then you might think: I could be doing stuff while I wait for I/O. Actually, I'd like to do a lot of stuff, in parallel, but the AVRs are single-core (so to speak). So you do what you've heard other OSes do: take available compute time, divide it into slices, and distribute slices to processes. And thus, you have learned about multi-tasking.
This was relatively simple to do on AVRs, and great fun.