Man I can't tell you what amazing information this all is, and how professional your presentation is! The only reason this channel isn't huge is because its a pretty niche audience but know that to this crowd you're a godsend
Thank you! Yeah, with these old 8-bit systems I think it makes good sense since there is such an interplay between the two. And also… who doesn’t like getting really close to the metal?
Hi Ryan, thanks a lot for this phantastic video. Especially the combination of a look at the hardware and some actual code makes your video so helpful to fully understand the NES. I am interested in creating a homebrew game myself, so your channel is highly appreciated. One suggestion since you have now presented the normal controller. There are some games for up to four players, which require a special adapter. Perhaps you can talk about this special hardware in a future video.
It's been well documented the way an NES controller works (being a shift register the most popular IC in RUclips) but it's always nice and fun to have another perspective. Thank you.
Can you tell me where to go to research information on "micro PCB circuit boards" to make a micro controller for NES that works on NES original console/hardware. That has a ability to have direction on D-pad and/or buttons A/B to have auto-fire turbo capabilities? All the while working without the need for any external programs running on a PC like Joy2key, Rewasd etc....So basically all the turbo functionality is self-contained within the pad controller itself. Somone said something about altering the shift registers to produce turbo. How do I find info about that? Googling it does not really bring anything up but pre-made third party Turbo controllers and that is not what I am talking about.
@@rebranded1248 either I don't understand what you want or I haven't seen that type of gamepad, I saw a gamepad with extra 2 A and B buttons that fires rapidly, and I can't think of how to build one of those from scratch, but it shouldn't be terribly hard to build up.
@@deltakid0 I am talking about a micro controller where you switch out the original NES OEM circuit board and replace it with a ardruino micro controller board. That way you can have a NES controller with hidden auto fire and macros. I suspect there might be a couple speedrunners who do it professionally and they are indeed hiding the fact they are using micro controllers with auto fire. It would have to be a micro controller cause the NES controller needs to retain auto fire ability independant of wether or not it is plugged into a PC or not. Just needs to have that special function if it is plugged into OEM NES console.
@@rebranded1248 well, Arduino is the first option to come up when you need to prototype something, so, yeah, I think it's just an Arduino or even an ATTiny85 to solve your need, I would prefer the latter because of size so that you can fit it in the retail gamepad
I'm so happy I found your videos I've been trying to understand NES programming for quite some time. To the point of getting NESMaker, buying a book by Steven Hugg, and even hiring a tutor, which is kind of frustrating given I am a programmer for my job. Your videos are starting to help everything click. If you have a patreon I'd love to subscribe to support the channel and if you ever want to develop a course consider me your first student.
Wow, that's very high praise Tim, thank you so much! I'm exceedingly happy that you find my videos helpful as you're the kind of person that I had in mind when I decided to make the channel :) I don't have a Patreon at this time, but you're the second person to mention it today... so I should probably consider getting on that, lol. If / when I do set one up I'll announce it in a supplemental channel video. So just stay subscribed and setup with alerts and you'll see a video when I release it. Thanks so much for watching, and get pumped cause part 3 of the 6502 assembly crash course is scheduled to drop in two weeks ;)
@@NesHacker I'm really excited to see it. I don't know if it's because my job is basically coming into departments assessing how reports are made and data is structures then making them more efficient but it seems like every NES resource out there is "do this to get that" and none of them explain why you're doing what you're doing or what the code is actually doing. NESMaker is really awesome but basically you're working within a giant set of code that was pre-written and trying to read through the variables is pretty difficult. The Steven Hugg book is written for a specific NES library in C which again is a "do this to get that". All of that isn't really helpful to me. I think when it comes to NES there are basically the structure: How to draw a background (how to switch background tiles) How to move from one background to another How to draw a sprite to the screen How to animate a sprite How to make the sprite collide with things How to use bank switching How to use ROM vs RAM for graphics Those are the things I'm struggling wrapping my head around. I'm really hoping since I code anyway all the time that something will just click with NES and I'll off and running. Thank you so much for this channel though, it's already so helpful.
Awesome channel, brother; I just watched a bunch of your videos and subscribed. Thanks for the super informative and well-edited videos, can't wait to see what comes next!
Wonderfully done explanation! The pacing is fantastic and the information is presented in a nice, visually appealing and logical manner! Can't wait to watch more videos 😎
Thanks for this, I’m enjoying the series. I’d love to see some discussion about how to call this and react to inputs. Do you do this at the start of the NMI to check for game inputs on each frame?
Yeah reading inputs every NMI is definitely the easiest way to go. That said, you only have around 2200 cycles to play with during the VBLANK to update the PPU VRAM. So if your VRAM update code is very tight you might need to save the NMI cycles and use a flag in RAM somewhere so the non-interrupt code can break out of the infinite loop and perform the read while the screen is being rendered by the PPU.
Yeah they really messed up with the SNES… 12 buttons and 16 bits?! That’s not mathematically pleasing! At least the controller works exactly the same way xD
Thanks! That was a super fun animation to make. So the exact chip most likely changes for each of the specific system models, but according to the schematic the original famicom used two 40H368 3-state logic drivers to do the trick (each port used one of the inverters on each of the chip). The mechanism of operation is a bit complicated since those chips are used for more than just inverting the incoming button data. Here’s a link to a modern equivalent: www.ti.com/lit/ds/symlink/cd74hc367.pdf
It depends on situation. For things like menus and the like button bounce might be handled by waiting some amount of time to ensure the player is pressing the confirmation button. For most gameplay, however, responsiveness is more important so generally you don’t try to denounce the inputs (remember the NES runs pretty darn slow even compared to modern hobbies microcontrollers).
That’s true, I suppose you have negative voltages sometimes! I’m just so used to only working with digital logic so I always think of ground as “low” when perhaps I should think of it as “zero” 🤔
I remember back then for some reason I took apart my NES controller , stripped the wiring and I tried to attach to my Atari plug . I was young and did not know much about testing but I never got it to work . I wonder if you can actually use a NES controller on a original Atari system . Has anyone tried this before ? Great channel by the way . Thanks
Atari controllers don't have a shift register. Each pin is used for a different input (Up, Down, Left, Right, Button). You'd have to completely rewire the controller's innards to make it work. You can, however, use a Sega Genesis controller on an Atari because they both use the same shaped plug with the same directions for the same pins. Several other systems work as well.
Wow what a great explanation. Your visuals make it so much easier to grasp. For future such videos, it might be of interest to give an idea of the number of clock cycles such a routine requires, and to compare that with the actual time it represents. One question: I've noticed in GameBoy ROM disassembles that joypad inputs are read multiple times in a row, and I assume it's to limit mistakes, but I don't understand how that helps. Is it also the case for NES controllers? Thanks so much for your excellent work. I look forward to supporting you on Patreon when your page is launched.
From what I can see, the GameBoy requires this as the values in the joypad register may not be set immediately and require you to perform multiple reads. I am unsure as to why this is the case, as I’ve not done much tooling around with gameboy programming. NES controller reading doesn’t require this. As I showed in the video you simply need to “strobe” the controller, then proceed to read each of the bits one at a time.
This video came in more handy then you could possibly know. I have maybe a tote full of NES systems with no controllers to test them. Now I don’t need one exactly. Thanks.
@@NesHacker I actually found NOS wireless NES controllers at a thrift store. For a dollar I picked up a few. I originally wanted to see if it worked for the system I have. Upon further review they went to some remake edition that didn’t use cartridges.
For the longest time, I thought the NES used the same 9-pin connector as say, an Atari. Obviously I was wrong. Never owning a NES but owning one of the many Fami-clones out there that used the 9-pin connector, I thought the NES would be the same. It makes sense though why I would think that ... 9 pins, one pin being common, the other 8 pins for the 8 buttons.
It's interesting that they used an integrated circuit on the controller itself to digitize the controller inputs before sending them to the NES. It seems it would have been cheaper to skip the IC within the controller and send the analog signals from the button presses to the NES to be digitized, but I guess this didn't work as well. I wonder if earlier game consoles did something like that.
If you didnt have the shift register you would have to have 8 wires returning instead of 1. The shift register makes it so that you can send a string of 8 bits back over one wire which tells you which buttons have been pressed rather than having one wire returning per button. Apparently wires were more expensive or something compared to the IC in the controller. Doesn't make a lot of sense to me either.
that controller is the sturdiest bit of engineering I have ever used. I was a little bastard as a child, and I could break almost anything. but no that brick of a controller. until I retired my NES I still had and used my original controllers. none of my other consoles could make that distinction.
I there are only 5 buttons on an NES controller “A” button 1 “B” button 2 Start button 3 Select button 4 and the D-pad 5 where does he get 8 from does each direction on the D-pad count as a separate button? If so then it would be “A” button 1 “B” button 2 Start button 3 Select button 4 up direction 5 down direction 6 right direction 7 and left direction 8 so if you count each direction on the D-pad separately as opposed to the D-pad as one button then yeah there are 8 buttons
Can you tell me where to go to research information on "micro PCB circuit boards" to make a micro controller for NES that works on NES original console/hardware. That has a ability to have direction on D-pad and/or buttons A/B to have auto-fire turbo capabilities? All the while working without the need for any external programs running on a PC like Joy2key, Rewasd etc....So basically all the turbo functionality is self-contained within the pad controller itself. Somone said something about altering the shift registers to produce turbo. How do I find info about that? Googling it does not really bring anything up but pre-made third party Turbo controllers and that is not what I am talking about.
So if I have an SNES controller hooked up to an NES, and I want to read the controllers extra 8 bits, I just need to have 2 loops and read the other 8 bits into another memory location, correct?
Conceivably, though I’ve never tried it… I believe the SNES controller just has two shift registers in series to register all 12 bits of button data. Would definitely make for a fun experiment!
I know I'm super late to the party but, amazing video - thanks for sharing ! Out of curiosity, some FC controller models appear to have a 15 pin interface, would it possible/feasible to rewrite the controller input pooling routine so it could read a more "modern" controller, with at least L and R? I feel like this could open so many tools for romhacking and modders to add ergonomics into NES games such as zelda1 to swap weapons for example.
Yep totally feasible. The SNES controller is almost exactly the same except it has two shift registers which holds the value for all of its buttons. Basically you can use the controller ports as a general serial port as long as the game is programmed to use it that way.
So was writing code back in those days the same as writing code today ? Besides the new updated stuff that they have added for newer tech, is the basic code writing from today the same as back in those days ?
The communication sounds exactly like an SPI protocol. Assuming the limiting factor is the chip on the controller, It should be easy to replace it with a modern microcontroller with a higher clock frequency to decrease latency and improve response times.
It is similar, but you gotta remember: games execute specific instructions at a particular clock speed, so even if you increased how fast the chip on the controller worked it would take the same amount of time due to game code. Also you can easily handle the reading of all buttons in a fraction of a frame, so even if it were faster there would be no noticeable increase in responsiveness.
I thought the NES automatically did this and loaded it into memory, that's interesting to know it doesn't. The explanation is really good as well and I understood it without prior assembly knowledge. It's really cool to learn the ins and outs of hardware like this, as a single person can actually understand the entire system as it's relatively simple.
It’s kinda cool too, cause you can use the controller ports as a general I/O interface that way. There’s no reason why you’d have to only transmit exactly eight bits.
@@NesHacker If I recall some of the TASbot submissions for GDQ have actually used the control ports for general I/O for things like audio playback through the console.
I’m sure most people know this but opposite directions on the D-pad can’t be pressed at the same time for example the up and down directions can’t be pressed at the same time or the right and left directions can’t be pressed at the same time but up and right or down and right or up and left or down and left can be pressed at the same time
I used to do programming on the Commodore 64 which used 4 position joysticks which like the NES controllers should not be able to press opposite directions at the same time, but I can tell you if you move it around vigorously you may get some from time to time. So best to design the code to handle it cleanly.
I once had this one NES controller that was a little messed up I was playing SMB1 with it and the “A” and “B” buttons made the game pause instead of the Start button for pausing I don’t have that controller anymore for obvious reasons (it didn’t work properly)
If I can add one tip to this great video: as an electronics hacker myself, TAKE LOTS OF PICTURES as you go. Buttons, pads screws will get knocked over or you will forget where things went. Trust me.
IDK if the pads on the silicone are printed with a pattern or if the pattern is imprinted by repeated uses. I say this because I took apart these controllers as a kid and never noticed a pattern on the pads, and these controllers were new back in 1985. 😜
Yeah I was having a hard time finding solid information on how those switches work. I’ve only ever seen them with the patterns, but like you say it could be due to use. Thanks for the info!
NES Hacker, what is your view on starting a ROM Hack by finding the subroutine that reads controller input, then stepping through the code from the controller read, then trying to understand that code step-by-step from there. i.e. using the controller read as an organic starting point for code investigation. 1.) Finding whatever subroutine loads from $4016 (via searching function list in MESEN) 2.) Set a break point on LDA, $4016 3.) Understand confusing mess of assembly?? Thank you so much for all your great content and amazing videos.
I think that’s okay, but honestly the controller reading code for *most* games probably doesn’t have much to do with the actual game logic. For instance, a game like MegaMan 2 has at least 6 distinct controller contexts: Main menu, Boss Select, Password Select, Main Gameplay, Start Menu, & Game Over. So the controller code is most likely abstracted out away from the logic that handles those different game states as part of a set of general routines that runs every frame. That said, you can still piggyback off the *result* of the controller code, by this I mean if you can find the memory location where the controller buttons are stored, you can use it to find code that reads and reacts to that code. By combining this with other memory locations you can setup breakpoints that can pinpoint the exact location for code that handles various things (e.g. handling of the D-PAD buttons on the boss select or the code that initiates a jump for MegaMan himself, etc.).
Something I found really strange is that some official NES controllers are not cross-compatible in different regions. I believe the 101E models will only work on PAL system while the normal 101 will work on either. I'm also curious about something. You say the controller can receive inputs from the NES. I was wondering to what extent this could be used. Like, let's say we had a theoretical NES controller with a little LCD display ala the Dreamcast. Would it then be possible to send picture information to this little display while you play if the controller had some ram onboard to handle it?
Yeah, so there are apparently PAL consoles included diodes on the controller ports, which require the controller itself to pull the clock and latch signals high in order to operate correctly. The PAL version of the NES-004 has a 3.6K Ohm resistor pulling both lines up to high voltage. As for using the ports for external communication, I’m pretty sure this is possible (from what I’ve read) but I haven’t tried it myself. Might make for an interesting experiment to document in a video :)
It sounds like the longer route on how Modems work. Encode data into signals and have them converted back into readable data on the other side in the console. This kinda explained me how they could send all eight buttons through mere 3 data + 2 electricity cables, unlike other contemporary consoles with cables that weighted more than the controller itself! And the blacked out graphite pads above the main buttons pads on the PCB are just resistors??
Yeah pretty sure they are, I was reading around 50k Ohm with my multimeter when I tested across them (though that’s probably a bit high since there is probably some amount of corrosion on the test points and pins I was using as contact points). Also one side is connected to high voltage and the other connects to the button switch / pin trace, so the only thing they could really be is the pull-up resistors for the button switch circuits.
@@NesHacker And me thinking they were left overs from the 2nd player or japanese FamiCom controller PCB designs and that I should scratch and tap to see what they do, haha! Now I see it's a terrible idea... Will you point out the differences and mechanics on the FamiCom controllers in a future video? They seem a bit smarter than American ones.
For two controllers you can read the 2nd player joypad from $4017 instead of $4016. In the case of the "Four Score" (4 player adapter for the NES) controllers 1 & 3 are read back-to-back from the the first port, and controllers 2 & 4 are read back to back from the second port. So yes, there are 32 bits of button data: 16 bits from port 1, and 16 from port 2. Good deduction :)
@@NesHacker @NesHacker Thanks. Back-to-back, eh? Meaning every even and odd clock cycle, respectively? That is an intriguing strategy and has me wondering if the only limit on the number of controllers would be the clock speed of the 4021 chip? 🤔
The dollar sign is the conventional notation for hexadecimal in 6502 programming. It could have been written as rol $20 or rol 32 and it would mean the same thing.
You for get to mention that the nes cannot read and process a controller input signal along with a dpcm sound signal atonce,that’s because they share and use both the same pin,most early nes games had no dpcm audio,trough,nes games that did supported dpcm audio, solved that problem by comparing button presses with it’s own interprationss(because the nes always assumes that a button was pressed),and if they match the button presses will be considered as legit,if it finds no match,it rejects it,another option would be to disable dpcm playback during button presses,or it could ignoire button presses during during dpcm playback during button presses(wich could be ideal during cut scenes when theres no game play) Supermario 3 for instance uses an comparision algorithm and surprisingly enough theres no input delay at all,or atleast it’s unoticible for us(alltrough i do hear story’s about speedrunners complaining that the duck jump doesn’t alway’s get’s registred), well i would be not surprised if supermariobros 1 plays just slightly smoother because of not using the dpcm channel at all, Not this issue has been solved on pal nes systems,but i don’t think that pal games were adjusted with this fix in mind,maybe some pal games?? (Wich may explain why they could behave strange on a ntsc nes because of this aside from timing issues??? ) but not sure, but it’s interesting to examin that.
I can't believe that the controller's "brain" is just a shift register. I was expecting something more complicated like the PSX controller. I guess I shouldn't be that surprised.
7:15 that number 4021 in Toronto Canada where I live in our old streetcar fleet (which is now retired we have new streetcars now) but one of the streetcars in our old now retired fleet one of those old streetcars had the fleet number 4021
13:11 there it is LSR not shift and INVERT. it wont invert value its allready 1 if button was pressed. your graph show it invert, bcoz u thing controlled do what you say, but looking 4021 chip its doing opposite with those pullup resistors and input are inverted button press is 1. code not invert why cant we just read $4016 when data is there or there is circuit when read it clock and new serial bit come and LSR shift right bit 0 move to carry and in not INVERTED and i was nice i tested it button is 1 i know circuits you not know 6502 LOL LSR not invert bit its allready 1 when button is pressed. now you know
i love the channel and production quality. but the accentuation and pauses on random words makes it hard to follow and sometimes annoying coupled with the abstract words means i loose track of what hes actually saying. the animations are beautiful and very professional but sometimes they dont really show what hes explaining so end up being more distracting than helpful. anyway great videos and great series i love to learn more about all these details.
11:16 I never understood why when talking about numbers like these they have dollar signs we’re not talking about money here like next to where it says “4016” it has a dollar sign and I’m pretty sure we are not talking about four thousand and sixteen dollars here so why the dollar sign?
I love the content, just watch your cadence, it sounds (tonally) like you are repeating the same sentence over and over again and makes you sound like a bit of a robot lol
I never even considered that there might be people who did not just intuitively understanding precisely how they were put together and function both from a hardware and software perspective. common Sense really
I think it is to allow for more complex controllers or specific ones for games. The controller ports are basically just serial ports so it wouldn’t even have to be a controller plugged in.
The NES doesn't have an operating system, (or rather the game on the cartridge is the OS) and there's no hardware in it to scan the controller regularly as that would cost more money to add. Leaving it up to the game code is the simpler option, and it doesn't take up enough time or code space to be worth doing differently.
Yeah a lot of people get *really* angry for call-outs like that. It’s a method that is often espoused by “insiders” and the like when you google stuff like “increase subscribers”, etc. I tried it out, but honestly, I can take it or leave it. Decided to simply ask at the end of the next video. The biggest problem is this, though: people who would indeed have liked or subscribed often forget to do so without call outs. So I’m kinda stuck, right? More subs and likes are good, but pissing people off is bad.
You push a BUTTON and it RESPONDS - There I saved some time for a lot of PEOPLE.... Actually - It is quite interesting how early and then later controllers worked...
Why do people do that “up-down-up-down” talking thing when they read stuff in front of a camera? Just say the things 😂 no need to bash us over the head with weird inflections. I swear that social media has changed the way people present information for the worse lol
Reading something “normally” is much harder than you’d expect. If you watch across multiple videos you can see my voice pattern changes quite a bit, and more recently I’ve tried my best to get away from that particular pattern. That said, it’s still rough… especially when everything is completely scripted.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Man I can't tell you what amazing information this all is, and how professional your presentation is! The only reason this channel isn't huge is because its a pretty niche audience but know that to this crowd you're a godsend
Yep, I didn’t make this channel to “get huge,” I made it to for people like yourself who appreciate the craft of 8-bit game creation :D
Can't get enough of your videos! Found the channel recently and the mix between hardware explanation and assembly code is right up my alley.
Thank you! Yeah, with these old 8-bit systems I think it makes good sense since there is such an interplay between the two. And also… who doesn’t like getting really close to the metal?
until I saw the title I didn't know the controller needed explaining. You learn something new every day!
I just found your channel randomly. I haven’t even though about nes in years, but now I think I have a new hobby!
Hi Ryan, thanks a lot for this phantastic video. Especially the combination of a look at the hardware and some actual code makes your video so helpful to fully understand the NES. I am interested in creating a homebrew game myself, so your channel is highly appreciated. One suggestion since you have now presented the normal controller. There are some games for up to four players, which require a special adapter. Perhaps you can talk about this special hardware in a future video.
Yeah I’m interested in exploring different things in the future, and more on controllers is definitely one of the topics.
Awesome 'AHA!' moment with the animations about carry use. Great interesting content.
I'm less intimidated by assembly now.
It's been well documented the way an NES controller works (being a shift register the most popular IC in RUclips) but it's always nice and fun to have another perspective. Thank you.
Can you tell me where to go to research information on "micro PCB circuit boards" to make a micro controller for NES that works on NES original console/hardware. That has a ability to have direction on D-pad and/or buttons A/B to have auto-fire turbo capabilities? All the while working without the need for any external programs running on a PC like Joy2key, Rewasd etc....So basically all the turbo functionality is self-contained within the pad controller itself. Somone said something about altering the shift registers to produce turbo. How do I find info about that? Googling it does not really bring anything up but pre-made third party Turbo controllers and that is not what I am talking about.
@@rebranded1248 either I don't understand what you want or I haven't seen that type of gamepad, I saw a gamepad with extra 2 A and B buttons that fires rapidly, and I can't think of how to build one of those from scratch, but it shouldn't be terribly hard to build up.
@@deltakid0 I am talking about a micro controller where you switch out the original NES OEM circuit board and replace it with a ardruino micro controller board. That way you can have a NES controller with hidden auto fire and macros. I suspect there might be a couple speedrunners who do it professionally and they are indeed hiding the fact they are using micro controllers with auto fire. It would have to be a micro controller cause the NES controller needs to retain auto fire ability independant of wether or not it is plugged into a PC or not. Just needs to have that special function if it is plugged into OEM NES console.
@@rebranded1248 well, Arduino is the first option to come up when you need to prototype something, so, yeah, I think it's just an Arduino or even an ATTiny85 to solve your need, I would prefer the latter because of size so that you can fit it in the retail gamepad
Quality content here, good job.
Yeah, this one felt pretty good. Thanks!
I'm so happy I found your videos I've been trying to understand NES programming for quite some time. To the point of getting NESMaker, buying a book by Steven Hugg, and even hiring a tutor, which is kind of frustrating given I am a programmer for my job. Your videos are starting to help everything click. If you have a patreon I'd love to subscribe to support the channel and if you ever want to develop a course consider me your first student.
Wow, that's very high praise Tim, thank you so much! I'm exceedingly happy that you find my videos helpful as you're the kind of person that I had in mind when I decided to make the channel :)
I don't have a Patreon at this time, but you're the second person to mention it today... so I should probably consider getting on that, lol. If / when I do set one up I'll announce it in a supplemental channel video. So just stay subscribed and setup with alerts and you'll see a video when I release it.
Thanks so much for watching, and get pumped cause part 3 of the 6502 assembly crash course is scheduled to drop in two weeks ;)
@@NesHacker I'm really excited to see it. I don't know if it's because my job is basically coming into departments assessing how reports are made and data is structures then making them more efficient but it seems like every NES resource out there is "do this to get that" and none of them explain why you're doing what you're doing or what the code is actually doing. NESMaker is really awesome but basically you're working within a giant set of code that was pre-written and trying to read through the variables is pretty difficult. The Steven Hugg book is written for a specific NES library in C which again is a "do this to get that". All of that isn't really helpful to me. I think when it comes to NES there are basically the structure:
How to draw a background (how to switch background tiles)
How to move from one background to another
How to draw a sprite to the screen
How to animate a sprite
How to make the sprite collide with things
How to use bank switching
How to use ROM vs RAM for graphics
Those are the things I'm struggling wrapping my head around. I'm really hoping since I code anyway all the time that something will just click with NES and I'll off and running. Thank you so much for this channel though, it's already so helpful.
Awesome channel, brother; I just watched a bunch of your videos and subscribed. Thanks for the super informative and well-edited videos, can't wait to see what comes next!
Right on! Yeah I am pumped about the videos I currently have planned, so I hope you enjoy them!
Wonderfully done explanation! The pacing is fantastic and the information is presented in a nice, visually appealing and logical manner! Can't wait to watch more videos 😎
Insanely good video. Don’t know that RUclips has ever recommended me something I enjoy this much.
This video helped me build an interface for a NES controller using VHDL. Really great stuff!
Haha that’s rad :)
"I'll get to that in a Bit"
Don't think that went under the radar :D
Haha, you caught me :)
Quality content. I can watch these all day.
Thanks for this, I’m enjoying the series. I’d love to see some discussion about how to call this and react to inputs. Do you do this at the start of the NMI to check for game inputs on each frame?
Yeah reading inputs every NMI is definitely the easiest way to go. That said, you only have around 2200 cycles to play with during the VBLANK to update the PPU VRAM. So if your VRAM update code is very tight you might need to save the NMI cycles and use a flag in RAM somewhere so the non-interrupt code can break out of the infinite loop and perform the read while the screen is being rendered by the PPU.
You opened a new world -- big thanks!
Enjoy :)
i already knew roughly how nes controllers worked but this is way more in depth
That’s kinda the idea haha 😂
@@NesHacker good video :)
8 bits, 8 buttons. Balance in all things, as it should be!
Yeah they really messed up with the SNES… 12 buttons and 16 bits?! That’s not mathematically pleasing! At least the controller works exactly the same way xD
ps4 controller has 16 binary value buttons which is interesting but likely coincidental
Best channel ever, top content, regards from Brazil
I’m glad you’re liking it, and there’s a lot more in the works, obrigado!
I really like the way you animated the workings of the BU4021B. What I/O chip is the NES using to decode the incoming serial data from the controller?
Thanks! That was a super fun animation to make. So the exact chip most likely changes for each of the specific system models, but according to the schematic the original famicom used two 40H368 3-state logic drivers to do the trick (each port used one of the inverters on each of the chip). The mechanism of operation is a bit complicated since those chips are used for more than just inverting the incoming button data. Here’s a link to a modern equivalent: www.ti.com/lit/ds/symlink/cd74hc367.pdf
What about button bounce? Is that something that the programmer needs to worry about / test for?
It depends on situation. For things like menus and the like button bounce might be handled by waiting some amount of time to ensure the player is pressing the confirmation button. For most gameplay, however, responsiveness is more important so generally you don’t try to denounce the inputs (remember the NES runs pretty darn slow even compared to modern hobbies microcontrollers).
Of note: ground isn't always the lowest voltage on a board. It happens to be on many.
That’s true, I suppose you have negative voltages sometimes! I’m just so used to only working with digital logic so I always think of ground as “low” when perhaps I should think of it as “zero” 🤔
I remember back then for some reason I took apart my NES controller , stripped the wiring and I tried to attach to my Atari plug . I was young and did not know much about testing but I never got it to work . I wonder if you can actually use a NES controller on a original Atari system . Has anyone tried this before ? Great channel by the way . Thanks
Atari controllers don't have a shift register. Each pin is used for a different input (Up, Down, Left, Right, Button). You'd have to completely rewire the controller's innards to make it work.
You can, however, use a Sega Genesis controller on an Atari because they both use the same shaped plug with the same directions for the same pins. Several other systems work as well.
This is really cool to see how the controller actually works. It makes me wonder how it was possible at all to get system to do what it does.
Wow what a great explanation.
Your visuals make it so much easier to grasp.
For future such videos, it might be of interest to give an idea of the number of clock cycles such a routine requires, and to compare that with the actual time it represents.
One question: I've noticed in GameBoy ROM disassembles that joypad inputs are read multiple times in a row, and I assume it's to limit mistakes, but I don't understand how that helps. Is it also the case for NES controllers?
Thanks so much for your excellent work. I look forward to supporting you on Patreon when your page is launched.
From what I can see, the GameBoy requires this as the values in the joypad register may not be set immediately and require you to perform multiple reads. I am unsure as to why this is the case, as I’ve not done much tooling around with gameboy programming. NES controller reading doesn’t require this. As I showed in the video you simply need to “strobe” the controller, then proceed to read each of the bits one at a time.
This video came in more handy then you could possibly know. I have maybe a tote full of NES systems with no controllers to test them. Now I don’t need one exactly. Thanks.
You are very welcome, I’m glad I could help
@@NesHacker I actually found NOS wireless NES controllers at a thrift store. For a dollar I picked up a few. I originally wanted to see if it worked for the system I have. Upon further review they went to some remake edition that didn’t use cartridges.
14:56 The graphics helped a lot to understand
For the longest time, I thought the NES used the same 9-pin connector as say, an Atari. Obviously I was wrong. Never owning a NES but owning one of the many Fami-clones out there that used the 9-pin connector, I thought the NES would be the same. It makes sense though why I would think that ... 9 pins, one pin being common, the other 8 pins for the 8 buttons.
Pirates use 9 pin connectors for theirs famiclones .they have a theyrs own standard for the pin out 😊
It's interesting that they used an integrated circuit on the controller itself to digitize the controller inputs before sending them to the NES. It seems it would have been cheaper to skip the IC within the controller and send the analog signals from the button presses to the NES to be digitized, but I guess this didn't work as well. I wonder if earlier game consoles did something like that.
If you didnt have the shift register you would have to have 8 wires returning instead of 1. The shift register makes it so that you can send a string of 8 bits back over one wire which tells you which buttons have been pressed rather than having one wire returning per button.
Apparently wires were more expensive or something compared to the IC in the controller. Doesn't make a lot of sense to me either.
that controller is the sturdiest bit of engineering I have ever used. I was a little bastard as a child, and I could break almost anything. but no that brick of a controller. until I retired my NES I still had and used my original controllers. none of my other consoles could make that distinction.
It’s a seriously good controller. Here’s to all of us who were tiny terrors back in the day 😂
I there are only 5 buttons on an NES controller “A” button 1 “B” button 2 Start button 3 Select button 4 and the D-pad 5 where does he get 8 from does each direction on the D-pad count as a separate button? If so then it would be “A” button 1 “B” button 2 Start button 3 Select button 4 up direction 5 down direction 6 right direction 7 and left direction 8 so if you count each direction on the D-pad separately as opposed to the D-pad as one button then yeah there are 8 buttons
Can you tell me where to go to research information on "micro PCB circuit boards" to make a micro controller for NES that works on NES original console/hardware. That has a ability to have direction on D-pad and/or buttons A/B to have auto-fire turbo capabilities? All the while working without the need for any external programs running on a PC like Joy2key, Rewasd etc....So basically all the turbo functionality is self-contained within the pad controller itself. Somone said something about altering the shift registers to produce turbo. How do I find info about that? Googling it does not really bring anything up but pre-made third party Turbo controllers and that is not what I am talking about.
So if I have an SNES controller hooked up to an NES, and I want to read the controllers extra 8 bits, I just need to have 2 loops and read the other 8 bits into another memory location, correct?
Conceivably, though I’ve never tried it… I believe the SNES controller just has two shift registers in series to register all 12 bits of button data. Would definitely make for a fun experiment!
That same controller shipped with the NES in Canada as well
Correct me if I'm wrong didn't the famicon have built-in turbo? 🤔
how did the turbo button work on the max/advantage controller?
Hello neshacker do you Know the value in Hertz of the clocksignal?
I know I'm super late to the party but, amazing video - thanks for sharing ! Out of curiosity, some FC controller models appear to have a 15 pin interface, would it possible/feasible to rewrite the controller input pooling routine so it could read a more "modern" controller, with at least L and R? I feel like this could open so many tools for romhacking and modders to add ergonomics into NES games such as zelda1 to swap weapons for example.
Yep totally feasible. The SNES controller is almost exactly the same except it has two shift registers which holds the value for all of its buttons. Basically you can use the controller ports as a general serial port as long as the game is programmed to use it that way.
So was writing code back in those days the same as writing code today ? Besides the new updated stuff that they have added for newer tech, is the basic code writing from today the same as back in those days ?
The communication sounds exactly like an SPI protocol. Assuming the limiting factor is the chip on the controller, It should be easy to replace it with a modern microcontroller with a higher clock frequency to decrease latency and improve response times.
It is similar, but you gotta remember: games execute specific instructions at a particular clock speed, so even if you increased how fast the chip on the controller worked it would take the same amount of time due to game code. Also you can easily handle the reading of all buttons in a fraction of a frame, so even if it were faster there would be no noticeable increase in responsiveness.
The 4021 already works at 1 MHz and more. The whole latch-clockout procedure can be done within 10 uS. There isn't much headroom with this protocol.
Brilliant explanations and video editing 👍
I thought the NES automatically did this and loaded it into memory, that's interesting to know it doesn't. The explanation is really good as well and I understood it without prior assembly knowledge. It's really cool to learn the ins and outs of hardware like this, as a single person can actually understand the entire system as it's relatively simple.
It’s kinda cool too, cause you can use the controller ports as a general I/O interface that way. There’s no reason why you’d have to only transmit exactly eight bits.
@@NesHacker If I recall some of the TASbot submissions for GDQ have actually used the control ports for general I/O for things like audio playback through the console.
I’m sure most people know this but opposite directions on the D-pad can’t be pressed at the same time for example the up and down directions can’t be pressed at the same time or the right and left directions can’t be pressed at the same time but up and right or down and right or up and left or down and left can be pressed at the same time
I used to do programming on the Commodore 64 which used 4 position joysticks which like the NES controllers should not be able to press opposite directions at the same time, but I can tell you if you move it around vigorously you may get some from time to time. So best to design the code to handle it cleanly.
@@sa3270 I see
I once had this one NES controller that was a little messed up I was playing SMB1 with it and the “A” and “B” buttons made the game pause instead of the Start button for pausing I don’t have that controller anymore for obvious reasons (it didn’t work properly)
If I can add one tip to this great video: as an electronics hacker myself, TAKE LOTS OF PICTURES as you go. Buttons, pads screws will get knocked over or you will forget where things went. Trust me.
IDK if the pads on the silicone are printed with a pattern or if the pattern is imprinted by repeated uses. I say this because I took apart these controllers as a kid and never noticed a pattern on the pads, and these controllers were new back in 1985. 😜
Yeah I was having a hard time finding solid information on how those switches work. I’ve only ever seen them with the patterns, but like you say it could be due to use. Thanks for the info!
@@NesHacker dude thank *you* for doing these videos. I’d gladly contribute to your patreon account.
NES Hacker, what is your view on starting a ROM Hack by finding the subroutine that reads controller input,
then stepping through the code from the controller read, then trying to understand that code step-by-step from there. i.e. using the controller read as an organic starting point for code investigation.
1.) Finding whatever subroutine loads from $4016 (via searching function list in MESEN)
2.) Set a break point on LDA, $4016
3.) Understand confusing mess of assembly??
Thank you so much for all your great content and amazing videos.
I think that’s okay, but honestly the controller reading code for *most* games probably doesn’t have much to do with the actual game logic. For instance, a game like MegaMan 2 has at least 6 distinct controller contexts: Main menu, Boss Select, Password Select, Main Gameplay, Start Menu, & Game Over. So the controller code is most likely abstracted out away from the logic that handles those different game states as part of a set of general routines that runs every frame.
That said, you can still piggyback off the *result* of the controller code, by this I mean if you can find the memory location where the controller buttons are stored, you can use it to find code that reads and reacts to that code. By combining this with other memory locations you can setup breakpoints that can pinpoint the exact location for code that handles various things (e.g. handling of the D-PAD buttons on the boss select or the code that initiates a jump for MegaMan himself, etc.).
@@NesHacker Thanks so much for the detailed reply!!
Something I found really strange is that some official NES controllers are not cross-compatible in different regions.
I believe the 101E models will only work on PAL system while the normal 101 will work on either.
I'm also curious about something.
You say the controller can receive inputs from the NES. I was wondering to what extent this could be used.
Like, let's say we had a theoretical NES controller with a little LCD display ala the Dreamcast.
Would it then be possible to send picture information to this little display while you play if the controller had some ram onboard to handle it?
Yeah, so there are apparently PAL consoles included diodes on the controller ports, which require the controller itself to pull the clock and latch signals high in order to operate correctly. The PAL version of the NES-004 has a 3.6K Ohm resistor pulling both lines up to high voltage. As for using the ports for external communication, I’m pretty sure this is possible (from what I’ve read) but I haven’t tried it myself. Might make for an interesting experiment to document in a video :)
Is there a 001 NES controller or a 002 NES controller or a 003 NES controller or did they just start at 004?
@@klh. gotcha
It sounds like the longer route on how Modems work. Encode data into signals and have them converted back into readable data on the other side in the console.
This kinda explained me how they could send all eight buttons through mere 3 data + 2 electricity cables, unlike other contemporary consoles with cables that weighted more than the controller itself!
And the blacked out graphite pads above the main buttons pads on the PCB are just resistors??
Yeah pretty sure they are, I was reading around 50k Ohm with my multimeter when I tested across them (though that’s probably a bit high since there is probably some amount of corrosion on the test points and pins I was using as contact points). Also one side is connected to high voltage and the other connects to the button switch / pin trace, so the only thing they could really be is the pull-up resistors for the button switch circuits.
@@NesHacker And me thinking they were left overs from the 2nd player or japanese FamiCom controller PCB designs and that I should scratch and tap to see what they do, haha! Now I see it's a terrible idea...
Will you point out the differences and mechanics on the FamiCom controllers in a future video? They seem a bit smarter than American ones.
Really interesting video,
But what about the snes, or n 64 controller ?
Do they work the same ?
Where can I find your 6502 assembler course? Amazing information! You are an incredible teacher and communicator. Thank you!
That was fantastic, well done
But how does the NES handle multiple controllers? Are there actually four bytes (32 bits) of controller data to handle four controllers?
For two controllers you can read the 2nd player joypad from $4017 instead of $4016. In the case of the "Four Score" (4 player adapter for the NES) controllers 1 & 3 are read back-to-back from the the first port, and controllers 2 & 4 are read back to back from the second port. So yes, there are 32 bits of button data: 16 bits from port 1, and 16 from port 2. Good deduction :)
@@NesHacker @NesHacker Thanks. Back-to-back, eh? Meaning every even and odd clock cycle, respectively? That is an intriguing strategy and has me wondering if the only limit on the number of controllers would be the clock speed of the 4021 chip? 🤔
Thank you for sharing your brain. I admire your knowledge on this subject. I wish I would have taken the same path.
Great visuals. 🙂
Reminds me a lot of the microcontroller assignments I did in college.
0:36 he showed the original grey gun as opposed to the second edition orange gun
Excelente video!!!! 10/10!
0:38 I have both of those in front of me as I'm watching this lol, even the same color Zapper
Very very cool!
are the buttons debounced?
No 🤣
16:11 like why is there a dollar sign next to the “20” I’m pretty sure we are not talking about twenty dollars here so why the dollar sign?
If I'm not wrong, the dollar sign just means a memory address
@@ricoh9379 I see
The dollar sign is the conventional notation for hexadecimal in 6502 programming. It could have been written as rol $20 or rol 32 and it would mean the same thing.
@@sa3270 I see
You for get to mention that the nes cannot read and process a controller input signal along with a dpcm sound signal atonce,that’s because they share and use both the same pin,most early nes games had no dpcm audio,trough,nes games that did supported dpcm audio, solved that problem by comparing button presses with it’s own interprationss(because the nes always assumes that a button was pressed),and if they match the button presses will be considered as legit,if it finds no match,it rejects it,another option would be to disable dpcm playback during button presses,or it could ignoire button presses during during dpcm playback during button presses(wich could be ideal during cut scenes when theres no game play)
Supermario 3 for instance uses an comparision algorithm and surprisingly enough theres no input delay at all,or atleast it’s unoticible for us(alltrough i do hear story’s about speedrunners complaining that the duck jump doesn’t alway’s get’s registred), well i would be not surprised if supermariobros 1 plays just slightly smoother because of not using the dpcm channel at all,
Not this issue has been solved on pal nes systems,but i don’t think that pal games were adjusted with this fix in mind,maybe some pal games?? (Wich may explain why they could behave strange on a ntsc nes because of this aside from timing issues??? ) but not sure, but it’s interesting to examin that.
this is helpful thanks
11:03 the number 4016 was another fleet number in our old streetcar fleet in Toronto where I live
I can't believe that the controller's "brain" is just a shift register. I was expecting something more complicated like the PSX controller. I guess I shouldn't be that surprised.
Guess how many ICs were in an Atari 2600 joystick.
@@sa3270 Zero, I'd guess. 4 Pins for direction, 1 for the button and just simple switches on all of them.
The most rage proof controller known to man
Truth.
7:15 that number 4021 in Toronto Canada where I live in our old streetcar fleet (which is now retired we have new streetcars now) but one of the streetcars in our old now retired fleet one of those old streetcars had the fleet number 4021
13:11 there it is LSR not shift and INVERT. it wont invert value its allready 1 if button was pressed. your graph show it invert, bcoz u thing controlled do what you say, but looking 4021 chip its doing opposite with those pullup resistors and input are inverted button press is 1. code not invert
why cant we just read $4016 when data is there or there is circuit when read it clock and new serial bit come
and LSR shift right bit 0 move to carry and in not INVERTED
and i was nice i tested it button is 1 i know circuits you not know 6502 LOL
LSR not invert bit its allready 1 when button is pressed. now you know
Quality
Word :D
Why only 13000 views? quality! maybe too detailed? I guess that from your knowledge you get good money for somewhere else so it's all good :D
I'm still super confused about WHY they chose such a complicated serial design, instead of just having 1 pin = 1 button 🤔
Neshacker
i love the channel and production quality.
but the accentuation and pauses on random words makes it hard to follow and sometimes annoying coupled with the abstract words means i loose track of what hes actually saying.
the animations are beautiful and very professional but sometimes they dont really show what hes explaining so end up being more distracting than helpful.
anyway great videos and great series i love to learn more about all these details.
Open and explore a sega Saturn mission stick
Commenting to boost. I haven’t even watched the video yet
Thanks
Am I listening to the good version of Agent Smith from the Matrix?
The zapper gun isn’t weird but the Power Glove sure is but the Power Glove is more just garbage than it is weird💯💀
Haha, super true, I could never get it to do anything when I was a kid
11:16 I never understood why when talking about numbers like these they have dollar signs we’re not talking about money here like next to where it says “4016” it has a dollar sign and I’m pretty sure we are not talking about four thousand and sixteen dollars here so why the dollar sign?
The ‘$’ denotes that the number is in hexadecimal.
@@NesHacker I see that sign looks a lot like a dollar sign
@@michaelsegal3558That’s because it is a dollar sign.
I love the content, just watch your cadence, it sounds (tonally) like you are repeating the same sentence over and over again and makes you sound like a bit of a robot lol
Yeah my cadence can get somewhat repetitive, I think it gets better over time, though.
@@NesHacker I am really interested in what you have to say, this breakdown of electronics and circuits could keep me watching forever :D
wow
🥰
🤭
I never even considered that there might be people who did not just intuitively understanding precisely how they were put together and function both from a hardware and software perspective.
common Sense really
Ñpñ
Why do games have to go and ask the controller what buttons are being pressed? Why doesn’t the NES do it itself and tell the game?
I think it is to allow for more complex controllers or specific ones for games. The controller ports are basically just serial ports so it wouldn’t even have to be a controller plugged in.
@@NesHacker cool thanks for the comment
The NES doesn't have an operating system, (or rather the game on the cartridge is the OS) and there's no hardware in it to scan the controller regularly as that would cost more money to add. Leaving it up to the game code is the simpler option, and it doesn't take up enough time or code space to be worth doing differently.
@@gdclemo thanks!
Loved the video, but hate when people ask me to like it before I even watch it...
Yeah a lot of people get *really* angry for call-outs like that. It’s a method that is often espoused by “insiders” and the like when you google stuff like “increase subscribers”, etc. I tried it out, but honestly, I can take it or leave it. Decided to simply ask at the end of the next video. The biggest problem is this, though: people who would indeed have liked or subscribed often forget to do so without call outs. So I’m kinda stuck, right? More subs and likes are good, but pissing people off is bad.
You push a BUTTON and it RESPONDS - There I saved some time for a lot of PEOPLE.... Actually - It is quite interesting how early and then later controllers worked...
don't remind me to sub amd like, otherwise I don't.
Don't forget to ring the bell.
Please stop doing that with your voice.
Why do people do that “up-down-up-down” talking thing when they read stuff in front of a camera? Just say the things 😂 no need to bash us over the head with weird inflections. I swear that social media has changed the way people present information for the worse lol
Reading something “normally” is much harder than you’d expect. If you watch across multiple videos you can see my voice pattern changes quite a bit, and more recently I’ve tried my best to get away from that particular pattern. That said, it’s still rough… especially when everything is completely scripted.
Blah blah blah... Why are the a and b buttons not in alphabetical order?