Hardware interrupts

------------------

Social media:

Special thanks to these supporters for making this video possible:
Adrien Friggeri, Alexander Wendland, Andrew Vauter, Anson VanDoren, Anthanasius, Armin Brauns, bapu, Ben Dyson, Ben Kamens, Ben Williams, Bill Cooksey, Binh Tran, Bouke Groenescheij, Bradley Pirtle, Bryan Brickman, Carlos Ambrozak, Christopher Blackmon, Daniel Jeppsson, Daniel Sackett, Daniel Tang, Dave Burley, Dave Walter, David Brown, David Clark, David House, David Sastre Medina, David Turnbull, David Turner, Dean Winger, Dmitry Guyvoronsky, Dušan Dželebdžić, Dzevad Trumic, Emilio Mendoza, Eric Brummer, Eric Busalacchi, Eric Dynowski, Eric Twilegar, Erik Broeders, Eugene Bulkin, fxshlein, George Miroshnykov, Harry McDow, HaykH, Hidde de Jong, Ian Tait, Ingo Eble, Ivan Sorokin, Jason DeStefano, Jason Specland, JavaXP, Jay Binks, Jayne Gabriele, Jeremy A., Jim Kelly, Jim Knowler, Jim Van Meggelen, Joe OConnor, Joe Pregracke, Joel Jakobsson, Joel Messerli, Joel Miller, Johannes Lundberg, John Fenwick, John Meade, Jon Dugan, Joseph Locke, Joshua King, Kefen, Kenneth Christensen, Kent Collins, Koreo, Lambda GPU Workstations, Larry, Lucas Nestor, Lukasz Pacholik, Maksym Zavershynskyi, Marcus Classon, Martin Roth, Mats Fredriksson, Matt Alexander, Matthäus Pawelczyk, melvin2001, Michael Burke, Michael Garland, Michael Tedder, Michael Timbrook, Miguel Ríos, Mikel Lindsaar, Nicholas Counts, Nicholas Moresco, Örn Arnarson, Paul Pluzhnikov, Paul Randal, Pete Dietl, Philip Hofstetter, Randy True, Ric King, Richard Wells, Rob Bruno, Robert Diaz, sam raza, Sam Rose, SonOfSofaman, Stefan Nesinger, Stefanus Du Toit, Stephen Kelley, Stephen Riley, Stephen Smithstone, Steve Jones, Steve Gorman, Steven Pequeno, TheWebMachine, Tom Burns, Vlad Goran, Vladimir Kanazir, Warren Miller, xisente, Yusuke Saito

[plazmotech]

I love that Ben plays dumb and goes through all the mistakes and issues a beginner might have, showing us how we would troubleshoot something like that. It makes it much more informative, engaging, and relatable than if he just told us exactly how to do it perfectly first try.

[rowdee]

"Apologies for the INTERRUPTION..." I'll let it slide this once.

[billkendrick]

Absolutely love how you go through the process, failing a few times, and "discovering" why. It makes learning a lot smoother than just being told "you must do X, Y, and Z", and never find out what might happen if you only "do X and Y".

[jared]

Ben, I'm a firmware engineer and I love your videos, they are relaxing and easy to digest. What you do is a public service, your videos are a perfect starting point for so many students and enthusiasts. Hats off to you, keep it up!

[corydoras]

Videos from Ben Eater are always a NMI - drop everything, watch video, continue with what I was doing before.

[alexismandelias]

Make the interrupt shock you with some voltage so you release the button quicker

[doctorbobstone]

"Apologies for the interruption..."
Interrupt acknowledged.

[menhirmike]

What I really love about the videos is that you go over failure scenarios. That helps much more than just "Here's how to setup an NMI interrupt, like and subscribe". That makes it so much easier to troubleshoot when stuff doesn't work when I recreate things.

[PhilipSmolen]

Lesson 1: Hello world. Lesson 2: Interrupts.

[fire_silicon]

Congrats on 555k subscribers! Nice timing :)

[joeemenaker]

I love how Ben manages to sound momentarily perplexed about why it's not working (when he knows _exactly_ why it's not working and he knew it was going to do that from the start).

[renakunisaki]

One thing that's worth noting: whenever the IRQ line is pulled low, it sets a flag inside the CPU. Whenever the CPU is finished an instruction, if that flag is set and interrupts are enabled, it services the interrupt. So, disabling interrupts doesn't actually _prevent_ them, but _delays_ them. Once you enable them again, any pending interrupts are serviced.

Of course, it's only a flag, so even if 1000 interrupt requests happen while disabled, it will only run the handler once. It is also possible to manually clear that flag without actually handling the interrupt.

[HenrikDanielsson]

<3 Perfect timing! Just ordered a bunch of parts I was missing to start this project!

[nullplan]

"You don't want to use NMI in normal operation." Nintendo: "How about an NMI on every VSYNC?"

[WintonMc]

So that's how it works! When I was 15, I was a wizard with Commodore Basic, and I had a bit of a go ar machine code/ assembly programming, but never got very far because the learning resources available at the time were nowhere near as good as Ben Eater videos. All these years later, and suddenly Interrupts make perfect sense. Thanks Ben. 😃

[troyscheffel]

I just discovered Ben Eater's YouTube videos and electronic kits today. I quickly ordered the 6502 kit and several others. Having cut my teeth on 6502 programming back in the day on my Apple //e and later a IIgs (both of which I still own), I love the purity of 8-bit assembly language (it just makes sense; everything is clean). Kudos to Ben for his absorbing teaching style. I look forward to many adventures with his videos and kits.

[Mystixor]

What I love so much about your videos is that you take the time to discuss all the faults and misconceptions one could encounter. This builds a deep understanding of the matter and enables us to think the concept further ourselves.

[OllAxe]

One other use case for the NMI is synchronizing your program with a timer of some kind - it's perfect for highly timing critical code! One example of this in practice is the NES, which used the NMI to detect and react to the start of the vblank interval of the TV. As you showed, it's very easy to run into race conditions if you're not careful about how you access memory between the nmi interrupt handler and the rest of the code. The easiest solution is to avoid shared memory access between the rest of the program and the nmi to the greatest extent possible, and to really consider all cases where an NMI could occur when shared memory access is required.

[xbzq]

You can actually make the counter go up only once just from software:

in_irq = $020c ; 1 byte

...

reset:
lda #0
sta in_irq

...

irq:
pha ; save accu
bit in_irq
beq not_in_irq
lda #0

; we were already in the IRQ handler here
pla ; remove accu from stack (original is still on previous stack)
pla ; remove flags from stack
pla ; remove return address from stack
pla ; which is 2 bytes
jmp await_irq_off_loop

not_in_irq:
; actual handler goes here
inc counter
bne no_overflow
inc counter + 1
no_overflow:
; end of actual handler

lda #1
sta in_irq

await_irq_off_loop:
cli ; if the IRQ is still active, this will immediately recursively cause another interrupt

sti ; prevent a second interrupt from interrupting the following code
lda #0 ; if we've reached this instruction, the IRQ is off (pin high)
sta in_irq
pla ; restore accu
rti


Basically, when we re-enable interrupts inside the interrupt handler, the interrupt handler will get called again. By knowing when this occurs (flag in_irq), we can remove the stuff from the stack and continue on with the awareness the IRQ is still active. I'm not familiar with the 6502 so this code may not work or it may be more succinctly written.

[alexisraels]

Hi I am a soon to graduate Computer Engineer and your channel is literally everything that I have ever wanted to learn in school but still haven't. I am so beyond excited to binge through all your content. Thank you so much for sharing this information!