perhaps you'd be interested to know that, in trouble shooting odd defects in chips, we do something quite similar to the software you have shown, but do it in reality. If the chip is in a package, the package is removed as well as the upper parts of the chip so as to expose the actual circuitry. the circuits that are suspected to be involved "wired up" and powered with instructions to match the failure conditions.A camera is used capture photon emissions and you can actually SEE the transistors turning on and off.

I'm a chip engineer and I have to say, it's sometimes hard for even us to answer that question. We all specialize so far into our specific parts of a CPU that we may not know how a whole thing works. I did my PhD on ways to optimize active interposer design, which is basically a chip you put other chips on top of to allow them to talk together. Think about a Vega64 or Radeon VII. Those have passive interposers, just a bunch of tiny wires through a hunk of silicon to connect memory to the GPU. My work was on effective ways to implement some logic into that chip, like moving the memory controller down there, or the PCIE bus, or maybe a huge chunk of SRAM for a cache. I actually work on CPUs, not GPUs, but most people are more familiar with the Vega64 or VII than they are with Intel's Lakefield, which is actually something I worked on. I do regret the awful performance of those chips. A single Sunny Cove core with no hyperthreading paired with 4 old atom cores was never destined for greatness. Up next for me was the bridge dies in Sapphire Rapids, and now the topic of my PhD itself becomes a product in Meteor Lake. The architects make it all work inside, I'm just a glorified electrician wiring shit together.

Well done. I asked the same question for 30 years. I finally understood when watching Ben Eaters excellent video series "SAP-1" breadboard computer.

This was absolutely fantastic. I'm currently trying to teach myself Z80 Assembly as a hobby, many, many years after playing about with Basic as a kid in the 80s. This video has really helped turn the abstract concept of what's going on into a real visual way of seeing it happen. Superb. 😎👍

Might be worth mentioning, when you jump from 4004 to Z80. Those are related chips. The 4004 begot the 8008, the 8008 begot the 8080, the 8080 begot the Z80. All within a very very short period of time.

The inner workings of a Z80 CPU are registers, ROM and functional units (like the ALU (Arithmetic Logic Unit), memory unit etc). The CPU first loads an instruction into the instruction register, which connects to ROM. The ROM is also connected to a step counter, which is reset at the start of each instruction. Each step in the ROM is a list of signals to send to parts of the chip (e.g. use the memory unit to fetch the next byte of the instruction, then store the result in a register). The last step of each sequence in the ROM is to load the next instruction into the instruction register and the cycle repeats. All CPUs come down to the basic building blocks of logic (AND, OR, NOT), implemented in transistors, wired together and sequenced by the clock. Just like normal programming you break the task down into components, sub components etc, and build each part from simpler parts connected together to achieve the required effect. A register for example is made from a bunch of Flip-Flop units, a Flip-Flop (at its simplest) is made from a couple of NOR gates (that is OR gates with their outputs NOT’ed). The difference with normal programming is that many things happen in parallel (so you can be fetching something from memory, moving the contents of one register to another and adding two registers together at the same time for example). If you’re interested at that kind of level then take a look at FPGAs, which are basically a bunch of uncommitted logic that your program can wire up any way that you like. You can implement a Z80, 6502, RISC-V etc, or even your own CPU design on them by defining the logic for each unit and how they are wired together. There’s also code available on the web for implementations of the above CPUs, so (once you learn to read the language used - typically Verilog or VHDL) you can see what is happening.

Now I know why I’m a subscriber. One of the best videos I’ve ever watched on KZfaq. Bravo maestro.

I've not watched your channel for a few months and I love the progress you've made with editing and sound and script. Really informative. Kids at school are very lucky to have you as their teacher.

Z80 is amazing! I had a MSX back in the day. Thanks for your videos!

This is the big problem with modern x86 computers, anyone can overclock a Core i7 and think they know how a computer works. I thought I was an expert after doing x86 stuff for 10 years, only to discover 8-bit homebrew computers and realise I didn't have a clue what an instruction is, or memory addresses, or really anything at the machine code level and below. Once I built my first Z80 computer that could be programmed in machine language I had pretty much no idea how to even use it.

Amazing! This is really amazing. I've been wanting to take a deep dive into the Z80 for quite some time now.

Love these informational CPU videos. More please :D

Programmers that actually KNOW (I mean like an engineer) how a cpu works are rare, let alone programmers have an idea what CPU instructions actually are. Many programmers don't even know in to string and visa versa is actually done!!!!!!!!!!!!!!! ....I WEEP FOR THE FUTURE!!!!!!!!!!!!!!!!!!!!!!!!!!!!

10:36 Nothing says "I am not an electrical engineeer." as almost spilling some welding wire randomly in a PC motherboard for no reason at all. =) That made me pretty anxious and then I just started laughing XD

Good explanation right down to the registers and logic gates!

When I am asked, “How does it work?” I usually answer, “Just well enough to get by.” That applies to most people, so we can assume machines do the same.

Just finish up writing a Gameboy emulator at the moment (z80ish) - fun exercise. Z80 instruction set is fairly regular, with some odd exceptions - so 500 instructions crunch down to more like 50 with variations. Doable as about a 2/3 month evening exercise

Love that. I never would have imagined I could watch a Z80 with the hood off.

Although this i a good attempt. If you want to dive much deeper in the working of each part of a cpu. This channel www.youtube.com/@weirdboyjim/videos has made a quad pumped cpu from scratch. Quad pumped is more advanced then the 6502 or Z80 but it is still the beginning of CPU development before clock doubling and the use of caches. You will need to watch many episodes to see the whole working. And sometimes you might need to google how a certain electronic component works or what it's basic function is to understand the video but this is as close as you can get to fully understand it. The later added technologies like branch prediction, clock doubling and caches where to increase speed and efficiency. The quad pumped part in this video series is also a early example that was such a improvement for efficiency, quad pumped wastes less clock cycles between instructions.

When I was digging through Vega BIOS files, I seen some strings that started with $. I thought "maybe these are commands, since even modern PC components have ancient guts that get things started and handle plenty of the lowest level functions". Here I am over a year later hearing a teacher confirming that thinking.

I started with this CPU back then. I added bytes to the eprom for the operating system using a dip switch and programmed address after address using a button so that something useful happens after the start. Output was via hexadecimal system to seven segment LEDs.

This was cool. Though I know how all this works, it is another thing to know how to explain it properly -- which you did a marvelous job of.

There is yotube serie where guy is building simple CPU on breadboard with leds to show status of everything. This I reccomend for explanation how cpu work internally. This video here is good too.

one of the most helpful things i found to understand is the cpu reads the instruction stack from memory. this clarifies 1. cpu is not following instruction set literally as it also performs its own mem lookups to read the instructions (and other stuffs like store jump pointers), and 2. the cpu does not store any data itself and when data is fetched any one of several memory or peripherals could respond (has no control). understanding from this angle solidifies what role is and allows to imagine in head a continuous loop of operations.

This is quite simply a superb treatment on the subject. Thank you.

Typical answer to the kid would be 'don't worry, how computers work is not a topic in the exams'

Research "bit-slice processors" and all will become clear. Ben Eater's CPU on a bread board is a bit-slice CPU and is very easy to understand. More complex machines such as the z80 and 6502 are microcode architecture where each op code runs a little program inside the chip which coordinates the various parts of the chip. Start with bit-slice. Beautifully simple and elegant.

This was very informative. Enjoyed muchly.

Just perfect explanation - great job👍👍👍 Thank you 🙂

Nice CPU video. One little detail that you missed is that what happens if the CPU gets sent an opcode instruction that it isn't designed for. Older 8-bit CPUs had various opcode instructions undefined which could cause problems if used. For the 6502 there are quite a few "undefined" opcodes that one shouldn't use but people found that if they did use them they could carry out certain operations faster as it combined operations together in the CPU. And others would cause everything to crash. It used to be a thing for people writing 8-bit demo code they could use illegal opcodes to speed up their code using less cycles at the risk of breaking the program if later versions of the chip used completely different microcode (the internal instructions inside the CPU that carried out the machine code fed to it). This has proved an issue with implementations of CPUs on FPGA and they don't implement the undocumented instructions. Or you have a chip that is enhanced like the 65CE02 chip used in the Mega 65 which adds instructions to the "gaps" left in the original instruction set that were previously used as undocumented opcodes. There is a document called "The Undocumented Z80 Documented" by Sean Young which covers the unusual effects that can occur when you used these undocumented opcodes on the Z80 processor...

You are getting close. Watch the Ben Eater CPU creation videos for a marvelous series on the topic where he creates one on breadboards.

In the 1970's Radio Shack had a small book that explained the inner workings of the logic circuits in a handheld calculator. In about 1981, the Sinclair ZX-81 became available. It was a real computer, powered by a Z80 and had 1 or 2 kilobytes of RAM depending on the version you got. (I think the original English ZX-81 came with 1K and the U.S. Timex Sinclair ZX-81 version had 2K.). I put one together from a $100 kit. You could write small programs in Sinclair Basic, and if you were ambitious, you could escape from writing programs in Basic to programing directly in Z80 machine code. The Radio Shack book, and the Sinclair ZX-81 were a wonderful place to start to learn the basics of computing. I'm glad I had the experience of learning about computers on the ZX-81.

Doing some assembly coding on the z80 teaches you a lot of all this. Because the user manual for the CPU actually lists the encoding with each opcode.

I grew up in the 1970's and had the Radio Shack TRS-80 which utilized the Z8080 Microprocessor. I will never forget the day I upgraded my memory from 4K to 16k. I had more memory than I knew wat to do with. I had no choice but to learn Machine code as computers were so slow back then that using interpreters like Basic was not practical at all. When learning machine code, there were 2 things I found most important that you left out and they have a lot to do with the inner workings of the CPU. In fact, they give you extra insight into the innerworkings of the CPU. The first is the PC or Program Counter and the other is the Zero Flag. The PC(Program Counter) is a pointer. It tells the CPU at which memory location the next instruction to be executed is located. So the Add command only needs one number to execute. The code that instructs the CPU to add register A to B. The Load A register command, LDA is a 2 byte instruction, One byte that instructs the CPU to poke a value into the A register followed by the byte representing the value you want poked into A and thus 2 must be added to the PC. A Branch Not Equal to Zero command(BNE) is a 3 byte instruction which requires the byte representing the instruction itself and the next 2 byte representing the memory location to branch to. If you say wanted to BNE to memory location 4A00 then it would the Instruction code followed by the second byte of the destination address then the first byte. BNE 00,4A. Any operation that results in a zero will set the zero flag for comparison operations. If you want to code a loop that performs a task 10 times, you would load A with a value of 9. Remember, 0 counts as a number in computers. That is where the mysterious bit comes into play. If Hex FF or Binary 11111111 is equal to 255 then why is it 256. Because 0 counts as a number. After loading 9 into the Register, you perform a chunk of code, then Decrement the Register which subtracts one from that register. First time though it will be reduced to 8. Since it is not equal to zero yet the flag has not been set to 1. Now when we BNE(Branch not equal to zero) it will take you back to the top of the code just past where you loaded the register with 09. If you branch to the beginning, it will reload 9 into the register, you would never reach 0 and you would be caught in an endless loop. Any coders worst nightmare. If you set the memory location to one past the LDA instead of 2, it will see the 9 you entered as the next instruction code and you will likely crash. So if your code starts at 4A00, then the BNE would have to be to 4A02 as 4A00 contains instruction for load register and 4A01 contains the 9 you want poked into the register. the last time through our loop we decrement from 1 to 0, which sets the zero flag. Now when the computer reaches your BNE instruction, since the register is Zero the Program Counter(PC) will be incremented by 2 past the address you were branching to when not equal to zero. Memory Code 4A00 LDA - Load A register with 4A01 09 - value poking into A register 4A02 Loop content ...Coding in here 4A20 BNE - Branch not equal to Zero 4A21 02 - Second byte of destination memory location 4A22 4A - First byte of destination memory location 4A23 New code starts here so the value of 4A23 is place into the program counter(PC) or it is incremented by two to this address. In an assembler it would look something like Initiate: LDA,9 MainLoop: Loop content Code here BNE MainLoop exit loop to continue your next section of code. A third important aspect to know about is the stack which stores information for JSR type commands. JSR is Jump Saving Return and pushes the memory location your code will be returning to after the jump to other code is executed and the return instruction is encountered. The stack kind of takes care of itself, but if you start pushing and pulling your own values into and out of the stack, then you better keep track. That loop you are in, if it does any pushing or puling from the stack, better be null by the time you are done. If you push and pull equally from the stack you will be fine. But if you push something onto the stack and you don't pull it from the stack before utilizing the return instruction, the address will be buried under the data you pushed onto the stack, thus it will go to whatever memory location is equal to the values on the stack, which could be anywhere.

You brought back a lot of memories. LD B,0? XOR B,B! Probably the first "improvement" I learnt. Keep well m8. 😃 🖖 🇦🇺

it is very instructing, thank you !

I usually explain it like that: You know what register is ? That's "thing" in which you write bits and it stays there. Now lets look at 74xx chips of standard logic what we see? One of those chips is "register" and as we could see from description it works exactly as you expect from "software" point of view on "register". But now lets look how that value is stored - there is an actual voltages on pins of that register which represent bits you write into it. And with voltages what you can do ? You can control things. Like make LED light or turn on relay and such. So with that voltages you can control actual finite state machine which would generate other sequences of voltages like paper tape with holes make mechanical piano play music. And that finite state machine decompose each "cpu instruction" into series of elementary micro steps like "enable that circuit" or "switch that multiplexer" and such. So thats how cpu "knows" what to do with each instruction opcode.

First of all, thanks an informative video. I'd just like add a few things to the subject: Nowadays the programs (the opcodes) are stored in the main memory but it was not always the case. Originally the "computing machines" were more thought as super calculators because it was where the need arose first. Mechanical or electromechanical devices had data separated from the "code" that took the form of a hardware configuration. This was tedious and error prone. The idea of making the configuration virtual by storing the configuration as digital values was a novelty that got the name "stored program computer". Some CPU architectures still use separate spaces for code and data (Harvard architecture). All the "regular" machines that we use today come from the famous Von Neumann paper (the original sin of computing). This paper was a mathematician's view on how to use an automated device to perform calculus and only this; using that era's technology. How to decode a formula expressed in text form and compute (evaluate) its result. The issue is that that specific paper for a specific task was generalized. It went from: This is A way to build a computing device to: This is THE (only) way to build a computing device There are many other structures and means to perform computing tasks, many of which are not sequential. The first one that comes to mind is neural networks. But unfortunately the Von Neumann model (Y shape with arrows) has "polluted" the minds of all engineers. This is why it is often difficult to get away from the "sequential mind bias" (parallel programming). The machine code of a CPU is the "grammar" of that CPU and gives it it's "personality". This is carefully crafted because it is what the programmer will "see" from the CPU. This is evidenced by the acronym ISA (Instruction Set ARCHITECTURE). The coder is supposed NOT to know and not need to know how the instructions are actually implemented. This is "at the discretion of the implementer", a form of "API" to the CPU. The only way "construct complexity" out of thin air is to implement an FSM (Finite State Machine) in some way. This state machine is the link between the instruction opcode(s) and the internal logic components that actualy perform the intended operation. This is why the internal logic can be completely different from what is seen from outside (the Z80 has a 4 bits ALU, see Ken Sheriff's work). The instruction decode is only the first stage of this FSM. An operation symbolised by an opcode is rarely if ever performed in a single step of the internal logic. Most 8 bit CPUs like (8080, Z80, 68xx, 65xx) implement this in combinatory logic with a special note for the 65xx family that uses a ROM as a first stage. Because the CISC (x86 etc...) CPUs have become increasingly complex this has been replaced by microcode. The actual hardwired state machine is replaced by an internal, hidden CPU that runs that microcode. Because there has been an inflation of modes, flags, security conditions etc... the number of clock cycles to execute a single top level assembler opcode has increased (sometimes 20 or 30). As opposed to this the RISC design paradigm does the exact opposite. Most of the RISC CPUs seek to increase execution sped by using as few cycles per instructions as possible. The only business of the CPU is to EXECUTE code not make decisions it has no information about. All complex decisions are delegated to the compiler. This is only the CPUs that are inspired by the Von Neumann model. There are many "funny" CPUs even designs that seek to use analogue attributes of electronic components. These are usually, very application specific and require interfacing to the standard digital world.

The answer to the students question (a true answer, actually) about how a CPU executes binary machine code, is that the CPU is running a program written in micro-code that carries out the necessary operations to implement the machine code.

"the cpu. how's it work" (cue the full contents of a bachelor's degree in computer engineering)

I would recommend the book But How Do It Know to everyone for one of the best explanations on how a microprocessor works.

Interesting question I guess the CPU is built in such a way that the flows of electrons can open a series of minuscule gates in the transistors of certain kinds and that they can be arranged and built up to do basic computation? Who knows is like magic lol

If that kid really wants to understand they just need to go an implement an 8bit cpu from scratch in verilog on an FPGA. Then they'll understand the basics. I do understand why they would ask though, today everything CPU/Computer wise is stupidly complex, you'd struggle to understand how everything actually works. Those of us who started this journey as children back in the 70's and 80's had a much easier time, you really could understand exactly how a CPU and computer worked back then. The manuals even came with the full circuit diagram of the machine.

This is a long video that, to be honest, does not explain what your student have asked. If someone wants to know how a computer really works, this is the best explanation ever! @BenEater 8-bit computer

Don't know if the Z80 has any, but the 6502 has "illegal opcodes" which do strange things according to the decode matrix, as the bits of the opcode define what to do and what to do it to (with the later 65C02 locking out the functions and treating all the undefined as NOP of varying cycle time)

The array of dots is the instruction decoder (ROM). It's basicly just a lookup which is hooked to the internal control lines of the ALU and other parts of the chip. This decoder ROM is basically the physical predecessor to microcode.

I would of shown him "Ben eater" an amazing channel, I believe he built an 8bit computer on breadboard with wires(many many wires) lol. he also shows each part in working order, how and why if I remember correctly.

For a complete understanding of how a CPU works, you could do worse than to watch the series of 45 videos by Ben Eater as he constructs the SAP-1 (Simple As Possible) computer on breadboards.

New Sub! Detroit, Michigan, US Well Done Sir, Excellent Video!

The box on the cpu circled the cache, not the registers. You can tell because the are organised in rank and file like a grill. The registers are thousands of times smaller in area. A reprise of Turing's tape 'machine' is still a good place to start.

I took a whole semester of Digital Electronics in college to find out how CPUs work, so yeah, not a great topic for a tossed-off answer. It was a pretty cool course, what with designing circuits from scratch with flow charts and voltage timing diagrams, but it also wasn't especially relevant to my programming focus. (Aside from the bit of the final project where I had to hand-assemble a small 8080 program into octal.)

It's hard to give an exact one size fits all sort of explanation to a question like how does the CPU decode instructions. Different Instruction sets allow for different approaches and optimizations when decoding (for example by having categories of instruction types that share the same layout of bit fields), different hardware implementations can be done for those instruction sets depending on target performance, power usage etc. And different architecture types for a certain ISA can have different requirements for a decoder (for example parallel decoding in superscalar CPUs, predecoding, microcodes etc.). Looking at older hardware, which tends to be simpler is a good starting point however. I think working with the abstraction of logic gates and explaining a CPU using a visual logic simulator (like Logisim, DIgital by hneeman etc.) is much more approachable, as it is easier to see individual parts of the CPU and is easier to comprehend. By adding an explanation of how a universal logic gate (NOR or NAND) can be implemented using Transistors, all of the abstraction can be undestood.

A simple high level view I use is to think of computers as maps. Memory is like a map with latitude and longitude with each intersection being a physical address or bit that we choose to be on or off. All these addresses have roads connecting them. All roads lead to rome also known as the cpu. Just like rome the cpu controls all the roads with instructions. As the user we are the caesar.

I would add that even though it LOOKS complicated, it is knowable and understandable! There is a path to unraveling and understanding the complexity of a CPU. Ben Eater has a nice video series where he builds a CPU using only simple logic gates: kzfaq.info/get/bejne/ft-qodWVqbm3d4E.html Having a degree in electrical engineering is not really a requirement. This is completely within reach for anyone who is curious and persistent.

I was confused by the program to add two numbers. Register b cant be (conveniently) loaded from memory, so num1 is loaded to the accumulator and transfered to b. But b never needs loaded with 0 and the first add a,b instruction is redundant.

I taught it to primary age as a set of pigeon holes each with a number in it (RAM) and a set of instructions on a piece of paper (if the number in hole 45 is less than 25 then xxx and so on). Then I let them play with it for a bit. Then you talk about encoding the instructions as numbers also in pigeon holes. They kind-of got it at that point.

My first computer was a trs80 with a z80 chip in it. It was like star trek in our house when we got that 😆

So i get how a Z80 , and a 6502 work , and i use a model that is some sort of unholy mix between the two when im programming... now here is my question ive been trying to update that mental model for many years but cant seem to find anything up for the task... in my mind a cpu is always loaded 100% and doing instructions as fast as it can each clock cycle, (well with a little instruction decoding as preparation for the actual thing happens) here is the problem,... mow does a modern pc (or even the latest single core ones like a Pentium IV) know when not to run at 100% load , or even clock down its speed , or put it differently why does a loop waiting for input (not from a irq but from something that is polled like usb)not peg the core at 100% load (using a nonblocking check inside a while 1{} for instance

This video by Technology Connections (and I see he’s posted Part 2) kzfaq.info/get/bejne/q8tdZK2gr7fFdZs.html shows how a technical pinball machine works. The long and the short of it is that it too is using electricity to move stuff about so that it can keep score, change the state of paddles, bumpers etc, detect input. After watching this video of yours, I kind of feel that the two are distantly related, even though they are very, very different beasts.

Send him to Ben Eaton's excellent videos where he builds a cpu out of conventional logic gates on a prototype board.

Tell your students to build a bit adder in No Man's Sky. It is easier than one might think and will show them the electrics and logic of what is happening.

Your use of Seventy-Six implies a decimal number, not hexadecimal - imo "Seven Six" would avoid the confusion.

6:20 индусы код писали? Зачем столько лишних операций? ld a,(num1) ld b,a ld a,(num2) add a,b halt Зачем лишние сложения с нулём в начале?

a deep dive in 15 minutes eh....

Your audio is 15 dB down.

Why so many AI generated melted and artificial graphics? Interesting content but still - why? The "motherboard" has no chance of working and the spurious ceramic caps make no sense. It's like a bad dream or halucinations...

Unnecessary white-space is an indication of dreadful programming ability.

amazing video , thank you.

Microcode are the steps on the processor that tells the processor how to execute the machine code. I takes the machine code and then switches the right hardware lines to move a number from the data bus to the relevant register. This is why some instructions take several clock cycles. That’s what the “unknown” block in your video is doing. en.wikipedia.org/wiki/Microcode. Intel processors have complex instructions set that can perform many steps in on instructions, whereas RISC processors have simpler reduced instructions and smaller microcode.

Your simple diagam should have included the actual first code source or the BOOT ROM!!!