Interrupt handling
Hi everyone and thanks, as always, for your continued support! Here's the next video in the 6502 series. Here I build on some of what I discussed about how the IRQ pin works and use the 6522 versatile interface adapter to trigger an interrupt when we press a button, and then discuss how the 6502 services the interrupt and tells the 6522 to clear the interrupt.
As always, feedback is much appreciated. I'm planning to release the video this weekend, so definitely let me know if you catch any mistakes or anything else that can be improved between now and then.
Thanks,
-Ben
Comments (10)
I'd always learned that you should spend as little time as possible in your interrupt handler. Would it be better to just set a flag somewhere that we need to increment the counter, clear the interrupt, and handle the actual increment and debouncing in the main program loop?
Not a Technical observation Ben, just aesthetic: The Code screens look very dim..... otherwsie, excellent content, loving this series....
Great video, thanks. Only thing I noticed is that at about 15:48 you say that flags are pushed and pulled to and from register, that should of course be stack.
Hi Ben, Thanks for the great videos! I used to code z80 back in 1980s when I was a kid, and now things that were fuzzy those days make total sense to me, after watching your channel. Did you consider adding a simple video adapter to the computer, so that it could be connected to a VGA display? I saw your video about "the worst video adapter" but it is not clear to me how the video adapter and MPU could simultaneously access video memory.
I actually bought the 6502 Computer kit myself to do exactly this! I'm by no means at Ben's level when it comes to hardware designs, but the plan is to use the same "worst video adapter" and actually share the RAM chip. I have ordered both the Octal Bus Transceiver that was used in the 8-bit computer, and some AND gates that have 6.5 ns switching times so hopefully will have as little missing pixels as possible as the Transceivers are quite slow (40 ns) especially with the graphics running at 10x the speed. But I intend to make Pong with this so most of the screen will be black anyways so I have that going for me. I also learned about Memory Banking recently as well where you can have multiple memory chips at the same address but select them with the 65C22 or similar chips so that's a future improvement I plan on trying as well.
Nice video indeed! One question: at 23:26, would it be ANDing multiple 6522s together, or ORing them?
+1 for nybble :3
Nice video, very clear as usual! Some suggestions: 1. Note that traditional 6522s used an open-drain IRQ output pin, and for those you need a pull-up resistor, e.g. 3k3 I don't have a WDC one to verify but I'd expect this to also do no harm even on their versions that don't require it 2. When dealing with the IFR and IER, using plain hex numbers gets quite confusing - it's much clearer if you define some bitfield flags at least for the bits you're using, and 'or' them together, e.g. IER_SET | IER_CA1 3. In the past I've found that a single count-to-255 is fine for the debouncing with no perceptible delay, so then there's no need for the outer loop. It'll depend on the clock speed though I guess. 4. I'd definitely prefer to wire the buttons through to data pins and sample their states after the delay, before going ahead and increasing the counter. The button can bounce on being released as well as on being pressed, and you only want to count up if, after the delay, it settles in the "on" state. Hopefully you'll be covering that in the next video though. :)
Great idea with the bitfield flags! Makes it much nicer to read :)
Did the datasheet paper get brighter? It's really really white.