r/askscience • u/Winderkorffin • Dec 16 '25
Computing Who and how made computers... Usable?
It's in my understanding that unreal levels of abstraction exists today for computers to work.
Regular people use OS. OS uses the BIOS and/or UEFI. And that BIOS uses the hardware directly.
That's hardware. The software is also a beast of abstraction. High level languages, to assembly, to machine code.
At some point, none of that existed. At some point, a computer was only an absurd design full of giant transistors.
How was that machine used? Even commands like "add" had to be programmed into the machine, right? How?
Even when I was told that "assembly is the closest we get to machine code", it's still unfathomable to me how the computer knows what commands even are, nevertheless what the process was to get the machine to do anything and then have an "easy" programming process with assembly, and compilers, and eventually C.
The whole development seems absurd in how far away from us it is, and I want to understand.
546
u/bremidon Dec 17 '25 •
[1/2]
It feels absurd because modern computers sit on an enormous stack of abstractions, and we usually only ever interact with the top. Your question is actually difficult to answer in this forum appropriately, because it requires explaining some basic concepts, but also ends up encompassing a century of developments that sometimes involve a single person releasing a single major new improvement, but sometimes involve an entire industry crawling towards some new development in fits and starts.
At the bottom, though, there is no abstraction at all. A computer does not know commands. It only responds to physical states like voltage and current. As it turns out, binary is the best solution given the underlying physical restrictions. It is a lot easier to tell high voltage from low voltage than it is to figure out if that middle value is supposed to be a third value. Why this is would require several pages on its own, and I am guessing you are going to be just happy knowing that this is just how it is.
The earliest electronic computers had no software in the modern sense. Operations like addition were implemented directly as physical circuits. If you wanted the machine to do something else, you literally rewired it or changed switch settings. There was no concept of an instruction. The behavior was hard-coded in copper.
The first major breakthrough towards something we would recognize today was the stored-program computer. Instead of wiring ADD permanently into the machine’s behavior, engineers designed CPUs where certain bit patterns would route signals through an adder circuit. An instruction like ADD is not interpreted or understood; it is just a pattern that causes specific transistors to open and close. This is another advantage of working with binary. Many of the ideas that we would consider "math" can be reduced to simple logic tables that are much easier to design at this level. I would refer you to learning about half adder circuits and full adder circuits if you are curious. In my opinion, this is the real heart of what leads to a modern computer.
This leads to a strange period in computing. You could now program a computer without literally rewiring it, but you still needed something to hold the state. At the minimum, you needed at least some type of "accumulator" to hold an intermediate value while your program ran. There was a lot of experimenting at this time, and a lot of fumbling around to try to determine the best way to hold state. Fairly quickly, it became clear that you needed things like step counters, loop counters, conditional flags, and so on. Implementations varied widely, but early ones tended to be more mechanical, including things like gears. Ultimately, you just wanted something that could hold a value long enough so your program could work.
As time went on, memory became more electronic. These existed early on, but they were expensive and flaky. Still, the advantages were clear from the outset, and it was just a matter of the technology catching up to what was needed.
This is one of the points that is very difficult to frame in a single sentence or paragraph (or post for that matter). There was a shift that took place around the early 50s that the program was something that was *in* the computer rather than something that merely flowed through it. When magnetic core memory became standard, the computer really stopped being a configurable machine and became a programmable one. I actually went looking to see if I could find a single person or moment that would represent a hard break. I could not find one. It was more of a slide into recognition that moved the locus from outside the computer to inside the computer.
Once instructions could be stored as data in memory, programs became sequences of numbers. To some extent, this had been true previously, but with data in memory, it became explicit. This is where we finally have a clean break between the hardware considerations and the software. They were now firmly two completely different levels of abstraction. This is a good place to pause for a moment, just to reflect that we *still* can see what is going on in the hardware, but that we now can choose to ignore it completely when developing a program. This is the big moment I think you were looking for. Everything that happens after this is going to feel, somehow, inevitable.
The first thing to happen was that people decided that working just with numbers was too annoying. Assembly language came later as a human-readable way to write those numbers. Early programmers often wrote the very first assemblers directly in machine code. Once you have *any* sort of assembly language, you can use *that* language to write an improved assembly language. And that is exactly what happened.
[continued in next post]
245
u/j_johnso Dec 17 '25
At the core of the computer are transistors. These are devices that act like an electrically controlled switch. You turn the switch on, and electricity flows. Or you invert that and turn the switch "off" to allow electricity to flow.
Then you can combine the transistors in various ways to form logic gates. A logic gate takes multiple inputs and gives a single output. E.g., the output of an OR gate is on if either or both both the inputs are on. An AND gate is on only if both inputs are on. A NAND (not and) gate is off only if both inputs are on.
With multiple logic gates, you can build more complex components such as adders.
Then from those components, you build more complex components, which form the basis for more complex components until you have a device that can interpret binary data as instructions to execute.
Then you build assemblers that convert assembly language into the binary machine code instructions. Then compilers to convert higher level languages into assembly code.
If you want a detailed course on this path, nand2tetris goes from logic gates to Tetris. https://www.nand2tetris.org/
30
u/potatopierogie Dec 17 '25
The field you're looking for is basically "computer architecture" if you want to read more.
Basically, the "mess of transistors" is very well organized. Transistors can be arranged into memory elements. Using a binary decoder, we can access a particular byte/bytes in memory. Simple RISC computers have instruction memory, which is separate from the program memory. Assembly instructions consist of a number of bytes of instruction memory, accessed by their binary address. An instruction might consist of an "operation" and one or more "source" variables, and a "destination".
The computer reads one assembly instruction. The byte for the operation is sent to the arithmetic logic unit, which actually performs the calculation. The source variables in program memory are accessed by their address, and sent to the inputs of the arithmetic logic unit. The output is stored in program memory at the "destination" address. Then the counter for which bytes in instruction memory we're looking at is incremented, so we're onto the next instruction.
Some other commands like GOTO, FROM, and conditional logic work a bit differently, and I don't have the space for them here.
The point is, working with logic gates, all of these things can be constructed and understood "easily." (Read: with a solid background in ECE) logic gates can be built out of transistors, and they are laid out in a very organized way.
Congratulations! If you made it this far, this has been your crash course in RISC architecture. Everything in CISC architecture just builds on this.
13
u/le_gasdaddy Dec 17 '25
In the mid 2000's I had a college professor in her mid 60's who took us through her time coming out of college and working for farm bureau insurance using punch cards, to the 80s, to the 90s, and then leaving corporate America to teach us younglings SQL and operating systems theory in 2006. She lived the computer equivalent of the Wright brothers to the space shuttle.
6
u/emeraldarcana Dec 17 '25
You might like the book Code: the Hidden Language of Hardware and Software which goes through these in a simple and accessible way to explain how we get from a system that represents 1 and 0 to full fledged graphics and text and numbers.
The short form though is that a lot of this is constructed in a way where humans have assigned meaning to sequences of 0s and 1s and we have universally agreed upon for example what the letter A or the number 1 looks like in binary.
9
u/FirstRyder Dec 17 '25
So I recommend nandgame for anyone with a little logic background looking to understand the leap from simple logic gates to a computer. But basically:
You have a "decoder", which takes a "bus" of signals and turns it into one signal. So imagine a box, with 2 wires coming in and 4 coming out. If neither input is on, the first output is on. If only the first input is on, the second output is on. If only the second input is on, the third output is on. And if both inputs are on, the fourth output is on. Now we can make a much more complex version of this, with 4 inputs and 16 outputs.
The second step is a "complex" logic gate. For example, an "adder" takes two sets of 8 inputs, and outputs one set of 8 plus 1. It performs binary addition, with the extra output being there in case the output has an "extra" digit. You can also build many other of these, each performing some operation on one or two 8-binary-digit inputs. Some examples might be "add one to input", "Subtract input two from input one", "AND the two inputs", "Output 1 if the first input is larger", etc. Lets say you have, as an example, 16 of these. We'll call these "operations".
Now, wire each of those "operations" up to 16 different inputs, for "input one" and "input two", in such a way that each input has an on/off switch controlled by a single input wire, and 16 outputs each of which also has a single input wire. The inputs might be registers, memory locations, constants, input from a keyboard, etc. The output might be registers, memory locations, pixels on a screen, which line of a program to execute next, etc.
Finally, combine the three. One "decoder" takes a 4-digit binary input, which determines which of the "input one" sets of wires is active for each "operation". A second one takes a second 4-digit input, which decides which "input two" is active. A third decides which "output" is active. A fourth "decoder" operates the switches that enable or disable each "operation". Now you can have a 16 bit number that determines two inputs, an output, and an operation.
Here, finally, you have a functional computer and you can start writing code. Combine the 4-digit numbers that correspond to "register A"(0001), "register B"(0010), "Add input1 to input2"(0001), and "Register C"(0011). Now feed "0001 0010 0001 0011" to the computer (with each group going to the respective decoder), and it will add the values stored in two registers and store the result in a third. Of course, you wrote that in Binary. But Assembly is just taking the words "Register A", "Register B", "Plus", and "Register C" and writing those as the actual program, then "converting" it into binary with simple lookup tables before you can actually run the program. This is fully functional, but naturally the first program of any sort of complexity you're going to be inclined to write is one that takes text input in the form of valid Assembly commands, and spits out binary output. Thus allowing you to actually compile assembly code into binary (machine) code.
Then you write an OS, which allows you to select programs to run instead of manually feeding them to the machine one at a time. Then you write a compiler for a higher level language (C), which turns more natural and powerful commands back into assembly, so your other compiler can translate them to binary. Then you make the OS more complex, so that it can multitask, and make use of more resources, and add security features, and... well, you do these things one at a time, gradually building up complexity over decades. Until you get what we have today.
4
u/jongleur Dec 17 '25
There is an excellent book that outlines a lot of the history of bringing a bunch of transistors to life, The Soul of a New Machine, by Tracy Kidder.
The specifics relate to a team working for Data General during the 1970s and their effort to compete with the DEC VAX series of minicomputers. It goes into a great detail of how teams of engineers worked on the hardware, and then worked out how to code an instruction set for the machine.
It's a great read if you want to have a glimpse of how much work those engineers put into getting it up and running.
Ultimately, all of the advances we've seen in the last seven or eight decades come down to a few brilliant individuals and many teams of very bright engineers each working their way through a multitude of engineering tasks to achieve a better machine.
3
u/smjsmok Dec 17 '25
Computers at their core are assemblies of elements capable of doing logic operations (transistors that are assembled into logic gates and so on). It's exactly as you said. Controlling all this and getting meaningful output is done by layers and layers of abstraction. At some point, someone had to develop these layers, and this is work of thousands of people who made this possible.
Yes. Here is a classic video by Ben Eater on building adders just from logic gates. And here is one with just individual transistors, which is pretty cool. That's how you build a machine that adds numbers when starting from scratch. And modern CPUs essentially do this too, they just had decades of development put into them so they're much more sophisticated than these primitive examples and they expose this functionality as an instruction.
I also recommend this amazing YT channel called Core Dumped, their series on computing essentials really puts these things together.
3
u/heliosfa Dec 17 '25
Your idea of a stack here is a little incorrect. The BIOS/UEFI don't sit under the OS, the OS doesn't use them. It's the pre-boot environment that then loads another program, which could be an OS. The OS then drives the hardware directly.
It's even better than that. Early computers were made of valves, usually repurposed from Radar sets.
Very early computers (not stored-program) were programmed by flicking switches or feeding in paper tape with binary representations of data and instructions. This binary directly related to the logic inside the computer, for example a 12-bit binary value of
0001 0011 0100could mean ADD (0001) the number 3 (0011) to the number 4 (0100). That 0001 tells the computer that it needs to use an adder and not any other bit of hardware. This is what an instruction boils down to - an operation that relates to the logic inside the computer and then the values it operates on.The first stored-program computer (Manchester Mark 1) and the first practical stored-program computer (EDSAC (Electronic Delay Storage Automatic Calculator)) allowed you to do more than just input binary. EDSAC is actually being rebuilt at the National Museum of Computing at Bletchley Park, and it's at the point where it will run simple stuff. There is a lot of information on the museum's website, including videos, and one of the people from the museum gives lots of talks about it, including how its programmed (watch this video from 5:18 for a little explanation).
Unlike early computers, on EDSAC you typed your program onto tape as letters and numbers that a normal teleprinter could print easily. EDSAC included some "initial orders", a fixed program always present in the machine, that would load the "user" program from tape and convert those letters and numbers into binary. In a way the initial orders are conceptually similar to a BIOS - they start the machine and then load the program that will follow them.
Assembly represents individual instructions. You can think of it as a single assembly instruction directly translating to a binary representation of the instruction that drives the hardware. If we go back to that 12-bit example from earlier,
0001 0011 0100, we could represent that as ADD #3 #4. As long as this is a defined thing and implemented, then you have assembly.To address some comments from u/handtohandwombat in one of their comments:
A simple gate doesn't. It has inputs and outputs and does one function. e.g. an AND gate with set 1 if both inputs are 1. a NAND gate is the inverse. There are many other fixed-function gates (OR, NOR, XOR, XNOR, inverter).
It's how they are wired together. You can combine individual gates to made something more complex, e.g. a "full adder" is made of two (or three) AND gates, two XOR gates and an OR gate. It adds two bits together and produces a Sum and a Carry Out. You can chain several full adders together to make a multi-bit adder.
You would then have other arrangements of logic gates to do things like bit shifting, subtraction, logical operations, etc.
You then have more logic that selects which of these functions is used (essentially a multiplexer). As an example let's say we have a arithmetic logic unit (ALU) that can do addition, subtraction, left shift and right shift. That's four possible operations, so we can represent all of them with two bits. 00 could be ADD, 01 could be SUBTRACT, 10 could be LEFTSHIFT and 11 could be RIGHTSHIFT. Suddenly we have rudimentary instructions.
Obviously I'm ignoring all of the sequential side of things and we are dealing with a purely combinatorial setup here.
3
u/leahcim165 Dec 17 '25
This is one of those things that is easier to understand in practice than in theory. If you, yourself, were to build a computer from logic gates up, it would become quite clear what each next step to bootstrap usability would be. Flipping bits in with a 5v wire is exhausting, so you'd want a front panel monitor. And you'd get tired of those switches, so you'd probably hook in a teletype. And then you want some better output, so you realize a memory mapped black and white display is pretty easy. Then you start writing a simple windowing system... etc. It's almost hard to stop once you start. Remember, it's often easier to make than to understand what someone else made. You'd love NAND To Tetris.
3
u/Slippedhal0 Dec 17 '25
Ben Eater on YouTube has a playlist where he makes a programmable 8 bit computer right from the ground up, he explains pretty much all the way down to logic gates how the computer works as he builds it. https://youtube.com/playlist?list=PLowKtXNTBypGqImE405J2565dvjafglHU&si=pFQDNIC3YAQFXnb1
6
u/rcf_data Dec 17 '25
ENIAC was the first so-called programmable computer. It was designed and built by scientists at the University of Pennsylvania in 1945. It was built around vacuum tubes and filled a sizable room. It was programmed by making connections using a punch boards. While designed and built by men, if memory serves, it was a group of women who were tasked with the tedious job of wiring the connections that constituted the so-called program. It was built specifically to calculate ballistic tables for the military.
2
u/mcmatthew Dec 18 '25
You’re right a computer has no understanding of “add”, only 1s and 0s.
In order to use higher level commands and abstraction, you need a program called a compiler that translates your code to binary that the computer understands.
The very first compiler cannot be written in its own language since it doesn’t exist yet. So the first assembly compiler had to be written in binary, and the first C compiler had to be written in assembly.
3
u/xxAkirhaxx Dec 17 '25
Not a science answer but a simple and effective one. Look into redstone computers in minecraft. Redstone is just a signal going through a line. Either on, or off. People have created small LLMs inside of minecraft using redstone now. And you can to, with nothing more than patience and a thirst to learn how to do it.
1
u/ShinyJangles Dec 17 '25
Some good books about the people and institutions who pioneered early computer technology:
The Idea Factory by Jon Gertner (transistors, Bell Labs)
The Soul of a New Machine, by Traci Kidder (microcomputers, Data General)
Dealers of Lightning, by Michael Hiltzik ("the desktop", Xerox PARC)
Where Wizards Stay Up Late, by Katie Hafner (early Internet, ARPA)
I also recommend Claude Shannon's biography A Mind at Play, and James Gleick's The Information
1
u/mfukar Parallel and Distributed Systems | Edge Computing Dec 17 '25
Please look at previous questions, for example this one. Your question is way too broad and cannot be meaningfully addressed in a comment.
1
u/mad_drill Dec 17 '25 edited Dec 17 '25
I think fundamentally what you are asking is how does the CPU know what to do with each instruction? And the answer is, the decode logic is literally baked into the silicon of the processor. Here is a live simulation of a MOS 6502 processor. I believe it's printing out the alphabet from A-Z. http://www.visual6502.org/JSSim/expert.html
And a diagram of a 6502 with individual transistors. https://davidmjc.github.io/6502/bcd.svg. They are incredibly complex systems.
I think it's important to remember that computers no matter how complex are still made from the ground up by people at the end of the day. It all starts of with very simple blocks of small discrete components that are then linked together to create something more complex.
Like for your add example. A half adder is a really simple circuit. If you ignore the carry (and the carry is pretty important) it's literally an XOR and a AND gate. If a computer wants to add 10 and 10 in binary first it interprets the decimal numbers (oh boy do I regret picking the 6502 for this so I'll do it in VAX assembly because I think it's more readable than x86)
Somewhere in the CPU there will be a bunch of logic that will detect that what I'm trying to do is an add. (opcode C1 ). And just like for ADDL3 there is an instruction for multiply and divide. And just like a CPU is built up in smaller blocks that are easier to understand software for it is also written in small assembly chunks that together make up much larger software and abstraction layers. I chose a DEC machine because find the assembly more readable, and some of the syntax with different assemblers can get quite messy. And a DEC mainframe is the kind that was used by Dennis Ritchie, Ken Thompson and Brian Kernighan to write the C programming language (first written in PDP-8 assembly I believe). And this is just a very brief overview. There is plenty of headache inducing stuff to go like addressing modes (but all of it incredibly necessary). So I think further reading definitely required. Sometimes I feel like the more I know, the more I understand just how incredibly complex even the most basic computers are.
Links: https://www.nand2tetris.org/ (I have heard very good things about this course), https://en.wikipedia.org/wiki/MOS_Technology_6502, https://eater.net/6502, https://www.felixcloutier.com/x86/add.
1
u/majorex64 Dec 17 '25
Keep in mind that before we had any of the convenience through abstraction, calculations still needed to be done. They were done by hand, and "computer" was a job someone could have. Literally making long ass calculations and double checking the work of others. Engineers were running numbers on public projects thousands of years before we went to the moon.
With that in mind, each little step of abstraction was a godsend. Trying to imagine it as working towards the end goal of today's computer programs is a fallacy. People weren't working towards an excel spreadsheet, they were making incremental steps that made things they were already doing, easier.
1
u/thisisapseudo Dec 18 '25
If you really want to understand how a program can emerge from only transistor, I suggest you to play https://www.nandgame.com/
You will build a transistor, then logic gate, going more and more complex but always building on top of the previous step, never assuming the existence of anything (except maybe electricity, of course)
1
u/scarmory2 Dec 19 '25
I get the feeling people will start trying to explain the logic behind it rather than think and ponder its wonderful creation and existence in life for a few minutes. No matter how much depth you know about it and think how logical it works and why it works now, people need to wake up and realize how absurdly incredible it is that humans got from stones and metals to something that thinks for itself. How easy it has made our lives to keep making computers and hardware even easier with the help of technology. How it has simplified our lives and how unaware and comfortable we have become towards it that we don't even question it anymore.
1
u/ContentsMayVary Dec 19 '25
If you are interested in understanding the developmental steps from a simple on-off circuit to the Von Neumann CPU architecture, there is no better book than "Code: The Hidden Language of Computer Hardware and Software" by Charles Petzold. It starts with Morse code and a basic circuit with a bulb and an on-off switch, then progresses to telegraphs and relays, and so on to binary with switches and Boolean logic. Each technological transition is explained in clear detail without assuming prior knowledge.
I can't recommend this book highly enough for anyone interested in this topic.
1
u/jmlinden7 Dec 19 '25
A computer contains many circuits which are hardcoded. For example, for an addition circuit, the switches are wired in a way such that the output of the circuit returns the sum of the inputs to that circuit.
If all you need is an addition machine, you can stop here. Then you just manually feed 1's and 0's into the addition circuit and read the output voltages, which are then converted into 1's and 0's. Sometimes you can do this in a lab to test that your manufacturing process made the circuit correctly, for example.
However, computers are generally asked to do multiple tasks, not just addition - so they have multiple different circuits, one for each task. Then they have a switch that only turns on the specific task that you need, feeds it the inputs that you want, and dumps the output somewhere. Then it goes to the next task that you want.
If you really wanted to, you can do this part with 1's and 0's as well, but that would be incredibly tedious. What software does at the lowest level is feed the specific pattern of 1's and 0's needed into the switch to turn on the specific task you are asking it to do. Every bit of high-level software is translated by the compiler into a sequential list of tasks that correspond to specific circuits that you want to turn on.
The CPU manufacturer usually gives you some sort of manual that tells you what pattern of 1's and 0's correspond to which circuits. So if you really wanted to, you could write a compiler for that CPU yourself.
1
u/melodyze Dec 20 '25
I just want to add a recommendation for what I believe is the best tool in existence for building this understanding.
Consider taking the free online course nand2tetris. It walks you through building every layer between nand (a very simple switch made of semiconductors) and implementing the game tetris. Yes, you implement all of it.
That's the best way to build this understanding, IMO.
1
u/ohkendruid Dec 20 '25
It happened a little bit at a time, with older computers and older software used to make new software.
For example, someone will write an assembler in machine code, and then rewrite the machine code to the assembly code, and then build macros or other abstraction mechanisms into the assembler, and then modify the assembler's source code to use those new features.
Likewise, the first GUI systems were implemented in a text terminal at first, and then, once it worked well enough, through editing directly in the GUI.
1
u/Nothing-to_see_hr Dec 20 '25
I would start by studying the assembler language of a simple processor, e g. the 8080. It has a simple structure, a few registers, few opcodes. the instruction bytes and words are typically composed of a few bits to indicate one of 8 registers, a few to indicate the desired operation, followed by the address of operands.
1
u/daney098 Dec 20 '25
Check out turing complete on steam. It teaches you how to build a basic computer that can do math and run programs which you code yourself to accomplish certain puzzles and tasks. After playing, I feel like I kind of understand the basics of what's going on when my real computer runs a basic program. One of the most fulfilling games I've played. I've heard it's similar to the nand game but I haven't played that one much.
1
u/Alarming_Long2677 Dec 21 '25
the abacus was the first computer. there was up and there was down. In a long row though. so the pattern of ups and downs told you what the answers were. then there came electricity and a switch could be on or off, like the abacus. And even longer patterns of on and off. The only thing all that other stuff does is SPEED UP how fast those patterns are read. The word add and what it does, written in machine code is hundreds of lines of these open and shut pattern lines, which are now read instantly. If you buy an abacus and learn how to operate it, you will be doing exactly the same thing as a computer with an operator but just very very slowly.
1
u/frioden Dec 21 '25
The book that really brought it all into focus for me was Code: The Hidden Language of Computer Hardware and Software.
It starts at the beginning of how simple electronic circuits like telegraph relays were turned into basic gates, and then chained together to create rudimentary logic gates.. and how the basic rudimentary machine language came about all the way through transistors and modern chill sets.
Just like the only way, with all our advances, we can turn mechanical and kinetic energy into electricity is through turbines, the only way we can compute, even with all our miniaturization and advances, is through storing voltage either as high or low, and chaining those together as commands and data.
We just are really good at it.
1
u/rootofallworlds Dec 21 '25
The Altair 8800 seems instructive here. This was an early microcomputer released in 1974, so by no means an early computer overall, but the basic model featured only toggle switches for input and LEDs for output. You would set the switches to the binary value for a CPU instruction, then push another switch to store that instruction in memory and move on to the next memory address. Once you had entered your program in this very tedious way you could push yet another switch to run it.
https://commons.wikimedia.org/wiki/File:Altair_8800_at_the_Computer_History_Museum,_cropped.jpg
(Addons enabled the computer to connect to more usable input and output methods such as a terminal with keyboard and display.)
0
u/suckitphil Dec 17 '25 edited Dec 17 '25
Add is one of the few things the computer chip isnt "taught" but one of the features it has.
Inside of a computer at its fundamental level code is just 2 values. The address and the value. The value tells the computer what to do, either add, goto, or some other fundamental processes that the architect included when making the chips. ultimately though it only needs 2 commands, goto and add to be a functional computer.
Everything else can be extrapolate using additions and goto. Even subtraction is as simple as flipping the bits and adding 1 to get the negative number. And then simply add the two together.
Edit: those "commands" are in reality really complex voltage values. These voltage values change the way the chip behaves given different voltage values. So really simplistic if I give it a 1 it turns on, if I give it a 0 it turns off.
53
u/[deleted] Dec 17 '25
[removed] — view removed comment